E-mail List Archives
Re: Google Chrome Frame for Screen Readers?
From: Robert Fentress
Date: Jun 23, 2015 8:38PM
- Next message: Robert Fentress: "Longdesc implementations/alternatives?"
- Previous message: Sailesh Panchang: "Accessibility best practices - a perspective"
- Next message in Thread: Bryan Garaventa: "Re: Google Chrome Frame for Screen Readers?"
- Previous message in Thread: Richard Hulse: "Re: Google Chrome Frame for Screen Readers?"
- View all messages in this Thread
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 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
- Next message: Robert Fentress: "Longdesc implementations/alternatives?"
- Previous message: Sailesh Panchang: "Accessibility best practices - a perspective"
- Next message in Thread: Bryan Garaventa: "Re: Google Chrome Frame for Screen Readers?"
- Previous message in Thread: Richard Hulse: "Re: Google Chrome Frame for Screen Readers?"
- View all messages in this Thread