Re: longdesc - beside the box

On Tue, Apr 26, 2011 at 12:49 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> 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.

In my understanding, that link for video would only be exposed in-band
if the video is not exposed.
For screenreaders, what you describe does indeed work.

> 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, I regard the alt text (or whatever it turns out to be) as
"pre-action" information. I would listen to the alt-text (just like I
look at the video image) to find out if I want to watch the video. So,
for video it's not actually an alternative to the video. The
transcription is rather an alternative to the video.


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

Anyway, I'm not trying to do any arguments on short text alternatives.
I don't want to talk about @alt in this thread.

Maybe the word "text alternative" does not describe accurately what
@longdesc means. In fact, a transcription is always somewhat of
supplemental text. But for those not wanting to watch the video or not
able to, the text in @longdesc may well be an alternative to the
video. This is why I subsumed it under "text alternatives".

Basically, I was reacting to "thinking outside the box". Maybe
@longdesc works for video. I'd be happy if it does. I thought I'd just
describe how I can see a transcription work with a video. What it's
called in the end is secondary, but should not introduce conflicts
with other elements.

Silvia.

Received on Tuesday, 26 April 2011 03:12:42 UTC