- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 16 Aug 2009 16:56:47 +0300
- To: Steven Faulkner <faulkner.steve@gmail.com>
- Cc: Ian Hickson <ian@hixie.ch>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
On Aug 15, 2009, at 15:52, Steven Faulkner wrote: > as part of my work on http://www.w3.org/html/wg/tracker/actions/131, > to progress towards consensus by the html wg on the contents of the > html 5 specification in regards to text alternatives, it would be > helpful to get feedback from you and other interested people on the > 'WAI CG Consensus Resolutions on Text alternatives in HTML 5' > documenthttp://www.w3.org/2009/06/Text-Alternatives-in-HTML5 I noticed that your question was addressed to Ian and CCed to public lists, but I'll go ahead and reply myself anyway: I previously asked for clarifications on the WAI CG consensus: http://lists.w3.org/Archives/Public/wai-xtech/2009Jul/0057.html However, I didn't get further replies after: http://lists.w3.org/Archives/Public/wai-xtech/2009Jul/0087.html Therefore, I'd like to reiterate the following point: I think it doesn't make sense to evaluate the statement of consensus in isolation of knowing what ATAG 2.0 or its accompanying documents are going to recommend to developers of HTML5 editors. I think the following procedure should be followed: 1) Find out how browser/AT combinations behave given various combinations of <img>, alt, lack of alt, empty alt, aria-label, title, aria-describedby, etc. 2) Given the existing client behaviors discovered at step #1, develop authoring tool guidance for different scenarios of the authoring tool user being cooperative and uncooperative. In particular, develop guidance on what markup and authoring tool must emit when the user doesn't provide text alternatives (for whatever reason). 3) Adjust the HTML 5 specification so that following the guidance developed in step #2 doesn't render the output document of the editor invalid, because it would be non-sensical for one spec to tell authoring tool developers "do X" and another to tell "don't do X" and making some syntax invalid would make some tool vendors avoid the syntax even if doing so lead to a worse outcome considering step #1. (Note that defining a markup construct as invalid by definition means that authoring tools must not emit that markup construct.) 4) Adjust validators to comply with the result of step #3, so that output from tools complying with guidance from step #2 isn't reported as invalid. 5) Provide optional diagnostic help for validator users who wish to evaluate text alternatives or lack thereof in a way that doesn't motivate authoring tool vendors to fail to comply with the guidance from step #2. (Consider the Image Report feature of Validator.nu.) As far as I can tell, the WAI Consensus jumps to step #3 leaving step #2 unclear. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Sunday, 16 August 2009 13:57:33 UTC