geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack <greensi...@gmail.com>
Subject Re: Fixing usability/accessibility issues in Admin Console
Date Wed, 30 Jul 2008 06:50:40 GMT
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 <greensight@gmail.com>

> 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 <kevan.miller@gmail.com>:
>
>>
>> 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
>>
>>
>

Mime
View raw message