Posted by NonProfit on June 12, 2018 at 4:58pm
Hi, can anyone suggest resources of where to look on how to implement keyboard navigation? Certainly this must exist, but I've, as yet, been unsuccessful locating a tutorial. Thanks.
Keyboard Navigation
Group organizers
Hot content this week
-
12 hours 31 min ago
-
7 years 10 weeks ago
-
15 years 39 weeks ago
-
16 years 41 weeks ago
-
6 years 11 weeks ago
Comments
I like using the WAI-ARIA:
I like using the WAI-ARIA: Authoring Practices Guide examples to make sure that each component I'm using has the recommended keyboard controls.
Thank you!
Thank you!
I've not seen such a thing.
I've not seen such a thing. Granted, I've not looked for it. It may be something that would have to be created. It wouldn't seem real difficult, in concept. The biggest problem with such a thing would be, considering that there isn't really a "standard" menu (Sure, most everybody uses "Home", and "About/About Us" and "Contact", but... not everybody. And there are certainly enough others different that some use and most do not, so, presuming you're intending this for the visually impaired, the questions that come to me immediately are,
1) How would you inform the user what your particular menu is? Being, as you've said, quite a "specialty" thing, you would have to let them know just as example, (H) is Home and (A) is About Us and (C) is Contact and (S) is Services, etc. etc. etc. however, any way that I can think of to address my question (i.e. Screen reader) would seem to also have already addressed the issue giving call for a specialized keyboard navigation, as the Screen Reader would already be handling that. Which leads to the next question
2) If you're doing this for the Visually impaired, would these keyboard shortcuts interfere with the existing keys used for their screen reader or other accessibility tools/devices?
3) Considering the above, I have to question if there would really be need for such. I'm far from an expert on the subject, but these are my initial thoughts.
keyboard navigation vs keyboard shortcuts
Thanks for posting. NonProfit already said this wasn't what they had in mind, but you make some good points which are worth looking at.
What you've described are character key shortcuts, which are different from keyboard navigation.
Basic keyboard navigation involves operating interactive content with a minimal set of standard keys. At the simplest level, you use TAB to move between controls in order, and space/enter to activate it. A few more keys are used for going backwards (shift+tab), and picking options (arrows). Web browsers provide basic keyboard navigation for standard HTML controls. Users can operate web pages with a typical keyboard, and lots of alternative input devices can be configured to emulate keypresses.
Developers can provide keyboard navigation for custom controls using JavaScript. The best practice is to keep it similar to the native behaviour of HTML elements (and/or controls on the desktop operating system), using just the tab,space,enter, shift,escape, and arrow keys. I expect this is probably what the original question from NonProfit was about.
Character key shortcuts, like you've described, are seldom recommended by accessibility specialists today. You've already mentioned their main problem: since they can match any key to any control, how would a user discover them? Another problem is poor implementation where a website has the same key assigned to two controls.
Various organizations (government, higher education, etc.) have attempted to standardize character key shortcuts, in styleguides or national standards. For example, the UK PAS78 standard (now outdated) recommended the numbers 0 to 9 for the same links across government websites. It's not clear how effective this was; it seems to have been more useful to government staff (using their own sites every day) than to members of the public (as occasional visitors). You still occasionally find accessibility help assigned to the 0 key.
(Update: I'm probably wrong about that being specified in PAS78, as I can't find it now. It was possibly a different UK government document that called for them.)
A few browser add-ons can tell a user about any controls with HTML accesskey attributes for the page, but browsers don't do this themselves.
It depends how you implement them. Using the HTML
accesskeyattribute is fairly safe - this doesn't interfere with screen readers normal behaviour. Screen reader users can still use an accesskey if they know about it, though it can be fiddly.But if you implement them with JS and don't require modifier keys (e.g. like Twitter or GitHub), then they can be a problem for some speech control users. The new WCAG 2.1 success criterion 2.1.4 Character Key Shortcuts addresses this problem. For an example, this video shows a user accidentally triggering Twitter's direct message feature by picking up the "M" in "James".
UK Government Access Key System
I found it! I was thinking of the UK Government Access Key System, which dates from 2002.
The document does attempt to address the discoverability problem:
So this link for accesskey help could come early in the page, say just after the skip-link.
BEGRAFX, thanks for your
BEGRAFX, thanks for your reply. What I was envisioning (which may or may not be the ideal approach) was a way to navigate to all elements which can be interacted with using only the keyboard, which I assumed would be the tab key. Ideally, repeatedly pressing the key would grant access to not only menu items but inline links, images which expand on click, video content, etc.
This would benefit visually impaired users but they are not the only beneficiaries. Consider someone who has mobility issues. If grasping a mouse or using a trackpad is difficult due to a bandaged finger, keyboard navigation would be a great help.
What is the accepted standard? https://www.w3.org/WAI/ is the closest I've found to what I'm striving for. It works somewhat for me in Chrome, although I'm experiencing difficulty with Firefox and Safari. And all mobile viewports feel troublesome.
Keyboard Controls
The type of thing you describe is already part of a screen reader. I have a visually impaired friend who uses a package called JAWS, and that software allows him to do the sort of thing you describe. I'm not well versed on the subject, but I would presume this to be the case with most all packages of this sort.
MDN is starting to get some
MDN is starting to get some good accessibility resources. In your case, check out https://developer.mozilla.org/en-US/docs/Web/Accessibility/Keyboard-navi...
Thank you!
Thank you!
For native HTML elements
For native HTML elements (links, form controls) you don't need to implement anything for keyboard accessibility. Even generic
<button>elements just need a click handle for custom behaviour, and the browser knows that focused buttons are activated with space/enter keys. It's more the case that you need to take care not to break what the browser has already provided.For custom controls, the WAI-ARIA Authoring Practices, and MDN article already mentioned are good starting points.
I also recommend...
Some other tips from me...
Pay attention to focus styles, which keyboard users absolutely rely on. The default focus styles from web browsers are often poor when combined with a website's custom style sheet. For example Chrome's blue outline performs badly on a site with a blue page background (e.g. the menu, header or footer). They can also be hard to see when your buttons have a blue background. Read about WCAG Focus visible and Non-text contrast.
Other problems occur with some parts of a focus outline being "chopped off" by some positioning and box-sizing issues, like this screenshot from Drupal 8 Umami profile. It shows a focused link in a navigation menu. A dotted outline is seen on the left, right and bottom, but it's missing from the top of the link. Something to do with the box dimensions of the list elements.
https://www.drupal.org/files/issues/2018-05-17/05-current-focus-state.png
Avoid positive numbers in the tabindex attribute. This can really confound a user. For example, the Headingley Enterprise and Arts Centre site uses positive tabindex on form controls in the page footer. Users have to tab through a form before they can reach the main navigation. Don't do this, it causes a confusing page jump and causes the user too much work. Read about WCAG Focus order.
Avoid using CSS (e.g. flexbox) to position elements in a way that makes the tabbing order different from the reading order.
Think about focus order for the page as a whole, as well as just for a particular component. In particular, address WCAG Bypass blocks. I recommend using ARIA landmark regions (for assistive tech users) AND a skip-to-main content link (for sighted keyboard users, without assitive tech). Drupal 8's core templates do this well already.
WCAG No keyboard trap is a crucial thing to address. In the worst cases, a user's only recourse is to reboot their device (drastic), or ask someone else to use a mouse to click outside a component on their behalf (socially awkward, and doesn't work if you're alone).
It's important to to test that you can get everywhere on the page, tabbing from the start all the way to the end, without finding a keyboard trap.
Also, if a custom component can be "entered" in some way, it can also be dismissed or exited too. Date pickers, tab sets, and overlay windows are examples of components which should be tested for this. Flash video players used to be notorious for keyboard traps.
As an example, we accidentally introduced a keyboard trap into Drupal's vertical tabs. When a user reached the vertical tabs, they got stick at the first tab header, and could not move anywhere else. I fixed it just before D8.0.0 was released.
HTML title attributes don't work for keyboard users. If tooltips are important for you, implement your own with CSS/JS. The ARIA authoring practices have examples.