WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Web development; How to identify if a screen reader is in use

for

From: Jonathan Cohn
Date: May 15, 2017 11:22AM

One can get events for mouse move and click actions. And at least some
Screen Readers have been known to perform click actions by using injected
JS. Also, VoiceOVer and NVDA have a tendency to associate one cursor with
another, so perhaps always having the mouse hover over the reading cursor.
So if the mouse is tracking left to right top to bottom in a very jerky
movement and always stops at the center of a span you might be able to
guess that VoiceOver is running.

I have never tried to do such analytics but this would be my approach, and
I could see how teams that are developing tracking of user efficiency could
isolate large populations of distinct patterns of site usage and look for
common factors. I understand some companies even bring eye tracking
technology into user design labs in order to make a more effective site.
Best Wishes,

Jonathan Cohn

On Mon, May 15, 2017 at 12:59 PM Jeremy Echols < <EMAIL REMOVED> > wrote:

> I can't help but wonder how, technically, one could hope to track AT. By
> its nature, it communicates with the browser and only the browser, not the
> site itself. So in order to track on it, you'd need browser vendors to
> explicitly add something that allows you to track - or else use pattern
> recognition to make guesses, which would sometimes be terribly wrong. And
> with Firefox's privacy focus, that is very unlikely to happen without an
> opt-in-only situation. Tracking users in general is getting harder due to
> browsers making it easier and easier to block things like Google
> Analytics. I just don't see browser vendors purposely exposing such
> sensitive data.
>
> And then I think about some of the legalities of forcing a user to expose
> this data. I visit a job website and submit an application. The employer
> cannot legally ask a great many questions about disabilities, but the
> website is actually being fed that information for free. Does the employer
> choose to use that information in an illegal way? Quite possibly. And
> there's no way to detect that bias because it's just one piece of data the
> browser is sending to all sites I visit.
>
> Aside from all that, I kind of see this like mobile detection. A while
> ago everybody had their desktop site and their mobile site (and some sites
> still do). But the trend lately has been to build a single site that works
> for mobile devices and regular desktop browsers. There are a lot of
> reasons for this, but a big one is reduced cost. Providing a mobile site
> that's separate from the main site means you're managing two separate
> projects that need to be kept mostly in sync. Unless you design for
> multiple front-end experiences, this can be very expensive to maintain.
> Now you want to split it into AT users and non-AT users? Same problem all
> over again, but even worse. Now you're attempting to decide based on the
> use of JAWS how a user should experience the site.
>
> But what does it mean that somebody uses JAWS? It doesn't mean they're
> blind. More likely, they have a cognitive disability, low vision (and like
> to read along with the screen reader), or minimal mouse use and simply like
> the keyboard shortcuts screen readers provide. Even if your entire goal is
> strictly analytics, as opposed to separating two sites, you don't actually
> have much information to go on.
>
> Make a site that works for everybody and you have a single thing to manage.
>
>