Re: More on the ATAG-WCAG relationship

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. 

> - I think the WCAG- terms seem to imply definition by WCAG-WG, when in fact WCAG-WG has only fully defined WCAG Conformance.
> - 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. 
> 
> 
> 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.

try      " 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 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'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). 


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






> 
> Thoughts?
> 
> -Jan
> 
> 
> -- 
> (Mr) Jan Richards, M.Sc.
> 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
> 
>> -----Original Message-----
>> From: 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: 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-
>> 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.
>> 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
>> 
>> 
> 
>