- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 13 Jan 2012 10:43:21 +0000
- To: HTMLWG WG <public-html@w3.org>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi all, I am happy to say that in the latest round of testing: http://www.html5accessibility.com/tests/form-labels.html All major browsers (except Opera) tested now support both methods robustly and as Opera does not have practical support for assistive technology on any platform, its lack of support can be discounted. This does not mean that other parts of the HTML5 spec that recommend mark up antipatterns, do not need to be modified. I have raised these as issues: Remove CSS example that promotes inaccessible content https://www.w3.org/html/wg/tracker/issues/193 title attribute definition does not match reality https://www.w3.org/html/wg/tracker/issues/192 Replace poor coding example for figure with multiple images https://www.w3.org/html/wg/tracker/issues/190 Advice in spec about annotations promotes inaccessible content https://www.w3.org/html/wg/tracker/issues/182 regards Stevef On 6 January 2012 11:18, Steve Faulkner <faulkner.steve@gmail.com> wrote: > Hi all > One of the purported benefits of the the 'living standard' is that > implementors always get the most up to date implementation > information. In W3C terms this means that editors drafts are promoted > as the documents to refer to and use. I don't disagree with this idea, > but am a little perplexed by the differing strategies about providing > the most up to date and correct information to one group > (implementors) while continuing to provide information that is not up > to date and correct to another group (developers) in the very same > editor's drafts. > > One example (there are many more), > The use of implicit labels is found in examples in the HTML5 spec, > something that has been a documented feature of HTML since at least 24 > December 1999, yet at least one major browser has not implemented > accessibility support for it yet. [1] > > When it is suggested that this method should not continue to be > promoted alongside the more robust and better supported for/id method > the HTML5 editor's assistants response is > > "Examples that do not work everywhere yet is not a reason to change > the examples. It's an incentive to get the software fixed." [2] > > > So we have a method that has been promoted for 10 years and continues > to be promoted which is broken, how is that useful for either users or > developers? > > > When will specifiers give users and developers the same level of > consideration in the provision of useful practical information as is > afforded implementors? > > "In case of conflict, consider users over authors over implementors > over specifiers over theoretical purity."[3] > > The HTML design principles do not seem to be taken into account here > or am i missing something? > > > [1] http://www.html5accessibility.com/tests/form-labels.html > > [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=13531#c6 > > [3] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies > > > -- > with regards > > Steve Faulkner > Technical Director - TPG > > www.paciellogroup.com | www.HTML5accessibility.com | > www.twitter.com/stevefaulkner > HTML5: Techniques for providing useful text alternatives - > dev.w3.org/html5/alt-techniques/ > Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Friday, 13 January 2012 12:30:39 UTC