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 will read the alt=“” attribute.
• Make sure the alt=“” attribute describes what you want to do rather than what the image is.
The