- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Tue, 30 Nov 1999 20:21:49 -0500
- To: Kynn Bartlett <kynn-hwg@idyllmtn.com>
- Cc: Authoring Tools Guidelines List <w3c-wai-au@w3.org>
aloha, kynn! you observed: quote If my mom wants to make a web page have a particular shade of blue background, she just points at that color on a color wheel and clicks -- if she were blind, she'd have to learn RGB codes most likely. This is the distinction you're making, correct? unquote i can't speak for charles (and, since i began composition on this, he's spoken for himself), but my answer to your question is, yes, she would most likely need a crib sheet that contained the RGB codes and their named equivalents -- and it would be helpful (er, beneficial) if the tool either provided one, or pointed her to one (through a references section of the Help or Documentation) this is a topic -- the color palette problem -- that i've addressed in conformance evals for both AU and UA... in my conformance evaluation of MSIE5, NN 4.8,and Opera 3.60, performed with HAL95 back in september for the User Agent working group, i made the following comments: quote Checkpoint 1.4: Ensure that the user can configure the user agent in a device independent manner. [Priority 1] One of the strategies used by blind and low vision cybernauts operating in the GUI environment is to force the user agent to ignore author-defined colors for hyperlink text, so that it is always displayed in a consistent, uniform manner. This includes the use of user-defined colors for visited and unvisited links, which is not only useful for the low vision user, but also for the blind user. Under adverse circumstances (which, for the purposes of this review includes using HAL with Netscape), a blind user will be forced to use screen review commands to have the font attributes for a character (or a selected/highlit string of text) spoken, so as to ascertain whether or not the mouse-emulation cursor is positioned on a hyperlink, and whether or not that hyperlink has been previously selected. All three of the user agents examined in this evaluation offer the user some level of control over the visual presentation of hyperlink text. [NOTE: Please refer to the comments on Checkpoint 9.6 for further discussion of this issue.] Of the three, Opera offers the greatest amount of user configurability for hyperlink presentation -- enabling the user to configure the browser so that, for example, unvisited links are underlined and visited hyperlink text appears struck-through, thereby allowing the user a supplemental means of distinguishing between visited and unvisited links. All three user agents provide the user with the ability to define his or her own color scheme for visited and unvisited links, along with the option to override colors defined for a document by the document's author. All three, however, also fail to provide alternative textual equivalents for the colors available to the user, instead presenting the choice of colors as a palette comprised of "swatches-in-a-box", which are completely inaccessible to the blind user without sighted assistance. unquote the reference to Checkpoint 9.6 points to the following comments: quote Checkpoint 9.6 For a selected link, provide information to help the user decide whether to follow the link. [Priority 3] Note. Useful information includes: whether the link has already been visited, whether it designates an internal anchor, the type of the target resource, the length of an audio or video clip that will be started, and the expected natural language of target resource. Note. Using color as the only distinguishing factor between visited and unvisited links does not suffice since color may not be perceivable by all users or rendered by all devices. REVIEWER'S GENERAL NOTE: Using HAL's "Speak background and foreground color" and/or "Speak font attributes" key command, when the point of regard is a hyperlink allows the user to ascertain a limited amount of information about the currently selected link. The information that is available is as follows (NOTE: the terminology used to enumerate information about font attributes available to the user on demand, does not correspond to the syntax used in CSS): "Say Font Attributes" (LeftControlKey+F) 1. font family (e.g. Times New Roman) 2. font weight (bold or normal) 3. font style (italic, underline, strikethrough, etc) 4. font size (in points) "Say foreground and background color" (LeftControlKey+5) 1. foreground color 2. background color When querying HAL as to the fore- and background colors for hyperlink text, however, HAL was only able to report those colors defined using the hexadecimal notation (i.e. "#RRGGBB") and not those defined using the semantic equivalents defined for HTML4 (i.e. white, blue, red, etc.) which can be used to define colors in CSS. Despite this, hexadecimal color values are reported by HAL in plain English (e.g. the hexadecimal value "#00009C" is reported as "very dark blue", while the style defined as "background-color : white;" is reported as "background color unknown". unquote and, in my badly-in-need-of-an-update conformance eval of HomeSite 4.01, located at http://www.w3.org/WAI/AU/reviews/homesite-19991007.html i made the following observations on color palettes and their usefulness: quote 7.2 Allow the author to change the editing view without affecting the document markup [Priority 1] The editing view can be changed without affecting the document's markup. A very nice feature of HomeSite in this regard is that, unlike most GUI applications, the color palette is not only iconically/graphically demarcated, but is also textually demarcated. The author can change the following screen attributes for the editing view: Font family font size Tab width charset foreground color background color In addition, the author can edit HomeSite's color coding scheme--a mechanism which controls the display of the various components of a document as a means of providing visual cues. The components which can be color coded include: Allaire Cold Fusion Tags Comments Default Text HTML Anchor Tags HTML Attributes HTML Image Tags HTML Special Characters (character entity sets) HTML Style Tags HTML Table Tags HTML Tags JavaScript Identifiers JavaScript Keywords JavaScript Methods JavaScript Numbers JavaScript Strings JavaScript Symbols Microsoft ASP Tags Numbers Punctuation (such as braces) Script Tags Strings StyleSheet Properties StyleSheet Selectors StyleSheet Values According to the reports of sighted colleagues, when using the "Edit" workspace, HomeSite recognizes page components and changes the color scheme accordingly, providing a visual means of cueing the author not only to the page's components, but quickly alerting the sighted author when he or she has failed to correctly close containing tags, forgotten punctuation, etc. The main failing of the color scheme feature is that the color palettes offered for foreground and background colors do not contain textual equivalents of the colors displayed. unquote why would knowing the color values assigned to different snippets of code be of use to a totally blind user? if the blind user knows what background and foreground colors have been defined to visually symbolize different components, he or she could then set his or her screen reader to change pitch, speed, or voice in response to color changes -- a kludge that allows for the user to obtain an aural equivalent of the color changes, thus giving the blind user a clearer conception of the page components, without forcing the user to review the source character-by-character (which is what i tend to do, and which may explain my stunted personality and complete and utter lack-of-a-real-life) of course, the color swatches would need to be properly labeled with some sort of understandable text -- at least the hexadecimal or RGB value, at best a named color (when available) -- so that the label can be read or felt when the swatch is tabbed-to, rather than merely exposed when pointed-to via a ToolTip... gregory. -------------------------------------------------------- He that lives on Hope, dies farting -- Benjamin Franklin, Poor Richard's Almanack, 1763 -------------------------------------------------------- Gregory J. Rosmaita <unagi69@concentric.net> WebMaster and Minister of Propaganda, VICUG NYC <http://www.hicom.net/~oedipus/vicug/index.html> --------------------------------------------------------
Received on Tuesday, 30 November 1999 20:14:46 UTC