First thoughts on a minimum set, a secondary set, and several questions

At last week's meeting, we all took an action to try to figure out what is 
included in the minimum or not.  Here are some thoughts about a minimum 
set. It's an initial pass so I expect there will be issues and that I have 
probably missed something, but it at least gives us a place to start.

The minimal set consists of things that only the author knows or can 
provide.  The secondary set are things that could be derived using a 
tool.  In other words, as long as the author has infused the markup with as 
many semantics as possible, then a tool could be used to do some extra 
processing to increase accessibility.

For example, I did not include Checkpoint 3.1 Use consistent presentation 
in the minimal set since it could be possible for a tool to do this if it 
knew the schema/vocabulary/semantics the author is using.  Some authors 
will feel that they are the only one who can provide the presentation, such 
as particular look and feel for branding or what not.  Therefore, it would 
be one checkpoint above and beyond the minimum set - they would make this 
decision.  But, for authors who write good  markup and are comfortable 
letting it transform, then all they need to do is provide good markup 
(primarily, follow checkpoints 1.3 and 1.5).

So, here is a first stab at the minimal set of checkpoints.  Some reasoning 
behind some decisions follows this as well as thoughts for a secondary set 
and more questions about what to do with final form languages [0 - 
definition at the end].
·       Checkpoint 1.1 Provide a text equivalent for all non-text content.
·       Checkpoint 1.2 Provide synchronized media equivalents for 
time-dependent presentations.
·       Checkpoint 1.3 Use markup or a data model to provide the logical 
structure of content.
·       Checkpoint 1.4 Identify the primary natural language of text and 
text equivalents and all changes in natural language.
·       Checkpoint 1.5 Separate content and structure from presentation.
·       Checkpoint 2.5 Use device-independent event handlers.
·       Checkpoint 3.3 Write as clearly and simply as is appropriate for 
the content.
·       Checkpoint 3.4 Supplement text with non-text content.
·       Checkpoint 3.5 Annotate complex, abbreviated, or unfamiliar 
information with summaries and definitions.
·       Checkpoint 4.2 Use technologies according to specification.

Why some checkpoints are not included in this list:

I did not include 4.1 [1] in this list, b/c what if someone is using a 
device-specific final form language?  Then, they need to do something 
else.  We talked a bit about this at the Protocols and Formats Working 
Group face-to-face at the beginning of October.  We came up with a proposal 
for language, but I'll submit that later.  Right now, I'd like to focus on 
minimal set rather than wording of checkpoints.

Also, device-specific final form languages are part of the reason for not 
including Checkpoint 4.1 Choose technologies that support the use of these 
guidelines. As I said, if people choose final form, we need to think about 
if we think they ought to provide final form for {some set of devices} or 
provide something in an accessible format (similar to 11.4 in WCAG 1.0 - 
http://www.w3.org/TR/WCAG10/#alt-pages)

I did not include 4.4 [2] because if someone does all of these other 
things, then 4.4 should be satisfied (I think....).  Again, not an issue to 
get into so much right now perhaps.

I *did* include Checkpoint 3.3 Write as clearly and simply as is 
appropriate for the content since the author should write as clearly and 
simply as is appropriate, but no simpler. If someone (a user, or teacher, 
etc) wants to make it simpler or present it in a different language, then 
tools should exist to do those things.  Therefore, the author needs to make 
it as simple as is appropriate, but tools should exist that can simplify 
it.  For example, if we can translate a document from English to French 
(http://world.altavista.com/) then we should be able to translate a 
document from English to symbols or simpler English or .... 
something.  Like summarizer tools, such as Summarizer 
http://www.copernic.com/products/summarizer/

Therefore, of 21 checkpoints, I would say that 10 are core.  I expect 
developers to scream "too much" and disability advocates to scream "too 
little."  <grin/>

With the rest of the checkpoints I propose the following - those things 
that most tools do not yet do today and therefore good for authors to do, 
basically level 2:
·       Checkpoint 2.1 Provide multiple site navigation mechanisms.
·       Checkpoint 2.2 Provide consistent and predictable responses to user 
actions.
·       Checkpoint 2.3 Either give users control of mechanisms that cause 
extreme changes in context or warn them of pending changes.
·       Checkpoint 2.4 Either give users control over how long they can 
interact with content that requires a timed response or give them as much 
time as possible.
·       Checkpoint 2.6 Avoid causing the screen to flicker.
·       Checkpoint 2.7 Handle input errors, such as misspellings.
·       Checkpoint 3.1 Use consistent presentation.
·       Checkpoint 4.1 Choose technologies that support the use of these 
guidelines
·       Checkpoint 4.3 Design user interfaces compatible with assistive 
technology.
·       Checkpoint 4.4 Ensure that content remains usable when technologies 
that modify default user agent processing or behavior are turned off or not 
supported.

Therefore I've sorted this into the following levels or sets of checkpoints:
minimal level - 10 checkpoints
secondary level - 21 checkpoints (10 minimal + 11 secondary)
intermediate levels that may be described in detail in a conformance claim 
(e.g. minimal+).
conformance for device-specific final form languages - similar to 11.4 of 
WCAG 1.0.  Exception to checkpoint 4.1 or its own set of checkpoints?

4.1 seems to be a meta checkpoint of sorts.  Either you choose a language 
that supports these guidelines (and therefore either conform to the minimal 
level or the secondary level as described above) or you use a 
device-specific final form language that you have chosen as well as other 
device-specific final forms or a form that meets at least minimal level 
or....?.

Thoughts?
--wendy

[0] final form: usually used when data is being stored in some form and 
then some presentation is generated for a person.  device-specific final 
form languages are written for a specific device, such as a printer, a 
speech synthesizer, etc. (also called a "formatting object.")  For example, 
speech synthesis markup language is the "final form" representation to be 
passed to the speech synthesis engine.
http://www.w3.org/TR/speech-synthesis
WML is a final form for mobile devices.
HTML is a final form for desktop browsers.
Therefore, a final form can be accessible, but if it is media specific 
(such as a speech language) then other final forms in other medias will 
need to be provided.
I think this is a fair definition. Please correct me if I am wrong.
[1] Checkpoint 4.1 Choose technologies that support the use of these 
guidelines.
[2] Checkpoint 4.4 Ensure that content remains usable when technologies 
that modify default user agent processing or behavior are turned off or not 
supported.
--
wendy a chisholm
world wide web consortium
web accessibility initiative
seattle, wa usa
/--

Received on Tuesday, 23 October 2001 20:23:39 UTC