WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Google Chrome Frame for Screen Readers?

for

From: Robert Fentress
Date: Jun 26, 2015 6:44AM

Well, you would only have to have a screen reader that supported three
things:

1. aria-live="assertive"
2. role="application"
3. aria-hidden="true"


That includes the bulk of screen readers being used these days, doesn't
it? It wouldn't catch everything, but it would be an improvement.

And, as far as programming for a particular AT/browser, I don't know that
it is quite fair to say that is what you would be doing. In a way, this
approach almost does the opposite. You would be coding to the standard;
you'd just be providing a way for people who were not using the most
standards-compliant or feature-rich AT to take advantage of the features of
the standard. And you would be simplifying things for developers and and
encouraging them to at least do some screen reader testing.

Yes, you would be recreating a lot of the functionality already provided
natively by the screen reader the person was using (if they didn't want to
stick with what they had, which would be the default). That is the
downside. Perhaps it would be too difficult to develop or maintain or you
would incur too big of a performance hit to implement this with
JavaScript. I don't know.

If it could be done, though, and started to become popular, it might pull
the other screen reader vendors along, encouraging them to try to match the
functionality of the emulator, thus promoting standards (or at least a
standard way of doing things). I think this was the approach of Google
Chrome Frame, and it may have helped nudge IE to be more
standards-compliant.

Best,
Rob

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

> I wish you the best of luck if you want to attempt this, but it's
> important to note that screen reader usage varies unpredictably based on
> the user, not just the browser.
>
> For example, if you were going to emulate a screen reader like JAWS or
> NVDA, you may get users who use standard line by line navigation methods
> via the single up/down arrow keys, or paragraph by paragraph using
> ctrl+up/down, or quick navigation keys like 'h' or shift+h to jump between
> headings, or l or shift+l to jump between lists, etc, or internal structure
> navigation commands such as JAWS' commands for
> ctrl+shift+up/right/down/left for navigating between the cells of a data
> table and the announcement of all associated headers (if the markup is
> correct), and so on.
>
> If you wanted to make all of this available within an emulator without
> JAWS actually running, you would basically have to duplicate everything
> that is already programmed within the screen reader, and even then, if ARIA
> wasn't properly supported in the browser, it wouldn't provide the same
> feedback for a sighted developer expecting that this is what a JAWS user
> would hear when navigating the product.
>
> On the other side, if you had a non-sighted WE user who went to a website
> and if it provided an NVDA/Firefox mode, it still wouldn't work correctly
> if Window Eyes didn't properly support ARIA, because the lack of support
> would exist within the screen reader regardless.
>
> I may be misunderstanding the purpose, and if so I apologize, but it's not
> a good practice to program any web technology specifically for individual
> AT and browser combinations; providing different content for each, because
> there are too many variables to account for.
>
> Like I said, I may be misunderstanding, so please let me know if I am.
>
>
>