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

set-size and posinset are only necessary if the DOM does not reflect the full tree, so while your CSS counter example appears very clean in the small example:

>  aria-setsize: 16;
>  aria-posinset: calc(index + 1);


It would become more unwieldy when using larger data sets

<ul role="listbox" aria-labelledby="label_fruit">
  <li role="option" aria-setsize="247" aria-posinset="163"> apples </li>
  <li role="option" aria-setsize="247" aria-posinset="164"> bananas </li>
  <li role="option" aria-setsize="247" aria-posinset="165"> cantaloupes </li>
  <li role="option" aria-setsize="247" aria-posinset="166"> dates </li>
</ul>

Every time the table scrolled, you'd have to update your CSS rule offset.

>  aria-posinset: calc(index + 163);

Why bury functional information specific to one control inside a CSS rule? IMO, it's much better to store this on a DOM attr, even if it is more verbose.

James


On Feb 4, 2013, at 2:44 PM, Dominic Mazzoni <dmazzoni@google.com> wrote:

> 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
> 
> <graycol.gif>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> 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 Tuesday, 5 February 2013 00:39:18 UTC