Presentation - CF Conf Central by pengxuebo


									Creating Accessible Web Forms

          Sandy Clark
         Constella Group

• Identifying the Problems
• The 3 prong approach to creating web
• Special Considerations.
                The problem

• We tend to build forms
 as if we are laying them
 out on a sheet of
  üVisually appealing
  üLumped together
  üRely on color to visually
   Our forms are not accessible

• Can’t navigate easily through a speech
• 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!

• Need to make sure items are not
 denoted solely by color
   • “Required fields are in Red”
   • “Required fields have a blue *”
   • Required fields will be denoted by a (req)
       Functionally Disabled

• Keyboard Access
  üThe form must be usable with only a
  üMake sure the form’s tab order is
          Visually Impaired

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

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

• Make sure the form is usable in screen
    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 <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
   ü Surrounds the input or select tag.
          <label>Enter User Name
                 <input type=“text”/>
   ü 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

• 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
  ü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
   ü 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.

• 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
       • 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
• 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).

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

• 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”

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

• Image Buttons
  ü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
•   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
  ü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
    • (classes, <p></p>, <spans> and <divs>)
        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.

• 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.
        For Further Knowledge

• University of Minnesota Web Design
  References (accessibility)
• Building Accessible Web Sites – Joe Clark

To top