E-mail List Archives
Re: Accessible automated tools
From: Birkir R. Gunnarsson
Date: Jun 5, 2019 5:04AM
- Next message: Birkir R. Gunnarsson: "Re: WCAG 2.0 level AA and the combination between screen readers and browsers compatibility"
- Previous message: Mallory: "Re: Calendar VS Table Navigation"
- Next message in Thread: Scott Tate: "Re: Accessible automated tools"
- Previous message in Thread: Steve Green: "Re: Accessible automated tools"
- View all messages in this Thread
For using automated accessibility tols with a screen reader, check out
http://www.bats.fyi
For automated tools, Axe from Deque and Wave from WebAIM are the most
widely used tools, both are reliable, I've used both extensively.
Axe is open source, used by Google and Microsoft, reliable for
automated scans and comes in various forms including browser add-ons
and command line.
The newly released Arc inspector tool from the Paciello Group looks
promising and is picking up some subtle accessibility problems. I have
yet to do a deeper dive on it but I am interested in exploring it
further.
The web accessibility practitioner survey has a table of the most
widely used tools:
https://webaim.org/projects/practitionersurvey2/
For manual inspection we rely on a selection of bookmarklets to
visualize information such a screen reader markup.
We like ANDI (accessible name and description inspector), not its
automated test warnings but its ability to visualize accessible name,
description, headings, tables etc.
Blind testers can do this with a screen reader but sighted testers
need something simple and ANDI is a good fit.
We use a handful of other bookmarklets, but it'd get too long to list them.
We also roll some of our own and are experimenting with writing custom
tests and bookmarklets.
On 6/3/19, Steve Green < <EMAIL REMOVED> > wrote:
> We used to use Paciello's Accessibility Toolbar a lot, but now I only use it
> for the Images List feature and the colour contrast analyser. Almost all our
> testing is done by inspection of the user interface or by using browser
> developer tools to inspect the code. My understanding is that browser
> developer tools are pretty much accessible.
>
> Apart from that, we use a handful of bookmarklets to improve the efficiency
> of the testing, although the pass / fail decision is always made by a
> person, not the tool. Some of these will be accessible, such as the one we
> use to check the text spacing (SC 1.4.12). Others will be inaccessible, such
> as the one that uses coloured rectangles to show all the landmarks on a
> page. The user experience of all these is good, which is not surprising
> because they are all single-purpose tools.
>
> We rarely use automated tools, and it is invariably a painful experience
> when we do. Much of the time is spent trying to work out what the tool is
> doing and why it is not giving the results we would expect, even after
> taking into account what a tool can and cannot do in principle.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
>
>
- Next message: Birkir R. Gunnarsson: "Re: WCAG 2.0 level AA and the combination between screen readers and browsers compatibility"
- Previous message: Mallory: "Re: Calendar VS Table Navigation"
- Next message in Thread: Scott Tate: "Re: Accessible automated tools"
- Previous message in Thread: Steve Green: "Re: Accessible automated tools"
- View all messages in this Thread