RE: More on the ATAG-WCAG relationship

>ATAG serves a different section/column in the accessibility diagram
>structure and a different audience. Developers of authoring tools are a
>step away from the environment where content is consumed - a developer
>of an authoring tool cannot predict and test all the
>language/browser/assistive technologies where content produced by the
>authoring tool may be used. Further, it would hinder innovation in
>improving accessibility to require that

Although the primary audience is developers, I know of at least one instance
where the ATAG is used in a legal national law suit against a government,
and as such, the use of the less accurate term "accessible content" may have
a major effect on the outcome of the court case, and may be misleading to
decision makers who are trusting the W3C as accurate.

David MacDonald

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Judy Brewer
Sent: August-18-11 1:49 PM
To: Jeanne Spellman; AUWG; WCAG WG
Subject: Re: More on the ATAG-WCAG relationship

Jeanne, Jan,

Thanks for the additional clarifications in your replies.

Jan, yes I support a special CG to explore the details of the 
dependency and come back to the groups with options.

Will do a separate thread to check availability for that.

- Judy

At 11:07 AM 8/18/2011 -0400, Jeanne Spellman wrote:
>FYI: I found the email I was looking for on the WCAG archives and 
>included it below.
>
>-------- Original Message --------
>Subject: Re: More on the ATAG-WCAG relationship
>Date: Thu, 18 Aug 2011 09:51:59 -0400
>From: Jeanne Spellman <jeanne@w3.org>
>To: Gregg Vanderheiden <gv@trace.wisc.edu>
>CC: Judy Brewer <jbrewer@w3.org>, "Richards, Jan" 
><jrichards@ocad.ca>, "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>, WAI CG 
><w3c-wai-cg@w3.org>
>
>To recap:
>This discussion concerns the WCAG WG comment on the 2010 ATAG2 Last Call:
>WCAGWG17: "B 2.1.1 (a) and elsewhere term 'accessible content' is used
>where perhaps "conforming with WCAG 2.0" would be better. "
>
>The AUWG made changes to B.2.1.1(a) and some additional locations as
>requested. WCAG WG accepted all the changes made by AUWG to all their
>comments except this one.
>http://lists.w3.org/Archives/Public/w3c-wai-gl/2011JulSep/0081.html
>
>I would like to request that WCAG WG withdraw their overall objection to
>all uses of the term "accessible content" for the following reasons:
>
>1. UNDERSTANDABLE
>I want to keep the document readable, keeping the jargon to the places
>where precision is required.  Most of the places where "accessible
>content" is used, it is a conceptual term - especially in Principles and
>Guidelines.
>
>"Accessible content" is used in our principles and guidelines:
>
>Part B. Support the production of accessible content
>PRINCIPLE B.1: Fully automatic processes must produce accessible content
>PRINCIPLE B.2: Authors must be supported in producing accessible content
>Guideline B.2.1: Ensure accessible content production is possible.
>Guideline B.2.2: Guide authors to produce accessible content.
>
>A blanket decision for all uses of "accessible content" is
>counterproductive to our goals.  Gregg's desire to educate is
>commendable, and certainly belongs in the document, but not repeated 80+
>times making the document so jargon-ridden that even the basic
>principles and guidelines are intimidating to the first-time reader.
>
>I would rather keep "accessible content" as is, look for the places
>where "accessible content" impacts testing and use a more precise,
>normative-defined term there.
>
>I recommend putting a section on "accessible content" in the
>introduction with Gregg's ideas and links to normative definitions. It
>is counterproductive to the acceptance and implementation of ATAG to
>clutter the entire document with asterisks, hyphenated-phrases, and
>definition links wherever "accessible content" is being used.
>
>2. ACCESSIBILITY SUPPORTED TECHNOLOGIES
>ATAG serves a different section/column in the accessibility diagram
>structure and a different audience. Developers of authoring tools are a
>step away from the environment where content is consumed - a developer
>of an authoring tool cannot predict and test all the
>language/browser/assistive technologies where content produced by the
>authoring tool may be used. Further, it would hinder innovation in
>improving accessibility to require that ATAG2-conformant tools be
>restricted to existing browsers and AT.
>
>Jan's use case of SVG is important.  When a developer creates a tool
>that produces well-structured SVG that supports accessibility, we want
>that tool be ATAG-conformant, even though no browser or assistive
>technology currently supports it.  Requiring WCAG2-conformance (with its
>requirement for accessibility supported technologies) would mean a
>developer could not achieve ATAG2 conformance.  This would hinder the
>development of products that would improve accessibility overall. ATAG
>2.0 needs to be independent of the WCAG requirement for accessibility
>supported technologies.
>
>3. CLEAR SEPARATION BETWEEN WCAG AND ATAG
>"Accessible content" is not used in Part A (making the tool itself
>accessible). Gregg's argument would apply here, IMO, but that is not
>where it is used.
>
>WCAG 2.0 is the correct document for end-user-level precision in
>determining accessibility. ATAG 2.0 is not. The LAST thing we want is
>for the accessibility supported technologies discussion to be further
>confounded by subtle differences between ATAG and WCAG.
>
>I would like to ask WCAG WG to remove their objection to the broad use
>of "accessible content", with the proviso that AUWG will look critically
>at its use in SC where it impacts the ability to test the SC.
>
>
>jeanne
>
>
>On 8/18/2011 1:21 AM, Gregg Vanderheiden wrote:
>>
>>
>>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.
>>
>>
>
>--
>_______________________________
>Jeanne Spellman
>W3C Web Accessibility Initiative
>jeanne@w3.org

Received on Thursday, 18 August 2011 20:02:15 UTC