W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 2010

RE: re: ATAG 2.0 Conforming vs. Compatible

From: Boland Jr., Frederick E. <frederick.boland@nist.gov>
Date: Fri, 17 Sep 2010 08:46:48 -0400
To: "Richards, Jan" <jrichards@ocad.ca>
CC: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
Message-ID: <D7A0423E5E193F40BE6E94126930C49307C519B164@MBCLUSTER.xchange.nist.gov>
Some initial draft thoughts:

For 1, ATAG is "AUTHORING TOOL" Accessibility Guidelines.    Adding items that are not authoring tools to conformance would seem to significantly change the scope and applicability of the specification.    This may be a significant change which requires more thought as to its implications.  Maybe consideration should be given to several relevant sections of W3C Quality Assurance (QA) Specification Guidelines document : http://www.w3.org/TR/qaframe-spec/
"The goal of this document is to help W3C editors write better specifications, by making a specification easier to interpret without ambiguity and clearer as to what is required in order to conform. It focuses on how to define and specify conformance. It also addresses how a specification might allow variation among conforming implementations. The document presents guidelines or requirements, supplemented with good practices, examples and techniques. "

For 2, we would need to explicitly define "sole tool" and "predominant tool" ?    If normative, how would these categories be objectively measured (determined)?

For 3, we seem to be complicating the conformance model.   Is this necessary?    How do we want to subdivide the "technology"?   Maybe consideration should be given to W3C QA Variability in Specifications document: http://www.w3.org/TR/spec-variability/
"This document details and deepens some of the most important concepts related to conformance when designing a specification. It is a companion document of QA Specification Guidelines. It analyzes how design decisions of a specification's conformance model may affect its implementability and the interoperability of its implementations."

Apologies in advance if I've misunderstood..

Thanks Tim 

________________________________________
From: w3c-wai-au-request@w3.org [w3c-wai-au-request@w3.org] On Behalf Of Richards, Jan [jrichards@ocad.ca]
Sent: Friday, September 17, 2010 7:46 AM
To: w3c-wai-au@w3.org
Subject: re: ATAG 2.0 Conforming vs. Compatible

At the F2F there was some interest in principle in my proposal, so I've decided to flesh it out:

1. We would state that the "Full" and "Partial" ATAG 2.0 Conformance categories apply to Authoring Tools that are complete "Authoring Systems".
DEFN (Authoring System): One or more *authoring tools* that support the entire process of creating web content from planning to publishing. Authoring systems may be complex, with many tools and authors with different roles involved, or they may be very simple (e.g., a wiki). Authoring systems may also include software applications that are not Authoring Tools, such as an FTP client used in publishing.

2. We would encourage claims of Full or Partial Conformance when a tool is the either the sole tool in an authoring system or the predominant tool in terms of meeting the ATAG 2.0 requirements (e.g., the HTML editor in an authoring system comprised of an HTML editor, image editor and FTP client).

3. There would be another conformance category for Authoring Tools "Compatible with an ATAG 2.0 Conforming Authoring System (Level A,AA,AAA)" or "ATAG 2.0 Compatible" for short. To conform in this way the authoring tool must:
(a) meet all applicable SCs in Part A (because an accessibility barrier in an intermediate step can make the entire process inaccessible.)
(b) meet all SCs in Part B except in B.2.2 (checking) and B.2.3 (repair) [ed. BTW: to make this easier to understand maybe they move to a new B.4 Authors must be supported in discovering and addressing accessibility problems]
(c) If the authoring tool *publishes* web content for the authoring process (which is assumed to be ATAG2 conforming so has checking and repair) then checking and repair are either:
- available within the compatible tool before publishing (e.g., during regular authoring, during a final preview step); or
- the author is advised how to perform checking and repair of the published content (e.g., for a wiki).


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://inclusivedesign.ca/
Faculty of Design | OCAD University

Preliminary idea:

Microsoft's review brings up an issue that we've struggled with many times over the years. Namely, how to take into account tools that are just a small part of a larger authoring process.

Here's an idea:

1. We could more clearly state that the "Full" and "Partial" ATAG 2.0 Conformance categories apply to Authoring Tools that are complete "Authoring Systems" - currently its most clearly stated in a Part B applicability note (we should probably also define "Authoring Systems").

2. We could then add another conformance category for Authoring Tools that are a subset of a complete "Authoring System" (e.g., CSS editor, photo editor, accessibility checker). Perhaps something like e.g. *Compatible with an ATAG 2.0 Conforming Authoring System (Level A,AA,AAA) or "ATAG 2.0 Compatible" for short. The tool would have to:
- meet all applicable SCs in Part A because an accessibility barrier in an intermediate step can make the entire process inaccessible (and we should check the Part A SC wording to make sure they are properly conditional on the type of content and the editing options available).
- meet all SCs in B.1
- meet all SCs in B.3 (B.3.4 should be conditional on "if there is documentation")
- meet B.2.1
- etc....
...Essentially we would be holding off on checking, repair and maybe a couple others. (we might also consider moving the SCs that relate to the process as a whole to a new Principle to make these easier to specify).

Plus this important condition:
- The tool MUST NOT interfere with the other parts a larger authoring system meeting the SCs that it doesn't have to meet (e.g., by publishing the content in a way that it can't be easily repaired once an external checker has run, by failing to preserve accessibility info that another part adds, etc.).

3. I still think checking and repair are very important and so for tools that don't include it we need to make sure that the author is made aware that external check and repair (e.g. repair instructions) is advised.


Thoughts?

Cheers,
Jan
Received on Friday, 17 September 2010 12:48:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 17 September 2010 12:48:04 GMT