Re: longdesc - beside the box

Silvia Pfeiffer, Tue, 26 Apr 2011 12:10:17 +1000:
> On Tue, Apr 26, 2011 at 11:32 AM, Leif Halvard Silli wrote:
>> Silvia Pfeiffer, Tue, 26 Apr 2011 10:56:09 +1000:
>>> On Tue, Apr 26, 2011 at 3:20 AM, Laura Carlson wrote:

>>> I wonder: When you turn off images in a browser, does that also turn
>>> off video and audio? (In Chrome I don't even see a preference setting
>>> for images any more.)
>> 
>> Yeah, how should a text browser render <video>? If we look at <object
>> data=image.jpg>fallback</object>, then it presents the fallback.
>> Whereas for <img alt="fallback"> it renders the alt text in a different
>> color.
>> 
>> 3 options: 1) Behave like for <object>. 2) Behave like for object but
>> still color the text or something. 3) Treat <video> more or less as an
>> image map: Introduce a @alt attribute on <video> which is meant to
>> represent the video including the first frame. By pressing the video
>> element, the user can download the content of the src attribute. If the
>> video contains multiple video formats and/or fallback, then let the
>> user "open" the video element and navigate inside it to select video
>> format to download and read the fallback.
> 
> Careful about the use of the term "fallback" here. We already have
> "fallback" for non-HTML5 browsers, which is the stuff inside the video
> element. I really don't want to use the term "fallback" for text-only
> HTML5 browsers. I'd prefer if we can focus on calling it "text
> alternative" or something along those lines.

I said "fallback" because @alt represent a special kind of fallback. I 
see that you want to think of the fallback of <video> as yet another 
special kind of fallback. But OK, will try to stick to what you said.

> Also, we need to be careful what types of text alternatives we
> introduce. I was here not talking about short text alternatives such
> as can be done with @alt or @aria-describedby. I was particularly
> talking about full transcriptions, which typically would be provided
> in a separate html page or sometimes further down. So, it would
> definitely have to have a URI reference as value, e.g. "#desc" or
> "desc.html". That URI would be shown only when the video is not
> displayed (in a HTML5 browser!) and it would also be exposed to AT
> somehow - maybe a special sound could be made to make people aware
> that such a URL is available. It could also be exposed in a context
> menu such that anyone can have access. But it is not something that
> would go on a <source> or some attribute inside the video - it would
> go straight onto the <video> element. The DOM inside a video should
> never be exposed to AT since it represents a single entity.

For @longdesc there are already things to build on: it is introduced in 
a standard way in screenreaders, which announced "Link to long 
description" - or smilar. And GUI browsers can use a cursor to show 
that there is a longdesc link.

However, it must be said that @longdesc is not alternative text - it is 
supplemental text. Thus @longdesc works in tandem with a short 
alternative text. The link text of the longdesc link is the image - if 
you are sighted etc. If you are not using image, then the @alt text is 
the link text, so to speak.

For <video> then for ARIA supporting AT, it should be OK to pick the 
short alt text/short label from another element, via aria-labelledby. 
But for a text browser, this is not what we expect - it would be a 
layer violation for it to pick text alternative from another element.

Thus, if we focus on HTML5 supporting text browsers, which thus 
shouldn't present the fallback for old browser, what should they then 
presentd? If <video> has @alt, then it could serve as video 
identification and as "link text" for the longdesc URL.

Btw, one advantage that <video> has over <img>, is that it *is* 
interactive content. This means that it is illegal to wrap a link 
around a <video>. Hence @longdesc and link wrapper will not potentially 
compete about the attention. 

Anyway,  in a summary, I don't think that ARIA takes away the need for 
@alt on <video> per what you described above: Without @alt. Unless we 
want text browsers to represent a video element with a certain dingbat 
symbol?
-- 
leif halvard silli

Received on Tuesday, 26 April 2011 02:49:33 UTC