WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Running ChromeVox as a library in a web page?

for

From: Patrick H. Lauke
Date: Aug 30, 2017 4:11PM

On 30/08/2017 22:36, Robert Fentress wrote:
[...]
> I've mentioned this before and folks seemed to be baffled by why one would
> want to do such a thing, but I didn't totally understand the criticism, so
> I'd appreciate anyone who wished to (kindly) enlighten me. Basically, my
> thinking is that, if this were an option, developers could code their page
> or web application to standards, as best they could interpret them, and
> then test with ChromeVox. If it worked with that, and the developer could,
> essentially, include that screen reader as an option on the page itself,
> then it would help ensure at least a floor for screen reader
> accessibility. It would also provide another option for users, in general,
> to interact with their site.

This *may* help a subset of users that would require a screen reader/AT
- mainly those with mild vision impairment, or users that with cognitive
disabilities who would benefit from self-voicing pages. Clearly, any
other users that do rely on screen readers would already need to have a
screen reader installed anyway (in order to log in, open the browser,
navigate to the site, etc), but of course that's also true for ChromeVox
itself. But having it installed as extension at browser level means that
these users still benefit from it on all websites, not just on the ones
that decided to install some form of site-specific ChromeVox library.
Also, having it at browser level means that users can set their
preferences globally, while a site-specific version would need it own
settings - and then the user goes to another site that implements this
sort of thing, and the settings need to be changed again for THAT site.
This then goes into the same territory as the discussion around the
benefits of site-specific "text resize widgets" versus users actually
using text sizing options in their browser...

> I think many developers want to do right, but don't have the time to learn
> all the ins and outs of how different screen readers interpret things or to
> test in a half dozen or more different screen reader/browser/platform
> combinations, guessing, without any really reliable data, on what those
> might be.

In general, screen readers interpret well-formed and correctly
implemented HTML/ARIA stuff fairly uniformly - at least compared to
years ago. Ideally developers need to learn the "correct" way to mark
things up (particularly referring to official ARIA patterns) and then
their sites should work quite well in recent AT. Sure, every AT has bugs
(the same way every browser has bugs), but the answer to that is not to
just decide to bless one particular implementation (ChromeVox) as the
de-facto standard...

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke