- From: Jeanne Spellman <jeanne@w3.org>
- Date: Thu, 18 Aug 2011 11:07:32 -0400
- To: AUWG <w3c-wai-au@w3.org>, WCAG WG <w3c-wai-gl@w3.org>
- CC: Judy Brewer <jbrewer@w3.org>
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 15:08:05 UTC