Re: aria-describedat?

Jason White <[email protected]> Wed, 14 Mar 2012 19:21:45 +1100
Newsgroups gmane.comp.mozilla.accessibility
Message-ID <[email protected]>
Silvia Pfeiffer <[email protected]> wrote:
 
> So, moving to a new attribute name, recommending consistent ways of
> how to expose the link visually, and applying that attribute to more
> than just the <img> element might help with getting off-page
> descriptions for complex HTML elements.

I agree.

Concerning <video>, the use case would presumably be what WCAG 1.0 refers to
as a "collated text transcript" of the video. This was dropped as a
requirement in WCAG 2.0 even at the highest (AAA) level of conformance. As a
result, users who are deaf-blind and for whom captions and auditory
descriptions are inadequate, are deprived of access even at the strongest
conformance level.

I remember arguing that the requirement should be retained for exactly this
reason (at level AAA of WCAG conformance). Unfortunately, it's a debate which
I and others lost outright when the working group made its decision.

Of course, it would be possible to allow the "fall-back" content of <video> to
carry a description, without adding @longdesc or @aria-described-at; the HTML
5 draft, when last I looked, explicitly discouraged this practice in both
<audio> and <video>.

While I would welcome HTML support for collated transcripts of video, I think
their removal from WCAG will weaken the case - perhaps arguments from
consistency and universality of whatever design is chosen, will ultimately
prove decisive, but that could be misplaced hope on my part.