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.

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Mallory van Achterberg
Sent: Thursday, September 04, 2014 12:53 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Keyboard navigation using arrows only

On Wed, Sep 03, 2014 at 04:07:40PM -0700, Bryan Garaventa wrote:
> I understand your points, and those documenting the standards are aware of and do understand this problem as well, which isn't helped by the proliferation of outdated, half-correct, and incorrect data distributed across the web regarding ARIA that is publically accessible for all developers.
>
> If I may ask, did reading the training guide at
> http://whatsock.com/training/ help at all? A little bit?

This is what a developer does:
1. has an existing problem/set of code or needs to build it 2. wants it to be accessible without breaking things for other users 3. reads all demos with these particular examples in mind

So every single example that any website anywhere gives, the developer is reading those while thinking of the specific case in mind. Whenever anything it quite different from the example, the developer starts to make guesses, at least until they truly have understanding of the specs or the technology.

I've seen more and more articles stating that it's "more intuitive" for users if basic web interactive things "act like the desktop". Whose desktop? Windows? And what about where the web has done it differently and users who've used the web for the last 10 years and have been trained very well by every website how to get from area to area? DO we pull the rug out from under them?

I'm a keyboarder, and I tab (except when using Presto), because tab works.
It moves me to the next focusable thing without selecting it. Shift-tab brings me back. The few few few exceptions are some form controls. Also the web has had the very bad habit of styling buttons like links and links like buttons, meaning lots of users like me tend to start out assuming it's a link until proven otherwise. This means we use arrow keys to scroll the web page.
It means we tend to assume the buttony thingie will act like a link. It means we don't try arrow keys and spacebars on these things (and we don't all have a handy screen reader to tell us that that thing that looks like a button actually *is* a button). When we devs keep in mind that the user might have a screen reader or screen magnifier, we also need to remember we have users who don't have these things.

Whenever there's an aria-something demo that suddenly starts using arrow keys for visible, looks-like-they-can-be-focussed areas, that's pulling the rug right out from under the sighted keyboarder. Is this so a screen reader user can feel as if the webpage is a Windows application? Is this right?

The whatsock "menu" has form controls in it. The spec for the menuroles stuff mentions controls a lot, talks about managing focus to the first control.
This is *atypical* for menus on the web. They don't tend to have form controls. They don't tend to be applications. Most of the time, they're navigation, and traditional navigation has been tabbable, and spacebar has not "activated" anything traditionally. Spacebars are for buttons, radios, checkboxes, but why would we think to use it on a menu? How would the sighted user know there's a submenu if it doesn't appear on :focus? Why would we think to hit space on something that has been, everywhere on the web, a link?
And what happens when you hit enter on a link? Why, you go to the resource.
So whether you click/hit enter on the link is going to be completely based on whether you think you want to follow that link. Plus, as a developer you've had "progressive enhancement" and "graceful degredation" harped on you like in a church since way back when, so your menu links *should* have a destination, because what if the user couldn't get the submenu to appear?

The fact that sites out there not implementing all the aria stuff acts one way, and sites who do act a completely different way, means as a user I'm ready to throw my computer out the window. As a dev, it means I'm *very* reluctant to change web convention when I build something that's not some totally-new widget (which I see aria as addressing best most of the time, as these are indeed mostly taken from desktoppy applications and do not have good HTML bases or semantics or default "web" behaviours users have been trained to expect).

and...
The tab-panel example frustrated me because of course the one I was told to build had to be quite different from teh whatsock version, meaning I can't translate it enough to know if it's of any use to all users.

(more below)

> -----Original Message-----
> From: <EMAIL REMOVED>
> [mailto: <EMAIL REMOVED> ] On Behalf Of Michael
> Tangen
> Sent: Wednesday, September 03, 2014 2:04 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Keyboard navigation using arrows only
>
> A lot of us web developers are *trying hard* to be compliant, but let's be honest — those documenting ARIA standards for web developers are not doing us any favors, those of us who don't work with system properties and operating system level environments. Most web developers work with HTML and Javascript, or perhaps CSS — we're largely familiar with those sorts of things.

When I first ran across the whatsock pages, I really liked how it showed how events propogated down to a (one particular) OS level. It meshed well with the things the Mozilla developers have been discussing in bugs for a while. It seemed a bit academic, but it also pushed really well the idea that when you screw aria up as a developer, you could really be kicking your user in the gut.

> If those documenting ARIA standards could translate those standards for web professionals in terminology and contexts we understand and work with, then I think we'd be a lot further along in building menus that were much more accessible.
>
Mostly, demos are good enough. The problem comes in when your thingie is not set up like, and does not work like, the demo. When a dev completely understands the technology, the dev can make the correct decision and think for themselves and generally get it right.
But some of this stuff, when it talks about "manage focus" and all you have is a bunch of text for example, means we're still very dependent on many different demos showing different examples.

It's similar for Javascript, the demo is king, so as many demos as needed for the variety of situations is probably what we'd want best, and currently there are a few aria-y implementations of things but not so much variety.
How about tab panel where the first tab is selected by default, is labelled "ALL" and shows all the panels at once? Only the other panels do the radio-button-style behaviour. How should we map that first tab?
Should it be mapped to the panel container?? (that's what I tried at first) etc.

_mallory