MoDisco/Accessibility Guidelines

Regarding the Helios simultaneous release train, the official guidelines and tools for Accessibility compliance are not mature enough : advice of the Accessibility Cross Project Team.

So the policy proposed here is a minimal checklist, awaiting for an official one, which sums up the main Accessibility Article highlighted by the Planning Council. Every MoDisco User interface must comply with this checklist.

As indicated by the Planning Council, the main target for accessibility is Windows OS.

Colors and images

Purpose

The aim is to keep good contrast between text and background for readability, either in normal and higher constrat mode.

Guidelines

• Do not use images which contain text
• Background colors should not be hard-coded, or there should be at least a "reduced palette theme" mode (see Accessibility Article), which should be accessible from Preferences->General->Appearance->Colors and Fonts

Testing

Use hight contrast mode from Windows : Control Panel>Accessibility Options

Fonts

Purpose

The end user should have some possibilities to use applications with specific fonts and font sizes.

Guidelines

• When using a "large font" mode dedicated to accessibility, the texts should not be cut and should fit the windows.
• The users must be able to change any font they wish (see Accessibility Article)

Testing

Use hight contrast mode from Windows : Control Panel>Accessibility Options.

Change font in General>>Appearance>>Fonts and Colors and see how it applies to the guis.

Keyboard and Mouse

Purpose

Every feature in an application must be reachable using the keyboard, for people who do not have the motor control to get a mouse.

Guidelines

• Every feature in a menu shoule be accessible from keyword. This requirement is already fullfilled with standard F10 behavior. Optional : associate some mnmonic for fast navigation.
• Every control that the user needs to manipulate (such as combo boxes, text fields, and buttons) the user should be able to navigate to it with a keystroke. This requirement is logically aready fullfilled with tab key behavior. Optional : associate hot keys for fast navigation.
• Everything that needs scrolling to be seen needs to have that scrolling accessible to the keyboard. The usual way to do this is to listen for tabs or the page up and page down keys and to move the viewing area appropriately.

Accommodating Screen Readers

Purpose

When focus comes on a widget, the right label should be pronounced with a screen reader.

Guidelines

As a text and combo box widgets do not have a label associated with them we have several ways that we can get a screen reader to infer a label for a widget with focus:

• A label immediately precedes the focus widget in the z-order.
• The focus widget is the direct child of the shell (in this case the shell label gets read).
• It is the parent of a widget that has a label and is labeled itself. For instance, a labeled text inside of a group box will have both its label and the label of the group box read. But if there is an unlabeled widget (say an intermediate Composite) between the label and the group box, the group box will not be read.