WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web Analytics

for

From: Stella Mudd
Date: Apr 10, 2012 3:40PM

Two words: dojo toolkit.

On Tuesday, April 10, 2012, Ryan Hemphill wrote:

> Hi Lucy, I understand what you are saying. I get it - I really do, but
> technology-wise it's just not going to work in a Rich Internet App
> environment. It isn't about what I want - I would much rather not have to
> worry about the differences, it's a royal pain in the neck - but there are
> only 3 screen readers that can truly handle Rich Internet apps at this time
> (Focus Management and ARIA support) and the rest wouldn't be able to use
> most those sites at all even if they wanted to. Granted I haven't worked
> with ChromeVox much yet and that is a possible 4th.
>
> It's annoying, it's upsetting and a whole list of other things that
> shouldn't be said in public - but logistically, I can't see how we can move
> forward and avoid these things. There is simply too much noise and most
> dev/design teams would throw up their hands if they were dealing with a RIA
> that needed to be made accessible, just like the guy at Google expressed.
> This may be the reason they created their own SR. That being said, I have
> been hammering away at that particular plugin and it doesn't work very
> nicely in the RIA version of Gmail at all - or maybe I haven't figured out
> how to use it just yet.
>
> In most cases I would not be coding up tables or things like that any
> differently - it's when we start getting into the interactive aspects.
> Jumping back and forth through focus management techniques. Being able
> to drop focus onto modal windows and use it in several different methods
> without the screen reader going up in flames is a perfect example. I
> actually had to take the AEGIS plugin (considered fully accessible, for
> those who don't know) for modal/dialog and revamp it so that it would
> behave like a typical modal window and work across multiple screen readers.
> Part of fixing it required me to actually remove the role="dialog"
> attribute because it seriously screwed up our ability to extend its usage.
> ARIA actually REDUCED the accessibility of the widget. Imagine that! And
> it didn't have the same effects on different SRs (NVDA and JAWS) until we
> played around with it for some time. I can tell you some other bugs that
> would have been introduced if we'd kept the native version, one of which
> has the potential to break the whole site and kill the virtual buffer
> permanently in JAWS, by the way. VoiceOver hasn't been handled yet, but
> making that one work requires a different tweak to pull it off. Does it
> matter? I would say yes. Purchasing textbooks cross-platform should
> definitely be a priority use case for screen reader users. Would that
> require compatibility hacks? Also yes.
>
> This isn't something I love spending my time doing. It's something that
> has to be done to insure accessibility of the site, which in this case is
> for purchasing textbooks, by the way. SRs like Windows Eyes don't do focus
> management at all, so we didn't even bother testing that SR because it
> simply can't handle the interactive requirements of the site. Could we
> make this site work for all SRs? Yes, we could as a basic page with no
> bells and whistles at all. Could we make the site work for all SRs and also
> have rich internet behaviors which involve focus management and possibly
> ARIA attributes? NO WAY. Can I tell the marketing team to cease using
> these features? They would laugh me right out of the room.
>
> I go back to what I said before - we can't move forward if we're constantly
> expecting to wait for the AT companies to get their act together and all
> pull in the accessibility row boat in tandem. There is a good chance many
> of the SRs aren't going to be considered usable for the web at all in a
> short while, such as Windows Eyes, if they don't get their act together.
>
> All that being said, I do appreciate your passion for the topic.
>
> Ryan
>
>
>
> On Tue, Apr 10, 2012 at 2:06 PM, Lucy Greco < <EMAIL REMOVED> <javascript:;>
> >wrote:
>
> > Hello:
> > there would be no point in determining that a screen reader user is
> > accessing your website because every single screen reader works
> differently
> > than the other. You can't go out and detect every single competitive
> > screen reader and expect to have a modified version of your website. So
> > are you going to code your tables differently for JAWS then you would
> with
> > chrome vox? Are you going to make your website change to voiceover
> > compatible or are you going to work with NVDA or window eyes. Maybe the
> > visitor is using guide or the full supernova suite.
> >
> > It's none of our business what the person is using to access our website
> I
> > know there are people out there still using links but we don't code for
> > that either. I know it's already been said on this thread but equal
> access
> > means you made a good site that works for as many people as possible.
> Who
> > cares what screen reader they're using. Who cares if they're using a
> > screen reader the website should work and work for everyone. I don't
> want
> > Amazon to know if I'm blind or not I don't want you to know if I'm blind
> or
> > not I just want you to consider me a potential visitor to your website
> and
> > make it work.
> >
> > Once all this is been said and done as a trainer I need to be able to
> test
> > something at home on my machine and understand how it works then go to a
> > client system and not have any surprises because they might be using an
> > earlier version of the screen reader or the browser or the OS.
> >
> > Lucy Greco
> > Assistive Technology Specialist
> > Disabled Student's Program UC Berkeley
> > (510) 643-7591
> > http://attlc.berkeley.edu
> > http://webaccess.berkeley.edu
> >
> >
> >