Key Accessibility Best Practices for Design

  • Include alternative text for non-text content such as pictures or images.
  • Utilize meaningful document structure such as headings and lists.
  • Mark up data tables with headings and associate cell content with the headers.
  • Ensure that all form elements have labels and that the labels are associated with the correct formelement.
  • Use concise, meaningful text for links so that links make sense out of context.
  • Add captions to all multimedia elements; if not possible, provide a text transcript.
  • When links to documents such as PDFs or MS Word Docs are provided, make sure those documentsare accessible as well.
  • If a scanned document is used, be sure it is readable text and not just an image of text. OpticalCharacter Recognition (OCR) software can often convert images of text to readable text.
  • Allow users to skip repetitive elements on the page.
  • Do not rely on color alone to convey information.
  • Make sure content is clearly written and easy to read.
  • Care should be taken early in the website development process if using Java script; Java script cancreate accessibility challenges.

    Key Considerations for Accessible Web Form Application Process

    Typical composition tools are not adequate to ensure accessibility. A grammar checker will tell you if the words should be used together, but will never tell you whether your meaning is clear. Human judgment is critical.

Test or evaluate your website accessibility

You may use one of the following programs to evaluate accessibility issues in a particular website program and design:

  • WAVE Web Accessibility Evaluation Tool ( Freely available tool to support testing accessibility from WebAIM.
  • WAVE Toolbar ( Because no data is sent to WAVE server, can be used to evaluate content that is password protected, dynamically generated or scripted, or on an intranet.

Other Tools: W3C Web Accessibility Evaluation Tools List (

Evaluate form accessibility and usability

  • Check to make sure all necessary instructions and cues are provided.
  • Check that form controls are associated with a label element.
  • Check that groups of checkboxes and radio buttons are associated using field set and leg end.
  • Check that the form can be completed and submitted with a keyboard only.
  • When tabbing through the form, make sure the navigation order is logical and consistent with thevisual order of the form.
  • Check that error recovery is functional after form validation.
  • Alert the user to the presence of the error in an obvious and accessible manner.
  • Allow the user to easily access the form controls that need to be modified.
  • If certain form fields are required, the field should be labeled accordingly, and configured to alertthe screen reader.
  • After submitting the form, user will need to be alerted to submission confirmation and anysubmission errors.
  • Allow resubmission and revalidation of the form (
  • The use of CAPTHCA is inaccessible and should not be used to validate submissions.
  • Use tables for tabular data, not for layout because tables add additional verbosity to screen readerusers.
  • Use of ARIA roles and landmarks to enhance the ability of screen reader users to navigate andinteract with content.
  • Make dynamic content accessible (

    Test with a Screen Reader

    Screen reader users navigate using functions that are more sophisticated than just reading the page. Testing with a screen reader can be useful to get a sense for how navigation, forms, and dynamic content are working.