W3C home > Mailing lists > Public > public-html-a11y@w3.org > March 2012

Re: 48-Hour Consensus Call: ARIA-DescribedAT & Longdesc

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 29 Mar 2012 16:14:14 -0700
Message-ID: <CAHp8n2mf8Ewhsn7ezTybrEuQn4AQAaanL6QwZRun8pVnSXeoMg@mail.gmail.com>
To: Charles McCathieNevile <chaals@opera.com>
Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
On Thu, Mar 29, 2012 at 3:59 PM, Charles McCathieNevile
<chaals@opera.com> wrote:
> On Thu, 29 Mar 2012 22:56:57 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Thu, Mar 29, 2012 at 9:45 AM, Janina Sajka <janina@rednote.net> wrote:
>>> Colleagues:
>>> On 29 March last the HTML-A11Y Task Force teleconference meeting
>>> reached consensus as follows:
>>> RESOLUTION: The HTML-A11Y Task Force confirms that ARIA-DescribedAT will
>>> not be ready for HTML 5 in HTML 5's currently published timeframe, and
>>> therefore reaffirms its support of Laura's authored CP to reinstate
>>> longdesc (Issue-30).
>>> The TF resolution, together with minutes of the discussion leading up to
>>> it, is logged at:
>>> http://www.w3.org/2012/03/29-html-a11y-minutes.html#item03
>>> As usual, if there is objection to this consensus position, please
>>> respond by replying to this message no later than close of business,
>>> Boston Time, on Monday 2 April.
>> I have two comments on this:
>> Laura's change proposal [1] asks for @longdesc to be reinstated for
>> <img> elements.
>> @longdesc is currently an obsolete attribute [2] for both, <img> and
>> <iframe>.
>> First a question: we are not asking @longdesc to be reinstated for
>> <iframe>, or are we? And: why not?
> We are not. Because when I wrote the original change proposal for ISSUE-30
> (and indeed, when I raised the issue, oh so long ago), I didn't think it
> would be a multi-year project for such a simple piece of missing
> functionality to be added (back), and conceived it as a simple step on what
> I did expect to be a reasonably difficult path of getting HTML5 to support
> accessibility to the level that the Web as a whole did 5 years ago.

Fair enough. :-) I was just curious.

>> Secondly my opinion: if we are not planning to introduce a
>> @aria-describedAt attribute into HTML5, we should drop issues 194 [3]
>> and 203 [4] and defer them to HTML.next. I don't want to see the
>> problem of long descriptions / transcripts solved for <video> elements
>> in isolation from other elements. It would make more sense to have a
>> common solution on all elements.
> At this stage I think the situation is pretty sad, and while I'm prepared to
> work on anything that makes sense, I am unhappy enough to accept a
> half-arsed hand-me-down as better than nothing. :( But in principle I still
> agree with you, because it seems that putting in accessibility solutions we
> haven't thought through really incredibly carefully isn't a good idea
> (witness the small editorial mistakes that cost accesskey a decade, or the
> apparently spur-of-the-moment "solution" to hit testing on canvas).

We can for now suggest to include any long description for video
underneath the video and provide the machine-discoverability through
aria-describedby pointing to a <div> around the (set of) links to long
descriptions. That is not an elegant solution in my opinion, because
e.g. it can't be crawled by a search engine as "the" long
description/transcript for the video. But it works now and may be
sufficient for HTML5. That's why I suggest moving the issues to

<video src="http://..." aria-describedby="#links"></video>
<div id="links">
  <a href="http://...">Transcript</a>

Received on Thursday, 29 March 2012 23:15:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:06 UTC