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

Checkpoint 3.1 Proposed Solution (Action Item)

From: Jan Richards <jan.richards@utoronto.ca>
Date: Tue, 25 Apr 2000 16:41:18 -0400
Message-ID: <390602EE.84113C33@utoronto.ca>
To: "w3c-wai-au@w3.org" <w3c-wai-au@w3.org>
*************************

NOTE BEFORE READING:
It cannot be over-stated that DEVELOPERS should determine the specific
CHARACTER and TIMING of accessibility related tasks in their tools.

*************************

For the record, I don't think tools should allow accessibility to be
COMPLETELY AND UNIVERSALLY disabled (in other words, one switch for ALL
future documents). I DO think there is lots of room for configurability
before that point is reached.

*************************

Checkpoint 3.1 is met if:

IN SHORT:

"The tool includes a fairly reliable information request mechanism for
alternative equivalent information".

IN LONG:

Where "Fairly reliable" means....

1. The typical method of insertion for objects for a particular tool is
required to includes a request for alternate equivalent information in a
prominent way.

Example #1:
->Method: Authors add images in HTML4 using an IMG insertion dialog that
lists a variety of properties.
->Solution: The ALT property should have a similar visual prominence to
the SRC property.


2. Loopholes (ex. Phil's dragging and dropping images without having a
dialog displayed and then saving immediately without ever having seen a
request) are allowed, as long as this is not the typical method of
authoring for that tool AND there are fairly dependable backups when
typical authoring resumes.

Where "fairly dependable backups" means...

Example #2: a constantly displayed properties toolbar that will update
to include a text box for ALT whenever the cursor is on the image.

Example #3: a blue Word2000-like underline with a status bar message
asking for the alternative text.


IMPORTANT, not prompting for ALT text when saving out a word processing
document into HTML does not qualify as an allowable loophole, since this
is the typical way that such an application produces HTML and there is
no future editing during which the author is likely to run into a
backup.



-- 
Jan Richards
jan.richards@utoronto.ca
Access Software Designer
Adaptive Technology Resource Centre
University of Toronto
(416) 946-7060
Received on Tuesday, 25 April 2000 16:41:41 UTC

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