Thanks Keven for your comments! A good start point on accessibility is here [1]. W3C has released a guideline years ago [2]. And a newer version is under development (for a long time) [3].
I understand that might be lengthy. So I extracted the most relavent guidelines to Geronimo below. I suggest we can put it somewhere in our developer's documentation. Can someone help to do that? Or can someone grant me wrtie access to the confluence wiki? My account is caijunj. As to the tools that we used to check accessibility, one is WebKing, and the other is JAWS, both commercial software. - WebKing can scan the source code and detect accessibility issues based on static code analysis. - JAWS is a popular screen reader software that people with visual problems use to access information on a computer screen. It basically reads all the information it understands via text-to-speech. To make the mail not too lengthy, I'll discuss the error response formats in another mail later on. [1] http://www.w3.org/WAI/ [2] http://www.w3.org/TR/WCAG10/ [3] http://www.w3.org/TR/WCAG20/ *Web accessibility guidelines (short version)* 1. Provide equivalent alternatives to auditory and visual content. - Set meaningful ALT attribute for IMG, APPLET elements. - Provide equivalent text links if a server-side image map is used. 2. Don't rely on color alone. - Ensure that all information conveyed with color is also available without color. 3. Use markup and style sheets and do so properly. - Use style sheets to control layout and presentation. - Use relative rather than absolute units in markup language attribute values and style sheet property values. e.g., in CSS, use 'em' or percentage lengths rather than 'pt' or 'cm'. 4. Create tables that transform gracefully. - For data tables, identify row and column headers. e.g., use TD to identify data cells and TH to identify headers. - Do not use tables for layout unless the table makes sense when linearized. Use css instead. 5. Ensure that pages featuring new technologies transform gracefully. - Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. 6. Provide context and orientation information. - Title each frame to facilitate frame identification and navigation. e.g., in HTML use the "title" attribute on FRAME elements. - Associate labels explicitly with their controls. e.g., in HTML use LABEL and its "for" attribute. 7. Make all functionality operable through a keyboard interface. 8. Help users avoid mistakes and make it easy to correct mistakes that do occur. Jack 2008/7/5 Kevan Miller <[EMAIL PROTECTED]>: > > Hi Jack, > Thanks for the information. > > I doubt that accessibility was given much (if any) thought during > development of the console. We'll probably need some education about > important factors regarding accessibility. If you have some pointers, they'd > be welcome. Also, it looks like some tools have been used to identify > problems with the console. It would be useful to understand what these tools > are. > > From your description above, I think we'd welcome your contributions. > > Regarding 1), sounds like a reasonable approach. I think a specific > illustration of your proposal would be useful. > > --kevan > >
