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)

>