Re: Drop longdesc, get aria-describedat?

Benjamin Hawkes-Lewis, Sat, 10 Mar 2012 13:00:19 +0000:
>>> It is not possible to draw a line between "all users" and "accessibility".
>> 
>> ARIA and HTML lives in different working groups and in different
>> communities. I agree about what you say about all users. But,
>> currently, we must play tricks to make it work in all ATs - e.g it
>> doesn't work in the increasingly popular VoiceOver and NVDIA. By
>> contrast, if you want to expose aria-describedby to non-A11Y users,
>> then you must play tricks. And that seems like the right order of
>> things.
> 
> It is not the right order of things if "tricks" are involved to
> provide access to long descriptions to people with learning
> disabilities, people with minor sight problems (e.g. colorblindness)
> that are not using AT.

The 'trick' is ususually a browser add-on or a JS library that 
transforms the link into an anchor element without setting the anchor's 
AT visibility to aria-hidden='true', thus often leading to link 
duplication - a longdesc link and an identical anchor link - if an AT 
with @longdesc support is used together with the 'trick'. 

Hence, the fact that the user categories you mention have to switch 
'visible longdesc' to 'on' before it works, has the advantage that it 
avoids that the solution for 'your' user groups interferes with the AT 
user group.

But of course: If the 'tricks' were dressed up with *more* ARIA - such 
as aria-describedby from the <img> to the visible anchor, they could 
probably serve both AT users and the user groups you mention.

> Nor is it the right order of things if "tricks" are involved to
> provide access to long descriptions to people using console browsers,
> when an image fails to download, or when users are searching for
> content in a search engine. (No, these are not strictly
> "accessibility" concerns, but they are core One Web concerns that
> @longdesc attempts to meet.)

There are no console browsers with support for longdesc. I've 
personally filed bugs to get longdesc support in all the console/text 
browsers I know about. So far, no result.

> Also, we're not talking here about @aria-describedby versus @longdesc
> but a new attribute without any implementations (@aria-describedat).

OK. I should have said @aria-describedAT, to avoid confusion.

>>>> Yeah, deciding once and for all whose responsibility it is to
>>>> specify the long description link mechanism,
>>>> would probably be the most important decision.
>>> 
>>> Specifying @longdesc isn't the problem; designing and implementing
>>> effective user interfaces for it is. I don't think it matters much who
>>> specifies it if it doesn't make a difference to how or whether such
>>> interfaces are implemented.
>> 
>> It is my impression that ARIA is pretty internally coherent and also
>> that lots of A11Y technicians look at ARIA. Hence, to me it seems
>> likely that it would help if 'the attribute' - whatever its name or
>> historical origin - was the responsibility of ARIA.
> 
> For a hidden long description mechanism to succeed we need to involve
> people who are involved in producing mainstream user interfaces (or
> produce them ourselves), not just retreat into a well-meaning internal
> discussion between "a11y technicians". Getting interfaces comparable
> to Charles's Tell Me More extension built into user agents is no small
> challenge when a dominant tendency in software design is towards
> minimalism, streamlining, and the Pareto principle.

'Tell Me More', Anthony's Firefox Longdesk add-on [1] or any other 
browser add-on that, as presentation strategy, transforms the @longdesc 
link into an anchor element, would be able to do the same with the help 
of @aria-describedAT.

[1] https://addons.mozilla.org/en-US/firefox/addon/longdesk/
-- 
leif halvard silli

Received on Saturday, 10 March 2012 17:29:49 UTC