Re: [user-context] What are the use cases for exposing screen reader or magnifier version info?

Dominic,

Although the page load may increase if authors were to bind CSS to ARIA
attributes the amount of JavaScript would drop considerably. Also, the
really big overhead for ARIA is the keyboard support which should drop
considerably with Indie UI both from a device independence perspective and
from a content adaptation, based on user preferences, perspective.

So, this looks like a longer term strategy. If this approach were taken how
do you address some of the added functionality that is provided for by
screen readers and magnifiers like detailed review mode, etc. that you
would not (at least it is not readily apparent to me) get form a media
adaptation?

Rich


Rich Schwerdtfeger



From:	Dominic Mazzoni <dmazzoni@google.com>
To:	Janina Sajka <janina@rednote.net>,
Cc:	public-indie-ui@w3.org
Date:	02/04/2013 01:22 PM
Subject:	Re: [user-context] What are the use cases for exposing screen
            reader  or magnifier version info?



I understand the privacy concerns. I also fail to see the benefit of
reporting specific AT brands and version numbers, that would more likely to
encouraging overoptimizing for one tool rather than finding general
solutions.

I'll give a couple of reasons why web developers might like to know that
assistive technology is running:

1. ARIA can be incredibly verbose. In order to make some apps accessible,
many hundreds of elements might need to be annotated with ARIA. In some
cases we've seen this increase the size of the resulting HTML by 50% and
increase page load time by 10%. Web developers sometimes feel like they're
forced to choose between accessibility and performance.

2. Some applications might act in a dynamic way that is not inherently
inaccessible, but can be confusing for an AT user. As an example, imagine a
context-sensitive toolbar that only shows commands relevant to the
currently selected item in a list. This can be quite intuitive for a
sighted user because they can visually see toolbar commands appear and
disappear as they move through a list. However, an AT user might not
realize items are appearing and disappearing, so they might when they first
explore the toolbar they might not understand why certain commands aren't
there. An application could detect the presence of AT and simply switch on
a preference to show all toolbar items by default.

One potential idea to explore would be to make use of CSS media types for
accessibility. I know there are media types for speech and braille now, but
I don't think those encompass quite the same thing - and plus, most user
agents don't actually implement them. What I'm proposing is that the CSS
media type could be used as a way for a web app to dynamically enable
accessibility features that are normally disabled. We could potentially
ease privacy concerns by encouraging user agents to simulate this media
type when debugging, precaching, downloading a page as an archive, or at
other times when it wouldn't impact the user but would make it more
difficult for sites to identify and discriminate against AT users.

- Dominic

On Fri, Feb 1, 2013 at 12:58 PM, Janina Sajka <janina@rednote.net> wrote:
  I agree with Rich, but I also think we've yet to see a compelling case
  for exposing AT make and model info.

  While it's true that several ATs have been notorious for bugs associable
  with particular versions, I'm not sure this historic fact points to a
  requirement going forward.

  Haven't these bugs been related to the AT performing its own HTML
  parsing--at least from an IndieUI reachable perspective? If I'm not
  wrong about that, I submit there is likely to be little, or at least
  much less of this going forward.
  I agree with Rich, but I also think we've yet to see a compelling case
  for exposing AT make and model info.

  While it's true that several ATs have been notorious for bugs associable
  with particular versions, I'm not sure this historic fact points to a
  requirement going forward.

  Haven't these bugs been related to the AT performing its own HTML
  parsing--at least from an IndieUI reachable perspective? If I'm not
  wrong about that, I submit there is likely to be little, or at least
  much less of this going forward. Not only is it a huge undertaking,
  there's much better a11y support in today's browsers and parsing engines
  obviating the need for this kind of solution.

  In other words, I suspect the historic pressure relates to ATs that were
  also serving as browsers, something that I submit is going away. Am I
  wrong?

  Janina

  Richard Schwerdtfeger writes:
  >
  > I am extremely worried about privacy issues around exposing the AT a
  person
  > is using.
  >
  > Rich
  >
  >
  > Rich Schwerdtfeger
  >
  >
  >
  > From: Jason White <jason@jasonjgw.net>
  > To:   public-indie-ui@w3.org,
  > Date: 12/06/2012 08:04 PM
  > Subject:      Re: [user-context] What are the use cases for exposing
  screen
  >             reader  or magnifier version info?
  >
  >
  >
  > James Craig <jcraig@apple.com> wrote:
  >
  > > Assistive technology vendors are not beholden to W3C specifications
  (and
  > > most AT vendors are notoriously uninvolved in the standardization
  > process),
  > > so exposing this information when it's absolutely necessary, (and
  only
  > with
  > > user content), is one attempt to reduce the unreliability of AT
  > interfaces
  > > on the Web.
  >
  > At a Web accessibility conference last week, a content author mentioned
  > this
  > to me as a highly desired feature due to bugs and limitations (often
  > version-specific) in various screen readers.
  >
  > I am concerned however that the information is open to misuse: content
  > authors
  > may start designing for the "most popular" ATs instead of writing
  according
  > to
  > spec. They can also ascertain which ATs are "most popular" for their
  > particular content by gathering data, which is not possible now, since
  the
  > name/version of the AT are not revealed.
  >
  > Thus I have decidedly mixed feelings about this proposal and, frankly,
  I'm
  > not
  > sure whether the practical benefits of being able to work around
  certain
  > bugs/differences outweigh the opportunity to "design for the UA and AT
  > implementation" instead of designing to standards.
  >
  >



  --

  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 Monday, 4 February 2013 22:07:36 UTC