W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > February 2008

Change \"accessibility supported\" to \"accessibility-supporting\"

From: WCAG 2.0 Comment Form <nobody@w3.org>
Date: Sat, 2 Feb 2008 19:47:43 +0000 (GMT)
To: public-comments-wcag20@w3.org
Message-Id: <20080202194744.025575F70B@stu.w3.org>

Name: EOWG
Email: shawn@w3.org
Affiliation: W3C WAI EOWG
Document: W2
Item Number: (none selected)
Part of Item: 
Comment Type: general comment
Summary of Issue: Change \"accessibility supported\" to \"accessibility-supporting\"
Comment (Including rationale for any proposed change):
Several in EOWG continue to feel strongly that it should be \"accessibility-supporting technologies\". Here are two perspectives on this issue:

What is doing what to what? I *think* it\'s that technologies such as HTML and CSS are supporting accessibility in that they give structures that are available to AT to provide data about relationships within content.

<excerpt>\'Here is how I think the WCAG WG is thinking of it: \"Accessibility supporting\" would talk about what the technology does. That is, it supports accessibility. \"Accessibility supported\" refers to what has been done to (or is true of) a technology. That is, that there is accessibility support FOR the technology. We mean the latter not the former. So \"accessibility supported\" would be the correct term and would be hyphenated whenever used as an adjective.\'</excerpt>

So let\'s unpack this. Is it true that HTML is accessibility-supported? That is the same as saying that HTML is supported by accessibility. I\'m not sure that \"HTML is supported *by* accessibility\" is a meaningful phrase. \"HTML or CSS provides support for AT\" would be meaningful. But it doesn\'t do what we want to do, which is to differentiate between technologies that remove accessibility barriers and technologies that don\'t.

Consider a fictional new content delivery technology, let\'s call it PEBKAC. PEBKAC has some integral accessibility features, but these are not supported by users\' assistive technologies, nor by current browsers and other user agents. Where is the \'accessibility\'? Is it sitting in PEBCAK, unsupported by AT? Or is it sitting in the AT, unsupported by PEBKAC? Or is it an emergent property of the link between the two?

Clearly it is the last of these. Can an emergent property perform an action? Possibly. Love conquers all, after all.

EOWG supports love. EOWG is a love-supporting group.

EOWG would like to be a love-supported group. Does love itself support us?

**Only if we personnify \'Love\'**

Maybe WCAG-WG have personnified Accessibility?

But accessibility is not a person, it\'s a property.

So I still vote for accessibility-supporting.


Accessibility supported would be valid if it was defined in terms of what has been done to a technology to achieve interoperability with assistive technologies and their hosting user agents.  If this is what is meant then the definition should state what has been done, i.e. it identifies roles through ARIA or it has been developed to support particular API\'s. 

The definition of Accessibility Supported is not stated this way.  It describes how the technology should behave when it operates with assistive technology and hosting user agents.  The only action that has been done to the web technology in the definition is that it has been tested for appropriate behavior with users\' assistive technologies and user agents.  The appropriate behavior is using accessible interfaces that assistive technologies and user agents recognize -present tense.  The way to make a noun phrase that is present tense is to add \"ing\" to the verb. 

For a grammatically correct name the concept should either be defined in terms of what has been done (accessibility-supported) or name needs to change to what it does (accessibility-supporting).  Right now the name does not fit the definition.  One has to change.  The easiest change is the name: accessibility-supporting.


Proposed Change:
Received on Saturday, 2 February 2008 19:47:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:46 UTC