WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Keyboard navigation using arrows only

for

From: Mallory van Achterberg
Date: Sep 4, 2014 1:52AM

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