Re: User Contexts: identifying assistive technologies (resending to add vision australia)

James,

I managed to get Internet access on this flight I am on. Let me try to
articulate my concerns and a way forward.

But first, it is not that I don't think we are doing everything we can from
an engineering perspective to give the user control over supplying these
settings to a web site. I also understand how the security mechanism works
and why you think it is important to expose screen reader preferences to a
web application. I also appreciate that you are clearly articulating the
risks in the documentation.

Here is the situation and use case if you will:

- Some apps. like gmail and most browsers pay a tremendous amount of
attention to performance and almost to a fault. Consequently, there has
been numerous instances where applications disable accessibility features
until the user activates them:
    - Open Office has had a checkbox that needed to be checked to support
the Java Access Bridge.
    - Google Chrome checks the Windows system registry to see if a screen
reader was registered before exposing the accessibility tree. Firefox does
something similar.
    - Java has a properties file called accessibility.properties that
installs the access bridge only if applied for users that need it. This is
for performance reasons.

So, I can easily see that a web site would not expose say ARIA support if
they knew a screen reader was not being used. There is clearly enough prior
examples where accessibility features are removed to improve performance
for those users who do not need this support. There may be sites where
users need to access the site but they don't want them to expose this type
of information as it may be used to start tracking this information about
the person.

So, I believe it is better that we address this issue now vs. later on. I
think we need to cast a wider net than this group and I would be asking
non-browser people the following:

The IndieUI working group is trying to produce a better experience for
users who are blind. We feel that to do this we need to expose additional
information that would indicate that the user is operating a screen reader.
We are employing a security mechanism that allows the user to determine if
a site is provided this information so the user does have control over what
features are exposed to a site. However, there may be instances where these
sites will not provide screen reader support, for performance reasons,
unless the user explicitly tells the site that they are using a screen
reader. A site could also use this information to track this need about the
user which is something that has not yet been possible today.

Given the fact that we have given user control over what features are
exposed to a web site we feel the benefits of providing this information
outweigh the potential for a site to track the user's need to use a screen
reader. Do you agree?

We would of course list the benefits.

So, by casting a wider net I would take this to the NFB, Vision Australia,
and RNIB. If we have done this and we get acceptance then I would be much
more comfortable with this approach and it would document that we did the
due diligence to ask a broader set of stake holders. It is clear the intent
is to provide a better user experience. I just don't want us to do all this
User Context work and then have us end up in a rat hole down the road.

I don't think doing this is spreading FUD. I hope you can see this now.




Rich Schwerdtfeger



From: James Craig <jcraig@apple.com>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS,
Cc: Jason White <jason@jasonjgw.net>, "public-indie-ui@w3.org"
            <public-indie-ui@w3.org>
Date: 06/04/2013 08:24 PM
Subject: 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/