my action item: 4.1, 4.2 & 4.4

I took a stab at re-writing several of the checkpoints under guideline
4.  This is really rough, but you'll get the idea.  

The stuff between the <notes></notes> tags are explanations that would
not be in the draft.

 

 

 

Checkpoint 4.1 Choose technologies that are designed to support
accessibility

<notes> This is what we say when we're explaining the checkpoint. Let's
make it the checkpoint, so we don't have to explain it.</notes>

 

Success Criteria:

 

A technology can be considered accessible if it

 

supports device independence

includes accessibility features

has publicly documented interfaces for interoperability

makes use of operating system accessibility features (either directly or
via the user agent)

is supported by assistive technologies in the natural language(s) of the
content.

is implemented in user agents and/or proxies in the natural language(s)
of the content.

 

<notes> 

The big change here is that I'm putting a lot more weight on implemented
technologies, and their interactions with other software in the real
world.  

 

I've also added the concept of looking at available technologies based
on the human/natural language of the content.  The idea is that if I'm
creating a French site, then it matters a lot more that it works with
French screen readers than with Swedish ones.  I'm not sure this is the
right place for this, but it's another example of adding implementation
and real-world concerns to the success criteria.  

</notes>

 

 

Checkpoint 4.2 Use technologies according to specification

 

Success criteria

 

General:

You have used the accessibility features available in your chosen
technologies

 

For markup: 

the markup has passed validity tests of the language*, and

structural elements and attributes are used as defined in the
specification.

 

For api's: 

programming standards for the language are followed.

 

* passing the validity tests of the language would include conforming to
a schema, DTD, or other tests described in the specification.

 

<notes>changes here are editorial.  Made "use the accessibility
features" explicit, and moved the parenthetical phase to a
footnote.</notes>

 

 

Checkpoint 4.4 Design for backward compatibility

<notes>Again, this is what we say when we explain the checkpoint, so
let's just say it</notes>

 

Success criteria:

Your site can be considered backward compatible if 

You have determined and documented your baseline browser requirements in
metadata and/or a policy statement on your site.

Your content is still usable when features above your baseline (for
example, scripting and stylesheets) are turned off

 

Informative:

1) When determining your baseline browser requirements, consider that
assistive hardware and software is often slow to adapt to technological
advances, and the availability of assistive technology varies across
natural languages.  Verify that assistive technology compatible with the
technologies you choose is available in the natural language(s) of your
content.

 

<notes>

The concept of a baseline browser is made explicit.  The definition of
that baseline is left up to the author. 

This will probably be controversial.  Here's the reasoning:  

   a) The working group has yet to come up with a workable solution for
defining a baseline and having it not become obsolete.  I'm not
convinced that it is possible to do so.

    b) The author has much better information than we do about the
specific situation in which his content will be used.  This includes
things like audience, available tech in a given language, and the state
of technology at the time he's reading the guidelines (not the time
we're writing them).  

 

We could perhaps provide a few sample baselines, like the no script/no
stylesheets standard assumed by WCAG 1.0.

 

Again, added the concept of technology available in the language of the
content.

</notes>

 

2) In some situations, there are trade-offs between this checkpoint and
checkpoints 4.1 and 4.2.  Older user agents may not be compliant to
standards.  Newer technologies (or their accessibility features) may
break older user agents.  In these situations, you will need to make a
judgment call as to which is more important for your audience, and
adjust your baseline browser requirements accordingly.

 

<notes>We will never get around this trade-off, so let's acknowledge it,
and see what we can come up with to help the author make the right
decision.</notes>