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

Re: 48-Hour Consensus Call: InstateLongdesc CP Update

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Tue, 18 Sep 2012 07:32:59 -0500
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Léonie Watson <lwatson@nomensa.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, David Singer <singer@apple.com>
Message-ID: <OFBE9E3779.F510C017-ON86257A7D.00435D34-86257A7D.0044FC6B@us.ibm.com>

Sorry, folks, I am on vacation but I wanted to weigh in briefly.

Silvia, David Bolter (Mozilla), Dominic Mazzoni (Google), and I have been
discussing an aria-describedat solution which would be a better version of
longdesc. It is not getting traction, in part, as this was being targeted
for ARIA 1.1. I agree with David Singer that longdesc, in its current state
is not adequate to ensure that we have real developer adoption, yet I do
understand that companies have implemented it. So, there are really only
two options that would satisify every one:

1. We apply changes such as Silvia is discussing below to longdesc itself
which is something we have been targeting a new ARIA attribute for -
aria-desccribeat ... OR,
2. We deprecate longdesc and create an aria-described at for ARIA 1.1
AND/OR modify aria-describedby to show a special indicator (of the user
agent's definition) when it points to a IFrame in ARIA 1.1 with a lot of
SHOULDs or MAYs for user agent manufacturers on how to expose the IFrame.

I can appreciate the fact that the HTML5 chairs need to get v5 out the door
so consensus on either of the two approaches needs to be addressed either
way and quickly by consensus from the browser manufacturers. Regardless of
what happens with longdesc the ARIA working group will try to address all
or part of 2. The reason we did not address a better longdesc in ARIA 1.0
was because HTML already had a longdesc at the time.

I strongly urge that the accessibility people work with the chairs to get a
proposal takes one of the two approaches and which the browser
manufacturers can agree on.  There are advantages over the IFrame approach
as on a mobile devices you would not be launching another tab for the URL
that you then need to close in a tablet browser. I had spoke with James
Craig and he had concerns about implementing aria-describedat for the 1.1.
time frame as a longdesc replacement - this many be the reason.


Rich Schwerdtfeger

From:	Silvia Pfeiffer <silviapfeiffer1@gmail.com>
To:	Léonie Watson <lwatson@nomensa.com>,
Cc:	David Singer <singer@apple.com>, HTML Accessibility Task Force
Date:	09/18/2012 06:46 AM
Subject:	Re: 48-Hour Consensus Call: InstateLongdesc CP Update

On Tue, Sep 18, 2012 at 6:14 PM, Léonie Watson <lwatson@nomensa.com> wrote:
> David Singer wrote:
> "So your thesis is that we should stick with a poor solution, that works
only in controlled environments (not the public internet), and with a
limited number of UAs, not all, and for whcih the situation is not
improving nor likely to, rather than do better?
> "I'm sorry, I cannot give you a car because you already have a broken
bicycle."  Pshaw, I say, I and many others have much higher aspirations."
> I think (hope) we all share those higher aspirations. The thing that
puzzles me is why we'd want to take away the broken bicycle before a
quality car is available? In other words, what would we lose by leaving
longdesc in situ, whilst we focus our collective energies on finding a
robust replacement?

If we leave img@longdesc in situ, we have to fix it up and turn it
into something usable, otherwise we may as well leave it derelict.
Browser vendors won't want to fix up their @longdesc implementation
now if we are already putting our collective energies into a
replacement solution and will quite clearly get rid of @longdesc in
the next round.


(image/gif attachment: graycol.gif)

Received on Tuesday, 18 September 2012 12:33:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:30 UTC