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.
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Jonathan C. Cohn
> Sent: Friday, May 12, 2017 5:45 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Web development; How to identify if a screen reader
> is in use
>
> Thinking about it, Google captua algorithm needs to be able to detect
> these patterns also. Otherwise AT users would be complaining that they
> always get visual or audio captures while AT users will automatically be
> verified.
>
> Best wishes,
>
> Jonathan Cohn
>
> On May 12, 2017, at 8:06 PM, Jonathan Avila < <EMAIL REMOVED> >
> wrote:
>
> >> Are you suggesting then that any time a person is using the keyboard
> only, that there is likely a screen reader involved there somewhere?
> >
> > No I am not. In fact I didn't say keyboard -- I said navigation with a
> screen reader. I can't go into details but I'd say that when a screen
> reader is active there are clues related to events and interactions, etc.
> that can accurately predict this. Similarly when only the keyboard is used
> or when speech recognition is used there are certain patterns of events and
> interactions that provide clues. For high contrast and zoom there are
> similar clues when you insert content and you see the aspects of that
> content changed by the user's browser settings.
> >
> >> I think we both know that's not always true - people with mobility
> issues will also likely be using a keyboard only (or speech input), and /
> or power-users who have a preference for the keyboard.
> >
> > And this is important information as well. Seeing power users use
> keystrokes can be motivation to add or tweak settings -- and it has nothing
> to do with disability.
> >
> >> WCAG says that all content must be accessible to the keyboard for that
> specific reason, so meeting that requirement ensures that the content
> remains accessible to all of those users.
> >
> > I agree that all content should be fully keyboard accessible. But there
> is more to keyboard access than simply being keyboard accessible. The
> discussions currently surrounding single key shortcuts and there benefits
> or detriment to speech recognition users is one example.
> >
> > Jonathan
> >
> > Jonathan Avila
> > Chief Accessibility Officer
> > SSB BART Group
> > <EMAIL REMOVED>
> > 703.637.8957 <(703)%20637-8957> (Office)
> >
> > Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
> > Download our CSUN Presentations Here!
> >
> > The information contained in this transmission may be attorney
> privileged and/or confidential information intended for the use of the
> individual or entity named above. If the reader of this message is not the
> intended recipient, you are hereby notified that any use, dissemination,
> distribution or copying of this communication is strictly prohibited.
> >
> > -----Original Message-----
> > From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> > Behalf Of John Foliot
> > Sent: Friday, May 12, 2017 3:32 PM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Web development; How to identify if a screen
> > reader is in use
> >
> > Hi Jon
> >
> >> but rather looking at the user's behavior on the site to predict
> >> whether
> > the user is navigating with a screen reader.
> >
> > Are you suggesting then that any time a person is using the keyboard
> only, that there is likely a screen reader involved there somewhere? I
> think we both know that's not always true - people with mobility issues
> will also likely be using a keyboard only (or speech input), and / or
> power-users who have a preference for the keyboard. It is unclear to me how
> you would know the difference between those users, and a user dependent on
> a screen reader simply by tracking their progress and interaction through a
> site. WCAG says that all content must be accessible to the keyboard for
> that specific reason, so meeting that requirement ensures that the content
> remains accessible to all of those users.
> >
> >> I never suggested that the data should be modified or redirected for
> >> a
> > screen reader user.
> >
> > That is correct, you have not.
> >
> > However, I've been hearing this request/argument for many, many years
> > now, and more often than not, from non-Accessibility SMES, who
> > *explicitly* want to use this information to modify what is being
> > delivered (think Media Queries), so while *YOU* haven't suggest that,
> > many have. This is a problem, and has been for at least a decade, when
> > Flash allowed for the ActionScript *Accessibility.isActivemethod*
> > (https://www.paciellogroup.com/
> > blog/2008/04/developer-beware-using-flash-to-detect-screen-readers/)
> >
> >> for example, we need better data
> >
> > Agreed 101%!
> >
> > But that data also needs to be accurate, and I will continue to assert
> that capturing and analyzing user-interaction data is not very accurate in
> terms of what tools any specific user (or groups of users) is using. There
> may indeed be other useful observations derived from that analysis, but
> returning to the Subject Line of this thread ("Web development; How to
> identify if a screen reader is in use"), attempting to determine if a
> screen reader is present and being used is, to me at least, a fools errand,
> as those software tools are expressly attempting to "cloak" their presence
> for the aforementioned security and privacy considerations.
> >
> > JF
> >
> > --
> > John Foliot
> > Principal Accessibility Strategist
> > Deque Systems Inc.
> > <EMAIL REMOVED>
> >
> > Advancing the mission of digital accessibility and inclusion
> >
> >> On Fri, May 12, 2017 at 1:35 PM, Elizabeth Pyatt < <EMAIL REMOVED> > wrote:
> >>
> >> Hello:
> >>
> >> The discussion about detecting screen reader use is very enlightening
> >> to me and I agree that it could be harmful.
> >>
> >> Clearly, it would be unethical to collect that data tied to a
> >> specific individual. I am also against using any sniffing technique
> >> to direct a user to a 'text-only- site. In fact, using detection to
> >> push mobile devices to a less functional site is equally bad.
> >>
> >> However, it should be noted that many reports such as Google
> >> Analytics provide aggregate reports on detected browsers/OS
> >> combinations. This can help webmasters make decisions such as whether
> >> it is viable to enable a particular new web technology (e.g. new CSS
> >> attributes, plugins, tags,
> >> etc) and how much effort must be made to support older systems. Back
> >> in the 2000s, when use of Netscape 4.7 finally dropped off, I jumped
> >> for joy because I could finally get rid of many FONT tags and use CSS.
> >>
> >> An example applicable to the screen reader community is when
> >> particular ARIA attributes are supported or not supported by
> >> different screenreader platforms. We may know that some older
> >> screenreader versions don't quite fully support all the ARIA
> >> specifications, but knowing generally which versions (in an aggregate
> >> sense) might be used can help determine what new technologies can be
> fully implemented.
> >>
> >> Based on the responses I have seen, I would not recommend
> >> implementing a sniffing algorithm at this time at this time. But I
> >> did want to point out why someone might want to do that for
> >> legitimate reasons that could benefit the community.
> >>
> >> Best
> >> Elizabeth
> >>
> >> =-=-=-=-=-=-=-=-=-=-=-=-> >> Elizabeth J. Pyatt, Ph.D.
> >> Accessibility IT Consultant
> >> Teaching and Learning with Technology Penn State University
> >> <EMAIL REMOVED> , (814) 865-0805 or (814) 865-2030 (Main Office)
> >>
> >> The 300 Building
> >> 304 West College Avenue
> >> University Park, PA 16801
> >> http://accessibility.psu.edu
> >>
> >> > >> > >> archives at http://webaim.org/discussion/archives
> >> > >>
> >
> >
> >
> >
> > > > > > archives at http://webaim.org/discussion/archives
> > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > at http://webaim.org/discussion/archives
> > > > > >