On February 26, 2014, the webAIM project published the results of their 5th screen reader user survey. Two questions were new in this survey that pertain to a recently growing desire of some web developers to know whether they’re dealing with assistive technologies on the other end or not. The results were rather shocking to me as a representative of a browser vendor and experienced assistive technology user:
78.4% of respondents were very comfortable or somewhat comfortable with letting a web site know they are using a screen reader. And even 86.5% were very or somewhat comfortable if doing so resulted in better accessibility of the website. For each question, only roughly 2% of respondents answered “I don’t know” to that question.
In my opinion, it should have been the other way around. I took the questionaire myself back in January, and because I am involved in making a web browser and knowing about the various desires by web developers and some standards people, I knew what was meant here, and also knew the implications. I submit, carefully, and without wanting to diminish anyone’s maturity in this matter, that most of those who responded didn’t actually know what the screen reader detection actually means. There was just too little context given, and information on this subject is also not so easy to find on the web.
For one, letting a website know you’re using a screen reader means running around the web waving a red flag that shouts “here, I’m visually impaired or blind!” at anyone who is willing to look. It would take away the one place where we as blind people can be relatively undetected without our white cane or guide dog screaming at everybody around us that we’re blind or visually impaired, and therefore giving others a chance to treat us like true equals. Because let’s face it, the vast majority of non-disabled people are apprehensive in one way or another when encountering a person with a disability.
Second, this is just a modern form of the text-only alternative web sites of the 1990s when screen readers were still learning to stumble around graphical user interfaces, let alone the web, and those text-only alternatives were a necessary evil to get anything done in most cases. In the early 2000s, as screen readers became better and browsers more modern, those faded away. And only in recent years has the trend sort of reverted, primarily because people just don’t know, or don’t care, to make their new shiny dynamic web sites and widgets properly accessible, even though the techniques exist to do just that. The current worst of the bad examples is the “accessible alternative” of the Audible.com web site. For one, its feature set is limited, and second, it constantly throws you back to the standard web presence, when doing searches, for example, and other totally screwed user experience snafoos. Or is there anyone out there who is actually wanting to tell me they enjoy this and find it even remotely useful? And to add insult to injury, the stuff that is currently a bit tricky on the standard web site can easily be fixed by some WAI-ARIA markup and some consistent keyboard navigation JavaScript.
And the old arguments still apply: Alternative versions of web sites tend to get out of date, no longer being maintained, and creating and maintaining them is more expensive than properly applying markup and learning the web accessibility skill properly once.
Third, there are security implications. Ever since I started working for Mozilla in 2007, there have been repetitive inquiries about exposing whether a screen reader is running with the browser, and if so, also granting access to the accessibility APIs to content JavaScript to manipulate what screen readers read to the user. Either of these would give web sites knowledge or exposure of operating system bits that, in every other case, would be considered unacceptable. You wouldn’t want to give web site JavaScript access to your file system, which type of keyboard you’re using, what brand your processor is, or if your machine still has a floppy drive or not, would you? Accessibility APIs hook into all kinds of channels to expose all the needed information to assistive technologies. Granting a web site access to these APIs would open a level of access to a computer that is just unacceptable, and unnecessary, for a web site to have.
Some might argue that apps on mobile devices have access to that information, even through defined APIs, and the same is true on desktops. Yes, but the entry for an app is much higher. There is usually an installation process, and apps have by definition access to more information. They aren’t as casually visited as a web site is. Even on Firefox OS, there is a 3 level app privilege model, even though Firefox OS is built of web technologies, and not all of these levels will have access to the information whether the screen reader is running or not.
Aural style sheets never gained acceptance because the expected gain was just not there, and the desire to have equal access to the same content as everybody else was much stronger. More recent requests all are just the same thing in different disguise.
WebAIM should either have given more context to this question, especially since it was not a topic even most advanced screen reader users would be familiar with, or they should have asked a third question highlighting the privacy/security context. Funny enough, the question about plain text alternatives was answered with “seldom or never” by almost 30% of respondents, so the desire to use such sites in general is much lower than the two screen reader detection questions might suggest. So I again submit that only the lack of proper context made so many people answer those questions differently than the one about plain text alternatives.
It is my sincere hope that the work currently done by the IndieUI group at the W3C will provide enough incentive for web authors not to abuse the querying mechanisms described, and that this will only be used by very well-informed sites where the developers provide actual value. The privacy examples in that document look at least promising. Let’s hope it all holds up until this becomes a standard one day. I, for one, will strongly discourage web developers who ask me from using this unless I am personally convinced they know what they’re doing. And yes, like with Location sharing, I will personally be very restrictive about allowing sites access to that particular information if I’m asked.
related reading: Bug 946370 – implement CSS reader media type
Rather than spreading undeserved fear about IndieUI, I encourage you to participate in the process. You’ve never commented on the editor’s draft, which incidentally is still pre-WD, and you clearly don’t understand the use cases or the security features that are included to protect user privacy. Most websites should never have this information, and most will never get it but some things just can’t be done without access to more information about the user. What you’ve written about IndieUI above is spreading misinformation and being an irresponsible web citizen.
Get involved in the process. It’s open to all.
James, using prompts to have users make choices is a terrible “solution” to the privacy problem. For one, because people don’t read them. For another, because they create security holes (for instance, many currently shipping browsers can be ‘hostaged’ by cleverly applying onbeforeunload, frames, redirection, or some combination thereof). For another, because it inevitably increases fingerprintability. For yet another, because if I have 5 bits of info I need for my website, either the browser will have to show 5 prompts (which is even more terrible UX) or we’ll need to compromise on security (ie access to one thing means access to everything). For yet another, because you’re opening users up to phishing-type things. Anyone can have the prompt say “I need this information to provide you with a better experience”, and then sell the information on. And finally, it seems the draft doesn’t care about authentication, so if the website isn’t using good SSL for all it does, the data will leak to e.g. ISPs, who I’m sure would also be interested…
I don’t see the draft providing any more protection than the prompt. That seems to be the central privacy feature of the draft. To be sure, from a fundamental perspective, if you have information X and you want to make it available to others, you essentially need the user to determine intent and what privacy guarantees the website gives. We as users are notoriously bad at making that judgment.
For the record, we’re in 100% agreement that it would be terrible to allow screen reader detection API without restriction, but that’s not what IndieUI User Context proposes.
In a similar way, we allow location sharing with certain websites, but no browser gives out this private location information without a user prompt. The current editor’s draft of IndieUI User Context even increases that restriction by requiring authors provide a justification explaining the reasons why the site needs access to this information. If you don’t like the explanation, don’t share your information.
@Marco, I found it scary that so many people were so open to allowing to know they are using a screen reader. This just opens up the old discussion of “accessibility means I can arrow through with JAWS all right, correct?”
@James, Unfortunately the process is not open to all, as W3C likes to think. For my situation, I either can get 3 or 4 levels of approval to be able to use information I know from work to contribute. My other option is to talk to my ethics department and swear I’ll never do anythin W3C related while at work, or use knowledge I have gained from my workplace. Or I guess I could get a new job.
Your post echoes my sentiments perfectly. As a code-literate, informed non-developer, I feel highly uncomfortable at the thought of such a feature being implemented, however securely and responsibly it is done and used.
There are roads down which it is very dangerous to walk; I think if there is a place where universal design is not only desirable but actually possible, that is the web.
S.M.
This was possible years ago in flash ( and so technically still possible ):
flash.Accessibility.active
“Indicates whether a screen reader is active and the application is communicating with it. Use this method when you want your application to behave differently in the presence of a screen reader.”
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/accessibility/Accessibility.html
Yeah, but that wasn’t a feature so much as a security issue. Actually, that can be said of Flash in general.
@jer brand
technically possible to detect a running MSAA client which does not = screen reader running. And confined to Windows platform as MSAA is windows only. Related reading: Developer Beware: Using Flash to Detect Screen Readers (2008).
@RyanBenson
> @James, Unfortunately the process is not open to all, as W3C likes to think.
Anyone can file email feedback or post a bug to W3C Bugzilla component, even using an alias if needed for job security.
@Gijs
I’d love to have you file some feedback on the draft as well, either before or after it actually it is “first published.” (Reminder again that this is a publicly accessible editor’s draft, but it is not yet published as a working draft.)
> the draft doesn’t care about … SSL
We thought about requiring SSL to use some restricted properties like this one, mainly as a backup to ensure its only used on sites that know what they are doing and actually need it (document editing suites for example), but it’s not needed for security unless the site was try to store that user preference on the server via XHR. All the back-and-forth happens on the client, so it’s not as if this data goes over the wire via HTTP. Maybe I’m misunderstanding your point. Again, please file it in bugzilla or through email b/c we don’t use blog comments as a issue tracker.
> …if I have 5 bits of info I need for my website, either the browser will have to show 5 prompts
Please read the spec (or wait until it’s a WD and then read it). Specific UI exposure in browsers is an implementation detail, but nothing in the spec requires this, and the ED even recommends restriction categories (e.g. general, media, screenreader, etc.) with separate justifications.
> Anyone can have the prompt say “I need this information to provide you with a better experience”, and then sell the information on.
As @Jer points out, this information is available today heuristically and through disparate published APIs and the sites don’t have to ask for it or provide any justification. Fingerprinters and shady dealers already get this info a variety of ways and do their best to not alert you to the fact that they are tracking you, so I doubt they would want to broadcast that knowledge through a user prompt. We’re trying to codify a way to make this information available in a standard way while being diligent about the potential privacy concerns. Again, I encourage you to provide feedback to the working group in bugzilla or email.
I can see a lot of the technical/privacy/security challenges with a full blown API but as someone who works with small organisational websites a lot, knowing how many screen reader users (a simple user-agent style record would be enough) were visiting them would certainly help in allocating resources and convincing people in making the right decisions. The argument that all websites should be made accessible by default (while fine as an ideal) simply does not stand up in the real world of small to medium websites. A proper accessibility audit often costs as much as the website development so companies just rely on the word of developers that they deliver ‘compliant’ (NOT accessible) websites. Most of these developers are absolutely clueless and are essentially lying but their clients don’t have the knowledge to identify the issues. And then the standard response is: ‘How many blind people come to our website, anyway.’ And at the moment, we don’t have an answer for them. I, too, am against alternative versions of websites, but even if some sites chose that option, most would probably just focus on straight up accessibility. As it stands, they’re just burying their heads in the sand. And the accessibility community is not making it easier by not giving them information. (After all, how hard would it be to add a switch user agent option to a screen reader for those who feel strongly about this.)
@Dominic wrote:
> as someone who works with small organisational websites a lot, knowing how many screen reader users (a simple user-agent style record would be enough) were visiting them would certainly help in allocating resources and convincing people in making the right decisions.
I personally think that’s an argument against the API. It sounds like tracking user metrics for the purpose of convincing your management to do the right thing. That’s almost like putting a surveillance camera near set of stairs so you can track how many wheelchair users were unable to get into the building.
> clients don’t have the knowledge to identify the issues. And then the standard response is: ‘How many blind people come to our website, anyway.’ And at the moment, we don’t have an answer for them.
Answer: One is two many, and at that point, it’s too late for that one. Just build the wheelchair ramp.
> And the accessibility community is not making it easier by not giving them information.
The accessibility community you speak of is also a disability community, and they have the right to protect the knowledge of that disability from anyone for any reason. I understand you have good intentions, but I don’t think you’re helping the case. I wrote the API proposal—I want it to succeed—and yet your comments here in favor of the API have proven more of Marco’s points than mine.
It seems Marco is at least right that the working group is going to have its work cut out for it to “provide enough incentive for web authors not to abuse the querying mechanisms described.”
PS. Marco, thank you for the edit to the last paragraph. I think it’s well phrased now and retract my previous comment about “being an irresponsible web citizen.”
@Dominik (sorry for misspelling your name earlier)
I agree that this is a real problem, but I don’t think the screen reader detection API is the right solution for your problem. Better developer and auditing tools may be.
I do think exposing screen reader preferences (or other AT-interoperability preferences) can be useful, even necessary, but most of the use cases are in large scale document editing suites. For example, in web-based spreadsheet apps, there is a real computational and memory cost for inserting extra attributes on tens of thousands or hundreds of thousands of elements. Google developers specifically requested this because adding accessibility support to Google Docs caused a measurable performance regression for all users due to the sheer number of elements that were being modified.
Another example is that, due to the severe inadequacies of contenteditable implementations today, many advanced web-based document editing suites use custom rendering views and need to make them accessible using scripted live region announcements. There is currently no way for these web applications to adequately respect a screen reader user’s settings for things like typing echo, verbosity, etc, so the interface of extremely complex web applications will always feel foreign to a screen reader user until some of these preferences can be shared with trusted web applications.
The specification should probably include some more detailed examples like these.
I think there needs to be some way of figuring out which screen reader is being used and on which operating system, but the privacy element does need to be taken into full account.
If we can come up with a way to make this process not only happen, but inexpensive to put into play, then we’ll have it made.
While there are current standards for “putting alt tags on graphics and other elements”, even that is sometimes not enough.
Not only because a lot of web developers don’t have a clue they even exist, but some are to blasted lazy to put the alt tags in their ccode, but they sometimes charge a rediculus amount to put them into the site code.
Having some web design experience, I’ve been able to educate fledgling web devs on the fact that not only do said alt tags exist, but how to put them in as well.
Can’t the detection be optional on the part of the users like do not track option in browsers?
while I fully agree with Marco, in many parts of the world, user metrics are perhaps the only solution for convincing website devs.
Also, in my specific case, many devs (in whatever part of the world) do not even realize that a blind person would want to access their website. Websites for downloading data, using online data analysis, language learning webapps, and online markdown editors come to mind.
Well, nice discussion !
@BlindIndianWomanEconomist wrote:
> Can’t the detection be optional on the part of the users like do not track option in browsers?
Yes, and the IndieUI API already takes this into account. As currently specified, the user would be prompted on a per-domain basis. Web site authors would have to include a string explaining why they need this information. Users could determine if the reason was justification enough to share their settings, and if not, they would just click “Don’t share” or press the Escape key.
My main argument for the API is that this information can already generally be detected through heuristics. This just standardizes the API and adds a security mechanism so that users can 1) know when a site is trying to user their settings, and 2) deny that access if desired.
I don’t think it is just a privacy issue with regards to data but also the fact that visually impaired users fear they will lose their right to be treated like anyone else.
The web is a place where nobody knows they are disabled and are therefore not treated any differently, something that unfortunately does not happen in the real world.
As a developer I understand that having information on who uses screen reading software could be an advantage with regards to proving to product owners that we need to account for these users, in the same way we do for IE users with conditional style sheets.
I can see both sides of the argument but the solution is simple, developers (myself included) need to code sites with the visually impaired in mind. This needs to be ingrained into devs when they are learning to code. Just as we learn to indent code, use nav tags for navigation, we should be taught WAI-ARIA markup and keyboard navigation.
Sadly as far as I am aware this isn’t happening.
A couple of U.S. government websites have a identify yourself as blind user checkbox.
I apologize to all who are in favor of this type of proposed loophole to proper web development, but I am going to have to say that I have only seen one example of a case where this API could be useful and in my opinion there is no need to provide a generalized loophole that introduces all of these other problems when there is already an easy fix that is already implemented by the company that was targeted by the example.
Google docs and any other web apps that run into that performance degradation problem could take the Gmail approach and provide a link to the accessibility rich text only version right at the tip top of the page. We’re dealing with simple cases of minorities and majorities here. The web is finally getting to a point where when you design properly it works properly. There is no need to encourage people to start taking the easy way out when so much work has already been put in to make creating accessible content a pretty trivial task for the majority of web sites.
Someone mentioned the good old “alt” tag in a different comment, and this brings up a point that I think should be stressed on each and every discussion regarding accessibility. While this tag is nice, one, it is rarely used to it’s full potential, and two… Accessible web content all too often seems to be defined as just using this tag. I can’t speak for all, but I can surely speak for this low vision user. Using aria-label or a label for element on your form fields is WAY more useful to me than alt=”A picture of a cat”.
Another huge useability problem that is often overlooked is the presence of in-text links. If you are going to work on an API to make things better for everybody involved, please make that one. Doing so would allow pages to be easily read by screen readers without needing to rewrite 99% of the internet. Lets focus on users not Google’s bottom line. I’d much rather click a link than have to okay anything anyway. If you’re already going to build things twice, just link to it in this way and BAM… Problem solved. You know, now that I think about it more, the needed API was one of the first elements on the web. It’s the A HREF if you need an acronym. Now lets feed starving children.