- 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 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 <public-html-a11y@w3.org> 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. Regards, Silvia.
Attachments
- image/gif attachment: graycol.gif
Received on Tuesday, 18 September 2012 12:33:58 UTC