Priorities in WCAG: Explaining the Problem

At 3:28 PM +1000 2001/10/27, Jason White wrote:
>The WCAG definition of priority 1, in effect, includes only those
>requirements which, if not met, will render the content completely
>inaccessible to certain groups of users on account of disability. The
>notion of impossibility here was taken strictly--that is, if a tool
>could overcome the barrier then the checkpoint qualified as priority 2
>rather than priority 1. This is why issues such as table linearization
>arising from HTML, were dealt with by priority 2 checkpoints in WCAG
>1.0.

This definition causes extreme problems in practice among web developers.
Very few people who are not involved in the recommendation creation
process (and who are thus not accessibility experts themselves) can
discern the subtleties of this distinction.  In order to understand why
something is "impossible" vs. "very difficult", someone would need to
be at least as knowledgable on accessibility issues as a member of this
group.

Therefore, to the outside world, a checkpoint is Priority 1 and not
Priority 2 because it is _more important_ to do.  It is a "MUST" (as
defined by RFC whatever whatever) because it should be done, and the
other is just a "SHOULD" and thus is _less important_.  This is a
perfectly natural and reasonable way to understand the WCAG priority
levels.

And unfortunately it's completely and utterly wrong.  Priorities in
WCAG 1 do not mean this, they mean exactly what Jason said above.  But
the distinction is meaningless to most people and near impossible to
teach, and leads to absolutely incorrect assumptions about web
accessibility.

--Kynn

-- 
Kynn Bartlett <kynn@reef.com>
Technical Developer Liaison
Reef North America
Accessibility - W3C - Integrator Network
________________________________________
BUSINESS IS DYNAMIC. TAKE CONTROL.
________________________________________
http://www.reef.com

Received on Saturday, 27 October 2001 12:10:59 UTC