E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 18 (In chronological order)

From: Robert Fentress
Date: Tue, Jun 23 2015 2:08PM
Subject: Google Chrome Frame for Screen Readers?
No previous message | Next message →

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

From: Robert Fentress
Date: Tue, Jun 23 2015 2:09PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

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

From: Jennifer Sutton
Date: Tue, Jun 23 2015 2:38PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

Robert and all:

Apologies if I'm taking over your thread, but I wonder if you're
getting at something I've been envisioning, but perhaps, you're
coming at it from a different angle.
Please redirect the conversation if I'm off-base.

I don't like the idea of focusing this on screen readers; rather,
what I've been wanting to see is a visual way for sighted people to
test for ARIA. While ARIA is screen reader-centric, at the moment,
it's not necessarily going to stay that way, at least based on some
things I've read. And as we know, Dragon Naturally Speaking is
beginning to take advantage of some of its functionality.

What I'd like to see is a cross-platform approach that would visually
represent ARIA behaviors (perhaps including validation indicators,
when possible). In other words, let's have ARIA meet many developers
where they are, in a visual context, rather than having to have them
learn a screen reader at all. So, to be very specific, if there's
ARIA markup, make sure it's clear when keyboard handlers/focus
indication have been excluded. And run the Javascript, with ARIA, and
show the *words* the screen reader would (or wouldn't) say.

Let's make this about complying with the specification, rather than
representing screen reader quirks/inconsistencies.

In my experience, developers either get overwhelmed by the notion of
having to learn a screen reader (so they do nothing), or they get
totally engrossed in screen reader-centricity, so they miss the
easier wins. And I seee this especially with ARIA implementations.

When I first started dreaming of this, I was envisioning an interface
something like the old HomePage Reader, for those who remember that
i.e. you could have some kind of split screen scenario, perhaps with
code-syntax highlighting.

But as we all know, ideas are a dime a dozen, so I'll stop here.

Thanks for reading and considering. Maybe there are existing pieces
that could be put together to create something like this more easily
than I imagine.

Best,
Jennifer

From: Richard Hulse
Date: Tue, Jun 23 2015 3:09PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

Since this my first post here, a quick introduction:

I am the digital product lead/webmaster at www.radionz.co.nz which is the
website for Radio New Zealand. We are a public radio broadcaster and we are
very focussed on accessibility, particularly at the moment making the site
more screen reader friendly.


On Wed, Jun 24, 2015 at 8:38 AM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = >
wrote:

> Let's make this about complying with the specification, rather than
> representing screen reader quirks/inconsistencies.
>

This is an interesting approach and seems to me to be the same as that
taken by the Web Standards project back in the late 90s. That is: that
everyone should be using standard markup, written to spec, and let's get
the screen readers (and other tech) makers to their tools follow the spec.

In some ways the current state is similar to what we had to deal with in
terms of browser quirks in the 90s.

Perhaps we need some way to indicate to the tech if we are using
'standards' and leave all the other sites to render as 'quirks'?

In my experience, developers either get overwhelmed by the notion of having
> to learn a screen reader (so they do nothing), or they get totally
> engrossed in screen reader-centricity, so they miss the easier wins. And I
> see this especially with ARIA implementations.
>

In my case I do use a screen reader as part of my testing regime, and I use
that along with other tools to ensure the markup makes sense for as many
uses as possible. Markup may serve many clients, just as a responsive site
serves many different screen sizes.

I found learning how to drive the screen reader no more difficult than an
other new piece of software. Certainly a lot simpler than vim or emacs!

A tool that validates the markup as being 'accessibility standards
compliant' would be a big win. At the very least the average punter will
test their sites, make adjustments, and they won't be horrendous. Those in
the know can use the tool to take the site to the next level.

Could this be an online tool like the W3C validator?


Cheers,

Richard Hulse
Webmaster
Radio NZ

From: Eades, Terri
Date: Tue, Jun 23 2015 3:55PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

Richard,

I know WAVE (by WebAIM) will check to see what errors in your code you have and present them visually on top of your site. It can also give you tips on how to fix errors. Also, SiteImprove will analyze your site and go a step further, (at a price), to tell you whether it meets WCAG 2.0 A, AA, or AAA. Is either one of these what you are looking for in terms of validators?


Terri Eades
Webmaster

Morgan Community College
920 Barlow Road, Fort Morgan, CO 80701
Phone: (970) 542-3155 | Fax: (970) 542-3115
= EMAIL ADDRESS REMOVED =

www.MorganCC.edu

From: Richard Hulse
Date: Tue, Jun 23 2015 4:37PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

On Wed, Jun 24, 2015 at 9:55 AM, Eades, Terri < = EMAIL ADDRESS REMOVED = >
wrote:

> I know WAVE (by WebAIM) will check to see what errors in your code you
> have and present them visually on top of your site. It can also give you
> tips on how to fix errors. Also, SiteImprove will analyze your site and go
> a step further, (at a price), to tell you whether it meets WCAG 2.0 A, AA,
> or AAA. Is either one of these what you are looking for in terms of
> validators?


Hi Terri,

I have WAVE and use it a bit.

I was thinking more of a tool to guide people in getting the basics right -
correct use of heading levels, hidden headings where appropriate, and the
most basic ARIA attributes that we know are consistently supported. This
might help raise the overall quality of site markup, and make the minimum
standard a bit higher, much as there was a phase when HTML validation was
worn as a badge of honour.


Cheers,

Richard

From: Robert Fentress
Date: Tue, Jun 23 2015 8:38PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

Thanks for the reply, Jennifer!

I'm not sure we're talking about the same idea exactly, but a couple things
come to mind. I think FAE <http://fae20.cita.illinois.edu/>;, Google's
Accessibility Toolbar
<https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en>,
and the plain old W3C Markup Validation Service <https://validator.w3.org/>
all provide varying degrees of validation of WAI-ARIA. As far as a
WYSIWYG/visual editor, I think Maqetta
<http://maqetta.org/features/states.html>; maybe tried to do some of that
using the Dojo toolkit, but I haven't had a chance to play around with it
(and active development on it has stopped).

I think focusing on the standard is a good idea, but things are so patchy
right now, it is quite challenging to know what parts of the ARIA standard
one should even include. Is a particular role, attribute, or property
supported at all on my target AT? How does the AT present this attribute?
Would I get a vastly different user experience by including it in my
application? Having a sort of shim that would let one code to the standard
*and* provide a fallback option that you know would work minimally would be
the desired state.

Good point about how WAI-ARIA affects more than screen readers, though.
Maybe this wouldn't address all issues, but it could be a start.

Best,
Rob

On Tue, Jun 23, 2015 at 4:38 PM, Jennifer Sutton < = EMAIL ADDRESS REMOVED = >
wrote:

> Robert and all:
>
> Apologies if I'm taking over your thread, but I wonder if you're getting
> at something I've been envisioning, but perhaps, you're coming at it from a
> different angle.
> Please redirect the conversation if I'm off-base.
>
> I don't like the idea of focusing this on screen readers; rather, what
> I've been wanting to see is a visual way for sighted people to test for
> ARIA. While ARIA is screen reader-centric, at the moment, it's not
> necessarily going to stay that way, at least based on some things I've
> read. And as we know, Dragon Naturally Speaking is beginning to take
> advantage of some of its functionality.
>
> What I'd like to see is a cross-platform approach that would visually
> represent ARIA behaviors (perhaps including validation indicators, when
> possible). In other words, let's have ARIA meet many developers where they
> are, in a visual context, rather than having to have them learn a screen
> reader at all. So, to be very specific, if there's ARIA markup, make sure
> it's clear when keyboard handlers/focus indication have been excluded. And
> run the Javascript, with ARIA, and show the *words* the screen reader would
> (or wouldn't) say.
>
> Let's make this about complying with the specification, rather than
> representing screen reader quirks/inconsistencies.
>
> In my experience, developers either get overwhelmed by the notion of
> having to learn a screen reader (so they do nothing), or they get totally
> engrossed in screen reader-centricity, so they miss the easier wins. And I
> seee this especially with ARIA implementations.
>
> When I first started dreaming of this, I was envisioning an interface
> something like the old HomePage Reader, for those who remember that i.e.
> you could have some kind of split screen scenario, perhaps with code-syntax
> highlighting.
>
> But as we all know, ideas are a dime a dozen, so I'll stop here.
>
> Thanks for reading and considering. Maybe there are existing pieces that
> could be put together to create something like this more easily than I
> imagine.
>
> Best,
> Jennifer
>
> > > > >



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

From: Bryan Garaventa
Date: Wed, Jun 24 2015 10:57AM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

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

From: Robert Fentress
Date: Wed, Jun 24 2015 12:23PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

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

From: Jonathan Avila
Date: Wed, Jun 24 2015 12:28PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

Rob, there is a proposed technology called WAPA (https://github.com/cyns/wapa) that would allow scripted applications to access an accessibility API in the browser. You may want to check this future technology out as it may provide some of what you are looking for.

Jonathan

-- 
Jonathan Avila 
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957  
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Bryan Garaventa
Date: Wed, Jun 24 2015 3:20PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

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.

From: Robert Fentress
Date: Fri, Jun 26 2015 6:44AM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

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

From: Patrick H. Lauke
Date: Fri, Jun 26 2015 7:35AM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

> On 26 Jun 2015, at 14:44, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
>
> 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.

My hunch is yes, on both counts. Also, most of this would not readily work for AT on touch devices, as there is no way currently - that I know of - to go into "application" mode and handle gestures yourself.

In short, I think it's an interesting thought experiment, but not practical. I'd rather see small, very focussed little polyfills that fix/bridge one very specific shortcoming at a time.

P

From: Moore,Michael (HHSC)
Date: Fri, Jun 26 2015 7:39AM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

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)

From: Robert Fentress
Date: Fri, Jun 26 2015 8:49AM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

But how do you implement polyfills if you can't test for feature support?
Perhaps the WAPA thing Jonathan mentioned might help with that.

On Fri, Jun 26, 2015 at 9:35 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

>
> > On 26 Jun 2015, at 14:44, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > 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.
>
> My hunch is yes, on both counts. Also, most of this would not readily work
> for AT on touch devices, as there is no way currently - that I know of - to
> go into "application" mode and handle gestures yourself.
>
> In short, I think it's an interesting thought experiment, but not
> practical. I'd rather see small, very focussed little polyfills that
> fix/bridge one very specific shortcoming at a time.
>
> P
> > > > >



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

From: Robert Fentress
Date: Fri, Jun 26 2015 9:04AM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

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

From: eero hauskamaa
Date: Fri, Jun 26 2015 9:32AM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | Next message →

Hello all

Good question. Google Chrome is a innovative web browser, but it is not
a easiest selection, if user is a basic user.

For example Nvda is a chrome-compatible screenreader.

Eero Hauskamaa

From: Jennifer Sutton
Date: Fri, Jun 26 2015 2:22PM
Subject: Re: Google Chrome Frame for Screen Readers?
← Previous message | No next message

Thanks, all, for this interesting discussion.

I'll make a few last points, at least based on my fifteen years of
experience in this field, both as an end-user and an active
participant in many activities to move the field forward. I actually
do more than simply post links to email lists <smile>.

As I suspected, Robert and I are talking about pretty different
things. And my idea isn't really possible, right now.

Thanks, Bryan, especially, for making that altogether clear to me.

But I will reiterate my point that I don't think the current paradigm
of having developers *have* to learn how to use screen readers is
working very well, in terms of the wide adoption/correct
implementation of ARIA. It's too much knowledge to be able to scale,
in my experience. Just turning on ChromeVox or VO, and arrowing
through (or tabbing through) a page (never having seen an end-user
use a screen reader) is not working out very well, based on the
results I find, daily, in the "real world," of an end-user i.e. I
don't mean when I'm being paid to test.

Heck, we have seen this issue on this list for years -- sighted
people get bogged down in screen-reader issues that *they* perceive
as issues, but that really aren't.

As I see it, the unfortunate outcome of the integration of VO into
the Mac (less so with IOS, I believe) and ChromeVox into Chrome is
that it gives folks who've not seen end-users the sense that they
actually understand that experience. And I don't find that to be the
case, unfortunately.

Robert, I'm not sure I actually understand what you're aiming at that
would help blind people, unless, perhaps, it'd be a standards-based
training tool so that then, pblind people could provide feedback to
vendors about how they should change what they're currently doing.
But I don't see the blind audience being very significant for such a thing.

Also, not many blind folks use ChromeVox, based on this:
http://webaim.org/projects/screenreadersurvey5/

Personally, I'd like to see a vendor agnostic tool (not by Google, or
anyone else), but rather, build a *collaborative* tool to which *all*
browser vendors would contribute, as well as AT vendors. It'd be a
great learning experience for these folks to work actively together,
but of corse, I imagine in dreamland.

Finally, in case this may help somebody, here's this FF toolbar that
does look for ARIA, though I'm not sure whether Gez is maintaining
it/whether it will be updated when ARIA 1.1 comes out:

https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/


Maybe somebody should propose this project to the $20 million
challenge Google's got going; I suppose Google-centric would be
better than nothing. Go for it, Robert!:

http://www.huffingtonpost.com/2015/05/29/google-challenge-disabilities_n_7469866.html

Best,
Jennifer