- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 24 Jun 2009 11:49:20 -0700
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: HTML WG <public-html@w3.org>, Sam Ruby <rubys@intertwingly.net>, Chris Wilson <Chris.Wilson@microsoft.com>, Anne van Kesteren <annevk@opera.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>, W3C WAI-XTECH <wai-xtech@w3.org>
- Message-id: <1AE55070-9370-453A-9C9E-A4051B73D5C9@apple.com>
Thanks for the feedback on the Design Principles document. On Jun 23, 2009, at 10:41 PM, Laura Carlson wrote: > 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. I see two changes here: 1) Addition of a specific statement requiring coordination with W3C WAI groups. I think this is inappropriate to add to the Design Principles. The Design Principles are about technical aspects of design, not process and social coordination. They are are also supposed to be descriptive, helping to understand the design decisions in the spec, but stating what groups were listened to does not have explanatory power. The Design Principles are careful to stay away from requiring coordination with other groups since that is charter territory. The document does not even mention HTML WG except in front matter. May I ask why you feel the coordination requirement in the charter is insufficient, and why WAI should be the one exception that also gets mentioned in the Design Principles? 2) Some minor wording changes. I would appreciate rationale for these. Tentatively, I'm not in favor of most of them: * "Design features to be accessible to..." --> "We will design all features so as to ensure that they are accessible to... " The proposed alternative is more verbose, and does not match the style of other Design Principles, none of which start with "we will". * "Access by everyone regardless of ability is essential." --> "Access for people with disabilities is essential." It seems like the change here is to exclude people who would not be classified as disabled from the scope of the principle, since people with disabilities were already specifically called out by the previous sentence. Content should be accessible to people of normal ability, as well as those with minor or temporary difficulties that might not traditionally be classified as a disability. Arguably this is so obvious as to go without saying, but I can't think of a reason to remove such people from consideration except to argue otherwise. I think the principle should continue to require access for all. * "should be omitted entirely if not all users can make full use" --> "should be omitted if not all users can fully make use" This change seems all right; doesn't make the wording or substance any worse. * "alternate mechanisms" --> "rather that alternative/ equivalentmechanisms" I'm happy to change to "equivalent or alternative mechanisms". * "should be provided" --> "must be provided" The Design Principles are careful never to say "must", to avoid confusion about their normative status. The whole document is completely non-normative. I would prefer to keep it that way. I'm happy to reconsider any of these if rationale is 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." I'm happy to add a headers="" example. Note that I think it satisfies the principle even without removing the reference to "everyone regardless of ability" since sighted users that aren't also using a screen reader or other assistive technology get equivalent content in the form of the visible structure of the table. Regards, Maciej
Received on Wednesday, 24 June 2009 18:50:04 UTC