This document describes the best practices to make a Genero application accessible for disabled people.
Since a mouse or other pointing devices may not be used by people with reduced vision, an accessible application must be usable with the keyboard alone. Therefore, all the possible actions that could be triggered by a user must have a keyboard shortcut.
We strongly suggest that you define consistent keyboard shortcuts for all actions through the use of Genero Action Default files (.4ad) and Genero Action Defaults sections in Genero form definition files. Developers can avoid overriding the system default shortcuts by checking the target platform guidelines, especially for system shortcuts that trigger accessible actions (for example, CTRL+SHIFT+ENTER, which triggers spoken information about the currently selected item). Overriding system shortcuts is generally a bad practice, even for non-accessible applications, although overriding may be unavoidable due to compatibility issues.
Generally, keyboard navigation in an application may be easier if you keep the MENU actions in the menu frame; the actions can have the keyboard focus and the user can navigate through them using the up and down arrows.
You can also use a TOPMENU, because you can pull it down with the keyboard ( the ALT key on Windows) and then navigate using arrow keys, but it may be less accessible than the menu panel. You must also be sure that every item of the menu can be activated by a keyboard shortcut. You may use the & (ampersand) to specify character which letter should be used. Under Windows the GDC automatically creates a shortcut for the first letter of each menu item.
Avoid using TOOLBARs only in an accessible application, because toolbars by default are not accessible using the keyboard. Toolbars cannot have the keyboard focus, and there is no way to navigate through all toolbar items or to activate one of them using the keyboard. If you do use toolbars, provide keyboard shortcuts and duplicate them in a TOPMENU.
Screen readers are special system applications, usually on Windows, that transform the applications graphical user interface into speech; we use the Windows Narrator, but it is not the only one available. The behavior may change between screen reader implementations, but, basically, each widget is named and described by speech. Special keyboard shortcuts are available (at least on Windows) to trigger the complete enumeration of all the components of a window, or to describe only the component having the current focus.
Screen readers use special bindings to get the information that they need (name, full description, hierarchy, triggered actions...) about each graphical component of the entire GUI. It's up to the programmer to provide these bindings to the screen reader, but most of the work is already done by the Genero clients.
BDL developers can provide two things for each widget:
an accessible name - using the TEXT form attribute if available. otherwise using the COMMENT form attribute.
an accessible description - using the COMMENT form attribute.
This can be tedious, but it absolutely must be done carefully, keeping in mind that the text will be “spoken”: customer's name is preferable to _cust_name_str_. Spaces and punctuation are allowed.
Examples:
In a Genero Top Menu definition file (accessible.4tm)
<TopMenuGroup name="file" text="File" tag="File" comment="File commands">
<ActionDefaultList>
<ActionDefault name="new" text="New..." image="new.svg" comment="Create a new database"
acceleratorName="control-n" />
<ActionDefault name="open" text="Open..." image="open.svg" comment="Open an existing database"
acceleratorName="control-o" />
<ActionDefault name="save" text="Save" image="save.svg" comment="Save the current database"
acceleratorName="control-s" />
...
In a Genero form specification file (accessible.per)
ATTRIBUTES
EDIT login_name = formonly.login_name, NOT NULL, COMMENT="Login name of the current user";
EDIT password = formonly.password, NOT NULL, INVISIBLE, VERIFY, COMMENT="Password of the current user";
EDIT first_name = formonly.first_name, NOT NULL, COMMENT="First name of the current user";
EDIT last_name = formonly.last_name, NOT NULL, COMMENT="Last name of the current user";
DATEEDIT birthdate = formonly.birthdate, FORMAT="mm/dd/yyyy", COMMENT="Date of birth of the current user";
EDIT email = formonly.email, COMMENT="E-mail of the current user";
END -- ATTRIBUTES
In this form specification file the COMMENT attribute is used for both the accessible name and the accessible description.
Most of the BDL components are supported as is: all FORMFIELD, static LABEL, static IMAGE, and ACTION-based components (BUTTONS, MENU, ….); some containers (GROUP and FOLDER) should work out of the box as soon as their TEXT attributes are correctly set. The notable exceptions are TABLE and CANVAS, which are not supported at this time, and SCROLLGRID, which is only partially supported, because we don't have information about the current index to the accessible name or description.
Keep the complexity of a form to a very minimal level. As everything will be spoken, it is preferable to have a lot of small and concise forms with five fields or less, rather than a huge mega-form with everything displayed (or "spoken") at once. If your form is composed of more than 30 fields, it would take a very long time for the narrator to enumerate every field's name and description. In addition, the user must be able to keep everything in his memory, and it would be almost impossible for him to correctly navigate through all the fields and to retain that information.
Consider using a special Genero style file (.4st) that has big fonts, big icons, and high contrast color themes, This will make your application a lot more efficient for users who are not completely blind. It will take more space on the screen, but if you followed the first point ( less than five fields on a form...) you should have sufficient space left.
Don't be afraid to use 14 point fonts or 64 square pixels icons, as people with impaired vision may use your application. Do not forget that most of the default sizes (font, icons, gui components,...) were set when the default resolution was 640*640 pixels in 16 colors. Now, even if the user has very good eyes, with the screen resolution available today everything looks small.
Using a high contrast color theme will also help. Although support of the system high contrast theme is only partial, nothing prevents you from setting up the correct theme using a Genero style file.
Example Genero style file accessible.4st, defining larger, bolder fonts and icons:
<StyleList>
<Style name="*" >
<StyleAttribute name="fontSize" value="10" />
</Style>
<Style name="Action" >
<StyleAttribute name="scaleIcon" value="28px"/>
<StyleAttribute name="fontSize" value="12" />
</Style>
<Style name="Window" >
<StyleAttribute name="actionPanelPosition" value="bottom"/>
<StyleAttribute name="actionPanelButtonSpace" value="huge"/>
<StyleAttribute name="actionPanelHAlign" value="center"/>
<StyleAttribute name="ringMenuPosition" value="bottom"/>
<StyleAttribute name="ringMenuButtonSpace" value="huge"/>
<StyleAttribute name="ringMenuHAlign" value="center"/>
</Style>
<Style name="ToolBar" >
<StyleAttribute name="scaleIcon" value="32px"/>
</Style>
<Style name="Edit:focus" >
<StyleAttribute name="fontWeight" value="bold" />
<StyleAttribute name="backgroundColor" value="darkBlue" />
<StyleAttribute name="textColor" value="white" />
</Style>
</StyleList>