E-mail List Archives
Thread: Web development; How to identify if a screen reader is in use
Number of posts in this thread: 32 (In chronological order)
From: John Contarino x245
Date: Thu, May 11 2017 9:48AM
Subject: Web development; How to identify if a screen reader is in use
No previous message | Next message →
Hi,
Is it possible in web site development to identify if a screen reader is in use by the end user?
Similar to how different browsers are identified and can be interpreted in code based on browser.
Thanks.
John Contarino
Programmer Analyst
From: Beranek, Nicholas
Date: Thu, May 11 2017 9:57AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
Hi John,
Not for Web Accessibility. On iOS, we have the ability to detect whether or not assistive technologies like VoiceOver are running, but this is only through native applications. I remember discussions about how people would feel if developers could detect whether or not they're using a screen reader, magnifier, or other AT. I don't recall what came out of those discussions.
I gave a talk about data and accessibility and how we're unable to get numbers related to screen reader usage. If we could, would we use it to "water down" the experience? We are firm believers at Capital One in providing an inclusive and enriching experience regardless of disability.
I think it's time to discuss this very topic again. Thanks for bringing it up.
Nick Beranek
Capital One
From: Jonathan Avila
Date: Thu, May 11 2017 10:08AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
> Is it possible in web site development to identify if a screen reader is in use by the end user?
Similar to how different browsers are identified and can be interpreted in code based on browser.
John, the short answer is yes, with limitations on not knowing the specific version or model of screen reader. There are particular markers and behaviors that can be detected programmatically by JavaScript to tell if a user is likely to be using a screen reader, zoom, high contrast, keyboard-only mouse, etc. just as there are some methods of detecting touch screen as well. I'm aware that there are limitations in the approaches for touch screen detection and it's important to keep in mind that touch screens can be on larger devices and users can switch between modalities as well.
One of the WebAIM screen reader surveys asked about concerns that users may have around this topic. While there is some concern that users don't want to be tracked based on their assistive technology the majority felt that if it could improve the accessibility of their experience that some sort of detection could in theory be beneficial. Knowing that users with assistive technology and accessibility features visit a site can be compelling evidence that indeed people with disabilities are using your site and here is the location that they leave your site after this length of time can help organizations to address accessibility issues and create more accessible sites.
Applying accessibility analytic information like this provided by SSB's Access Analytics is one recent strategy to provide organizations with real-time tools to understand their customer's needs.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART GroupÂÂ
= EMAIL ADDRESS REMOVED =
703.637.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.
From: Patrick H. Lauke
Date: Thu, May 11 2017 10:08AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
On 11/05/2017 17:57, Beranek, Nicholas wrote:
> Hi John,
>
> Not for Web Accessibility. On iOS, we have the ability to detect
> whether or not assistive technologies like VoiceOver are running, but
> this is only through native applications. I remember discussions
> about how people would feel if developers could detect whether or not
> they're using a screen reader, magnifier, or other AT. I don't recall
> what came out of those discussions.
There are privacy implications if a site can potentially identify an
individual user based on factors such as AT used. On that point, it
should at the very least be something permissions-based in the browser,
where a user would specifically allow/block sites from accessing
information about any AT that may be running/present (similar to
permission dialogs for things like geolocation, fullscreen,
notifications, etc).
There's also a fear that sites would try to detect AT and simply
redirect to a separate "accessible" version which lacks content/richness
of experience of the "main" site.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Thompson, Rachel
Date: Thu, May 11 2017 10:09AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
Hi, all.
Automatic detection of assistive technology presents problems in my world. We cannot legally "out" someone with a disability and this approach has the potential to do that. This would certainly be an issue for our lawyers if it existed on any sort of application materials for attending or working at our institution.
Even if it comes from good intentions, I am loathe to support an idea that results in a "separate, but equal" experience.
Hope you have a good day,
Rachel
Dr. Rachel S. ThompsonÂÂ
Director, Emerging Technology and AccessibilityÂÂ
The Center for Instructional TechnologyÂÂ
The University of Alabama
110 Russell Hall
Box 870248ÂÂ
Tuscaloosa, AL 35487ÂÂ
Phone 205-348-0216
= EMAIL ADDRESS REMOVED = | http://cit.ua.edu | http://accessibility.ua.edu
From: Jonathan Avila
Date: Thu, May 11 2017 10:15AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
> Even if it comes from good intentions, I am loathe to support an idea that results in a "separate, but equal" experience.
Any technology has the capacity to be mis-used -- telephones are mis-used everyday to spam or harass callers. However, overlooking the benefits of a potential technology must be considered. Any intention to identify user behaviors has benefits. For example, scripts already exist to identify high contrast users in order to provide them with equivalent information when background images are turned off. Responsive websites are used every day and adjust to the users viewport width which is based on factors including low vision users using the zoom feature in your browsers. So I would urge people to consider this not as a means to track people with disabilities to better understand how users are interacting with your website and provide adaptability and flexibility to those users.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART GroupÂÂ
= EMAIL ADDRESS REMOVED =
703.637.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.
From: Andrews, David B (DEED)
Date: Thu, May 11 2017 10:22AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
Another concern is "numbers." If you take any given segment of the disabled population, blind people, deaf people, low vision persons, screen reader users, etc., its numbers are going to be relatively low compared to the whole. So, I think people are afraid that if sites have specific numbers, "I only had five screen reader users last month," for example, it will work against us, and not for us in the long run.
Dave
From: Thomas Lee McKeithan II
Date: Thu, May 11 2017 10:35AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
I agree!
Respectfully,
Thomas Lee McKeithan II | Optum Technology Solutions
Electronic Accessibility Engineer, UX Design Studio (UXDS)
MD018, 6220 Old Dobbin Lane, Columbia, MD, 21045, USA
T +1 443-896-0432
M +1 202-276-6437
= EMAIL ADDRESS REMOVED =
www.optum.com
ÂÂ
From: Jonathan Avila
Date: Thu, May 11 2017 10:36AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
> Another concern is "numbers." If you take any given segment of the disabled population, blind people, deaf people, low vision persons, screen reader users, etc., its numbers are going to be relatively low compared to the whole.
Dave, I agree. Any numbers have to carefully be considered and message to stakeholders. It is however compelling to be able to say x% of your screen reader users are using Firefox or x% are using Internet Explorer and x% are using Chrome while x% of your zoom users are using Chrome, etc. Knowing how many screen reader users are using iOS who visit your site versus Android may allow you to focus or not focus on browser specific issues or decide how to handle potential touch challenges with certain AT and user agent combinations.
Right now the community only has access to the WebAIM screen reader survey to get information about these topics. This is an important area where we need more data to focus and push back to organizations and say you can't just focus on one user agent just because all of your non-AT users are using that user agent -- you have to consider user agents used by people with assistive technology as well.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART GroupÂÂ
= EMAIL ADDRESS REMOVED =
703.637.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.
From: Lucy Greco
Date: Thu, May 11 2017 11:17AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
use best pracktuses and do not even think about detecting my screen reader
i don't want you to change your site thinking that is the only way to make
your site useable if that is the only way no one elce likes what your
doing and they might want you to re think the fancy stuff that needs to be
changed for them to
Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces
On Thu, May 11, 2017 at 9:36 AM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:
> > Another concern is "numbers." If you take any given segment of the
> disabled population, blind people, deaf people, low vision persons, screen
> reader users, etc., its numbers are going to be relatively low compared to
> the whole.
>
> Dave, I agree. Any numbers have to carefully be considered and message to
> stakeholders. It is however compelling to be able to say x% of your screen
> reader users are using Firefox or x% are using Internet Explorer and x% are
> using Chrome while x% of your zoom users are using Chrome, etc. Knowing
> how many screen reader users are using iOS who visit your site versus
> Android may allow you to focus or not focus on browser specific issues or
> decide how to handle potential touch challenges with certain AT and user
> agent combinations.
>
> Right now the community only has access to the WebAIM screen reader survey
> to get information about these topics. This is an important area where we
> need more data to focus and push back to organizations and say you can't
> just focus on one user agent just because all of your non-AT users are
> using that user agent -- you have to consider user agents used by people
> with assistive technology as well.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.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.
>
>
>
From: Jennifer Sutton
Date: Thu, May 11 2017 11:43AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
All:
This business of identifying assistive technology users (why are screen
reader users pretty much always the only target here, I wonder) has long
been of deep concern to me.
I am opposed to it for all the reasons that have been cited. And I
especially object (as I have told Jared privately, on at least one
occasion) to the citing of the WebAIM screen reader survey as anything
like "authoritative" in this matter.
I believe the question was poorly framed, i.e. lacked any of the kinds
of scenarios that would really explain/illustrate to most end-users
what the results of such identification would inevitably mean, and trust
me, it sure as heck won't all be for "their good." In fact, I'd say none
of it will be, despite the supposed "good intentions" of the industry.
Anybody remember which road is paved with "good intentions?"
As I believe many of us know, at least those of us who've been around
for a while . . . the WebAIM survey is, indeed, the only research we
have, but it is flawed since sometimes the screen reader vendors and/or
users, themselves, have often encouraged its use (some more blatantly
than others) as a "marketing campaign," i.e. popularity context. That's
not a criticism of the WebAIM team; there's nothing they can do about
it. But it is often context that people who see the survey as
authoritative lack. And it might even play into this question and its
responses. Who can say?
Getting back to the topic at hand:
I wonder how Deaf people would feel if they were tracked, very
specifically, every time they used captions. And I wonder how sighted
people who use screen readers would feel, since we know there are
sighted people (with and without print disabilities) who do. How could
one tell who is who? Let's break out the numbers and track all the
sighted testers who use screen readers, while we're at it. And then,
let's start sending them ads or surveys that we expect them to take for
free to "help" us. I mean, we need *very* specific data about each
screen reader user, so we can target our surveys, don't we?
Does anybody with a disability who reads this list remember how
liberating it was to be able to be on the Internet and not be
identified, unless one chose to? But we should give that up?
It's one thing if an iOS app. knows that I have VoiceOver turned on, but
that information is strictly kept within my personal device. I don't
like how few people actually are aware that, as far as I know, that's
true, but that's the choice Apple has made.
But it's quite another when we're talking about "phoning home to the
mother ship." As has been indicated by others, this is an issue of
privacy, security, safety, misuse/abuse of statistics that will
inevitably lack context . . . plus, I suspect, may result in other
issues we've not even yet anticipated.
Below my name is one of the bazillions of articles that has been written
on this subject; it just happens to be the most recent I've seen.
I think people who use AT are being naive if they believe that this kind
of data gathering would actually result in good. Sorry, folks, but I
learn from history. I do not believe that having this data would improve
people's commitments to accessibility; in fact, I think it would
fundamentally distract people from just "getting the work done."
Jennifer
Notice that this article's title suggests it'll be about people with
disabilities, but really, as far as I recall, it's primarily about
screen reader users. It would really be a good idea if people stopped
perpetuating the myth that the main people with disabilities we help
with web accessibility are blind people. I know most on this list know
that, but please help combat this kind of ongoing and misleading use of
terms.
https://www.mightybytes.com/blog/how-many-people-with-disabilities-use-my-website/
From: John Foliot
Date: Thu, May 11 2017 11:48AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
Jon wrote:
> the short answer is yes, with limitations on not knowing the specific
version or model of screen reader.
Really? Since when? (Although, after writing this, I do recall seeing a
third-party analytics program that could spit out iOS details, but only
iOS... and i freaked out when i saw that too.)
I recall a number of years ago at a CSUN (back in the LAX days) where the
president of Freedom Scientific explicitly stated that they would be
opposed to anything like that, and would actively block attempts at doing
that. Additionally, this is not a new request, yet this is the first time I
am hearing that you can actually target AT (outside of the hoary old Flash
test of years ago). Jon, can you point this list to further reading /
resources about this please?
Like others who have chimed in, there are serious security and privacy
considerations that need to be contemplated here. Additionally, sniffing
for a screen reader (for example) doesn't mean that the end user is
actually using the screen reader themselves (it may be a shared machine,
where 1/2 of a "couple" need a screen reader, the other doesn't), or
situations where both sighted and non-sighted users are looking at the same
web page together at the same time. Thus, the presence of AT alone is
meaningless, and attempts in using that data to modify the user-experience
will likely fail as often as succeed.
In short, IMHO this is a really bad idea.
> Does anybody with a disability who reads this list remember how
liberating it was to be able to be on the Internet and not be identified,
unless one chose to?
Agreed! What's the old New Yorker cartoon? "On the internet, nobody knows
you are a dog"? This is not a bad thing!
JF
On Thu, May 11, 2017 at 12:17 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = > wrote:
> use best pracktuses and do not even think about detecting my screen reader
> i don't want you to change your site thinking that is the only way to make
> your site useable if that is the only way no one elce likes what your
> doing and they might want you to re think the fancy stuff that needs to be
> changed for them to
>
> Lucia Greco
> Web Accessibility Evangelist
> IST - Architecture, Platforms, and Integration
> University of California, Berkeley
> (510) 289-6008 skype: lucia1-greco
> http://webaccess.berkeley.edu
> Follow me on twitter @accessaces
>
>
> On Thu, May 11, 2017 at 9:36 AM, Jonathan Avila <
> = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > > Another concern is "numbers." If you take any given segment of the
> > disabled population, blind people, deaf people, low vision persons,
> screen
> > reader users, etc., its numbers are going to be relatively low compared
> to
> > the whole.
> >
> > Dave, I agree. Any numbers have to carefully be considered and message
> to
> > stakeholders. It is however compelling to be able to say x% of your
> screen
> > reader users are using Firefox or x% are using Internet Explorer and x%
> are
> > using Chrome while x% of your zoom users are using Chrome, etc. Knowing
> > how many screen reader users are using iOS who visit your site versus
> > Android may allow you to focus or not focus on browser specific issues or
> > decide how to handle potential touch challenges with certain AT and user
> > agent combinations.
> >
> > Right now the community only has access to the WebAIM screen reader
> survey
> > to get information about these topics. This is an important area where
> we
> > need more data to focus and push back to organizations and say you can't
> > just focus on one user agent just because all of your non-AT users are
> > using that user agent -- you have to consider user agents used by people
> > with assistive technology as well.
> >
> > Jonathan
> >
> > Jonathan Avila
> > Chief Accessibility Officer
> > SSB BART Group
> > = EMAIL ADDRESS REMOVED =
> > 703.637.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.
> >
> >
> >
From: Jonathan Avila
Date: Thu, May 11 2017 11:55AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
I'll say that many clients tell us that 90% of their users are using Chrome and thus they only care about Chrome and we shouldn't test their content with any other browser. Having metrics about browser usage from a client site is compelling to tell them that the browser used by the general public may not be the browser that is used by most people using assistive technology. The WebAIM screen reader survey is helpful but having other metrics to back that up is important. So when I speak to analytic information I'm by no means referring only to screen reader users or implying that an alternative version of anything should be shown to the user. As I mentioned many sites today use high contrast detect and also reflow content based on zoom level. Adapting the same content for responsive sites is a prime example of how this can benefit users with disabilities. Responsive sites allow for linearization and increased sized of text benefiting users with disabilities. Knowing that people are viewing responsive sites helps to convince clients that they should invest in responsive sites.
As you point out people who are not blind use screen readers and different interfaces. People who don't have dexterity challenges also use Dragon. So I see this not about detecting disability but about knowing how the user wants to interact with your site -- whether it be their voice, keyboard, or a touch screen.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART GroupÂÂ
= EMAIL ADDRESS REMOVED =
703.637.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.
From: Jared Smith
Date: Thu, May 11 2017 12:13PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
Jennifer (and others) make very good points. We at WebAIM are the
first to admin that our surveys are based on a convenience sample that
is impacted by various uncontrollable factors (and we're trying to
secure funding to conduct a nationwide survey of a representative
sample of users with disabilities). It's perhaps a stretch to say that
the survey is representative of screen reader users generally, but we
can certainly state that it is representative of the 1465 respondents
who answered this question in 2014.
The question itself was "How comfortable would you be with allowing
web sites to detect whether you are using a screen reader if doing so
resulted in a more accessible experience?" 86.5% of respondents were
very or somewhat comfortable with allowing this.
It is correct that this question did not contain any number of
possible scenarios of how that data might be used (many of which would
create less accessible experiences, and thus be contrary to the
question). But the question itself was pretty straightforward and the
results rather definitive.
With that said, I'm also generally opposed to supporting assistive
technology detection in most circumstances because it likely would
result in worse accessibility on the web (as has been the case with
ARIA) and ghettoization of users with disabilities.
Jared Smith
WebAIM.org
From: Scott Brackett
Date: Thu, May 11 2017 12:16PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
So in terms of creating a better experience, what is the way forward then?
Is the idea to use an"opt in" model, like a button to request the mobile/
linearized version of the site, rather than making that decision for the
user?
Scott Brackett
Programmer for Short-Term Programs
Texas School for the Blind and Visually Impaired
NOTICE OF CONFIDENTIALITY: This electronic communication may contain
confidential student record information intended solely for school business
by the individual to whom it is addressed. Any disclosure (verbal or in
print), copying, distribution, or use of this information by an
unauthorized person is prohibited, and may violate TSBVI policy and/or the
Family Education Rights and Privacy Act (FERPA). Should you receive this
electronic communication in error, please notify the sender immediately at
the following telephone number: 512-206-9176 <512-206-9181> Thereafter,
please delete the message.
On Thu, May 11, 2017 at 12:55 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED =
> wrote:
> I'll say that many clients tell us that 90% of their users are using
> Chrome and thus they only care about Chrome and we shouldn't test their
> content with any other browser. Having metrics about browser usage from a
> client site is compelling to tell them that the browser used by the general
> public may not be the browser that is used by most people using assistive
> technology. The WebAIM screen reader survey is helpful but having other
> metrics to back that up is important. So when I speak to analytic
> information I'm by no means referring only to screen reader users or
> implying that an alternative version of anything should be shown to the
> user. As I mentioned many sites today use high contrast detect and also
> reflow content based on zoom level. Adapting the same content for
> responsive sites is a prime example of how this can benefit users with
> disabilities. Responsive sites allow for linearization and increased sized
> of text benefiting users with disabilities. Knowing that people are
> viewing responsive sites helps to convince clients that they should invest
> in responsive sites.
>
> As you point out people who are not blind use screen readers and different
> interfaces. People who don't have dexterity challenges also use Dragon.
> So I see this not about detecting disability but about knowing how the user
> wants to interact with your site -- whether it be their voice, keyboard, or
> a touch screen.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.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.
>
>
>
From:
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
I have reservations about screen reader detection (both as a web
professional and screen reader user). I shared them here:
https://tink.uk/thoughts-on-screen-reader-detection/
Léonie.
From: John Contarino x245
Date: Thu, May 11 2017 12:29PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
I better give an update to reasoning for my question.
Thanks for all the applies; still going through them. I didn't take into the account the possible privacy side of the question.
The thought first came into mind while I was using the screen reader testing and did a quick search for Weather Underground.
Upon getting to the 10 day report it was defaulted on the descriptive tab view.
Our site makes use of descriptive/narrative data display. I thought did the weather underground site know I was using AT and defaulted this view...
Turns out not the case for those wanting to know after testing with SR turn off.
My only thought was as a way to improve the user's experience with default views of descriptive/narrative views of data tables.
From: Birkir R. Gunnarsson
Date: Thu, May 11 2017 1:09PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
Another aspect of this is that there are tens of likely combinations
of screen readers, browsers and operating system, not to mention
customizations by users (e.g. auto forms mode or verbosity settings).
was reminded of this when I had a discussion a few days ago with a
friend of mine who is one of the best accessibility pros in the
business. She was thinking about changing a component because NVDA
intercepts the escape key, even in application mode, so users with a
menu widget open need to press escape twice to close it.
Sure, we can add role="application" to the container (or I think it
will work) as a hack to address that NVDA habit, but it would confuse
NVDA users that use a similar widget on other sites.
This is a standard menu widget, and pressing the escape key is coded
to close the menu and place focus on the trigger element. This is
coded exactly as recommended in the ARIA authoring Practices Guide.
I was working with mainstream developers a few months ago that added
so much invisible text to explain visual formatting, that it made it
difficult to read the webpage. They wanted all screen reader users to
understand all the intricacies of the visual formatting. I love the
centiment, but it ended up making a less accessible webpage.
Bottom-line, your average developer, not even a professional
developer, can understand or anticipate the intricacies of using every
screen reader. Even if they did, there are so many combinations that
they couldn't code for them all, or it would take weeks to write one
complex widget to suit all combinations in all situations.
This is why we have a standard. We need web developers to follow the
standard, but we also have to rely on browser vendors and assistive
technology vendors to translate standards compliant code to the best
possible end user experience.
This is the only way the web can become universally accessible.
To Jon's point, Yes, I agree we have too little user experience
research and too much hearsay about the accessible experience of the
web.
WE need to systematically and actively involve real users using real
assistive technologies in real situations in our research and
standards.
So if we can develop technology that can do that on a large scale,
without targeting individuals and invade their privacy or security, I
applaud that idea. It is just hard to develop such technology. The
saying "guns don't kill people" is simply not true.
-B
On 5/11/17, John Contarino x245 < = EMAIL ADDRESS REMOVED = > wrote:
> I better give an update to reasoning for my question.
> Thanks for all the applies; still going through them. I didn't take into the
> account the possible privacy side of the question.
> The thought first came into mind while I was using the screen reader testing
> and did a quick search for Weather Underground.
> Upon getting to the 10 day report it was defaulted on the descriptive tab
> view.
> Our site makes use of descriptive/narrative data display. I thought did the
> weather underground site know I was using AT and defaulted this view...
> Turns out not the case for those wanting to know after testing with SR turn
> off.
> My only thought was as a way to improve the user's experience with default
> views of descriptive/narrative views of data tables.
>
>
>
From: JP Jamous
Date: Thu, May 11 2017 1:26PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
I've always wondered, why do people try to make life harder rather than easier?
As a site is evaluated against WCAG guidelines, suggest as many fixes as possible to try to achieve an inclusive design. The closer you shift the slider towards an inclusive design, the more people you'd be able to accommodate.
Once you achieve that level, there is no need to try to gather any analytical information about users. The site would become robust and your customers would appreciate the convenience you provide them. If the customer is happy, the customer will continue to return. Of course, that's from a marking prospective.
If you have a dev team that you are battling with on daily bases, then welcome to the A11Y field. We all deal with it whether we work with UX design, devs or QA. The reason being is because of lack of awareness and not wanting to go back and redo the work.
As I always state from my development days, the easier you make it to customers the harder you make on developers. That is why the design should be simple straight to the point. People want to find their information, finalize their transactions and carry on with their work. Unless they are young kids with lots of time on their hands. Then they want something "Cooool", which meanings a pain in the neck for adults with busy lives.
From: Jonathan Avila
Date: Fri, May 12 2017 8:13AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
> sniffing for a screen reader (for example) doesn't mean that the end user is actually using the screen reader themselves (it may be a shared machine, where 1/2 of a "couple" need a screen reader, the other doesn't), or situations where both sighted and non-sighted users are looking at the same web page together at the same time.
I'm not talking about whether a screen reader is installed but rather looking at the user's behavior on the site to predict whether the user is navigating with a screen reader. I agree that a person could be using a screen reader and also use a mouse and the person may not have a disability. That supports the point that I am trying to make that the purpose is not to detect people with disabilities but to understand user behaviors using different technologies. So this isn't about disability -- many people without disabilities use speech output for navigation and speech output (and input) with Alexis and Siri. So it's more about understanding how the user is interacting with the site regardless of anything else.
> Thus, the presence of AT alone is meaningless, and attempts in using that data to modify the user-experience will likely fail as often as succeed.
I never suggested that the data should be modified or redirected for a screen reader user. That's the knee jerk reactions that everyone has had. I am against alternative sites. Separate is not equal.
In the future we will be interacting with content in many different ways both accessing the information and operating the content. Having information on those interactions is important to supporting different method of interaction, adaption, etc. It's nice to say just create your website using universal design and it will work for everyone. But that's an oversimplification that doesn't address the real world obstacles that even WCAG conformant sites have. We are living in a situation where assistive technology is always behind the current technology and where huge gaps in user agent support exist. This isn't just about screen readers -- for example, we need better data on other user behaviors such as zoom. Low vision people are asking for 400% zoom with no scrolling in the direction of the text in WCAG 2.1 on sites and some on this list are pushing back suggesting 150% is only possible. But without data we don't know what most people are using and we don't know what sites are really capable of. Data is an important part of research and can help us make more informed decisions on how prevalent zoom is used and at what level, etc.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART GroupÂÂ
= EMAIL ADDRESS REMOVED =
703.637.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.
From: Elizabeth Pyatt
Date: Fri, May 12 2017 12:35PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
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 ADDRESS 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
From: Tim Harshbarger
Date: Fri, May 12 2017 1:29PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
I think I understand the arguments for both sides. I tend to find myself favoring the side of no AT detection. I suspect in the current environment it would just be grossly misused--even though it might prove useful for those of us who want some more data.
It would be great if we could come up with at least some partial solution. We really could use something like object detection for things like aria.
Simplified, in object detection, you find out what a browser supports by checking to see if an object or its attributes are present. No support, no object or attribute. Unfortunately, I expect it would take a lot of work to implement something like this since you would only want a browser to make those attributes and objects available if both the browser and the active AT support it.
From: John Foliot
Date: Fri, May 12 2017 1:31PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
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 ADDRESS REMOVED =
Advancing the mission of digital accessibility and inclusion
On Fri, May 12, 2017 at 1:35 PM, Elizabeth Pyatt < = EMAIL ADDRESS 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 ADDRESS 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
>
> > > > >
From: Jordan Wilson
Date: Fri, May 12 2017 2:41PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
I'll jump in on Jon's side of this - I believe better data and tracking is important.
At scale its very difficult to manage accessibility priorities with so little data. I'm not looking for data to weigh accessibility against no accessibility, I'm weighing 90 accessibility projects against each other and looking to optimize the accessibility of what's already been made accessible.
A lot of this discussion has been fixed on the legal reasons for accessibility, but the marketing opportunity reasons can be even more compelling. If I'm missing 32,000 visitors a month because my site doesn't provide strong accessibility I don't just want to remediate to the minimum standard, I want to enhance the experience so that it's driving business. That means Marketing and Sales are now advocates and not just Legal/Compliance. Marketing is driven by data, without it we'll never get them on board.
How many of you are building sites that are compatible w/ IE5 or IE6? The answer is (hopefully) none. Because of data. We make decisions because of data all of the time. We've all been in a meeting where someone uses theory craft to voice an opinion but then someone else shows the actual data and the opinion shifts.
The same is true of accessibility data - my accessibility budget is large, but we all have limited resources. I have hundreds of sites and millions of assets that I need to make accessible. Stronger data would allow me to better allocate our resources to benefit the most people over time. Without it, I'm doing the best I can in the dark based only on opinion and I have very little information about what is really going on.
Here's how I would use good data if I had it:
Prioritization:
Two sites get a ~ 8 million hits a month. Site A gets 150,000 AT hits a month, site B gets 63,000. Let's remediate Site A first then Site B.
Identifying Pain Points:
90% of AT users started this particular form and didn't complete it. We should re-evaluate that form to make sure we didn't miss an issue.
Showing lost opportunity:
There are 130,000 AT users visiting the site but only 500 completing a transaction. That rate is much lower than the site average. How can we optimize the experience?
Avoiding waste:
Only 112 AT users / year are using this archival PDF service but the effort to remediate will take a ton of resources. We'll provide an appropriate on-demand solution until we have finished other more important accessibility projects.
Identifying trends and outliers:
Across all of our sites, AT user's average time spent per visit is 105% of non AT users. Site X is at 20% why is there such a discrepancy?
Showing improvement trends:
Ever since we remediated the site, AT users are spending on average 4 minutes per visit which is now comparable to the average and up 140 seconds.
Having AT data is not about disability detection - in fact as Jon described that's not even possible. Detecting keyboard input doesn't tell us anything about a user's individual disability. It really is about technology patterns. As a manager of multiple digital projects, the disability of one individual is not useful and is protected under security and privacy laws.
What's useful are cumulative technology trends, outliers and prioritization of solutions.
-Jordan
On 5/12/17, 10:13 AM, "WebAIM-Forum on behalf of Jonathan Avila" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
> sniffing for a screen reader (for example) doesn't mean that the end user is actually using the screen reader themselves (it may be a shared machine, where 1/2 of a "couple" need a screen reader, the other doesn't), or situations where both sighted and non-sighted users are looking at the same web page together at the same time.
I'm not talking about whether a screen reader is installed but rather looking at the user's behavior on the site to predict whether the user is navigating with a screen reader. I agree that a person could be using a screen reader and also use a mouse and the person may not have a disability. That supports the point that I am trying to make that the purpose is not to detect people with disabilities but to understand user behaviors using different technologies. So this isn't about disability -- many people without disabilities use speech output for navigation and speech output (and input) with Alexis and Siri. So it's more about understanding how the user is interacting with the site regardless of anything else.
> Thus, the presence of AT alone is meaningless, and attempts in using that data to modify the user-experience will likely fail as often as succeed.
I never suggested that the data should be modified or redirected for a screen reader user. That's the knee jerk reactions that everyone has had. I am against alternative sites. Separate is not equal.
In the future we will be interacting with content in many different ways both accessing the information and operating the content. Having information on those interactions is important to supporting different method of interaction, adaption, etc. It's nice to say just create your website using universal design and it will work for everyone. But that's an oversimplification that doesn't address the real world obstacles that even WCAG conformant sites have. We are living in a situation where assistive technology is always behind the current technology and where huge gaps in user agent support exist. This isn't just about screen readers -- for example, we need better data on other user behaviors such as zoom. Low vision people are asking for 400% zoom with no scrolling in the direction of the text in WCAG 2.1 on sites and some on this list are pushing back suggesting 150% is only possible. But without data we don't know what most people are using and we don't know what sites are really capable of. Data is an important part of research and can help us make more informed decisions on how prevalent zoom is used and at what level, etc.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.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.
From: Jonathan Avila
Date: Fri, May 12 2017 6:06PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
> 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 ADDRESS REMOVED =
703.637.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.
From: Birkir R. Gunnarsson
Date: Fri, May 12 2017 6:34PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
It is a fact that we have too little data on how many people with
disabilities use our sites and apps.
I wonder if it is the technical challenges that discourage us from
trying to find out, or if we are worried that the actual number of
people with disabilities who use our site is a lot less than we try to
indicate using general population percentages.
It shouldn't matter, but it would still be good to have numbers,
especially numbers that create a solid accessibility business case.
The dangerous thing about measuring only the number of people with
disabilities (if such a thing is possible) who use our site is that we
are not considering people who may simply have given up on using
technology, and that could be lured back to the site with more
options, better assistive technology and a more accessible web.
It's like tracking customer complaints, almost 80% of customers leave
sites they are not happy with and less than 10% of unhappy customers
actually bother to send in a complaint.
So if you start using customer complaint as a measure of how many
customers would benefit from fixing a particular website issue, you
might be under estimating that number by a factor of 10.
On 5/12/17, Jonathan Avila < = EMAIL ADDRESS 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 ADDRESS REMOVED =
> 703.637.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.
>
>
From: Jonathan C. Cohn
Date: Fri, May 12 2017 6:44PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED =
> 703.637.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.
>
>
From: Jeremy Echols
Date: Mon, May 15 2017 10:59AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
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.
From: Jonathan Cohn
Date: Mon, May 15 2017 11:22AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
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 ADDRESS 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.
>
>
From: Mallory
Date: Wed, May 17 2017 1:44AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
> On Mon, May 15, 2017 at 12:59 PM Jeremy Echols < = EMAIL ADDRESS REMOVED = >
> wrote:
>"Now you want to split it into AT users and non-AT users?"
I don't think that's the question we want to ask. It's more like, if
some of the things on your single site for both mobile and desktop has
some parts that work terribly on mobile still and you don't know any way
to fix it except by offering a version that works better for [your idea
of mobile] but is kinda sucky, clunky, unweildy on desktop... the
shortsighted step is to ask "can I detect mobile?" But that's not what
we really want to ask.
Instead of detecting [mobile, touchscreen, AT, network speed], what we
*really* want are better ways to build things and better support by
browsers, AT, and the specs of HTML, CSS etc so that our "one thing"
that we'd like to build for reasons of cost and maintenance actually
does work, and not half-works or kinda works if the user tries twice as
hard, but just works.
Sometimes if you're horribly creative, you can build a bit of a
monstrosity that accounts for all the major players and you get awards
for making a great experience for all your users. But we're not all
creative geniuses, and not all those needing a technical solution can
afford to hire geniuses, so it would be much nicer and better for
everyone if these solutions could be simpler and better supported.
Every time someone asks "is there a way we could detect AT?" the real
question behind it is usually "AT doesn't work well with this thingie,
how can I get this thingie to work or what is the alternative that
actually works for everyone?" So maybe we can turn that energy around
and get some better support for things?
No, we don't *really* care what browser, AT, OS people are using. We
don't care if they're wearing pants. That's just what comes out when
stuff doesn't work and we're grasping for solutions in desperation.
From: Patrick H. Lauke
Date: Wed, May 17 2017 2:17AM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | Next message →
Related to this topic, we've had some further discussions on twitter
(which annoyingly got a bit fragmented, so two separate pointers below):
https://twitter.com/jessebeach/status/864082337792970752
https://twitter.com/patrick_h_lauke/status/864084060309737473
My take, in short: instead of a high-level "detecting if a user has a
'screen reader'" or AT in general, we should explore getting very
specific and granular information (similar to how nowadays we don't
really want a 'the user is on a mobile device', but rather having
indications of viewport size, connection speed, use of a touchscreen,
and so on).
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Maxability A11Y
Date: Thu, May 18 2017 10:56PM
Subject: Re: Web development; How to identify if a screen reader is in use
← Previous message | No next message
At this point I believe that tracking assistive technology is not a good
idea. Here are my thoughts put together couple of years back and I still
stand on it. After reading this email conversation I want to publish a
related article. May be an unbiased information leaving the developers take
their decision.
http://www.maxability.co.in/2015/08/developers-please-dont-detect-my-screen-reader/
Thanks & Regards
Rakesh
www.maxability.co.in
On Wed, May 17, 2017 at 1:47 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:
> Related to this topic, we've had some further discussions on twitter
> (which annoyingly got a bit fragmented, so two separate pointers below):
>
> https://twitter.com/jessebeach/status/864082337792970752
>
> https://twitter.com/patrick_h_lauke/status/864084060309737473
>
> My take, in short: instead of a high-level "detecting if a user has a
> 'screen reader'" or AT in general, we should explore getting very specific
> and granular information (similar to how nowadays we don't really want a
> 'the user is on a mobile device', but rather having indications of viewport
> size, connection speed, use of a touchscreen, and so on).
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >