W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 2011

RE: More on the ATAG-WCAG relationship

From: Richards, Jan <jrichards@ocad.ca>
Date: Thu, 18 Aug 2011 13:33:20 +0000
To: Gregg Vanderheiden <gv@trace.wisc.edu>, Judy Brewer <jbrewer@w3.org>
CC: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>, WAI CG <w3c-wai-cg@w3.org>
Message-ID: <0B1EB1C972BCB740B522ACBCD5F48DEB0367A8BC@ocadmail-maildb.ocad.ca>
Judy said:

"Jan, we had discussed using "WCAG2-conformant content" earlier today, and I thought agreed that that was a clear and useful term in this instance. I'm unclear why you're re-opening this; it is only marginally longer than "accessible content.""


JR: Sorry Judy, but we didn't agree on the term "WCAG2-conformant content" yesterday. The biggest issue with the term is that the content in question may *not* actually conform with WCAG2 because the technology of the content is not "accessibility supported" (see below), which makes the term confusing.

Gregg said:
I'm not sure however how you can drop the "accessibility supported" part.   If the techniques you use require AT but there is no AT to support them -- then the techniques are useless and a waste of developer time to implement.   If they only work on some platforms -- that information should be provided rather than saying it was "accessible*" except that people with disabilities cannot use it.  I think you need to figure out how to handle accessibility support rather than ignore it since it is an essential aspect of accessibility (essential in that if you don't have accessibility support then you have zero accessibility if it depends on AT).

JR: This is really the central issue. On Monday, the AUWG members in attendance confirmed their belief that there is value in allowing tools to conform to ATAG 2.0 ahead of real-world user agent and AT support of the technologies the authoring tools produce (as part of the process of ramping up the accessibility of new technologies).

For example: Imagine a new format SVGX that encodes vector-based graphics and has followed WAI-PF advice so that it includes language features that encode lots of accessibility information. AUWG thinks it should be possible for an SVGX authoring tool to meet ATAG 2.0 by supporting authoring of that accessibility information even before an accessible SVGX browser+AT combination has actually been released.

That is not to say that AUWG disagrees with WCAG 2.0's approach to conformance - because WCAG has a focus that is closer to determining real-world accessibility of specific web pages.

I wonder if we need a special CG call to discuss this.

Cheers,
Jan

--
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca<mailto:jrichards@ocad.ca> | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://idrc.ocad.ca/
Faculty of Design | OCAD University

From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]<mailto:[mailto:gv@trace.wisc.edu]>
Sent: August 18, 2011 1:21 AM
To: Judy Brewer
Cc: Richards, Jan; w3c-wai-au@w3.org<mailto:w3c-wai-au@w3.org>; WAI CG
Subject: Re: More on the ATAG-WCAG relationship



On Aug 17, 2011, at 11:11 PM, Judy Brewer wrote:



(2) when we need to use "accessible content" as shorthand in the normative success criteria, we could say "accessible* content" (note the asterisk) and in the definition of the term:
- we require such content to meet the WCAG 2.0 success criteria, but not necessarily the WCAG 2.0 conformance requirements, such as "accessibility supported".
- we state that WCAG 2.0 notes "that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas".

I like the    accessible* content    approach personally.   Very nice actually.     It both allows a 'generic' or simple term  --- and puts the qualifiers on the term via the footnote.   In fact, it helps define the term in a way that could generalize to other uses of the term  "accessible content" in other places.   In fact, some people might pick up this usage in other docs.

I think that the "accessible*" approach would create a significant degree of confusion in many settings.

By the way, I continue to think that the term "accessible content" could be an option, _if_ appropriately defined in the normal definition section to indicate that it is not an absolute term. Creating a special footnote category for an asterisk-version of the term "accessible" would very likely only exacerbate that confusion. Few terms are absolute, actually; and we seem to be straying further and further from clear communication with some of these approaches. However, if this remains too much of a concern, then the approach of using the term "WCAG2-conformant content" seems both clear and non-controversial; and Jan I therefore encourage you to reconsider using it.

GV:   I am already finding many people wanting to define "accessible" as meaning "conforming to some guidelines".   This is a severe problem for all the disabilities and people who are not addressed in these guidelines -- particularly  cognitive, language, and learning disabilities .  (but deaf blind and others as well)

So I don't think we should ever user  "accessible content"   in any formal document -- or as anything other than an aspirational goal.     I thought the asterisk idea was a great way to use this common phrase - yet also bring attention to the fact that it is more than meeting guidelines.  That guidelines are the start - the minimum that you should do.

Maybe   "minimum accessibility standard"  is a bad phrase since it implies that it only provides minimum accessibility.    What I meant was  "minimum required accessibility"  meaning that you should do AT LEAST this  (not A MOST - or   JUST THIS).

Maybe we should write   "Basic Accessibility"  but that sounds like  full accessibility to basic functions -- and that is not true.    hmmmmm  What do we say WCAG is that will get across the idea that is it substantial but only the minimum that you should do.  Any ideas anyone?

here is my attempt to fix this -- and address your comment Judy about the old text being too full of negatives.   is this better?:

1) We try to be clear in our informative sections that WCAG 2.0 defines minimum level(s) of accessibility."

(2) when we need to use "accessible content" as shorthand in the normative success criteria, we could say "accessible* content" (note the asterisk) and in the Footnote definition of the term:


FOOTNOTE DEFINITION:

* Accessibility has an asterisk because nothing is absolutely accessible  (accessible to everyone in all environments and tasks)
  * When we say  "accessible* content" we mean content that conforms to WCAG 2.0  [at level A or Level AA]
  * Note that although WCAG 2.0 conformance provides good accessibility, it does not provide complete accessibility.  "Even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas ( From Intro section of WCAG 2.0)".  It is good therefore to use WCAG 2.0 as the basis but to also implement advisory and other techniques to further enhance accessibility where possible.
Received on Thursday, 18 August 2011 13:33:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 18 August 2011 13:33:49 GMT