WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Google Chrome Frame for Screen Readers?

for

From: Robert Fentress
Date: Jun 24, 2015 12:23PM

Hi, Bryan.

Thanks for the response.

In answer to your question, the Javascript library--I'll call it Access
Emulator, so it is more clear when I use it in the rest of this
email--would be a a tool for both the developer and a screen reader user.

*Developer Scenario:*

I am a developer working on a fairly complex single page web application
and want to make sure it is accessible. Assuming the Access Emulator team
decides it wants to standardize on NVDA/Firefox, then, as a developer using
the framework, I write code that meets standards, and test it in
NVDA/Firefox. I then include Access Emulator in my code, which results in
a link being added at the beginning of my web app that says "emulate
NVDA/Firefox". Clicking that link turns on the emulation, sticking
role="application" and aria-hidden="true" on the content in the page,
basically making it opaque to a screen reader (SR) user. Access
Emulator then intercepts all the key strokes, handling them as NVDA/Firefox
would, accessing the DOM to retrieve the right text and sticking it in a
live region outside of the hidden content to be voiced.

*Screen Reader User Scenario:*

I am a SR user who uses Window-Eyes on Internet Explorer (totally random
choice here). I come to a web application that is unusable with that
SR/browser combination. I look at the help for the application and it says
it has been tested with NVDA/Firefox. I've created a bookmarklet or
installed a browser extension that can basically add Access Emulator to any
page after the fact. I activate this bookmarklet/extension and, presto, I
have an application I can access. Sure, it is not my preferred means of
access, and that is problematic, but I am not totally locked out.

Of course, this would require someone, or a dedicated team, to keep Access
Emulator up to date with the latest version of NVDA/Firefox (I nominate
you, Bryan--wink), but the point is that all the effort would be
centralized in one place. It's not like each developer using the library
would have to keep on top of things. That's the whole point. Basically,
all a developer would have to do would be to code to standards and test
with NVDA/Firefox. Of course, it wouldn't really be that simple (mobile
and Dragon come to mind), but it would remove a lot of the uncertainty and
at least simplify testing.

Let's be realistic--not every developer is going to buy JAWS or Window-Eyes
and learn how to use them in order to make sure their web application works
with them. Sure, they should code to standards, but I think we're at the
stage where we're still trying to figure out how those standards are going
to be implemented with vendors. That means, if you'll pardon the pun, that
a lot of developers are flying blind.

Best,
Rob

On Wed, Jun 24, 2015 at 12:57 PM, Bryan Garaventa <
<EMAIL REMOVED> > wrote:

> Hi,
> I'm not really sure who the emulator would be for, would this be for the
> non-sighted screen reader user, or for the sighted non-screen reader user
> who is a developer?
>
> As far as the most standards compliant open source screen reader and
> browser combination goes, NVDA with Firefox is the only one that fits this
> description, which is also free.
>
> The problem with adding a bunch of ARIA markup such as aria-hidden and
> role=application to a general JavaScript framework, is that you are only
> going to be limiting the non-sighted screen reader user, none of which
> would be conveyed to a sighted developer, which would be far too easy to
> abuse if a sighted developer implemented this without understanding what
> the impact of this would be for the non-sighted screen reader user.
>
> If you would like to visually see what a non-sighted screen reader user
> would hear, the following article by Marco is helpful in describing how
> this can be done:
>
> https://www.marcozehe.de/articles/how-to-use-nvda-and-firefox-to-test-your-web-pages-for-accessibility/
> Also keeping in mind that this was written in 2009, and ARIA support has
> improved greatly since then.
>
> One of the biggest challenges with mapping support levels for various ATs,
> is that it becomes obsolete very quickly as bugs are addressed and new
> releases address the original issues described, so then there is a
> disconnect between what is perceived as being accessible versus what
> actually is accessible in common practice.
>
> So basically, to build an AT support emulator, it would be necessary to
> constantly test with ATs in the very way that the emulator is supposed to
> simulate without having to test using the same ATs.
>
> As an example, within the last couple of years, support for ARIA has
> jumped forward in leaps and bounds, which has negated many of the prior
> data about support levels found on the web today.
>
> As with any moving target, ARIA is an evolving technology, but the good
> news is that it is getting better all the time.
>
> One thing to keep in mind, regarding when or when not to use ARIA, it's
> important to ask yourself whether what you are building cannot work
> accessibly without it.
>
> E.G If you are building a custom slider control that uses a drag handle,
> and you make this keyboard accessible using the arrow keys, it will still
> be inaccessible to non-sighted screen reader users without the use of ARIA
> because none of the textual equivalent data will be conveyed, causing a
> critical stopper for all non-sighted users. This goes beyond whether ARIA
> is supported by the AT, but rather, is a requisite programming feature that
> is needed to ensure accessibility for all ATs that support it.
>
> If it's helpful, the following tables show which attributes are required
> and when for the successful understanding of ARIA role implementation:
> http://whatsock.com/training/matrices/
>
> Best wishes,
> Bryan
>
>
>