Re: Request to Strengthen the HTML5 Accessibility Design Principle

Hi Maciej,

You wrote [1]:

> 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?

The purpose of the design principles has been discussed on numerous
occasions to no avail. We disagree with your view but respect it, as
you are the author of this document.

Our view is that the accessibility principle is ambiguous and has
impeded accessibility issue resolution. Strengthening it would provide
needed guidance.

We will be authoring a separate procedure document to help foster
positive outcomes with regard to accessibility issues in HTML5 and/or
be asking for a vote on our Strengthened Version of Accessibility
Design Principle [2] if substantive edits are not agreeable to you and
Anne.

> 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".

"Design features to be ..." is grammatically ambiguous; it could
commence with the noun phrase "Design features" or with the verb
"Design".  The re-cast was intended to eliminate the ambiguity. If
there are objections to "We will", then the whole can be re-cast in
the passive voice : "All features will be designed ...", etc.

> * "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.

Charles has already provided solid rationale [3] for this change. We
would add that people with temporary limitations could and would
benefit from some accessibility features. However, people with
temporary limitations or technical constraints are *not* a part of the
socio-economic demographic that is the community of people with
disabilities. This community faces some unique challenges and barriers
(and is only too often systemically excluded). To ensure that such
exclusion does not occur in HTML 5, it may need to contain some
features that are *only* of use to people with disabilities, if
functional equivalents are not provided.

Accessibility is a condition of access for all, as other conditions
(media independence [4], language [5], infrastructure, geographical
location, culture, etc.). When accessibility has been considered in
its own right within universal access, people with disabilities won't
be overlooked. If people with disabilities are overlooked in a design,
then the design doesn't embody the principles of universality in the
first place. The danger of broadening the scope and distorting the
meaning of accessibility to include everyone is that discussions can
quickly degenerate to pandering to people's whims, rather than real
issues that affect people with disabilities.

To that end, the reason for the proposed change is to clarify that
*accessibility* is about ensuring that people with *disabilities* do
not encounter barriers through things that they cannot readily change.
This modification will allow the meaning of accessibility in the
accessibility design principle to align to what is promoted within W3C
and its Web Accessibility Initiative. [6]

> * "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;

Thank you.

> * "alternate mechanisms" --> "rather that alternative/equivalent mechanisms"
>      I'm happy to change to "equivalent or alternative mechanisms".

Changing it to "equivalent or alternative mechanisms" would be fine. Thank you.

> * "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.

We would prefer to strengthen all of the design principles, rather
than intentionally weaken them by downgrading one from a "must" to a
"should". But we could try to live with the other principles being
weak if in this instance the word is changed to "will" as the charter
[7] specifies, "deliverables will satisfy accessibility requirements."

> 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.

Your current wording for that example is "The image in an <img> may
not be visible to blind users, but that is a reason to provide
alternate text, not to leave out images."

The abstract [8] indicates that the principles offer guidance for
specification design not for author use. The rationale for this change
is to align the example by phrasing it to indicate spec design not
author use.

In addition the terms "text alternatives" [9] and "perceivable" [10]
align with WAI terminology.

> * 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.

Thank you.

Respectfully,

Laura L. Carlson <laura.lee.carlson@gmail.com>
Catherine Roy <ecrire@catherine-roy.net>
Debi Orton <oradnio@gmail.com>
John Foliot <jfoliot@stanford.edu>
Philip TAYLOR <p.taylor@rhul.ac.uk>
Robert J Burns <rob@robburns.com>
Steve Faulkner <sfaulkner@paciellogroup.com>

[1] http://lists.w3.org/Archives/Public/public-html/2009Jun/0692.html
[2] http://esw.w3.org/topic/HTML/AccessibilityDesignPrinciple
[3] http://lists.w3.org/Archives/Public/public-html/2009Jun/0702.html
[4] http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#media-independence
[5] http://www.w3.org/TR/2007/WD-html-design-principles-20071126/#support-world-languages
[6] WAI http://www.w3.org/WAI/about-links.html
[7] http://www.w3.org/2007/03/HTML-WG-charter.html#wai
[8] http://dev.w3.org/html5/html-design-principles/Overview.html#abstract
[9] http://www.w3.org/TR/WCAG20/#text-altdef
[10] http://www.w3.org/TR/WCAG20/#perceivable

Related Reference:
United Nations Article 9 - Accessibility:
http://www.un.org/disabilities/default.asp?id=269

-- 
Laura L. Carlson

Received on Tuesday, 7 July 2009 17:09:33 UTC