WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible automated tools

for

From: Amber James
Date: Jun 5, 2019 2:06PM

Hi all,

In addition to the great automated testing tools already mentioned (Axe,
Wave, bookmarklets), I use the Hemingway Editor
<http://www.hemingwayapp.com/>; to check the grade level and complexity of
copy on a sentence level. I come to accessibility by way of content
strategy and copywriting, so I always have my eyes on the words. If anyone
has questions about that, lmk.

Cheers,
Amber James
Accessibility Consultant
U.S. Bank
https://www.linkedin.com/in/amberajames/



On Wed, Jun 5, 2019 at 1:00 PM < <EMAIL REMOVED> > wrote:

> Send WebAIM-Forum mailing list submissions to
> <EMAIL REMOVED>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.webaim.org/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> <EMAIL REMOVED>
>
> You can reach the person managing the list at
> <EMAIL REMOVED>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Re: Accessible automated tools (Birkir R. Gunnarsson)
> 2. Re: WCAG 2.0 level AA and the combination between screen
> readers and browsers compatibility (Birkir R. Gunnarsson)
> 3. Screen readers that DISPLAY what they see (Haim Roman)
> 4. Re: Screen readers that DISPLAY what they see
> (Farough, David (CFP/PSC))
> 5. Upcoming free webinars on accessibility (Marissa Sapega)
> 6. Fill in the Blanks Form Implementation (Tiller, Mary)
>
>
>
> ---------- Forwarded message ----------
> From: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Cc:
> Bcc:
> Date: Wed, 5 Jun 2019 07:04:11 -0400
> Subject: Re: [WebAIM] Accessible automated tools
> 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
> >
> >
> >
> >