- From: Jutta Treviranus <jutta.treviranus@utoronto.ca>
- Date: Sat, 22 Mar 2003 09:47:17 -0500
- To: "List (WAI-AUWG)" <w3c-wai-au@w3.org>
- Cc: Jan Richards <jan.richards@utoronto.ca>
Here are my proposed additions and revisions to the rationales for the guidelines. Also at one time we had agreed to use "author" instead of "user" to distinguish the author from the reader or viewer of the documents. We seem to have digressed from this. Should we edit the document to adhere to this convention again? In guideline 1 should we move the two checkpoints regarding structure together? Jutta 1.2 Rationale: Element or object properties displayed and edited through graphic means are not accessible to authors using screen readers, Braille displays or screen enhancers. The explicit property value should be accessible to assistive technologies which read text. 1.3 Rationale: When using a screen reader, screen magnifier, on-screen keyboard or Braille display it is very difficult to get an overview of the document. Items are viewed and controlled sequentially at the lowest level. To effectively edit a document, authors require the ability to flexibly collapse the document so that chunks of the document can be edited, moved or deleted at a less granular level. Editor's Note: This guideline and it's techniques are somewhat muddled. My interpretation of this is that we want to have the option to edit the document in a collapsed structure view and we also want to be able to edit the hierarchy while in that view (eg. demote a header from H1 to H2). 1.4 Rationale: Authors may require a set of display preferences to view and control the document that is different from the desired default display style for the published document. 1.5 Rationale: When using a screen reader, Braille display, or many keyboard alternatives it is not possible to quickly and accurately identify and jump to a desired location in the document because the document is viewed and moved through sequentially. The document structure allows the author to move through the document at a higher level. 2.5 Editor's Note: Should we have the statements regarding checking and correcting here or should they be elsewhere? 3.6 Rationale: A summary of the document's accessibility status will prompt the author to improve the status, allow the author to keep track of problems to address and allow the author to monitor their progress towards making the document accessible. 4.1 Rationale: The author should be able to easily locate, activate and use accessible authoring practices supported by the tool. If the features that support accessible authoring are difficult to find, activate and use they are less likely to be used. Ideally these features should be turned on by default. 4.2 Rationale: When the author is given a choice of authoring practices or features within the tool the accessible choices should be among the first and easiest choices. 4.3 Rationale: Using accessible authoring practices should not require that the author depart from the authoring conventions of the tool. Accessible authoring should be a natural, integrated component of authoring with the tool. --
Received on Saturday, 22 March 2003 09:47:31 UTC