geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack <>
Subject Re: Fixing usability/accessibility issues in Admin Console
Date Wed, 16 Jul 2008 14:03:03 GMT
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.


*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

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


2008/7/5 Kevan Miller <>:

> 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

View raw message