Thread: Web Analytics
Number of posts in this thread: 3 (In chronological order)
As a screen reader user I'm glad you posted this. I believe that web
designers and others need to become more familiar with the specifics of
screen reader design so that accessibility can be complied with. It needs to
be a two way street if we are going to gain full accessibility.
----- Original Message -----
From: "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, April 10, 2012 8:09 AM
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
> 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
> 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
> 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
> 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
> 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,
> 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
> 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,
> 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.
> > >
On Tue, Apr 10, 2012 at 12:37 PM, Ryan Hemphill <
= EMAIL ADDRESS REMOVED = > wrote:
> 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.
Have you given this feedback to Hans Hillen? I'm sure he would appreciate
hearing it. I'd also be really interested.
I'd also love to hear about your solution to the virtual buffer issue which
still seems to hit us every now and again after page updates.
> 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.
I'd love to hear about this but I'm not sure this is the right venue for
that discussion. Are you on the free-aria list. That might be a good venue
to try to have some more technical discussions about some of these things
> Glad to hear I was able to offer up something you liked. Virtual buffer
> failures have become a speciality of mine. While they almost exclusively
> happen in Jaws, there are some distinct patterns behind how and why they
> happen. If you want, I would be happy to provide you with some insights.
Shipping is a Feature...Perhaps the Most Important Feature.