Exceptions in guideline formulations (non-urgent)

Hello everyone,

Reading the working draft, I noticed that in some guidelines we have
included the exceptions in the guideline text, while in other guidelines we
have not. Some of the guidelines now read like a summary of the checkpoints,
which I think is the wrong way around. The succes criteria should explain
how to meet the guidelines. 

Compare:

Guideline 1.1 "For non-text content, provide text equivalents that serve the
same purpose or convey the same information as the non-text content, except
when the sole purpose of the non-text content is to create a specific
sensory experience (for example, music and visual art) in which case a text
label or description is sufficient."

To:

Guideline 1.2 "Provide synchronized media equivalents for time-dependent
presentations."

Both of these guidelines have exceptions, but in 1.1 these are included in
the guideline text whereas in 1.2 they are only mentioned in the success
criteria. Personally, I think guidelines without the exceptions in the text
are much stronger, easier to understand and easier to remember. 

It's just like formulating use cases in UML: I think we should focus on the
normal case, not the exceptions. I propose we formulate the guidelines as
the normal cases of what we want to say, and leave the exceptions,
alternatives to tackle specific circumstances and further explanations to
the success criteria.

Proposed changes:

Guideline 1.1

Current wording:
For non-text content, provide text equivalents that serve the same purpose
or convey the same information as the non-text content, except when the sole
purpose of the non-text content is to create a specific sensory experience
(for example, music and visual art) in which case a text label or
description is sufficient.

Proposed wording:
Provide text equivalents for non-text content.

Guideline 2.1:

Current wording:
Make all functionality operable via a keyboard or a keyboard interface.

Proposed wording:
Make all functionality operable via a keyboard.

Guideline 2.2:

Current wording:
Allow users to control time limits on their reading or interaction unless
specific real-time events or rules of competition make such control
impossible.

Proposed wording:
Allow users to control time limits on their reading or interaction.

Guideline 4.2:

Current wording:
Ensure that user interfaces are accessible or provide an accessible
alternative

Proposed wording:
Ensure that user interfaces are accessible.

Yvette Hoitink
CEO Heritas, Enschede, The Netherlands
E-mail: y.p.hoitink@heritas.nl

Received on Thursday, 4 March 2004 14:19:10 UTC