WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: testing for keyboard accessibility

for

Number of posts in this thread: 7 (In chronological order)

From: Howard Kramer
Date: Fri, Sep 21 2012 1:57PM
Subject: testing for keyboard accessibility
No previous message | Next message →

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

From: Jared Smith
Date: Fri, Sep 21 2012 2:09PM
Subject: Re: testing for keyboard accessibility
← Previous message | Next message →

It's very difficult to test keyboard accessibility in an automated
way. Automated tools can detect markup or patterns that *might* result
in keyboard issues (such as elements with mouse dependent event
handlers, or non-focusable elements that have event handlers), but to
truly ensure keyboard accessibility you need to use an actual
keyboard. Fortunately this is pretty easy to test.

Jared

From: Howard Kramer
Date: Fri, Sep 21 2012 2:27PM
Subject: Re: testing for keyboard accessibility
← Previous message | Next message →

Thanks Jared.

-Howard

On Fri, Sep 21, 2012 at 2:09 PM, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:

> It's very difficult to test keyboard accessibility in an automated
> way. Automated tools can detect markup or patterns that *might* result
> in keyboard issues (such as elements with mouse dependent event
> handlers, or non-focusable elements that have event handlers), but to
> truly ensure keyboard accessibility you need to use an actual
> keyboard. Fortunately this is pretty easy to test.
>
> Jared
> > > >



--
Howard Kramer
AHG Conference Coordinator
Access Specialist
303-492-8672
fax: 492-5601
Disability Services
Division of ODECE- achieving excellence through diversity and inclusion

From: Glenda Sims
Date: Sun, Sep 23 2012 8:42AM
Subject: Re: testing for keyboard accessibility
← Previous message | Next message →

Howard,

I totally agree with Jared on this. I think to comprehensively test for
web keyboard accessibility you need to use your keyboard.

Glenda


From: Howard Kramer < = EMAIL ADDRESS REMOVED = >
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Cc:
Date: Fri, 21 Sep 2012 13:57:38 -0600
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

--
glenda sims | deque.com | 512.963.3773

*web for everyone. web on everything.* - w3 goals

From: Tim Harshbarger
Date: Mon, Sep 24 2012 9:03AM
Subject: Re: testing for keyboard accessibility
← Previous message | Next message →

<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 ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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

From: Bryan Garaventa
Date: Mon, Sep 24 2012 11:08AM
Subject: Re: testing for keyboard accessibility
← Previous message | Next message →

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 ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
< = EMAIL ADDRESS 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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
> > > > > >

From: Tim Harshbarger
Date: Mon, Sep 24 2012 2:52PM
Subject: Re: testing for keyboard accessibility
← Previous message | No next message

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 ADDRESS REMOVED = [mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"
< = EMAIL ADDRESS 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS 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
> > > > > >