WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web Analytics

for

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

Ryan you stated "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."

If you think it is so important, why would you avoid releasing this
information? I think if your methodology is sound, the community could use
your information, unless you are under some type of NDA. Let us know.
Thanks!

On Tue, Apr 10, 2012 at 8:09 AM, Ryan Hemphill < <EMAIL REMOVED>
> wrote:

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