This page contains material related to a presentation at the Web Accessibility Best Practices Evaluation Training in Sankt Augustin, Germany on 25 October, 2005, as part of the WAI-TIES Project (WAI - Training, Implementation, Education, Support). It is not intended to stand-alone; rather, it is primarily provided as reference material for participants in the training.
Scope of Training and Materials: This one-day training focused on select topics that were particularly suited to the circumstances of this specific training session. It did not to cover all aspects of evaluating Web accessibility, and did not cover all Web Content Accessibility Guidelines (WCAG) 1.0 checkpoints.
No Endorsement or Recommendation of Evaluation Tools: W3C/WAI does not endorse Web accessibility evaluation tools and does not recommend one tool over another. Some tools were listed, demonstrated, and used in activities in this training. Mention of a specific tool does not imply endorsement nor recommendation. WAI does provide a comprehensive list of Evaluation, Repair, and Transformation Tools for Web Content Accessibility.
Evaluating Forms
Andrew Arch, Vision Australia - Accessibility Information Solutions
Last updated: 1 November 2005
Introduction
- Accessibility is experiential
- Is your online form actually usable?
- Do you get high completion rates?
- Web forms should not replicate paper forms - web is a new medium!
- Forms are the means of e-commerce and communication on the Web
- Getting it right is critical to business
Issues for People With Disabilities #1
- Might have fine-motor control problems
- Can they easily select the radio buttons?
- Not necessarily using a mouse
- Will the tabbing order make sense?
- Can they select the items in the drop-down quick-links box?
Issues for People With Disabilities #2
- Can't read small text
- Do the form fields get larger?
- Might be using a screen magnifier
- Will all the form elements be found?
Issues for People With Disabilities #3
- Can’t see the labels
- Will the reading order be correct?
- Are the labels associated with the form elements via the code?
- If using a screen reader, might not appreciate the existence of place-holding text in a form
Issues for People With Disabilities #4
- Might have a cognitive disability
- Has the form been laid out clearly?
- Are the labels clearly expressed?
- Are the required fields clearly indicated (and explained)
WCAG 1.0 Checkpoints - Forms
- 10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned
- 12.4 Associate labels explicitly with their controls
Forms Accessibility - Follow the Rules #1
- Always provide text labels for form controls
- Place form labels adjacent to their corresponding form controls (follow conventions)
- Provide markup for labels, using the
label
element
- Use the "for" attribute & place a corresponding "id" attribute in the form control
- Use a "title" attribute on a form control if the use of a
label
element is not practical
Form Rules - Label Positioning
Form Field Type |
Label Placement |
Text/Edit Field |
Top/Left of the form field |
Select Menus/Combo Boxes |
Top/Left of the form field |
Check Boxes |
Right of the check box |
Radio Button |
Right of the radio button |
Submit Button |
label is the Value attribute |
Forms Accessibility - Follow the Rules #2
- Always provide a button to submit forms
- Don't use JavaScript to automatically submit them
- Group related form elements using the
fieldset
elements
- Provide a "title" attribute or
fieldset
for each field set using the legend
element
- Group radio buttons or check-boxes in a
fieldset
element (and provide a label
for each radio button or check-box)
Forms Accessibility - Follow the Rules #3
- Set a relative font-size for form controls
- Set Textbox & Drop-down font-size to 100% via CSS
- Set Radio Button & Checkbox height and width to 1.2 ems
- Default values in text field
- No longer required and not recommended (unless scripted away on focus)
- Many screen readers users will not realise it is present
Other forms issues
- Structure forms linearly
- Users are happy to scroll vertically
- Reduces user error - reduces user frustration wit respect to error messages
- Increases success rate for form completion - good for business
- Clearly identify compulsory fields
- Place conditions & clarifications at top of form
- Don't use colour alone to indicate compulsory fields
- Follow conventions and use an asterisk ["*"]
- Use colour too for those who can see the colour
- Consider carefully whether you place the focus automatically in first element
Tip: Place the compulsory field indicator ["*"] adjacent to the label, not adjacent to the form field
Leave a space between the label and the "*" (or a screen reader may not understand - the form label may be spelt as the combination is unpronounacable)
Testing forms for accessibility #1
- Tab through the form
- Does the order make sense?
- Change the font-size in IE [view / text-size / largest]
- Did the fields (and the labels) get larger?
- View with a screen magnifier (or a simulator)
- Can all the fields be easily seen?
Testing forms for accessibility #2
- Look for "required" indicators
- Are these fields differentiated with more than colour?
- Is the "*" explained before the form starts?
- Don't assume everyone knows what it means.
- Look for "conditions" and/or "clarifications"
- Are they clear and before the form starts?
Testing forms for accessibility #3
- Are the labels correctly positioned with respect to their form elements?
- Show table borders with Firefox Developers Toolbar
- Are the labels explicitly associated?
- Show form "id" and "for" attributes with AIS Web Accessibility Toolbar in IE or the WAVE
- Have "fieldset" and "legend" been appropriately used?
- Show form
fieldset
and legend
elements with AIS Web Accessibility Toolbar in IE or the WAVE