Creating Accessible Web Forms

1
Creating Accessible Web Forms

• Sandy Clark
• Constella Group
• sclark_at_constellagroup.com

2
Overview

• Identifying the Problems
• The 3 prong approach to creating web forms
• HTML
• Validation
• CSS
• Special Considerations.

3
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
4
Our forms are not accessible

• Cant 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 cant use a mouse are locked out when
  the form is not navigable by keyboard alone.

5
Who needs accessible forms?

• Lots of us!

6
ColorBlind

• Need to make sure items are not denoted solely by
  color
• Donts
• Required fields are in Red
• Required fields have a blue
• Dos
• Required fields will be denoted by a (req)

7
Functionally Disabled

• Keyboard Access
• The form must be usable with only a keyboard.
• Make sure the forms tab order is reasonable.

8
Visually Impaired

• Visual Impairments
• Make sure page also works with screen magnifiers.
• Can users see the page larger or smaller?
• Sample

9
Deaf

• Unless you have audio cues in a form, there is
  nothing special
• Contact Phone numbers are an issue.

10
Blind

• Make sure the form is usable in screen readers

11
Steps to designing a web form

• Structural Markup first
• Validate and Test
• Make it look good

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

13
ltfieldsetgtlt/fieldsetgt

• Visual and programmatic way of grouping related
  inputs together.
• Used in conjunction with the ltlegendgt tag to
  caption the grouping.
• Fieldset Example

14
Captioning Form Fields

• Two ways to identify a form field
• The label tag
• The title attribute

15
Label Tag

• Preferred way to render text.
• Implicit label
• Surrounds the input or select tag.
• ltlabelgtEnter User Name ltinput
  typetext/gtlt/labelgt
• Not recommended.
• Explicit label
• Linked to an input or select tag via the tags id.
• ltlabel forusernamegtEnter User
  Namelt/labelgtltinput typetext idusername /gt
• The id attribute is case sensitive and cannot
  contain underscores, hyphens or spaces.

16
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

17
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

18
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
• Dont require extra coding
• Not readable in all screen readers
• Labels - Sample
• Requires styling to hide them.
• Readable in all screen readers

19
Keyboard Access

• Keyboard access is important for
• Blind users
• Functionally disabled users.
• Make sure everything on your form can be used
  through the keyboard.

20
Access Keys

• The WAI recommends using an access key attribute
  for important links.
• ltlabel accesskeySgtltinput typesubmit /gt
• This works for most people with functional
  disabilities but not blind people.

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

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

23
Text Input and TextArea

• Not much is needed to make these accessible.
• Place labels prior to the input or text area tag.

24
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 dont need to do it. (even though some
  validation programs mark it as a problem).

25
Select

• Use optgroup for ltselectgt 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

26
Checkboxes and Radio Buttons

• Consider making checkboxes bigger using styles.
• Group radio buttons or related checkboxes in a
  ltfieldsetgt tag, and provide a ltlabelgt for each
  checkbox or radio button.

27
Buttons

• Submit Buttons
• Submit Buttons 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

28
Buttons

• Reset Buttons
• Dont use Reset. Most people will hit it
  accidently and clear out their form.
• If you must have it, dont 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.

29
Buttons

• Image Buttons
• Image Buttons ltinput typebuttongt will read the
  alt attribute.
• Make sure the alt attribute describes what you
  want to do rather than what the image is.
• The ltButtongt tag will act as a container
• Sample

30
Validate your page

1. Validate with an HTML validator
2. Use accessibility validation tools such as Bobby
3. Try using a keyboard through the form.
4. Turn off Javascript and make sure page still
   functions.
5. Try it with assistive technology.

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

32
CSS for Styling

• CSS makes it easy to change the look.
• Add extra structural markup to support
  presentation.
• (classes, ltpgtlt/pgt, ltspansgt and ltdivsgt)
• Sample

33
Special Considerations

• Phone Numbers
• Error Checking
• Javascript
• Tables

34
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

35
Error Checking

• Provide error checking that doesnt just alert
  the user to a mistake, but tries to correct it.
• Offer alternatives based on spelling errors
  (helpful for dyslexics)
• Consider Googles search engine which provides a
  new search based on correct spelling

36
Error Alerts

• Must use redundant methods
• While you can use client side validation and
  alerts, you must always use server side.
• Dont use color only to alert errors.
• IE, fields marked with red asterisks to denote an
  error.

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

38
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 ltnoscriptgtlt/noscriptgt
  block so only browsers which dont render
  Javascript see it.
• Always provide a submit button.
• Dont rely on Javascript to submit your page.

39
Javascript and Keyboard

• Avoid only using onClick() events. Keyboard only
  users wont trigger this.
• Use onfocus() as well.

40
Tables and Forms

• Dont use tables to layout forms.
• If you must put a form in a table, make sure that
  a form is completely contained in one lttdgtlt/tdgt
  cell.

41
QA
42
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/Chap
  ter12.html
• http//www.shayna.com/blog