- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Fri, 29 Mar 2013 17:13:29 +0100
- To: "Frank M. Palinkas" <fmpalinkas@gmail.com>, "David Woolley" <forums@david-woolley.me.uk>, "Jonathan Avila" <jon.avila@ssbbartgroup.com>
- Cc: "Mattingly, F Darrell" <darrell.mattingly@uky.edu>, "WAI Interest Group" <w3c-wai-ig@w3.org>, "Guettler, Karen M" <kmguet2@uky.edu>
Hi Jonathan, all On Fri, 29 Mar 2013 01:53:40 +0100, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote: > [Frank wrote] FYG about @longdesc: > I posted to the WCAG HTML Accessibility Taskforce list my thoughts on > this (do you have a pointer to that mail? I can't find it :( ) > – I’ll briefly restate them here. I'll reply here. But since there is a suggestion here to change the spec, I'll also reply to your mail if I find it, or start a new thread on the topic, in the HTML-a11y task force (which is the group formally producing the spec). > With the current proposal and previous requirements user agents were not > and still are not required to expose longdesc to users or required to > make it keyboard accessible. It’s indicated that “user agents” should > make them keyboard accessible. I'm not sure I understand. The requirements on user agents are: User agents should make the link available to all users through the regular user interface. User agents should expose the link to relevant APIs, especially accessibility-oriented APIs. User agents should enable users to discover when images in a page contain a long description. Are you simply proposing that the "should" reqiurements be strengthened to MUST? And that there should be a matching requirement to make them keyboard accessible? I would certainly be happy if the the shoulds listed become musts. If you would like to raise a bug, please do, or I can do it if you prefer. I don't think that the normative requirement to be keyboard-accessible belongs in this spec - it is a general accessibility requirement for User Agents that run on devices where keyboards can be used, so is in UAAG. I would propose instead adding an informative note and a reference, if you think it is necessary to make this particular point. > This perpetuates the idea that alternatives are only needed for users who > cannot see images or have images turned off. It is certainly not my intention to perpetuate that idea, because I believe it is wrong. > The HTML specification in fact indicates that alt shall NOT be > display when images are displayed as it acts a replacement for images. > So it’s not surprising the longdesc would follow down this same path as > alt. It would surprise me, as the person who wrote the text of the longdesc spec. I would think the HTML spec is wrong to insist on that, and would not want to follow. But I just read http://www.w3.org/TR/html5/embedded-content-0.html#the-img-element (the Candidate Recommenation draft) all the way through, and as far as I can tell it doesn't have that requirement. On a related note, I had an example in an early draft of a decorative image, with a null alt attribute, but which used longdesc to provide a detailed description for those who wanted it. This example was removed because a) it was not necessary and b) it was in conflict with WCAG techniques. Personally, I think the example is valid, and we should consider whether there is a real conflict with WCAG techniques, and if so which is actually correct. > I have no problem with programmatically associating long description or > long description links with an image but it MUST be available to all user > groups without having to install special plug-ins or run assistive > technology to access or make user agents display information that others > can access without such requirements. I agree that user agents that don't make longdesc available to all users all the time are not doing as well as they should. Putting requirements in specifications doesn't, by itself, change implementations. But I welcome input on strengthening the requirements... cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Received on Friday, 29 March 2013 15:14:06 UTC