Re: Request to Strengthen the HTML5 Accessibility Design Principle

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