Re: More on the ATAG-WCAG relationship

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

Received on Thursday, 18 August 2011 13:52:33 UTC