WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: testing for keyboard accessibility

for

From: Tim Harshbarger
Date: Sep 24, 2012 2:52PM

Those are definitely excellent points.

I guess what I was trying to get across is that, if you are documenting accessibility items in your design specifications, you may be able to automate some testing. While you can't automate a test for whether or not an alt attribute is meaningful, you could automate a test to determine if logo.gif has the alt text of "Home" when it is used as a link if that is what you designate in your design specifications.

Technically, the test wouldn't validate whether or not the item conformed to SC 1.1.1. However, if you validate that in the QC for your design specifications, then you can verify that the application conforms to your design spec which conforms to whatever standard you are using.

It isn't the same as being able to feed a tool an URL and get a report, but it is a way to potentially automate testing to a greater degree. Consider it sort of a test driven development approach to accessibility--for what it is worth.



-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Bryan Garaventa
Sent: Monday, September 24, 2012 12:09 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] testing for keyboard accessibility

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.

E.G

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
keyboard.

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
http://lnkd.in/jYnkZq
if it helps.

----- Original Message -----
From: "Tim Harshbarger" < <EMAIL REMOVED> >
To: < <EMAIL REMOVED> >; "WebAIM Discussion List"
< <EMAIL REMOVED> >
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-----
> From: <EMAIL REMOVED>
> [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
> > > > > >