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