WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Google Chrome Frame for Screen Readers?

for

From: Robert Fentress
Date: Jun 26, 2015 9:04AM

It wouldn't exactly be a browser-based screen reader like ChromeVox, since
it wouldn't be handling any of the speech synthesis. It would require that
you already had a screen reader that supports those three features I
mentioned. Access Emulator would just handle what got spoken in response
to key commands, using the existing screen reader to handle the voicing.
As I see it, it would have to query the DOM for everything, rather than the
accessibility APIs (unless WAPA becomes a supported standard, I guess).

Thanks for the contact info for the person at Google. Perhaps they would
be interested in this strategy as a way of encouraging people to
standardize on ChromeVox's way of doing things. I'm not sure whether this
would be a good thing, but perhaps it would encourage Google to make
ChromeVox more robust.

Best,
Rob

On Fri, Jun 26, 2015 at 9:39 AM, Moore,Michael (HHSC) <
<EMAIL REMOVED> > wrote:

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