Before this post sinks, would someone help to put the accessibility guidelines somewhere in our doc? Maybe in the coding standard? If I can get the write access (I've signed ICLA), I can do that if no one objects...
Jack Cai 2008/7/16 Jack <[EMAIL PROTECTED]> > 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 >> >> >
