Re: Drop longdesc, get aria-describedat?

On Tue, Mar 13, 2012 at 4:40 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Silvia Pfeiffer, Tue, 13 Mar 2012 13:12:26 +1100:
>> Anyway, I think we should write a spec and start shopping it around
>> with browser developers to get some feedback and see if there is will
>> to implement. Whether we call that attribute @aria-longdesc or
>> @aria-describedat or just extend the existing @longdesc to video and
>> audio and update its spec (which I frankly think is the maddest path
>> of them all) doesn't really matter - a problem needs to be addressed.
>
> I have started to shop: https://bugs.webkit.org/show_bug.cgi?id=10448#c6
>
> This is a proposal for how Webkit should implement @longdesc in the
> chrome [context menu etc], the link behavior, how the CSS should work,
> how to become keyboard focusable and how VoiceOver should behave
> including when the longdesc announcement should be made - before or
> after the @alt text? And, not least: what do do if <img> is wrapped
> inside a link. Ideas are taken from many places, including the CP and
> Webkit's Alexey Proskuryakov who suggested that longdesc should be
> displayed when image wasn't display - which is a thought that we seem
> to not have dared thinking ...
>
> One thing that struck me, as I was writing this - at least the things
> relating to fallback, is that much of what I was describing probably
> only makes sense for the <img> element. Simply because only the <img>
> element has a such a specific behavior whenever it isn't displayed.
> E.g. for <video>, <audio> etc, then there is no guaranteed fallback.
> And even if there is fallback, it isn't guaranteed to be a textual
> substitute. This, IMO, points towards 'the HTML feature' rather than
> 'an ARIA feature'.

Yes, I agree that there are differences between the elements that need
longdesc-like features. I also wouldn't restrict it just to <img> and
<video>/<audio>, but include <table>, <canvas> and other complex
elements that may better be described through an additional long text
description.

I'd also not go quite as far as your recommendations go, but rather
restrict it to a limited number of recommendations for how to display
the URL. Something more like what Alexey suggested on the same bug:
- adding a link to context menu;
- implementing a property inspector for end users, similar to the Firefox one;
- use for fallback content when the element's display is disabled by
the browser (e.g. in text-only browser).
- expose to screenreaders through a11y APIs.


> When it comes to implementing it as 'the HTML feature' or as a new
> 'ARIA feature', then another reason to go for the HTML feature, is the
> issues related to fallback. Because, as we know, there is no fallback
> when it comes to ARIA attributes: Browsers are not required to render
> aria-label if the image doesn't display. And so, I think, that unless
> we describe it as a HTML feature, then we can't - as easily - justify
> that the feature looks like in the chrome, via CSS, or how the link
> behaves to normal users.

In HTML there is also no need to specify visual presentations etc.
They can't be part of the normative text. However, it's always
possible to provide recommendations in non-normative text. I would
think that we can do that, too, in ARIA.


> The chairs in their responses have asked for justification, and so, if
> we can justify it, then a HTML feature is all good, in principle, I
> think.

Sure. My main reason for going for another attribute is that I want it
used for more than just <img>.

Cheers,
Silvia.

Received on Tuesday, 13 March 2012 19:44:27 UTC