WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Keyboard navigation using arrows only

for

From: Bryan Garaventa
Date: Sep 4, 2014 2:42AM

I understand all of your points, but most of these come down to education.

If a developer understands how ARIA works at the platform level including the Accessibility Tree, then it is easier to diagnose focus issues when they aren't being set to valid roles, how to recognize which attributes to use and when, how to test for these, and how these behaviors manifest in Assistive Technologies.

I have never claimed that all widgets are the same or that they should all use the same markup. What I have said, is that all widgets should be accessible from the keyboard, and that if ARIA is used as part of interactive widgets, that the roles need to match the paradigm for that widget.

ARIA is not platform specific, so to answer your question about which platform is valid, the answer is that the ARIA platform UI equivalent for a particular interactive widget is programmed by the user agent and Assistive Technology to match the platform UI equivalent on the OS that you are using at the time.

This is why you will get different feedback if you view the same control on Windows versus iOS on an iPhone or iPad, even though the markup is the same.

If you don't want to use ARIA, that is your choice, but choosing not to understand how it works is a different matter, and this limits your options. For example, if you want a Slider control to work properly using a drag and drop control with plain HTML and JavaScript, you must use ARIA to provide the correct feedback for screen reader users, otherwise this will not be accessible.

Education is important for screen reader users as well, and there should be more effort in this regard as part of this process as general usability training to understand how ARIA in particular is interacted with and what to expect.

I'm not sure what you mean that the ARIA Menus have form controls in them, these are triggered by a button which sets focus to an A tag that includes role=menuitem amongst all of the other requisite attributes, but there are no form controls within the menus. The Application role ensures that the correct modality will be enforced when JAWS is set within the menu after it opens, which is unreliable otherwise. The menus are programmed to act in the same manner as a standard context menu when you right click the web page, and the arrow keys are used to open or close submenus, not the Spacebar.

This is what I mean by education. If developers are aware of how such roles interact with the primary Assistive Technologies, and can thereby recognize when they are not being used correctly, it is then possible for them to modify the code accordingly in order to make these work. If developers have to guess all the time as you said, this will never work.

Additionally, when interactive widgets are programmed correctly and are verified by developers who understand these behaviors, then users have a responsibility to learn how these technologies are supposed to work, because these behaviors are not just the result of the developer, but are also programmed into the browser, and the Assistive Technology, in order to make them as accessible as possible within that platform. This is why ARIA exists. It is not just to make people's lives more difficult.