Re: User Contexts: identifying assistive technologies

Sent from my iPad

On Jun 4, 2013, at 8:24 PM, "James Craig" <jcraig@apple.com> wrote:

> 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.
>
James, I have been quite open about this all along. There are sites that
will turn off access features for performance reason if they are able. In
fact Chrome will not expose access features on Windows unless an AT
produces a registry entry.

Now, those same sites could start using the fact that you are a screen
reader user to track you.

> 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.
>
James, I know you have the right intent but but I don't believe the rest of
the web will have the same intentions.

> 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)"

Yes, I understand how these work.
>
> 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."
>
Yes, but the user may need to use the sight and the only way to do that is
to allow access and tell them they are using a screen reader.

> 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.
>
I was away on vacation and I started following this thread. I have
concerns. I am not trying to "loft grenades". :-)    As you know I have
been up front on my concerns here way before the group formed.

Look I would ask that we cast a wider net on this one than our group.

I am traveling the next few days unfortunately.

> 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/


>