- From: by way of Harvey Bingham <hbingham@acm.org>
- Date: Wed, 06 Jan 1999 04:48:41 -0500
- To: "WAI IG" <w3c-wai-ig@w3.org>
I recently encountered a variety of temporary inaccessibility problems trying to use my laptop while I was a passenger on a car trip. Another blind passenger had several other problems. The solutions exploit alternative information or methods. If the browser or other tool you are using supports accessibility features, and if the critical redundant information is available in the source, or provided by the tool, then the aware browsers, user agents, or tools can exploit it. 1. Problem: too bright sunlight to see the screen (I actually made a tent and hid in it.) A text-reader would have helped with output that would normally be on-screen. Keyboard navigation helps (such as tab through links, and use of arrow keys or other keyboard shortcuts, such as in the Opera browser). Earcons can announce position/context/requests for action. Emacs, vi, or other text tools, as they were originally text-aware and exploited it, can be navigated and be read by a text-reader. Search tools can locate content. Cursor position can be queried for context. Alternative text may describe content generated by scripts, applets, and plugins. For images, photographs, or animations, provide redundant textual description: HTML attributes on images <img alt="concise function of visual" ...>. If needed, include a more extensive description <img longdesc="URL of that description" ...> 2. Problem: too bumpy to use the mouse (I used keyboard equivalents for mouse actions.) Voice recognition for commands would have helped. Sensitivity adjustment on the mouse would have made it more useful. Tabbing and arrow keys helped navigate through well-described links, particularly when there are textual links to augment client-side image maps. 3. Problem: too dark to see the unfamiliar keyboard (I actually tipped my screen down to illuminate the keyboard, and found the differently placed characters.) Voice recognition of punctuation characters would have helped. Typed entry of known entity names, and software substitution would have avoided the dependence on keyboard placement, as well as the ability to enter additional characters. An on-screen keyboard would show where they were, as available in SoftQuad Software's HoTMetaL since 3.0 and will be in XMetaL soon. I learned where the repositioned keys were after a bit. That comparably motivated training would have helped me quickly learn the many available keyboard shortcuts that I normally do not use. 4. Problem: too noisy to hear subtle earcons or other audio source (I actually was able to repeat what the generator did, as if "say again".) Earcons used as event announcers can be augmented with visual effect: flashes or color shifts for examples. Headphones would have masked the surrounding noise. So would captions or transcripts if the audio were the primary source material. 5. Problem: Colors run together or inadequate contrast (I was able to override the inappropriate colors and turn off background.) Allow user to select appropriate color shift/substitution, say to avoid color-blindness, or get rid of visually cluttering backgrounds. For HTML use the user personalized style, as CSS or CSS2 important override of author recommended styles. For XML can use XSL with different user styles suitable to the particular environment(s) and user preferences, and broadly applicable to many documents. 6. Problem: Tables used for layout (This visual problem I did not experience, but it was for a blind passenger.) Use tools that read cell-by-cell, not across lines of row, important where the cell content wraps onto more than one line in the cell. Navigate left-right, up-down by cell, even across spanning cells. Determine implicit information from column heads and row stubs. Use HTML 4.0 attributes to describe table: caption tag on table, title attribute, IDs on header cells and headers list of IDREFs to those IDs on data cells, AXIS and AXES as alternative, abbreviated headers for text-readers. 7. Problem: Frames for input (I did not encounter this, but the blind passenger had this problem.) Label frames with title or name. Include hypertext to an alternative start page for a noframes element. Regards/Harvey Bingham Yuri Rubinsky Insight Foundation http://www.yuri.org/webABLE W3C Web Accessibility Initiative http://www.w3.org/WAI/
Received on Thursday, 21 January 1999 02:42:32 UTC