Creating Accessible Web Forms Sandy Clark Constella Group [email protected] Overview • Identifying the Problems • The 3 prong approach to creating web forms HTML Validation • CSS • Special Considerations.
Download ReportTranscript Creating Accessible Web Forms Sandy Clark Constella Group [email protected] Overview • Identifying the Problems • The 3 prong approach to creating web forms HTML Validation • CSS • Special Considerations.
Creating Accessible Web Forms
Sandy Clark Constella Group [email protected]
Overview
• • • • Identifying the Problems The 3 prong approach to creating web forms HTML Validation CSS Special Considerations.
The problem
•
We tend to build forms as if we are laying them out on a sheet of paper.
Visually appealing Lumped together Rely on color to visually separate conferenceapp/badconferenceapp.html
Our forms are not accessible
• • •
Can’t navigate easily through a speech browser Color blind people have a hard time separating out required fields if they are rendered by color.
People who can’t use a mouse are locked out when the form is not navigable by keyboard alone.
Who needs accessible forms?
Lots of us!
ColorBlind
•
Need to make sure items are not denoted solely by color
Don’ts
•
“ Required fields are in Red ”
•
“ Required fields have a blue *”
Do’s
•
Required fields will be denoted by a ( req )
Functionally Disabled
• Keyboard Access The form must be usable with only a keyboard.
Make sure the form’s tab order is reasonable.
Visually Impaired
•
Visual Impairments
Make sure page also works with screen magnifiers.
Can users see the page larger or smaller?
Sample
Deaf
• Unless you have audio cues in a form, there is nothing special • Contact Phone numbers are an issue.
Blind
• Make sure the form is usable in screen readers
Steps to designing a web form
• • • Structural Markup first Validate and Test Make it look good
Structural Markup
• •
Rely on XHTML for structure.
Separating content (form) from presentation helps accessibility.
There are HTML tags specifically designed for accessibility.
Groups related items together Associates captions and form inputs.
• •
Visual and programmatic way of grouping related inputs together.
Used in conjunction with the
•
Fieldset Example
Captioning Form Fields
•
Two ways to identify a form field
The label tag
The title attribute
Label Tag
Preferred way to render text.
Implicit label
Surrounds the input or select tag.
Not recommended.
Explicit label
Linked to an input or select tag via the tags id.
username”>Enter User Name •
The id attribute is case sensitive and cannot contain underscores, hyphens or spaces.
Labels (cont)
Do not use a graphic image in a label tag block. A screen reader will not read the alt text as the label.
• Labels
are useful in visual browsers.
Focus goes on the field when the label is clicked.
•
Gives a larger hit area to a form field.
•
Helps users with fine motor control difficulties.
Visual Label Placement
Text boxes and textareas : • Labels should precede the input Checkboxes and Radio buttons • Labels should come after the input Sample
Titles
• • • •
Most html tags offer the “title” attribute.
Some visual browsers take titles as a popup.
Not all screen readers read titles.
Some screen readers will use titles if a label is not available.
Better to use labels and hide them for a visual browser using CSS.
Sample
Grids and Accessibility
• When creating a grid of input boxes, how do we make them accessible and still easy to use for our regular users?
Titles • Sample Don’t require extra coding • Not readable in all screen readers Labels • • Sample Requires styling to hide them.
Readable in all screen readers
Keyboard Access
• • Keyboard access is important for Blind users Functionally disabled users.
Make sure everything on your form can be used through the keyboard.
Access Keys
•
The WAI recommends using an access key attribute for important links.
This works for most people with functional disabilities but not blind people.
Access Keys Problems
• • •
Many screen readers rely on use of alt key combinations for their users.
Unfortunately an access key will take precedence over the operating system or browser/screen reader software.
There are keys to avoid because of Brower/Operating Systems
Keys available for use, include • C,I,J,K,L,O,P,R,S,X,Y,Z,0 9,’,-,=,(,),[,],\,/ • Many of these keys will conflict with screen readers.
At this time, its probably best to avoid access keys since they will create more confusion.
TabIndex
• •
Sets up a form for keyboard use by providing an order for tabbing through a form.
Add a tabindex to
Search boxes Long Forms where visitors will fill out most or all fields • Set a tab index to the first item where an action is possible.
• • Set a tab index to the submit button.
Test your form by tabbing through it and make sure the ordering is correct. Add tabindex where necessary.
Text Input and TextArea
• •
Not much is needed to make these accessible.
Place labels prior to the input or text area tag.
Prewritten Text
•
If you have prewritten text in a field, you must provide some way to delete the text when using the field.
WAI 10.4 (Priority 3) states that you should use default, place-holding characters in edit boxes and text areas.
Most modern screen readers handle this correctly and you don’t need to do it. (even though some validation programs mark it as a problem).
Select
• • •
Use optgroup for
Sample
Checkboxes and Radio Buttons
• •
Consider making checkboxes bigger using styles. Group radio buttons or related checkboxes in a
Buttons
•
Submit Buttons
Submit Button’s value attribute is easily read by screen readers/speech browsers.
Make sure the value of the button indicates your intention.
• • • “Save” instead of “Go” “Submit” “Save and Continue”
Buttons
•
Reset Buttons
Don’t use Reset. Most people will hit it accidently and clear out their form.
If you must have it, don’t use any keyboard control including taboindex or accesskey.
• Might want to consider giving a tabindex to the items directly before and after the reset so that a tab will skip the reset button.
Buttons
•
Image Buttons
Image Buttons will read the alt=“” attribute.
• Make sure the alt=“” attribute describes what you want to do rather than what the image is.
The
Validate your page
1.
2.
3.
4.
5.
Validate with an HTML validator Use accessibility validation tools such as Bobby Try using a keyboard through the form.
Turn off Javascript and make sure page still functions.
Try it with assistive technology.
CSS for Styling
•
Now that our form is functional we can concentrate on making it look nice.
Line up fields and captions without using tables
Hide labels when necessary
Style Fieldsets
Make links and buttons look similar.
CSS for Styling
CSS makes it easy to change the look.
Add extra structural markup to support presentation.
• (classes,
,Special Considerations
• • • • Phone Numbers Error Checking Javascript Tables
Consider Phone Numbers
• •
If a user is deaf, then their phone number might not be voice, it might by TTY.
A TTY is a special device that lets people who are deaf, hard of hearing, or speech-impaired use the telephone to communicate, by allowing them to type messages back and forth to one another instead of talking and listening. A TTY is required at both ends of the conversation in order to communicate.
Besides a phone number consider type
Voice Fax TTY
Error Checking
•
Provide error checking that doesn’t just alert the user to a mistake, but tries to correct it.
Offer alternatives based on spelling errors (helpful for dyslexics) • Consider Google’s search engine which provides a new search based on correct spelling
Error Alerts
• •
Must use redundant methods
While you can use client side validation and alerts, you must always use server side.
Don’t use color only to alert errors.
IE, fields marked with red asterisks to denote an error.
Javascript
• •
Your page must be able to function correctly without Javascript.
Data Validation can be done client side and must also be done server side.
Any Javascript which changes the page will not work in a screen reader.
Javascript (cont)
Avoid items like pull down menus which trigger when you make a selection.
• Provide a valid HTML button next to this which will trigger the event server side when changed. •
If you wish, enclose it in a block so only browsers which don’t render Javascript see it.
Always provide a submit button.
• Don’t rely on Javascript to submit your page.
Javascript and Keyboard
•
Avoid only using onClick() events. Keyboard only users won’t trigger this.
Use onfocus() as well.
Tables and Forms
• •
Don’t use tables to layout forms.
If you must put a form in a table, make sure that a form is completely contained in one
QA
For Further Knowledge
• • • University of Minnesota Web Design References (accessibility) http://www.d.umn.edu/itss/support/Training/Online/ webdesign/accessibility.html
Building Accessible Web Sites – Joe Clark http://joeclark.org/book/sashay/serialization/Chapt er12.html
http://www.shayna.com/blog