WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible automated tools

for

From: Birkir R. Gunnarsson
Date: Jun 5, 2019 3:29PM

Good recommendation.
Sadly WCAG relegates clear language requirements mostly to AAA (best
practice) success criteria, but clear language benefits everybody.
It's especially important when working in banking, insurance or
similar not to get too tangled up in the abbreviations and complex
terms and language that people who are professionals hear and use as
part of their jobs every day. When they write they sometimes forget
that the clients are not financial professionals, not most of them
anyway.

Screen readers are highly useful accessibility tools, but they have
their drawbacks, like any other tool.
For some complex issues, you sometimes have to analyze whether the
problem is with the code or how the screen reader processes the code.
If it's the latter it's important to file an issue with the screen
reader vendor, so you can use this code in the future (when it is
fixed).
depending on the importance of the content that is being communicated
you may want to create a workaround or let the code stand as is.
You have to be aware of the accessibility supported requirements of
WCAG (which is why, in addition to testing with automated testing
tools and bookmarklets, you should do quick testing with a screen
reader, especially on templates and key pages).



On 6/5/19, Amber James < <EMAIL REMOVED> > wrote:
> 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
>> >
>> >
>> >
>> >