WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: testing for keyboard accessibility


From: Bryan Garaventa
Date: Sep 24, 2012 11:08AM

It's important to note that screen reader accessibility is not the same
thing as keyboard accessibility, and it's possible to have one and not the
other, which would make it inaccessible regardless.


With the below referenced span tag, without tabindex=0, it won't be keyboard
accessible, and without a keyDown handler, it won't be actionable from the

Also, without a click handler, it won't be accessible for screen reader
users via JAWS for example, and without role=link to indicate an accessible
role for the object, it won't be recognizable as an actionable element for
screen reader users either.

All of these pieces need to come together in order to ensure full
accessibility, and there really isn't a way to automate everything.

I wrote an article about this not too long ago with a similar example at
if it helps.

----- Original Message -----
From: "Tim Harshbarger" < <EMAIL REMOVED> >
To: < <EMAIL REMOVED> >; "WebAIM Discussion List"
Sent: Monday, September 24, 2012 8:03 AM
Subject: Re: [WebAIM] testing for keyboard accessibility

> <span id="SCDDmwsp">Home</span>
> Like others have said...there probably isn't a fool-proof way for an
> automated tool to determine that the above is an interactive widget and
> exactly what keystrokes need to be used.
> However, you might be able to devise automated tests that verify that a
> drop down menu that was included in the design specs is present and works
> like the design specs say it should.
> So you might be able to automate testing that way. Of course, it does
> mean that accessibility needs to be considered during design and
> documented well enough to create tests.
> -----Original Message-----
> [mailto: <EMAIL REMOVED> ] On Behalf Of Howard Kramer
> Sent: Friday, September 21, 2012 2:58 PM
> To: WebAIM Discussion List
> Subject: [WebAIM] testing for keyboard accessibility
> Does anyone have suggestions for testing web keyboard accessibility.
> Achecker seems to catch certain types of scripts that restrict access to
> mouse actions but it doesn't seem to catch everything. The functional
> accessibility evaluator seems to also sometimes catch this. Manual tabbing
> through a site and testing if a menu item responds to the enter key seems
> more reliable. Any suggestions on this is appreciated.
> Thanks,
> Howard
> --
> Howard Kramer
> AHG Conference Coordinator
> Access Specialist
> 303-492-8672
> > > > > >