W3C home > Mailing lists > Public > public-html@w3.org > June 2009

Request to Strengthen the HTML5 Accessibility Design Principle

From: Laura Carlson <laura.lee.carlson@gmail.com>
Date: Wed, 24 Jun 2009 00:41:21 -0500
Message-ID: <1c8dbcaa0906232241h2ca21512q1640c686e73875fe@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:04 UTC