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 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.

0 讨论(0)

查看其它3个回答

发布评论: