Creating Accessible Web Forms Sandy Clark Constella Group sclark@constellagroup.com

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 Sample 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.

<fieldset></fieldset> Visual and programmatic way of grouping related inputs together. Used in conjunction with the <legend> tag to caption the grouping. 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 Explicit label Surrounds the input or select tag. <label>Enter User Name <input type=“text”/> </label> Not recommended. Explicit label Linked to an input or select tag via the tags id. <label for=“username”>Enter User Name</label> <input type=“text” id=“username” /> 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. <label accesskey=“S”><input type=“submit” /> 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 <select> when using many options The optgroup tag groups options in a select box. It requires a label attribute, the value of which is displayed as a non-selectable pseudo-heading preceding that group in the drop-down list of visual browsers. Sample

Checkboxes and Radio Buttons Consider making checkboxes bigger using styles. Group radio buttons or related checkboxes in a <fieldset> tag, and provide a <label> for each checkbox or radio button.

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 Sample Image Buttons <input type=“button”> will read the alt=“” attribute. Make sure the alt=“” attribute describes what you want to do rather than what the image is. The <Button> tag will act as a container Sample

Validate your page 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 Sample CSS makes it easy to change the look. Add extra structural markup to support presentation. (classes, <p></p>, <spans> and <divs>) Sample

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 <noscript></noscript> 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 <td></td> cell.

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/Chapter12.html http://www.shayna.com/blog