W3C home > Mailing lists > Public > public-indie-ui@w3.org > February 2013

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

From: Dominic Mazzoni <dmazzoni@google.com>
Date: Tue, 5 Feb 2013 00:00:36 -0800
Message-ID: <CAFz-FYyU4935Td9K8ufmv3UYceB2ZwWnfrTDS75wu5Gf8PdfMw@mail.gmail.com>
To: James Craig <jcraig@apple.com>
Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, Janina Sajka <janina@rednote.net>, public-indie-ui@w3.org
On Mon, Feb 4, 2013 at 4:38 PM, James Craig <jcraig@apple.com> wrote:

> It would become more unwieldy when using larger data sets
> Every time the table scrolled, you'd have to update your CSS rule offset.
>
>  aria-posinset: calc(index + 163);
>
> Isn't that less code the updating the attribute in each of the rows in the
table?

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

You could make the same argument against CSS.

I think there are several potential arguments in favor:

>From a design perspective, I agree it's a matter of taste - but I can see
circumstances where web developers might love keeping ARIA details out of
the HTML so that content creators can feel free to hand-edit HTML.

>From a performance perspective, many web developers have experienced ARIA
slowing down page load time. Top web properties are obsessive about speed
and size (see [1], [2]), and I think it's really important that
accessibility isn't seen as something that burdens and slows down sites.

Finally, this could make it easier to take existing code and make it
accessible. Refactoring existing code to make it possible to add ARIA at
the right times is not always easy, and adding style rules might be simpler
and less risky.

- Dominic

[1]
http://blog.tagman.com/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/
[2] http://blog.kissmetrics.com/loading-time/





>
> 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*<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/>
>>
>>
>>
>>
>>
>
>
Received on Tuesday, 5 February 2013 08:01:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2013 08:01:05 GMT