RE: @aria-describedat at-risk in ARIA 1.1 heartbeat draft

Hi all,

 

I just want to remember that longdesc is not only useful for blind people and not only useful for users of AT.

 

Best,

 

Emmanuelle Gutiérrez y Restrepo

Patrono y Directora General

Fundación Sidar - Acceso Universal

Email:  <mailto:coordina@sidar.org> coordina@sidar.org

Personal:  <mailto:Emmanuelle@sidar.org> Emmanuelle@sidar.org

Web:  <http://sidar.org> http://sidar.org

 

 

 

De: Dominic Mazzoni [mailto:dmazzoni@google.com] 
Enviado el: sábado, 06 de diciembre de 2014 8:46
Para: John Foliot
CC: James Craig; WAI XTech; Alexander Surkov; Michael[tm] Smith; Daniel Weck; Ted O'Connor; Janina Sajka
Asunto: Re: @aria-describedat at-risk in ARIA 1.1 heartbeat draft

 

On Fri, Dec 5, 2014 at 5:16 PM, John Foliot <john@foliot.ca> wrote:

James Craig wrote:
>
> > Dominic wrote:
> >
> >> I have no strong opinion on supporting longdesc and/or aria-
> describedat for exclusive use by screen readers or other AT - i.e. as
> something that'd be invisible to most users.
> >>
> >> One thing I feel more strongly about: until now, everything in ARIA
> only affects how the user agent communicates with AT, it never changes
> the visual layout or the semantics of how the page works for users who
> aren't running any AT. Exposing aria-describedat in the context menu
> would be a significant departure from this. One potential concern is
> that web developers would become more suspicious of ARIA in general and
> not want to apply simple accessibility bug fixes without worrying about
> the implications for their design.
>
>
> I've expressed the same concern with aria-describedat, in addition to
> the concerns Ted listed in the formal objection to longdesc.

...and yet, Dominic himself closed the @longdesc bug in Chromium just
yesterday:
https://code.google.com/p/chromium/issues/detail?id=224285#c40

 

Yes, I'm still in favor of native longdesc support, this is the first step in that direction. The extension will hopefully graduate to a built-in but optional feature, and then a default feature, if we see evidence that web authors are increasing adoption of it and using it correctly.

 

A question to Dominic and Alexander, since they have both been singled out
as commenter's, do your respective organizations have any specific issue
with treating the "UI interaction" of aria-describedat with the same or
similar solution you have applied to @longdesc (given that the draft spec
does not specify any explicit UI requirements)? While I know that some are
still not 100% satisfied with the Chromium "plugin" requirement, I
personally have heard no complaints with moving the interaction into the
context menu.

 

I'm perfectly happy with exposing aria-describedat to AT via accessibility APIs. Unlike with longdesc, I don't like the idea of exposing aria-describedat in the context menu by default. The reason is that up until now, ARIA does not change the behavior of the user agent at all. It simply passes additional information to AT. The browser doesn't render anything differently, respond to events differently, or anything else like that. Suggesting that the browser directly expose aria-describedat to all users would totally change that, and I worry it would set a bad precedent. 

 

I hope that helps.