Re: More on the ATAG-WCAG relationship

Jan, Gregg,

At 05:27 PM 8/17/2011 -0400, Gregg Vanderheiden wrote:
>Comments below

Additional comments below.

>Gregg
>
>On Aug 17, 2011, at 4:12 PM, Richards, Jan wrote:
>
>>Hi all,
>>
>>Yesterday, I did what I could to craft a reasonable proposal to 
>>replace "accessible content" with a term such as "WCAG-capable 
>>content" or "WCAG-compatible"...but I have my doubts because:
>>- moving to one of these terms will involve a major change to the 
>>document (~80 instances)
>>- we will lose the intuitive ease of "accessible content"
>>- someone will likely point out that the WCAG- terms lack a version 
>>number, meaning we might end up with "WCAG2.0-capable"
>I would use WCAG2   -- it is shorter.

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."

>>- I think the WCAG- terms seem to imply definition by WCAG-WG, when 
>>in fact WCAG-WG has only fully defined WCAG Conformance.

Again I'm unclear about your concern; the issue you had mentioned 
concern about earlier today was reclarifying the "handshake" between 
ATAG2 and WCAG2. I think that the "handshake" between the two is an 
important and a good place to focus attention, and addressing it by 
using a "WCAG-" term works on multiple levels.

>>- If we take the concern with "accessible" to its most ridiculous 
>>end, the name of the entire document "Authoring Tool ACCESSIBILITY 
>>Guidelines" would need changing.
>
>That doesn't follow.   Accessibility is a fine term.  It defines a 
>quality.     "Accessible" on the other hand defines a 
>state.   Stated absolutely (without modification) it defines an 
>absolute state.   And as discussed there is nothing that is 
>absolutely accessible.

Ditto. There has never been any problem using "accessibility"; the 
guidelines that you're working on for authoring tools relate to 
accessibility of those tools, and accessibility of the content for 
which they support production.

>>So instead I suggest:
>>
>>(1) We try to be clear in our informative sections that following 
>>WCAG 2.0 will result in "content that is more accessible"
>
>Can't say "more accessible" without saying more accessible than what.

Well you could, but it might leave some people wondering -- in other 
words it is not the clearest formulation to communicate the guidance 
in the standard.

>try      " WCAG 2.0 defines minimum level(s) of accessibility."

I think I understand why you're proposing this, but it seems to be a 
significant underclaim on what WCAG2 does, and I think would create 
substantial confusion.

>>(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.

>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).

+1

>Also you might add your sentence from above regarding accessibility 
>in general. (e.g that there are no absolutely accessible anything).
>
>that would make it
>
>(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
>    * Nothing is accessible to everyone.  Nothing is accessible in 
> all environments and all tasks.
>    * When we say  "accessible* content" we mean content that 
> conforms to WCAG 2.0  [at level A or Level AA]
>    * WCAG 2.0 conformance does not mean that something is 
> 'accessible' in the absolute.  WCAG 2.0 sets standards for minimum 
> 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 (WCAG 2.0 document)"
Again, I have concerns about this approach. In addition to the 
concerns already noted above, it strongly and redundantly defines 
accessibility from the negative perspective, rather than 
communicating what the accessibility guidance actually does provide.

- Judy


>>Thoughts?
>>
>>-Jan
>>
>>
>>--
>>(Mr) Jan Richards, M.Sc.
>><mailto:jrichards@ocad.ca>jrichards@ocad.ca | 416-977-6000 ext. 
>>3957 | fax: 416-977-9844
>>Inclusive Design Research Centre (IDRC) | 
>><http://idrc.ocad.ca/>http://idrc.ocad.ca/
>>Faculty of Design | OCAD University
>>
>>>-----Original Message-----
>>>From: <mailto:w3c-wai-au-request@w3.org>w3c-wai-au-request@w3.org 
>>>[mailto:w3c-wai-au-request@w3.org] On
>>>Behalf Of Richards, Jan
>>>Sent: August 16, 2011 5:18 PM
>>>To: <mailto:w3c-wai-au@w3.org>w3c-wai-au@w3.org
>>>Subject: WCAG-capable proposal
>>>
>>>Hi all,
>>>
>>>On yesterday's call we continued the discussion of terms that might
>>>replace "Accessible Content (WCAG)", which WCAG-WG cautions us against
>>>using.
>>>
>>>Ideas we have considered:
>>>-------------------------
>>>
>>>"WCAG-Conformant" - directly implies WCAG conformance, which requires
>>>only using technologies in "accessibility supported" ways - problematic
>>>for ATAG 
>>><http://lists.w3.org/Archives/Public/w3c-wai->http://lists.w3.org/Archives/Public/w3c-wai-
>>>au/2011JulSep/0061.html)
>>>
>>>"WCAG-Conformant*" - note the asterisk. May still be confusing.
>>>
>>>"potentially WCAG-conforming web content" - too wordy
>>>
>>>"WCAG-capable" was suggested yesterday - for which I took an action to
>>>write the proposal (below).
>>>
>>>Other ideas that I had while doing this action:
>>>------------------------------------------------
>>>"WCAG-Compatible"
>>>"Accessible*" - once again using the asterisk.
>>>
>>>
>>>Deciding which term to use:
>>>===========================
>>>
>>>First, let's look at the term being replaced:
>>>
>>>accessible content (WCAG): Web content that meets the WCAG 2.0 success
>>>criteria (Level A, AA, or AAA).
>>>
>>>If we really want to be exact, we might say something like:
>>>
>>>WCAG-capable/compatible content: Web content that could potentially
>>>conform to WCAG 2.0 (to Level A, AA, or AAA) as follows:
>>>-Conformance Level: the WCAG 2.0 " Conformance Level" requirement is
>>>met.
>>>-Full Pages: if the content is one or more Web pages, the WCAG 2.0
>>>"Full Pages" requirement is met.
>>>-Complete Processes: if the content is a complete process, the WCAG 2.0
>>>"Complete Processes" requirement is met.
>>>-Only Accessibility-Supported Ways of Using Technologies: The WCAG 2.0
>>>"Only Accessibility-Supported Ways of Using Technologies" requirement
>>>is assumed to be met.
>>>-Non-Interference: the WCAG 2.0 "Non-Interference" Requirement is met.
>>>
>>>But that's getting complicated, so maybe:
>>>
>>>WCAG-capable/compatible content: Web content that could potentially
>>>conform to WCAG 2.0 by meeting the WCAG 2.0 success criteria (to Level
>>>A, AA, or AAA).
>>>Note: This term refers to potential conformance rather than current
>>>conformance so the
>>>WCAG 2.0 Conformance Requirements are not required to be met.
>>>
>>>
>>>
>>>Second, the term "Accessible [Web] Content" appears ~80 times in the
>>>document, so I will simply try to provide some representative examples.
>>>
>>>(1)
>>>A.1.1.1 Web-Based Accessible (WCAG): Web-based authoring tool user
>>>interfaces meet the WCAG 2.0 success criteria. (Level A to meet WCAG
>>>2.0 Level A success criteria; Level AA to meet WCAG 2.0 Level A and AA
>>>success criteria; Level AAA to meet all WCAG 2.0 success criteria)
>>>
>>>Becomes:
>>>
>>>A.1.1.1 Web-Based Accessible (WCAG): Web-based authoring tool user
>>>interfaces are WCAG-capable/compatible. (Level A, AA, or AAA as
>>>determined by WCAG 2.0)
>>>-----
>>>(2)
>>>accessible templates (WCAG): Templates that can be filled in to create
>>>web content that meets the WCAG 2.0 success criteria (Level A, AA or
>>>AAA),... Note: Under these conditions, some templates will result in
>>>completely empty documents, which are considered accessible by default.
>>>
>>>Becomes:
>>>
>>>accessible templates (WCAG): Templates that can be filled in to create
>>>WCAG-capable/compatible content (Level A, AA or AAA),... Note: Under
>>>these conditions, some templates will result in completely empty
>>>documents, which are considered WCAG-capable/compatible by default.
>>>-----
>>>(3)
>>>B.2.4.3 Author-Created Templates: If the authoring tool includes a
>>>template selection mechanism and allows authors to create new non-
>>>accessible templates (WCAG), then authors can enable the template
>>>selection mechanism to display distinctions between accessible and non-
>>>accessible templates that they create. (Level AA)
>>>Note: The distinction can involve providing information for the
>>>accessible templates, the non-accessible templates or both.
>>>
>>>Becomes:
>>>
>>>B.2.4.3 Author-Created Templates: If the authoring tool includes a
>>>template selection mechanism and allows authors to create new templates
>>>that are not WCAG-compatible, then authors can enable the template
>>>selection mechanism to display distinctions between the WCAG-compatible
>>>and non-WCAG-compatible author-created templates. (Level AA)
>>>Note: The distinction can involve providing information for the WCAG-
>>>compatible templates, the non-WCAG-compatible templates or both.
>>>
>>>
>>>
>>>
>>>Cheers,
>>>Jan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>--
>>>(Mr) Jan Richards, M.Sc.
>>><mailto:jrichards@ocad.ca>jrichards@ocad.ca | 416-977-6000 ext. 
>>>3957 | fax: 416-977-9844
>>>Inclusive Design Research Centre (IDRC) | 
>>><http://idrc.ocad.ca/>http://idrc.ocad.ca/
>>>Faculty of Design | OCAD University

Received on Thursday, 18 August 2011 03:21:53 UTC