- From: Daniel Dardailler <danield@w3.org>
- Date: Fri, 15 May 1998 12:09:55 +0200
- To: w3c-wai-ua@w3.org
My comments after DD:: DD:: Note: I'm ignoring typos and spelling for now. DD:: I still don't see a clear section on capabilities: support CSS1, CSS2, HTML4. DD:: I also would want to see in this document some explanation of the difference between an accessible "Markup Aware UA" and a simple "Screen Reader" whose input is the output of another graphical UA. > Scenarios > Short descriptions of how the changes impacts persons with different > types of disabilities on common WWW tasks and how it compensates for > WWW pages that are not designed for accessibility. > Implement Ideas > Considerations, options and ideas that developers can use for > implementing a particular access feature. > Test Pages > Self explanitory test pages that can be used by browser developers to > determine if a browser complies with a specific guideline. These definitions appear out of context, they need to be announced somehow. > A. Default Browser Display Style > > 1. [Priority 1] > User can adjust the default font face used by the browser. Persons with > visual impairments and learning disabilities can adjust the font to the > style characteristics that is best for them to view WWW pages. > 2. [Priority 1] > User can adjust the default font size used by the browser. Persons with > visual impairments and learning disabilities can adjust the font to the > size that is best for them to view WWW pages. > 3. [Priority 1] > User can adjust the default foreground and background colors used by > the browser. Persons with visual impairments and learning disabilities > can adjust the display colors to the colors that are best for them to > view WWW pages. > 4. [Priority 1] > User can turn off background images > 5. [Priority 1] > User can adjust the highlight foreground and background colors used by > the browser. Persons with visual impairments and learning disabilities > can adjust the display highlight colors used to indicate selections of > text. Highlighted text is often used by third party assistive > technologies to indicate what the user wants to read through speech > output. Highlighted text can also be used by screen readers to indicate > the focus of what the user is trying to read. Some screen readers are > sensitive to the highlight colors. DD:: The selection color is also important: the color used for selectext text, it often conflicts with the background or the ink itself. > 6. [Priority 1] > Keyboard command to switch between default browser presentation and > current user preferences. DD:: yes, this is important: to be able to quickly say "take by black on white brower default" just for this screwy page. then revert to author choice for next pages. > 7. [Priority 1] > Implement the important rule to allow users to override author CSS > specifications. DD:: be more precise: say the "CSS important rule" BTW, this capability is included in CSS2. Why mention it here ? > 9. [Priority 2] > Support Aural Cascading Style Sheets for the auditory presentation of > WWW documents. DD:: same thing. > 10. [Priority 2] > User can specify a Cascading Style Sheet to be used in cascading order > specified in CSS2 after the document style sheets have been loaded. The > style sheet is an external linked style sheet is applied to all > documents viewed. Users can define a style sheet to meet the needs of > their particular capabilites and preferences. Browsers should support > auditory style sheets for presenting information auditory, visually or > both. DD:: last sentence is dup with guideline 9 above. > 11. [Priority 1] > Implement the important rule to allow users to override author CSS > specifications. DD:: dup with 7 > B. Ignore Page Formatting Specifications DD:: better title: "Priority to User style" (color is not formatting for instance) DD:: The turn off background image in section 1 should be there. DD:: both section could be made into one about "Control style", with mention of default and turn off. > C. Alternative Representations of Images > > 1. [Priority 1] > > User selectable option is available to turn off the display of images > using the IMG tag and display descriptive text in place of the image. > There are three potential sources of descriptive text information: ALT > attribute, TITLE attribute and NAME attribute if the image is part of a > Anchor. The priority of presentation is the ALT, TITLE and then NAME > text. If none of these sources is available the name of the file should > be used as the alternative description. The entire text should be > rendered no matter what the source of the text or the dimensions > specified for the original image. DD:: Regarding finding ALT: the HTML4 spec has a more complete section: -- begin HTML 4 section B.9 Notes on accessibility Note. The following algorithm for generating alternate text may be superseded by recommendations by the W3C Web Accessibility Initiative Group. Please consult [WAIGUIDE] for more information. When an author does not set the alt attribute for the IMG or APPLET elements, user agents should supply the alternate text, calculated in the following order: 1. If the title has been specified, its value should be used as alternate text. 2. Otherwise, if HTTP headers provide title information when the included object is retrieved, this information should be used as alternate text. 3. Otherwise, if the included object contains text fields (e.g., GIF images contain some text fields), information extracted from the text fields should be used as alternate text. Since user agents may have to retrieve an entire object first in order to extract textual information, user agents may adopt more economical approaches (e.g., content negotiation). 4. Otherwise, in the absence of other information, user agents should use the file name (minus the extension) as alternate text. When an author does not set the alt attribute for the INPUT element, user agents should supply the alternate text, calculated in the following order: 1. If the title has been specified, its value should be used as alternate text. 2. Otherwise, if the name has been specified, its value should be used as alternate text. 3. Otherwise (submit and reset buttons), the value of the type attribute should be used as alternate text. -- end HTML 4 section DD:: We can use it, we don't have to stick to it. In particular, we could mention that for missing ALT for IMG used in link, a priority3 would be to provide on-user-demand way of fetching the TITLE of the linked URL (go fetch it, with performance hit, that's why it has to be on demand only). > 3. [Priority 1] > Images using the IMG tag which include the LONGDESC attribute should > display a D-Link to the LONGDESC URL when the user selectable option > for image presentation is off. The D-Link would be presented as part of > the text description (discussed earlier in this section). Keyboard > commands are required to locate and select the presentation of LONGDESC > attribute information. In addition the LONGDESC URL could also be > selected through mouse commands for able-bodied users or persons with > LD who prefer to use a mouse. DD: I mentioned that in a previous mail: we need to account for migration path. I've been trying to have people use both longdesc attributes and D-link when authoring today. If we make them exclusive, we have little chance that longdesc takes any role in the future. If the LONGDESC results in displaying a D-link, there are in effect exclusive (2 D-link is bad) > F. CSS Support > > 1. [Priority 1] DD:: Why just CSS, and which version ? We need to mention valid/complete HTML as well, and PNG. > D. Frame Navigation > > 1. [Priority 1] > Keyboard navigation commands to switch focus between frames. DD:: Do we talk about linearization of FRAME (and their navigation in this form) somewhere ? > F. Dyanmic HTML Events DD:: the proper name is DOM, is there a spec for DTHML somewhere ? I need to think more about DOM/DTHML to comment on event support when one doesn't have a mouse or a keyboard. DD:: In terms of navigation, one important thing to support if the HTML meta LINK conventions for prev, next, index, etc, that are mentioned as informative in the HTML spec (lynx 2.7 does it). DD:: on a process note, I already made some of these comments back in March on this list and I'm not sure there has been some followup back then or since. So I have to repeat them. How can I know what happened to the ideas put forward in http://lists.w3.org/Archives/Public/w3c-wai-ua/1998JanMar/0063.html It's important that we track the feedback received, by either saying: bad idea, or next time, or ok, soon, but not have people repeating their comments twice.
Received on Friday, 15 May 1998 06:09:59 UTC