|
Introduction, continued
Forms may appear to be accessible even when they are not usable by people who need assistive technology such as a screen reader. Here are some factors that play a part in a form's accessibility, along with their associated checkpoints:
- Keyboard accessibility
- Can all areas of the form be completed, and the form be submitted, using only the keyboard?
- Does the tab order of the form proceed logically and reflect the normal flow of form use?
- Accessibility of element names and properties
Elements must expose information about their role, value and state in an accessible manner.
- Are meaningful accessible names provided for all form elements?
- Do elements with multiple labels expose them in their accessible names?
- Instructions and errors
- Is there an alternative means of indicating completion or error other than audio information alone?
To be accessible, completion and error messages should not rely solely on color or sound.
- Are form field constraints clearly indicated?
Form field constraints refer to limitations on what can be input in a field; these include acceptable input types and character limits.
- Are error messages explicitly indicated and easily found by a user?
- Is instructive text placed at the beginning of a form or prior to the relevant form field?
- Groups of controls
- Are form control groups properly labeled?
- Are radio button groups properly formed?
- Indication of changes
- Is focus returned to the last focused element when returning to an open module?
- Are proper programmatic events fired to provide access to context changes?
- Timers and timing
- When a timed response is required, is a warning provided to the user that is available to Assistive Technology?
- Is the user given sufficient time to interact and/or request more time?
This may appear to be a daunting list. (It's a good thing this module was left for last!) But with a little attention and planning, it can be fairly straightforward in practice. The rest of this topic will discuss the meaning of these practices and how they can be developed and tested.
Keyboard Accessibility
Two checkpoints related to keyboard accessibility in electronic forms are:
- Can all areas of the form be completed, and the form submitted, using only the keyboard?
- Does the tab order of the form proceed logically and reflect the normal flow of form use?
Keyboard accessibility is one element of device independence, which allows users to interact with an application in the way that works best for them. That may be the mouse, the keyboard, or specialized input AT, such as speech input or simulated mouse input.
Developers should use standard Windows controls whenever possible. Use of the standard Windows 32 controls, which comes with different development environments, is the best way to expose accessibility. If custom controls are created, developers should ensure that there are multiple ways to access and interact with the controls. For example, if a custom control has been developed that requires dragging and dropping, ensure that there is also a keyboard-accessible feature to cut and paste.
Developers should associate actions to events rather than to specific mouse movements/clicks or keyboard actions. Using pre-defined events such as an on_click and on_press of an object allows default event handlers to accept input from both the mouse and the keyboard. This approach is preferred over watching for the Return key from an on_keypress event or a mouse click from an on_mousemoved event.
[back to top]
Accessibility of Element Names and Properties
Two checkpoints related to the names of controls in electronic forms are:
- Are meaningful accessible names provided for all form elements?
- Do elements with multiple labels expose them in their accessible names?
Form elements, including controls, must not only have meaningful and accessible names, but they must also expose information about their role, value and state in an accessible manner. All users need to understand the purpose of the elements they are interacting with, but for users of AT such as screen readers, this information is especially important because it conveys the meaning of the control (like OK, or Cancel), the type or role of the control (such as a button or checkbox) and its state (such as selected or checked). When this information is accessible, users will know which selections they have made and what kind of interactions are expected, even if they cannot see the screen.
Control labels should also be clearly associated with the appropriate control:
- Button labels should be in, to the left of or above the control.
- Radio button and checkbox labels should be to the right of the control.
- Other types of control labels should be close to the control and should end in a colon.
Properly locating control labels provides visual clarity to an electronic form. It also helps AT provide correct control names to the user when the accessible name cannot be set directly in the application programmatically. When the programming language/development environment supports setting an accessible name, that approach should be used in addition to properly locating the on-screen label.
[back to top]
Instructions and Errors
Four checkpoints related to instructions and error messages in electronic forms are:
- Is there an alternative means of indicating completion or error other than audio information alone?
- Are form field constraints clearly indicated?
- Are error messages explicitly indicated and easily found by a user?
- Is instructive text placed at the beginning of a form or prior to the relevant form field?
To be accessible, applications must indicate user completion and errors through an accessible means that does not rely solely on color or sound. If an application uses animations or bells and whistles to get a user's attention about successful completion or an error, remember that some users may not be able to see or hear them. Make sure that sounds are accompanied by information that can be understood if the user cannot hear them. Combine sound and visual indicators, and, just to be safe, make sure there's a textual option available as well.
It is also important to inform users if there is a character limit in text fields, or if the input information is expected to conform to a certain format, such as "Birth date, (mm/dd/yyyy)" and "Enter ID number (no dashes)".
When errors occur, users must be able to recognize that errors have occurred, identify the errors and understand how to correct them. Remember to add textual information to the symbols that indicate an error. Make sure that the word "Error" is clearly indicated to a user, and that error information easily gains focus so the user can access details about what went wrong, and then move easily to fix the problem.
Instructions are important so that users know what is expected of them. Explaining the purpose of a form or a set of controls is especially important if symbols convey special information. An example of this is when asterisks (*) are used to indicate required fields.
[back to top]
Groups of Controls
Two checkpoints related to groups of controls in electronic forms are:
- Are form control groups properly labeled?
- Are radio button groups properly formed?
These checkpoints relate to the way controls are grouped and presented. If a group of controls is associated with particular information, then that association needs to be clear, both visually and to a screen reader. For instance, if an electronic medical form has two panels – one for personal information and the other for medical data – and there are two buttons, but it is not clear which button is associated with which panel, a user could mistakenly submit a patient's address and phone number instead of medical intake data.
Similarly, make sure that each set of radio buttons is clearly associated with an overall label. A screen reader user needs to know not only the name and state of each radio button choice, but also the general label associated with the buttons. It does no good to answer "yes" or "no" if you aren't sure what the question is. The answer could be different for "Would you like free ice cream?" and "Does this parking ticket for $200 belong to you?"
[back to top]
Indication of Changes
Two checkpoints related to how changes are indicated in electronic forms are:
- Is focus returned to the last focused element when returning to an open module?
- Are proper programmatic events fired to provide access to context changes?
If, for any reason, the focus moves away from a form or form field, it should return to its last position on the form when focus is returned. This serves two purposes. It prevents potential disorientation among users who may be unsure where they are on the screen, and it prevents users from having to navigate through fields with which they have already interacted. This requirement supports access for screen reader and screen magnification users, and for users with motor/dexterity concerns.
Whenever there is a change on the screen that affects the users, make sure that appropriate programmatic events are being fired. This includes user-generated changes (such as changing the state of a control or selecting items from a list), and changes that are made by the program itself, such as information updates. If an alert pops up on the screen to indicate additional information, the user's AT must be able to access that alert. If the appropriate events are not fired, a screen reader may not recognize that there is new information available.
[back to top]
Timers and Timing
Two checkpoints related to timers and timing in electronic forms are:
- When a timed response is required, is a warning provided to the user that is available to Assistive Technology?
- Is the user given sufficient time to interact and/or request more time?
If there are time limits on interactions with an application, they must be clearly indicated to a user in an accessible way. All the rules you have previously learned apply here. Make sure the information is clear, available to AT and communicated in a way that does not depend solely on color or sound.
Also, after a timeout warning, a user must be allowed enough time to either complete an action or request more time. This is especially important for users with motor or dexterity impairments, as they may take longer to input information. The way to request more time should be simple and straightforward, and should not cause a user to risk losing his or her work and having to start over.
[back to top]
Select Next for some examples.
| 
