WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Google Chrome Frame for Screen Readers?

for

From: Bryan Garaventa
Date: Jun 24, 2015 10:57AM

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


-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Robert Fentress
Sent: Tuesday, June 23, 2015 1:10 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Google Chrome Frame for Screen Readers?

And I guess you'd need to apply role="application" to the whole page too for something like this to work.

On Tue, Jun 23, 2015 at 4:08 PM, Robert Fentress < <EMAIL REMOVED> > wrote:

> Hello, all.
>
> I wonder if anyone has ever thought of developing a JavaScript library
> that emulated the behavior of the most standards-compliant, open
> source, fully-featured screen reader/browser combination (not sure
> what that would be). The way I'm envisioning it, the library would
> apply aria-hidden to everything on the page and then use JavaScript to
> respond to key commands by adding content to a single ARIA live
> region. Basically, the live region would function as a virtual buffer of sorts.
>
> Why would you reinvent the wheel like this? Well, basically it would
> allow developers to code to standards, and ensure that if the user was
> accessing the page with a screen reader that supported aria-hidden and
> live regions, they could at least have a minimally accessible
> experience. The library could include code that would let the user
> turn this emulation on or off, allowing them to continue using
> whatever system they were comfortable with. However, by doing this,
> developers wouldn't have to code to and test on every single
> permutation of screen reader and browser and this would encourage
> writing standards-compliant, accessible code. It might also give AT
> vendors a common target. It would be something vaguely similar to the approach Google used with its Chrome Frame tool.
>
> Individual developers could add it to their pages, but it also
> wouldn't be hard, I would think, to create a browser
> extension/bookmarklet that let the end users apply the library to any page they wanted.
>
> Okay, have at it! Please tell me what obvious things I'm missing here.
> I've never done anything of this scope before (and I'm not
> volunteering), so perhaps it is just impossibly complex or would incur
> some unacceptably huge performance hit. Or perhaps it is wrong from
> some theoretical or ethical perspective. I'd love to hear what others
> think about this, as I suspect the answers will help me (and perhaps
> others) understand better the details of how the technology works. Thanks!
>
> Best,
> Rob
>
> --
> Robert Fentress
> Senior Accessibility Solutions Designer
> 540.231.1255
>
> Technology-enhanced Learning & Online Strategies Assistive
> Technologies
> 1180 Torgersen Hall
> 620 Drillfield Drive (0434)
> Blacksburg, Virginia 24061
>



--
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061