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

Rich,

To clarify, I'm not proposing that the media type would replace any screen
reader or magnifier features. The web app would still use ARIA to expose
accessible information about the page and Indie UI to get accessible
events. The difference would be that the author would have the option of
specifying this ARIA markup using CSS in addition to DOM attributes, which
could be a lot more efficient.

Here's a specific example of where this would help, taken straight from the
ARIA spec:

<ul role="listbox" aria-labelledby="label_fruit">
  <li role="option" aria-setsize="16" aria-posinset="1"> apples </li>
  <li role="option" aria-setsize="16" aria-posinset="2"> bananas </li>
  <li role="option" aria-setsize="16" aria-posinset="3"> cantaloupes </li>
  <li role="option" aria-setsize="16" aria-posinset="4"> dates </li>
</ul>

Instead, I propose the page could be marked up more like this:

<style>
ul#fruit li {
  aria-setsize: 16;
  aria-posinset: calc(index + 1);
}
</style>
<ul id="fruit" role="listbox" aria-labelledby="label_fruit">
  <li role="option"> apples </li>
  <li role="option"> bananas </li>
  <li role="option"> cantaloupes </li>
  <li role="option"> dates </li>
</ul>

There are several potential advantages of this approach:

* Many web pages already have CSS styles for certain properties that need
ARIA markup. This allows them to be tied together rather than requiring
duplicate code.
* When the accessible media type is not loaded, the browser wouldn't need
to bother keeping track of these attributes.
* Even when loaded, DOM operations would be faster in many cases because
there'd be fewer attributes per element.
* Finally, it'd add an additional tool for web developers to inject
accessibility fixes into shipping products without refactoring third-party
code.
* It'd be purely optional and wouldn't add any new ARIA attributes or
capabilities, it'd just provide alternative syntax.

- Dominic

On Mon, Feb 4, 2013 at 2:06 PM, Richard Schwerdtfeger <schwer@us.ibm.com>wrote:

> 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
>
> [image: Inactive hide details for Dominic Mazzoni ---02/04/2013 01:22:30
> PM---I understand the privacy concerns. I also fail to see the]Dominic
> Mazzoni ---02/04/2013 01:22:30 PM---I understand the privacy concerns. I
> also fail to see the benefit of reporting specific AT brands an
>
> 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*<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* <jason@jasonjgw.net>>
>    > To:   *public-indie-ui@w3.org* <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* <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* <%2B1.443.300.2200>
>                            *sip:janina@asterisk.rednote.net*<sip%3Ajanina@asterisk.rednote.net>
>                    Email:  *janina@rednote.net* <janina@rednote.net>
>
>    Linux Foundation Fellow
>    Executive Chair, Accessibility Workgroup:       *http://a11y.org*<http://a11y.org/>
>
>    The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
>    Chair,  Protocols & Formats     *http://www.w3.org/wai/pf*<http://www.w3.org/wai/pf>
>            Indie UI                        *http://www.w3.org/WAI/IndieUI/
>    * <http://www.w3.org/WAI/IndieUI/>
>
>
>
>