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

Colleagues:

It's good that we're delving into the privacy implications of our specs.
But, as I think we've always known, the privacy ramifications are not
purely technical questions. While we may be widely acknowledged as
authorities on technology as it respects persons with disabilities, we
do not enjoy this mandate outside the technical domain. Therefore, the
point below about asking for guidance outside our group is well
taken--and should be no surprise, frankly.

I will take the action to elevate this to our domain lead, Judy Brewer.
This is our first stop before we canvas more widely. Meanwhile, let's
continue to build the dataset of pros and cons, of use cases, and of
technical implications. Let's provide the community's policy wonks with
the best technical data we technical wonks can provide to obtain a path
forward that can, hopefully, reflect a community approach, not just our approach.

So, let's keep discussing, but let's understand we can't settle this
question for some time.

Janina

Richard Schwerdtfeger writes:
> 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/
> 
> 



-- 

Janina Sajka, Phone: +1.443.300.2200
   sip:janina@asterisk.rednote.net
  Email: janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Protocols & Formats http://www.w3.org/wai/pf
 Indie UI   http://www.w3.org/WAI/IndieUI/

Received on Wednesday, 5 June 2013 16:03:44 UTC