Authoring Tool Accessibility Guidelines 2.0 - SpecGL Conformance Assessment

Charles McCathieNevile
Assessing version
Against version
This version of the assessment
$Id: cmn-atag-review.html,v 1.5 2005/01/10 16:25:12 charles Exp $


The ATAG Last call draft seems to conform to all but one of the requirements - that of clarifying the deprecation of some features, and the group seems to recognise already that this needs to be done. In addition, most of the good practices are implemented too.

The major caveat is that since the specification relies on a non-free specification from ISO, to which I don't have access, I have not been able to check parts related to that. I think that at the least a much more detailed treatment of what is in that specification, and how it should be used (with examples) is important.

Conformance by requirement / good practice

Guidelines Y / N Comments
1 Specifying Conformance
1.1 A conformance clause is essential
Requirement : Include a conformance clause. Yes
Good Practice : Define the specification's conformance model in the conformance clause. Yes

Good Practice : Specify in the conformance clause how to distinguish normative from informative content. Yes
1.2 Specify how to make conformance claims
Good Practice : Provide the wording for conformance claims. Yes
Good Practice : Provide an Implementation Conformance Statement proforma. Yes
Good Practice : Require an Implementation Conformance Statement as part of valid conformance claims. Yes
2. Setting up Groundrules
2.1. Scope
Requirement : Define the scope. Yes
Good Practice : Provide examples, use cases, and graphics. Yes There are examples, use cases, and graphics in the accompanying Note "Techniques for ..."
2.2 What needs to conform
Requirement : Identify who or what will implement the specification. Yes
2.3 Normative (and non-normative) references
Requirement : Make a list of normative references. Yes
Good Practice : Do systematic reviews of normative references and their implications. Cannot Tell In particular it is hard to know what review has been done for ISO 16071, since it is not freely available and I don't have access to a copy.
3. terms
3.1 Define terms
Requirement : Define the terms used. Yes
Requirement : Create conformance labels Yes
Good Practice : define unfamiliar terms inline, group at the end Partial (No) Some things are defined inline, some in the glossary at the end, some in both ways.
Good Practice : Use terms already defined Cannot tell Terms seem to be used with their normal meanings.
3.2 What is mandatory to conform
Requirement : Use consistent style for things required Yes I think - RFC 2119.
Requirement : Indicate which requirements are mandatory, which are optional, ... Yes Success criteria are very nice.
4. Managing Variability
4.1 Subdivide
Good Practice : Create subdivisions of the technology when warranted. Yes To the extent that some checkpoints only apply to some kinds of tools. More substantially addressed in the techniques document where it is more relevant
Requirement : If the technology is subdivided, then indicate which subdivisions are mandatory for conformance. Yes
Requirement : If the technology is subdivided, then address subdivision constraints. Yes There is a simple cumulative model.
Good Practice : If the technology is profiled, define rules for creating new profiles. Not Applicable
4.2 Optionality and Options
Good Practice : Make sure there is a need for the optional feature. Yes The three levels of conformance effectively provide optional features. There is a strong demand for some graded scale, and it seems clearly explained and justified in the Spec.
Good Practice : Clearly identify optional features. Yes
Good Practice : Indicate any limitations or constraints on optional features. Yes
4.3 Extensibility and Extensions
Requirement : Address Extensibility. Yes The structure of the specification and the related techniques document means that maximum flexibility is allowed in meeting functional requirements, while guidance is provided in areas where the working group feels that there is currently only one practical way to meet a checkpoint.
Good Practice : If extensibility is allowed, define an extension mechanism. Not Applicable
Good Practice : Warn implementers to create extensions that do not interfere with conformance. Not Applicable
Good Practice : Define error handling for unknown extensions. Not Applicable
4.4 Deprecation
Requirement : Identify deprecated features. No The Status of the Document says the group will publish an analysis of the differences if there are any, before the last call.
Requirement : Define how deprecated feature is handled by each class of product. Cannot Tell
Good Practice : Explain how to avoid using a deprecated feature. Yes In so far as there are Techniques in the related techniques note...
Good Practice : Identify obsolete features. No See the requirement 4.4A
4.5 Error Handling
Good Practice : Define an error handling mechanism. Not Applicable
5. Do Quality Control
Good Practice : Define an internal publication and review process. Yes W3C process, which seems to have been followed pretty well.
Good Practice : Do a systematic and thorough review. Yes Apparently
Good Practice : Write sample code or tests. Partial There are some examples in the ATAG techniques note. This work is ongoing
Good Practice : Write Test Assertions. Yes There are success criteria for each checkpoint.
Good Practice : Use formal languages and define which from prose and formal languages has priority. N/A As far as I can tell