Re: More on the ATAG-WCAG relationship

Simplicity of presentation is always a good goal.  
But I quote Albert Einstein who said  "Everything should be made as simple as possible, but no simpler."

I would caution against simplifying language at the expense of accuracy when it would make it inaccurate in so fundamental a way. 

The fact that this is a technical standard makes this even more important. 

It is unfortunate that the field uses the word "accessible" so casually in an absolute fashion.  But there is a real danger if we use the term in this fashion in any document that might (or probably will) be used in any regulatory fashion.   The danger is that people will take us at our word -- and define WCAG conformant content (or any content - OR TOOLS ) as being "accessible" if they meet a standard for accessibility.   The result is that there would no longer be any legal basis for those not addressed by the standard to ask for anything.  Indeed it becomes a "solved" problem. 

I thought Jan's solution was a great one.  It allows one to use   accessible*   and     accessible* content   while (at least for this document) making it abundantly clear what the limitations on this word are.  

Is it a bit awkward -- maybe.   But a lot less than putting     "conformant content"  or  "WCAG2-accessible content"  or some such everywhere. 

you could try defining it one place up front but that is unlikely to be read by many people.  They tend to jump right to the provisions etc and miss the whole game.

PERHAPS you could but the note below in a big colored box at the front of the document.  That might catch people's attention and could provide legal basis for refuting any claim that we think 'conformant' means 'accessible'. 


============================ 
Accessible Content
In this document we use the term "accessible" and "accessible content" 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 for accessibility work, but, where possible, to also implement advisory and other techniques to further enhance accessibility and include more users.
===========================


Gregg
--------------------------------------------------------
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison

Co-Director, Raising the Floor - International
and the Global Public Inclusive Infrastructure Project
http://Raisingthefloor.org   ---   http://GPII.net








On Aug 18, 2011, at 9:51 AM, Jeanne Spellman wrote:

> 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.
> 
> [I was not successful in a quick search for the email where WCAG WG officially responded to the comments. If someone has a convenient link to that email, it would be helpful for background. My bad for not cc:ing the public list in when I sent the email requesting a response to the Last Call comments]
> 
> 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
>