- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Wed, 24 Jun 2009 00:41:21 -0500
- To: HTML WG <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>, Chris Wilson <Chris.Wilson@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Anne van Kesteren <annevk@opera.com>
- Cc: Catherine Roy <ecrire@catherine-roy.net>, Gez Lemon <gez.lemon@gmail.com>, Leif Halvard Silli <lhs@malform.no>, Philip TAYLOR <p.taylor@rhul.ac.uk>, Robert J Burns <rob@robburns.com>, Roger Johansson <roger@456bereastreet.com>, W3C WAI-XTECH <wai-xtech@w3.org>
To the Co-Chairs, Design Principles Editors, and Members of the W3C HTML Working Group The HTML5 Charter [1] states, "The HTML Working Group will cooperate with the Web Accessibility Initiative to ensure that the deliverables will satisfy accessibility requirements." Accessibility features address use cases that may be infrequent but such use cases are critical. Failure to provide such mechanisms when they are required excludes people solely on the basis of disability. The HTML5 Design Principles document claims accessibility as a principle [2]. After much discussion in 2007, the phrase "when possible" was removed from the accessibility principle. However, the accessibility principle is still ambiguous and has caused miscommunication and impeded issue resolution. We request that the accessibility design principle be disambiguated and strengthened by replacing it with the following definition text and two examples: "We will design all features so as to ensure that they are accessible to users with disabilities. To this end, we will look to the W3C WAI groups for guidance, listen to their advice, and collaborate with them to reach mutually agreeable accessibility solutions. Access for people with disabilities is essential. This does not mean that features should be omitted if not all users can fully make use of them but rather that alternative/equivalent mechanisms must be provided. * Example: The image in the img element is not perceivable by blind users. That is not a reason to drop the element from the specification, but is a reason to require mechanisms for adding text alternatives. * The headers attribute may not be rendered to sighted users. However, including it in the specification provides an equitable solution as its use allows users of screen readers the opportunity to hear the headers associated with each data cell in complex tables." Respectfully, Laura L. Carlson <laura.lee.carlson@gmail.com> Debi Orton <oradnio@gmail.com> Jason White <jason@jasonjgw.net> John Foliot <foliot@wats.ca> Joshue O Connor <joshue.oconnor@cfit.ie> Patrick H. Lauke <redux@splintered.co.uk> Shelley Powers <shelleyp@burningbird.net> Steve Faulkner <sfaulkner@paciellogroup.com> Catherine Roy <ecrire@catherine-roy.net> Gez Lemon <gez.lemon@gmail.com> Leif Halvard Silli <lhs@malform.no> Philip TAYLOR <p.taylor@rhul.ac.uk> Robert J Burns<rob@robburns.com> Roger Johansson <roger@456bereastreet.com> [1] http://www.w3.org/2007/03/HTML-WG-charter.html#wai [2] http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#accessibility A copy of this request is also in the ESW Wiki at: http://esw.w3.org/topic/HTML/AccessibilityDesignPrinciple -- Laura L. Carlson
Received on Wednesday, 24 June 2009 05:42:00 UTC