W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 1999

"Priorities: Eric's notes"

From: eric hansen <ehansen@ets.org>
Date: Tue, 25 May 1999 11:58:38 -0400 (EDT)
To: w3c-wai-au@w3.org
Message-id: <vines.Bh0E+iWgGrA@cips06.ets.org>
On Fri, 21 May 1999 18:14:48 -0400 (EDT) ("Priorities: Eric's notes"), 
Charles McCathieNevile wrote:

"I have assumed that the discussion of priorities at the meeting and 
subsequent redefinition has superseded the original comments."

However, the material I posted on the definitions of priorities on 19 May:


was intended as a current proposal rather than as something which was 
obsoleted by the proceedings of our face-to-face meeting.

Part A: Essential Features of the Definitions

Features that I consider most important in this proposal are:

1. Separation of the definitions for the two major components of the 
guidelines: (a) creating accessible content and (b) providing an accessible 
user interface. This separation seems important because the meanings of the 
priorities really do differ between these sections. I don't have any 
particular problem with also stating them in some combined fashion, but for 
clarity, I think that they must be defined separately.

2. Explicit reference to impact on disability groups. I think that people 
are agreed that this is the focus of the document. This focus must be 
reflected in the definition of the priorities.

3. Language that makes clear that impact on disability groups is the 
criterion for determining the priority level.

4. Explicit discussion of assumptions. Assumptions underlying the ratings 
should be listed. One may argue that some of this material is too lengthy 
for inclusion in the WATG document. While we may finally decide that some 
of that material may belong somewhere else, I believe that if we as a 
Working Group fail to reach consensus on what the actual assumptions are, 
then the meaning of the priorities will always remain vague to us and even 
vaguer to others. For example, do the priority definitions really apply 
equally to tools that are simple HTML editors and to tools with intuitive 
(e.g., WYSIWYG editors) interfaces? Another important example, concerns 
which groups are affected: Do some of the checkpoints just affect some 
disability groups or do they all affect all disability groups the same. 

Things that I think could more readily be changed from my proposal include 
the following:

1. Keywords for the Priority. In my proposal (as well as the WCAG document),
 the keywords are "must", "should", and "may". I don't thing that we should 
depart from this unless we reach consensus that we really have a better 
alternative. (The words "essential", "important", and "beneficial" seem to 
have become the favorites during my mid-day absence from the face to face 
meeting on Sunday.)

2. Stretching or Contracting Some Portion of the Scale. Whether it makes 
sense to stretch or contract the scale depends in part upon answers to 
questions such as: (a) whether there are checkpoints that truly make it 
"impossible" to author accessible content or for people with disabilities 
to use the tool (b) whether we wish to depart from the scale established 
for WCAG. We could, for example have priority 1 be for checkpoints that 
make it "very difficult or impossible", priority 2 for checkpoints that 
make it "difficult", priority 3 for checkpoints that make it "somewhat 

3. Elaborations. Elaborations such as "basic requirement" (priority 1) or 
"remove significant barriers" (priority 2), "improves access" (priority 3) 
(see the WCAG document) have both advantages and disadvantages. I am happy 
to consider inclusion or exclusion of such phrases. My proposal excludes 
them from the main definition and adds them as an addendum. It might be 
better to exclude them altogether though I could probably be persuaded 

4. Numbering, Ordering, and Aggregation. Per recent discussions, I think 
that it is fine, in principle, to modify the ordering, numbering, and level 
of aggregation of the checkpoints addressing the two major sections 
(accessible content vs accessible interface). I do have some concerns about 
putting the whole section into a single guideline, but am waiting to see 
what it actually looks like in the next draft.
Part B: Incompleteness

The definition breakdown in the 21 May 1999 draft reads as follows:

[Priority 1] 
Essential to meeting those goals 
[Priority 2] 
Important to meeting those goals 
[Priority 3] 
Beneficial to meeting those goals 

It is difficult to comment on these without seeing the rest of the 
definitions. As noted earlier, in my view, the definitions need to refer to 
different levels of impact on disability groups. Am I correct that these 
current definitions are not thought to be complete? Without having 
reference to impact on people with disabilities, there is no objective 
criterion for the priority levels. Without an objective criterion, I feel 
that one must more fully specify the rationale for individual priority 
decisions. I think that we should put the generic portions of the rationale 
(i.e., the impacts) in the priority definitions.

Part C: Assumption Regarding Time-Span Covered

One of the issues that one runs into regarding assigning priority levels 
based on impact ratings is that it seems strange to rate the impact of 
absence (violation) of a feature is not yet available in any commercial 
product, e.g., tools for managing alternative content.

However I suggest that this problem goes away if we assume that the ratings 
are based not only upon tools that are now available but also upon tools 
that we believe will exist over the next several years (let us say, 5 or 10 
years). Again, I think that the Working Group needs to make this kind of 
assumption explicit, even if it doesn't make it into the final document.

Under this assumption, it makes sense to say that absence of a certain 
capability makes it "difficult" (or some other term) for one or more 
disability groups to access the tool or access the content, even though the 
feature may never have been implemented. The WATG, in effect, establishes a 
standard of accessibility that we think will be appropriate for 5 or 10 
years, even though the document may need to be updated sooner than that.

Part D: Is Priority 3 Fundamentally Different From Priorities 1 and 2?

I think that the working group should be very deliberate about deciding 
whether it wants to use language that implies that priorities 1 and 2 
checkpoints address a different class of issues than priority 3 
checkpoints. For better or for worse, the WCAG document manifests a 
discontinuity between priorities 1 and 2 on the one hand and priority 3 on 
the other. "Must" (priority 1) and "should" (priority 2) are true 
imperatives; but "may" (priority 3) is different animal because it connotes 
optionality. It is, in a sense, a non-mandated level of accessibility -- a 
non-mandated mandate (my oxymoronic phrase). The WAI is advocating that 
organizations tackle priorities 1 and 2 but is less emphatic about priority 

For the WATG document, do we see priorities 1 and 2 as things that 
represent "standard" level of accessibility and priority 3 as something 
that is "above and beyond" actual necessity but that would nevertheless be 
highly beneficial for people with disabilities? I have concerns about that 
because it seems to put priority 3 outside the realm of accessibility and 
into the realm of "usability."

My point is that we ought to make our working assumptions explicit. I 
strongly suggest documenting them in the working drafts. If they are too 
lengthy for inclusion in the final document, we can decide later. To fail 
to make our assumptions explicit is to greatly hinder the establishment of 
a consensus regarding priority levels. See 
http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0242.html for my 
current assumptions regarding the priority definitions.

Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Rosedale Road
Princeton, NJ 08541
(W) 609-734-5615
(Fax) 609-734-1090
E-mail: ehansen@ets.org 
Received on Tuesday, 25 May 1999 12:49:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC