WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web Analytics

for

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

Two words: dojo toolkit.

On 4/10/12, Ryan Hemphill < <EMAIL REMOVED> > 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> >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
>>
>>
>> -----Original Message-----
>> From: <EMAIL REMOVED> [mailto:
>> <EMAIL REMOVED> ] On Behalf Of Tim Harshbarger
>> Sent: Tuesday, April 10, 2012 10:38 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Web Analytics
>>
>> Jared makes good points. I will try to make another good point.
>>
>> One of the big issues with this approach isn't technical but social.
>> People with disabilities have experienced and do experience
>> discrimination
>> based on their disability. One thing people with disabilities seem to
>> prize on the internet is having the opportunity to interact with other
>> people and organizations without their disability becoming known. While
>> it
>> might be hard to believe in this day and age, interactions with
>> organizations and other people can be qualitatively different if
>> disability
>> isn't one of the factors.
>> Another factor in this attitude might be too many well intentioned people
>> with little understanding. Basically, this approach is like saying "trust
>> me, I know exactly what you need." I expect we all here are in a better
>> position to understand what the user might need or want--but I expect
>> everyone on this list with a disability has stories about well-intentioned
>> people who felt they should make a decision on behalf of a person with a
>> disability--and things ended up in disaster. But I am just guessing about
>> this part.
>>
>> So, the population we want to design user interfaces for is going to be
>> somewhat resistant to us trying to determine if they have a disability and
>> then prescribing their user experience for them based on that information.
>> I even suspect that most of them would be more comfortable answering a
>> question like "Do you want white text on a black background?" rather than
>> "Are you a person with a visual impairment?"--not to mention it probably
>> will get more answers since not all people we might define as having a
>> disability define themselves as having a disability.
>>
>> I do realize that when we design user interfaces, we have to make
>> decisions based on what we think the users might need or want. I just
>> think that people with disabilities would see a big difference between
>> universal design and AT sniffing.
>>
>> That is just my two cents worth--or the denomination of your own choosing.
>>
>> Tim
>>
>>
>> I definitely understand the desire of some of the people in this community
>> to want that information about users--we all want to be able to give
>> people
>> the best user experience we possibly can design. With this approach, I
>> think the problem we run into is people with disabilities have had a lot
>> of
>> bad experiences with that identification approach. Screen reader only
>> pages, anyone?
>>
>>
>>
>> -----Original Message-----
>> From: <EMAIL REMOVED> [mailto:
>> <EMAIL REMOVED> ] On Behalf Of Ryan Hemphill
>> Sent: Tuesday, April 10, 2012 10:10 AM
>> To: WebAIM Discussion List
>> Subject: Re: [WebAIM] Web Analytics
>>
>> When I read the reason for not wanted to be identified as using an
>> accessibility technology, I gave a big sigh yesterday.
>>
>> You can't hide the fact that you are a screen reader user. Anyone with
>> any
>> understanding of screen reader behaviors would be able to detect your
>> technology almost immediately. Some of them are very straightforward.
>>
>> (1) Clicking on a hidden link/anchor/button within a page. While this is
>> listed as an accessibility technique/practice, it's a red flag that you
>> are
>> a screen reader user. No one else would see it in the first place and
>> there is definitely no one that would be able to click on it.
>>
>> (2) Tabbing a lot. One focus jump after another going all over the entire
>> page (let along the entire site) unless it was a form would immediately
>> give a high probability of the user leveraging a screen reader or some
>> other accessibility software.
>>
>> (3) Tabbing + Click event. This one would be a very strong indicator. If
>> the user was tabbing a lot and then clicked (via the simulated click event
>> that screen readers all use), the probability that the user is navigating
>> via screen reader is very very high. Why else would anyone tab through an
>> entire site only to use a mouse click once they have found what they were
>> looking for?
>>
>> (4) I can detect, at this time, whether you are using JAWS, NVDA or
>> VoiceOver in a heartbeat. I have 2 methods I could use in JAWS, and might
>> even be able to figure out the version of JAWS with a little bit of extra
>> research. Given the information you have just provided (thank you for
>> that), I will avoid releasing how I can do this, but suffice to say - it
>> isn't hard once you really understand the behavioral differences from each
>> other and keyboard/non-screen reader users as a whole.
>>
>> We need to revisit this issue. There is just no way you are going to be
>> able to hide many accessibility technologies from any developer on the
>> web.
>> If someone has nefarious purpose for detection of your screen reader
>> technology or wants to detect the likeliness that you are a keyboard only
>> user that might have motor skill impairments, for example, you are not
>> going to be able to stop them.
>>
>> Furthermore, you are creating a situation that makes it extraordinarily
>> difficult to deal with the differences between screen readers. The
>> compatibility issues that present themselves in rich internet applications
>> already make it so that JAWS, NVDA and VoiceOver are the only possible
>> means to handle things like focus management because it is that complex to
>> begin with. Add on the fact that they each handle it differently and you
>> are really looking at a major break between the desired avoidance of
>> detection and reality of making Rich Internet Apps work for these
>> programs.
>> Developers who are doing Rich Internet Apps need to know what you are
>> using especially when the RIA becomes complex.
>>
>> In our current situation at my company, we are required by law to provide
>> accessible solutions for screen reader users, but there is more than one
>> Rich Internet App in our company that require knowledge of which (JAWS,
>> NVDA or VoiceOver) screen reader is being used to insure failures
>> (interaction or formatting) don't occur. There is too much going on in
>> these apps for the SR software to handle it without some help as well. I
>> could go on for at least an hour or two about how these situations come
>> about and what we are doing to resolve them but mark my words, there is no
>> question at all that we need to know what we're working with.
>>
>> I get why no one wants to be identified. No one wants their information
>> broadcasted to companies that want to exploit their data. It is invasive
>> and unsetting - I completely understand the objection.
>>
>> But it isn't going to allow screen reader technologies (or others for that
>> matter) to maintain the pace of development that we are all witnessing
>> even
>> now. I even remember seeing a post about half a year ago by a Google
>> employee that was stating how making some technologies accessible at this
>> time was extraordinarily difficult. This is Google we are talking about,
>> a
>> company that hires super-geniuses to write their software - and they're
>> saying they can't the target. Now granted, I'm sure that there are those
>> among you that see this as an excuse or lack of knowledge on that person's
>> part - but for a massive technology driven company to have an employee
>> state publicly their doubts in creation of RIA accessibility - that's a
>> very bad sign. And we aren't doing them or any other design dev teams any
>> favors (or the user base it affects) by hiding the fact that you are a
>> screen reader user or have some other a11y tech-specific need.
>>
>> If this post needs to move to a new discussion (probably not a bad idea) I
>> would like to continue this conversation further with anyone that wishes
>> to
>> state their opinion. I am open to harsh criticism, so fire away, but I
>> feel very strongly that this perspective is going to hold back
>> accessible-friendly technology for the web in a critical and unfortunate
>> way. Don't get me wrong, I care very much about doing the right thing,
>> but
>> as the assessment of a 15 year veteran in design/development, there is no
>> way this is going to work in the long run - and I am not the only person
>> that would tell you that.
>>
>> We need to be open to telling the dev teams what tech we're shooting for.
>> A no-holds-barred approach to keep up with the pace we are seeing. It's
>> not going to slow down and you can't predict what is coming up next. I am
>> very unsettled and concerned by this issue.
>>
>>
>> Ryan.
>> >> >> >> >> >> >>
>>
>> >> >> >>
>
>
>
> --
>
>
>
> Shipping is a Feature...Perhaps the Most Important Feature.
> > > >