- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Sat, 24 Apr 2010 13:21:03 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: Steven Faulkner <faulkner.steve@gmail.com>, Maciej Stachowiak <mjs@apple.com>, Dave Singer <singer@apple.com>, Matt Morgan-May <mattmay@adobe.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi Ian, > As I understand it the only proposed non-ARIA solution is <figcaption>, > which is supported even less by ATs than title="". I would be open to eliminating <figcaption> from the list of options, if we do not have solid rationale for it. Steve mentioned, <figcaption> content is available by default to all users and it is not hidden. These are good points but are they enough? A couple of comments from the face to face meeting minutes seem relevant. I think it was Sean who pointed out that if we want the figure to be equivalent to aria-labelledby we would need figcaption to be available outside <figure>. And complete equivalence between figure and aria-labelledby would require the figcaption could go anywhere and have a pointer to the caption. Ian can you make that happen? You once explained your nine step procedure [1] for adding new features to the spec. You concluded by saying that the default state for a feature request is for it to be rejected and the default state for a section of the spec was for it to be eventually dropped unless the feature is widely implemented and so important that browser vendors "are actually ready to commit money and risk interop issues over it". Is figure widely implemented? Are browser vendors actually ready to commit money and risk interop issues over it? >> Authors are advised to only use the title attribute for "additional >> information" and not as a full equivalent alternative. > > The spec doesn't suggest using it as a full equivalent alternative. I think that this may be a key point of confusion in all of this that we need to clear up. WCAG allows alt text alternatives values that identify and describe purpose [2]. HTML5 doesn't. On the CAPTCHA bug you said, "HTML5's solution avoids conflating alternatives and purpose descriptions, and as such is an improvement over what could be done in HTML4." How do we reconcile this? Steve has illustrated the WCAG way in the "Techniques for providing useful text alternatives" document [3] with the examples from the Webcam [4] [5] and CAPTCHA [6] [7] bug face offs. I drafted a CAPTCHA survey last month [8]. It included Matt's idea of providing a "captcha" role on img to give user agents and assistive technologies a chance to call internal or cloud-based CAPTCHA solving systems like Webvisum, and validation/evaluation tools to mark them as an accessibility issue. Ian would you be open to something like this? >> Removing title would make the HTML specification in line with WCAG, and >> previous authoring practices. http://www.w3.org/TR/WCAG20-TECHS/H33.html > > WCAG's recommendations are based on HTML4; the whole point here is to move > forward. WCAG will need updating for HTML5. It might help if we think of it as a two way street. WCAG will need updating for HTML5 and HTML5 will need updating for WCAG. We are here to try sort out how best to do that. Working together maybe we can figure it out. Best Regards, Laura [1] http://lists.w3.org/Archives/Public/public-html/2008Jun/0140.html [2] http://www.w3.org/TR/WCAG20/#text-equiv [3] http://dev.w3.org/html5/alt-techniques/ [4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9215 [5] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9174 [6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9216 [7] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9169 [8] http://www.w3.org/WAI/PF/HTML/wiki/CAPTCHA_Survey -- Laura L. Carlson
Received on Saturday, 24 April 2010 18:21:36 UTC