Are Keyboard shortcuts mandatory for 508 compliance

Question

I researched a lot on this and seem to be getting conflicting answers on SO and all of the web. I understand that with Section 508 that compliance DOES NOT equal accessibility

Answer 1

I partially agree with thinice, but agree with the first two sentences of the comment left.

The sentences I am referring to are:

They should be -reachable- by keyboard for 508. I'm maintaining emphasis on the difference between a shortcut and being reachable

Crixus said:

Biggest thing is that the UI/UX designer is being told that keyboard shortcuts for the dropdown menu NEEDS to have keyboard shortcuts to be 508 compliant.

You need to clarify this. Do you mean a simple <select> or a drop down for a navigation menu? As Thinice stated in comments, Section 508 just says needs to be reachable. The question becomes:

how are you adding shortcut keys to your application? Are you adding them via the accesskeys attribute or how Gmail/Yahoo Mail adds shortcut keys?

I thought I did an answer about AccessKeys, but cannot find it. Essentially accesskeys sounds like a great thing, but if you look at the keys you are allowed to use that do not interfere with either browser or Assistive Technology keys, you are quite limited. Gez Lemon did an overview of AccessKeys, and their issues. If you want to do the Yahoo!Mail approach, you have to do a bit more work. Todd Kloots made a presentation about ARIA, which may be helpful. Which leads me into the second part. If you are using JavaScript heavily on a site to do stuff, people use both 1194.21 (software application/OS) and 1194.22 (web) standards to evaluate a site. If the site uses JS to make a navmenu (YUI menu example), the drop down behavior needs to be reachable by keyboard. I would say this falls under:

§ 1194.21 Software applications and operating systems.
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

AND

(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.

I say both standards are used because (a) says you have to be able to get into the navigation area via the keyboard. (c) comes into play because some menus you can tab to all of the parent items, but you cannot get into the drop down part without a mouse. I have seen menus that you can tab to the sub-menu items, but the menu does not pop open. So if you just use the keyboard (mobility imparments), versus using JAWS, you will have no idea where you are.

I see Windows Forms applications having this, but for web development I do not think that is mandatory to be "compliant"

I would say actual applications, like Word, Outlook, etc., supply shortcuts to frequently used commands. If you are doing this for a web application, I would think about how many you do. This is not a mandatory piece to be compliant. If you are making like a navigation bar, I would recommend using ARIA roles, specifically role="navigation", on the parent element as a best practise.

Answer 2

There are levels of 508 compliance, if you're talking about a government project. Some departments assign 508 scores to their developers, and it factors into your score for future contracts. 508 Compliance only requires that everything is reachable by keyboard, which is usually true, in a way. Screen readers will read everything that's not hidden, and tab keys will take people through links. But if you want a good score, you must address the intent and not only the letter of the law.

Edit: Screen readers will read some hidden elements. One method is to absolutely position an item above the screen with a negative top position. Another is to use the clip property. http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content/ But if you're using display:none, heights of zero, and javascript toggles, many screen readers will not speak these items.

In the case of a drop-down, you are actively hiding elements from screen readers etc, so you do have to fix it, because most readers won't hear things with display:none.

You will not find definitive documentation on keyboard navigation. The reason no one will specify exactly what to do, is that there are so many potential conflicts - with the browser, the OS, etc. There are also no standards, although Aria is making progress: http://www.w3.org/TR/wai-aria-practices/#keyboard

I would not put accessKeys on a menu, if that's what you meant.
Instead see: http://www.w3.org/TR/wai-aria-practices/#aria_ex_widget

I would save actual accessKeys for major things like 'Search' and 'Home'. Adding a learning curve to your site wouldn't help the cause, if you had an accessKey for everything. If you put for example, "About Us" accessKey=A, and you had 20 accessKeys assigned to letters, it would be bad.

I've been doing 508 sites for a long time, and personally, I just don't use drop-downs. It's far simpler to add subpage menus. And I personally hate clicking on dropdowns. Dropdowns require a precision in clicking that just irritates me, and doesn't help with accessibility, because remember accessibility also includes people who don't click very well. Plus, dropdowns are limited in the number of levels you can have, not technically but from a UX view.

What I use:

• Tab indexes.
• Carefully placed menus so that a user won't get a huge list of links before hearing the basic idea of the site or page.
• On some projects, tree menus with matching arrow-key page navigation, sequentially.
• Accesskeys H for home and S for search, if needed.

The problem especially is in sorting information. Think how quickly you scan a long list of links, and then imagine sitting there and waiting for it to be read to you. Perhaps, organize your content into digestible pieces & let the search box do the scanning. Depends on the content.

Luck. :)

Answer 3

The problem with some standards (as well as many laws) are that they're open to interpretation...

The only mention I can find in the 508 standards that mentions keyboard use is this (verbatim):

Subpart B -- Technical Standards

§ 1194.21 Software applications and operating systems.

(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.

My spin on this is:

• A keyboard shortcut for navigation options may be impractical given the amount of operations/features a given section may contain. It is important that they're reachable -somehow- via keyboard.
• From a UX standpoint, key features should have shortcuts "just because" it's good UX practice. But to shortcut everything goes from one ditch into the other.
• 508 != accessibility, but if you work for a gov/edu, chances are it's in your PD to be compliant.

Another end of the spectrum is the WCAG which is pretty much coupled with 508 compliance, and in my book better defined: Keyboard stuff is under 'operable' in WCAG.

In a nutshell: It's good practice for UX to have custom keyboard shortcuts for important features. But has no bearing on 508 compliance by itself. (With exception that functionality should be reachable by keyboard -somehow-).