- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Mon, 26 Nov 2007 11:08:15 -0500
- To: "Steven Faulkner" <faulkner.steve@gmail.com>
- Cc: wai-xtech@w3.org
[response follows the entirety of what Steve said] At 8:49 PM +0000 25 11 2007, Steven Faulkner wrote: >Hi Al, >This draft response does not appear to cover the core issue that >advice from WAI and PFWG was sought: >"the potential accessibility impact of omitting alt attribute for >critical content in HTML 5" [1] > >From the current draft of the HTML 5 spec under the heading "A key >part of the content that doesn't have an obvious textual alternative" > >"In such cases, the alt attribute may be omitted, but the alt >attribute should be included, with a useful value, if at all possible. >If an image is a key part of the content, the alt attribute must not >be specified with an empty value." [2] > >"When the alt attribute is missing, the image represents a key part >of the content. Non-visual user agents should apply image analysis >heuristics to help the user make sense of the image." [2] > >So in this circumstance > ><img src="poot.jpg"> signifies critical content for which no >alternative text has been provided. > >But how is this to be differentiated from all the img elements for >which an alt attribute has not been included, but are not "critical >content"? > >The spec moves the onus from the author to the assistive technology to >provide meaningful alternative text for images under certain >circumstances, which could be quite easily seen as the thin end of the >wedge as any HTML 5 img elements will be valid without alt attributes. >Currently no assistive technology applies image analysis heuristics of >any sophistication (if at all), at best they announce the content of >the title, src or href of the img or its parent. And it is unlikely >that they will be able to for the foreseeable future. > > >I would really appreciate a clarification on this issue be included as >part of the response. ** yes, that bit of editorializing by the editor is inapropriate. * bad technology assessment The suggestion to shift the burden to machine-vision technology in the assistive technology is not reasonable given the state of the art. WCAG regards etext as accessible content because TTS functionality is readily achievable by the consumer on the client side. Machine vision for the interpretation of images exists to some degree in some exotic contexts. But it is not readily achievable by the consumer on the client side and is not something that the HTML5 Spec. can rely on as client capabilities. * not respecting roles and missions (charters) of different groups. The quoted remarks from the Editor's Draft would put HTML5 in conflict with WCAG, and WCAG is chartered to produce Recommendations on this topic. Point, paragraph. The question in the quote is a matter of format usage, not format engineering. The answer is a matter of access policy, not format engineering. So by the charters, WCAG wins. Strike the remark. It's ill-considered editorializing by an individual and shouldn't be a big deal to get rid of. * second, why I didn't address this head on. I don't see why the issue page [1] accepted the terms in the quote from the current Editor's Draft as defining a real issue for the HTML Spec. The notion of 'critical content' is not used in developing the ALT text requirements in WCAG2, Guideline 1.1. They are more concrete than that and for good reason. One consumer's 'critical content' is another author's 'eye candy.' The WCAG WG took years to come up with the language they have. HTML WG has enough of a problem coming to consensus on questions that HTML5 does have to address; don't let the process in HTML WG get bogged down in yet another re-invention of that wheel. So the "core issue" is IMHO a non-issue. The necessary edit to the draft is a simple matter of applying the charter and WCAG and clean it up. I went through the roundabout dance of function and performance requirements because it is still appropriate for HTML5 to re-consider whether the best way to mark content that is "Decoration, Formatting, Invisible:" is with no @alt attribute at all or with an explicit null string as the value of the @alt attribute. Either of those choices, once offficially stated, is arguably a way to support what WCAG says. But "When is it appropriate to have meaningful content in @alt?" is addressed and settled by WCAG. HTML5 should stay out of that conversation other than to support the policy from WCAG with markup that enables readily-used techniques. Al >[1] http://lists.w3.org/Archives/Public/wai-xtech/2007Oct/0044.html >[2] http://www.w3.org/html/wg/html5/#the-img > >On 25/11/2007, Al Gilman <Alfred.S.Gilman@ieee.org> wrote: >> >> <note >> class="inDraft onProcess"> >> >> Earlier discussion on this point can be reviewed at >> http://lists.w3.org/Archives/Public/wai-xtech/2007Oct/thread.html#msg44 >> http://lists.w3.org/Archives/Public/wai-xtech/2007Nov/0012.html >> >> Please comment on this on the XTECH list. >> >> PFWG could reach consensus on some variant of this >> statement as early as Wednesday, 28 November or >> it could take longer depending on the nature of the >> commentary. >> >> </note> >> >> <premises> >> >> Let's note the following: >> >> WCAG2 is likely to become a recommendation before >> HTML5, and is reasonably likely to be a Rec for several >> years before HTML5. >> >> The Web has been under-performing as regards supplying >> good ALT text for images since 1997 when HTML4 was >> published with a syntactic requirement for @alt on all <img> >> elements. >> >> </premises> >> >> <position> >> >> HTMLWG should agree that authors SHOULD provide >> good text alternatives for all <img> elements as >> stated in WCAG2 Guideline 1.1. >> >> provisional URI: >> http://www.w3.org/WAI/GL/WCAG20/#text-equiv >> >> </position> >> >> <position> >> >> WAI should agree that well-placed informative references >> to existing W3C accessibility Recommendations is a >> suitable way for the HTML5 specification to address this, >> more or less as it has been done in the Specification Guidelines >> Recommendation. >> >> http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#address-other-topics >> >> </position> >> >> <position >> class="requirement"> >> >> WAI asserts that HTML5 should provide formal semantics >> bound to some markup pattern which enables a readily-followed >> technique for the part of Guidline 1.1 where it says >> >> <quote >> cite="http://www.w3.org/WAI/GL/WCAG20/#text-equiv-all"> >> > > Decoration, Formatting, Invisible: If it is pure decoration, or used >> only for visual formatting, or if it is not presented to users, then >> it is implemented in a way that it can be ignored by assistive >> technology. >> >> </quote> >> >> WAI suggests that the markup pattern >> >> @alt="" >> >> is a 'cowpath' in the language of the HTML5 Principles, in that >> assistive technology is already in the practice of recognizing >> <img> elements with that @alt value as ignorable. >> >> <note >> class="inDraft"> >> Somebody please confirm or deny this. Do screen readers >> actually skip images with @alt=""? >> </note> >> >> </position> >> >> Al >> /self (chair hat off) >> >> > > >-- >with regards > >Steve Faulkner >Technical Director - TPG Europe >Director - Web Accessibility Tools Consortium > >www.paciellogroup.com | www.wat-c.org >Web Accessibility Toolbar - >http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Monday, 26 November 2007 16:08:46 UTC