Re: User Contexts: identifying assistive technologies

On Jun 4, 2013, at 1:49 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:

> On Jun 4, 2013, at 7:49 PM, "James Craig" <jcraig@apple.com> wrote:
> 
>> On Jun 4, 2013, at 5:46 PM, James Craig <jcraig@apple.com> wrote:
>> 
>>> On Jun 4, 2013, at 1:39 PM, Richard Schwerdtfeger <schwer@us.ibm.com> wrote:
>>> 
>>>>  We are really stepping on privacy issues be forcing the user to have to expose the fact they are using a screen reader to be able to use a site.
>>> 
>>> We're not doing that.
>> 
>> In the same way, Location Services doesn't "force" you to share your location with a web site either.
> 
> well, if you want to have an accessible version delivered, triggered by stating you are using a screen reader, you are. 

Where is this FUD coming from? The implication that any website would *rely* on this for access is preposterous. This has absolutely nothing to do with blocking access for accessibility, and any implication that it does only serves to spread fear, uncertainty, and doubt. 

This is for optimizing experiences, not shutting off accessibility. Think if this as object detection for assistive technology. For example, if you were using a magnifier, and your zoom level and point of regard was such that you could not see status updates at the top or bottom of the screen b/c they were out of view, the web application could choose to provide a better experience by either 1) position them in view, or 2) speak an announcement via the Web Speech API. If you chose not to share your magnifier settings, the web page would just work the way it did before, with the status field out of view.

On top of that, the spec draft is *full* of privacy-related notes intended to address these concerns, including but not limited to:

1. "Description TBD (esp re: privacy and fingerprinting, and prompt access for certain parameters on a per-domain basis, similar to location sharing)"

2. "The different settings key groupings are intended to allow individual privacy restrictions for each group. We're still working on the best way to spec those privacy restrictions."

3. "Type settings will not be restricted (by default) from the requesting page, primarily because a site can figure out all of this information using some creative CSS and JavaScript. These keys are therefore primarily intended as convenience accessors so that web authors can more easily provide adaptive interfaces that work well for all users."

4. "TBD: Settings in this section will be subject to domain-specific privacy policy limiting initial access and prompting the user. TBD whether these keys may be accessed only on a user triggered event, as opposed to onload for example."

Some of these concerns are even called out in our group charter. Don't just lob a fear grenade and run! If there's a real problem, illustrate it with evidence, and better yet, suggest a solution. In this case, the "forcing the user to expose their disability" comments are both untrue and unproductive. This thread will do more harm than good.

The unfortunate alternative to standardizing this information is the approach Google appears to be taking with a completely non-standard ChromeVox-only accessibility API [1]. If you think web standards development and accessibility was terrible in the 90s, wait til you see what it's like where every screen reader and AT implements its own incompatible API for web authors to learn. If we don't standardize this stuff, it will happen anyway… It'll just be worse.

James

1. http://accessibility.oit.ncsu.edu/blog/2013/05/31/screen-readers-at-a-crossroads/

Received on Wednesday, 5 June 2013 01:24:38 UTC