On Mon, Mar 29, 2010 at 7:41 PM, tee <weblis...@gmail.com> wrote: > I am giving the benefit of doubt that there might be a good reason.
Hmm. There seems to a bit of confusion here. Not every document published by W3C is a Recommendation endorsed by W3C (an official "standard"). Examples of Recommendations include: * HTML 4.01: http://www.w3.org/TR/REC-html40/ * Web Content Accessibility Guidelines 2.0: http://www.w3.org/TR/WCAG20/ Examples of non-Recommendations include: * XHTML Media Types: http://www.w3.org/TR/xhtml-media-types/ * Techniques for WCAG 2.0: http://www.w3.org/TR/WCAG-TECHS/ Techniques for WCAG 2.0 are meant to be an unstandardized, evolving, technology-specific corpus of examples of how you might pass (standardized) technology-independent WCAG2 Success Criteria. The following are distinct (if overlapping) sets: * HTML4 validity * HTML4 conformance * WCAG2 conformance * Passing tests for chosen Techniques for WCAG 2.0 * Real-world accessibility For example, an individual document might (theoretically): * Validate and conform as HTML4, pass all the tests in all the WCAG2 Techniques, fail WCAG2 conformance, yet achieve real-world accessibility. * Flunk HTML4 validation and conformance and fail all the tests in all the WCAG2 Techniques but still achieve WCAG2 conformance and achieve real-world accessibility. Total Validator is checking your document for HTML SGML validity and against some snapshot of machine-testable tests from the WCAG2 Techniques corpus. You can check which by looking up the Error in their Error reference: http://www.totalvalidator.com/support/reference/index.html None of the distinct sets identified above necessarily require that labels and fields be descendants of "form" elements *or* any particular positioning of "label" elements relative to fields. But if you applying Technique H44 ("Using label elements to associate text labels with form controls") then "label" elements must be: * before associated field elements that are "select", "textarea", or "input" of type "text", "file", or "password" * after associated field elements that are "input" of type "radio" or "checkbox". How does this help real-world accessibility? The before/after distinction reflects a common convention in Graphical User Interfaces for positioning labels and fields: most labels go to the left of fields, but labels for checkboxes and radio buttons go to the right. Before "label" existed (it was introduced in HTML4), assistive technology such as screen readers had to infer what text labelled what control based on such GUI conventions. Continuing to follow those conventions allows such legacy software to continue to work. Modern assistive technology *should* correctly associate fields with labels regardless of label placement if there's a "for"/"id" association. But even with modern user agents, following those ancient GUI conventions helps accessibility because it helps make your interface immediately understandle to sighted users. This goes double if you are only poorly sighted and are viewing the page with zoom, or with your own preferred styles. See also the W3C discussions at: * http://lists.w3.org/Archives/Public/w3c-wai-gl/2005JulSep/0716.html * http://lists.w3.org/Archives/Public/public-bpwg-access/2007Oct/0003.html * http://lists.w3.org/Archives/Public/w3c-wai-gl/1998OctDec/0009.html * http://lists.w3.org/Archives/Public/w3c-wai-ua/1998OctDec/0030.html * http://lists.w3.org/Archives/Public/w3c-wai-eo/1999AprJun/0168.html * http://lists.w3.org/Archives/Public/w3c-wai-eo/1999AprJun/0169.html As a tangent, tee mentioned the "luxury to perform all sort of screen readers testing using pricy software". You cannot freely test with the free JAWS demo thanks to EULA restrictions, but the following are all free to test with: * Window-Eyes Demo (30-minutes-per-Windows-session limit) * NVDA on Windows (FOSS) * VoiceOver comes with OS X * Orca on GNOME (FOSS) The main hurdle here is not price, but developer inexperience with with complex assistive technology. -- Benjamin Hawkes-Lewis ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *******************************************************************
