WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Google Chrome Frame for Screen Readers?

for

From: Moore,Michael (HHSC)
Date: Jun 26, 2015 7:39AM

This sounds to me like a browser based screen reader with some additional diagnostic tools. Have you thought of contacting Charles Chen at Google and looking into extending ChromeVox.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)
(512) 574-0091 (Cell)

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Robert Fentress
Sent: Friday, June 26, 2015 7:45 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Google Chrome Frame for Screen Readers?

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
> ctrl+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
> ctrl+shift+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.
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Robert Fentress
> Sent: Wednesday, June 24, 2015 11:24 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Google Chrome Frame for Screen Readers?
>
> 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-tes
> > t- 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
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
>
> --
> 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
> > > archives at http://webaim.org/discussion/archives
> >
> > > archives at http://webaim.org/discussion/archives
> >



--
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