Re: [media] alt technologies for paused video (and using ARIA)

On Thu, May 12, 2011 at 9:37 AM, John Foliot <jfoliot@stanford.edu> wrote:
> Silvia Pfeiffer wrote:
>>
>> It is the recommended way for making content invisible at
>> http://webaim.org/techniques/css/invisiblecontent/ and if anyone
>> should know the best way it should be WebAIM IMO. I just followed
>> their recommendation and I think in this case it is appropriate.
>
> As it happens, Jared Smith is a long-time friend who, for a variety of
> reasons not relevant to this discussion is currently not able to
> participate directly in the HTML5 WG.
>
> However, I did manage to discuss this with him, and he helpfully responded
> with a fairly detailed email, provided in its entirety after this comment.
> Specific to this technique however, he wrote:
>
> "...regarding the off-screen content technique
> (http://webaim.org/techniques/css/invisiblecontent/) for aria-describedby
> elements. Here are several arguments against this as a recommended
> solution.:
>
> - While the aria-describedby content would be read when the <video>
> element that references it is accessed, it would ALSO be read in it's
> actual location within the page, thus introducing potential confusion for
> screen reader users reading later in the page. In other words, if I bypass
> the video (perhaps navigate by a heading), my screen reader may begin
> reading a description for an object that I am unaware of and for which
> there is no reverse programmatic association. While this is also an issue
> if the content is NOT hidden off-screen, such content would almost
> certainly be presented in proximity to or otherwise programmatically
> associated to the video itself (maybe within the same heading level or
> same <article>). This off-screen technique allows (and in some ways
> encourages) the long alternative to be presented anywhere within the page,
> thus allowing the alternative to be read to screen reader user twice
> and/or in isolation and without association to the video.

Hmm, that is indeed an issue with hidden text and aria-describedby. We
should discuss this on next week's call when we discuss that part of
my proposal.


> - This may encourage the presentation of additional and verbose content
> for only one set of users - screen reader users. Much of this information
> would be best served if made available to all users (either visibly within
> the page or via a separate page), particularly those with cognitive or
> other disabilities.

So, one solution to this is to not have @aria-describedby as the
solution to longer descriptions of the placeholder image, but instead
to have it in the resource pointed to by @transcription. I'd be happy
to just have that. Let's also discuss next week.


> - This solution (nor any of the other presented solutions) allow for
> content that necessitates or would be better served on a separate page.

Yes, @transcription provides for this.

> Simply presenting a link within off-screen content is obviously not
> suitable. This would limit not only content access, but also functionality
> to only screen reader users. It would also violate the intention of
> aria-describedby (the video is not described by a anchor element, but by
> actual content).

Ok, so that's an argument against providing hidden content in @aria-describedby.

 Something else (beyond
> @transcription) is necessary in this case

I don't think that's the case. Why would we need two separate
resources to link to for describing a video element's content? I think
that's overkill (or "persnickety" - a word I recently learnt :-) ).


> - This technique relies on current, yet somewhat arbitrary user agent
> behavior. Nothing prescribes that screen readers should read off-screen
> content (no more so than they prescribe that they should ignore content
> with display:none). Additionally, this results in styling dictating
> content functionality - something that both HTML5 and CSS strive to avoid.

OK, another point of discussion for aria-describedby.

> For these reasons, an HTML5 technique that recommends or relies on such
> styling makes me quite uncomfortable.
>
> **********************
>
> Jared's full response follows my sig.
>
> JF
>
> **********************
>
> John, feel free to pass this on or quote as you'd like.
>
>
> I noticed that a WebAIM technique was referenced in the mailing list
> (http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0291.html).
> I wish to provide some thoughts on this technique as well as some broader
> thoughts on media alternatives.
>
> The alternative to the video and the alternative to a poster frame will
> often not be the same. The editor opinion
> (http://lists.w3.org/Archives/Public/public-html/2011Mar/0690.html)
> was that "this does not happen in practice" and the dialogue of this
> thread generally indicates that video alt and poster alt are always the
> same and should not be treated differently.

The point that nobody seems to understand is that there is no need to
provide a text alternative for the video. All we need is a text
alternative for the poster (read: placeholder image). The video's
content is not presented at the time where a text alternative for the
video *element* is needed.


> However, I think several cases
> have been presented that show this is not always the case. The proposed
> solutions themselves
> (http://www.w3.org/WAI/PF/HTML/wiki/Media_Alt_Technologies) reference and
> describe these separately - strong evidence that they are distinct content
> items that must be described distinctly. The examples (both aria-label and
> aria-describedby) sometimes present alternatives for the <video>,
> sometimes alternatives for the poster frame (tellingly, the referenced
> elements have an id value of "posteralt"), and sometimes for both (not to
> mention the times they reference other stuff, such as metadata or control
> instructions).


All my @aria-label attribute values describe the poster content, while
all my @aria-describedby attribute values link to summaries of the
video content (the latter can include poster descriptions, too). I
don't think there is any bleeding-in of video content into the
@aria-label attribute.



> This would pose significant confusion for authors. I, as an accessibility
> 'expert', read the full threads and examined all of the examples and it
> still is not clear to me if the alternative being presented by each
> attribute should be for the video itself, for the poster frame, for the
> controls of the video, or something else? Or somehow all of them combined?

Maybe that is the key problem that we have with @alt and @aria-label.
We need to find a better name for the attribute so we stop confusion.


> The techniques that have been suggested (with the exception of off-screen
> text) seem to work splendidly for alternatives to the video. At first
> glance, it seems to me that <video alt> might be a suitable alternative to
> @aria-label for short alternatives.

Indeed.

> For AT and accessibility APIs, they
> would be presented and mapped identically.
> @aria-describedby would often be an appropriate method when longer,
> in-page alternatives are presented.

Good.

> But if video alt and poster alt are distinct things (as they clearly often
> are to me), providing descriptions of their content programmatically via a
> single attribute or referenced element (or even multiple elements) seems
> fundamentally wrong.

Indeed, no video alt is required, thus @alt would ever only describe
poster alt. Thus the confusion.


> If aria-describedby or aria-label is apply to the
> <video> element, they are, by definition, labels and descriptions for that
> element, not of some other characteristic, attribute, or state of that
> element. In many cases additional poster alt would not be necessary
> (usually in the case of random frames being presented and often in the
> case of first frame being presented). But in the cases where the
> alternative content for the poster alt is distinct, a distinct description
> mechanism is necessary - perhaps @posteralt (yes, this is structurally
> questionable, but no more so than <a hreflang> or <track srclang>, I
> suppose) for short alternatives or (optimally) a child <poster> (or
> similar) element for short and long description. I'm sure there are other
> solutions that don't convolute video alt and poster alt into one thing.

I'm now convinced it's a naming issue, not a use case issue. I think
we all agree on the use case of short and long descriptions.


> I do like the idea of associating full media descriptions (e.g.,
> transcripts) via @transcription (I'd prefer @transcript). Some
> wordsmithing on what should go on the @transcription page is necessary. Of
> note is that WCAG 2.0 never uses the word "transcript", but uses
> "alternative for time-based media"
> (http://www.w3.org/TR/WCAG20/#alt-time-based-mediadef) as transcripts are
> generally considered to be verbatim text versions of audio content whereas
> WCAG requires additional descriptions where necessary.

That is very true, which is why I picked the word @transcription. But
hopefully we can find a better word.

> @description or @longdesc would really be more accurate here, though these
> introduce other types of confusion.

Oh yes, let's please stick away from these and pick something that
will immediately indicate to authors what they are supposed to put in.

Cheers,
Silvia.

Received on Thursday, 12 May 2011 02:37:10 UTC