RE: 6.1 - priority

Charles,

This brings up an interesting philosophical philosophical point.  There is
not incentive for a web author to insert accessibility features that are not
supported by browsers.  There is no incentive for browsers to support
features that are never used in pages.  If support for content has the same
lower priority as the implementation of those features, why would a UA
writer ever support them?

Ultimately, we are hoping that priority 2 and priority 3 features are
supported.  This might be a serial raising of the bar for "conformance" over
time.  Would that be incentive enough?

Just wondering....

Denis Anson

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of Charles McCathieNevile
Sent: Monday, November 01, 1999 10:45 AM
To: WAI UA group
Subject: 6.1 - priority


Checkpoint 6.1 says "Implement the accessibility features of supported
specifications (markup languages, style sheet languages, metadata languages,
graphics formats, etc.). [Priority 1]"

However, not all accessibility features of languages are P1. According to
Web
Content, it is P1 to have equivalent alternatives (e.g. alt and longdesc in
HTML, and SMIL, title and desc in SVG, etc). But it is only P3 to create a
special tabbing order.

The Authoring Tool Guidelines use "relative priority" to deal with cases
where there are a number of features to be implemented, and they have
different priorities according to WCAG.

I propose that the User Agent Guidelines adopt the definition of Relative
priority, and apply it to 6.1

The AU group decided on the current usage after trying a number of formulae,
including separating the checkpoints, and spelling out the relative priority
in the checkpoint text. In AU there are 7 relative priority checkpoints out
of 28.

The definition of Relative priority in those guidelines is as follows:

[Relative Priority]

Some checkpoints that refer to generating, authoring, or checking Web
content
have multiple priorities. The priority is dependent on the priority in the
Web Content Accessibility Guidelines [WAI-WEBCONTENT].

For example providing text equivalents for images and audio is a priority 1
requirement in [WAI-WEBCONTENT] since without it one or more groups will
find
it impossible to access the information. Therefore, it is a priority 1
requirement for the authoring tool to check for (4.1) or ask the author for
(3.1) equivalent alternatives for these types of content. Expansion of
abbreviations and acronyms with ABBR and ACRONYM elements by using the
"title" attribute is a priority 3 in [WAI-WEBCONTENT]. Therefore, it is only
priority 3 for the authoring tool to check for (4.1) or ask the author for
(3.2) this information.

+ It is priority 1 to implement the checkpoint for content features that are
a priority 1 requirement in [WAI-WEBCONTENT].

+ It is priority 2 to implement the checkpoint for content features that are
a priority 2 requirement in [WAI-WEBCONTENT].

+ It is priority 3 to implement the checkpoint for content features that are
a priority 3 requirement in [WAI-WEBCONTENT].



Charles McCN

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Monday, 1 November 1999 11:29:05 UTC