Best Practice 1: Section Heading

Overview

Section headings are important as it describes the content that follows; much like a chapter of a book or a news headline. Developers and designers should implement the proper section headings in their web project because these help people easily jump to the content they want to see. Assistive technologies like screen readers also use it to jump from one section to another. It also helps people with learning disabilities understand the overall organization of the page content.

Implementing it properly helps screen readers to easily navigate sections as well as identifying the purpose or content of that section. Section headings must use appropriate heading tags since screen readers and assistive technologies rely on heading tags (<h1> to <h6>) to identify them. Text that is merely large, bold, or emphasized is not interpreted as a heading unless the <h1> to <h6>markup is used.

Examples

  • A menu contains different sections for different courses. Each section has a heading: Appetizers, Salad, Soup, Entree, Dessert.
  • A web application contains a settings page that is divided into groups of related settings. Each section contains a heading describing the class of settings.

Notes

  • Use headings only when they represent the following content. A page should only have one <h1>.
  • It is important to not skip heading tags like <h3> to <h6> just because <h6> is visually smaller than <h4>, since people who use screen readers might get confused on the sudden jump. It is better to use the next heading and apply CSS styles to it to achieve the same visual style.
  • To highlight or emphasize text that is not a heading, use styles—not heading tags—to achieve visual results.
  • Using tools like WAVE or AXE will help you check the hierarchy of your section headings.

Best Practice 2: Error Identification

Overview

Implementing error identification on web forms helps users keep track of an error that has occurred upon form submission. Visual cues are such as highlighted fields, colored borders, messages with a different color that indicates an error message, and applying focus on the particular field could help the user easily identify things that they have missed. Screen reader users, for example, will not know there was an error until they encounter one of the indicators. Without these cues, users might think that your website does not work and abandon filling up the form. Per the definition in WCAG 2.0, an “input error” is information provided by the user that is not accepted. This includes:

  • Information that is required by the web page but omitted by the user, or
  • Information that is provided by the user but that falls outside the required data format or allowed values.

Here are some examples of the scenarios mentioned above:

  • The user fails to enter the proper abbreviation in to state, province, region, etc. field;
  • The user enters a state abbreviation that is not a valid state;
  • The user enters a non existent zip or postal code;
  • The user enters a birth date 2 years in the future;
  • The user enters alphabetic characters or parentheses into their phone number field that only accepts numbers;
  • The user enters a bid that is below the previous bid or the minimum bid increment.

Examples

Identifying errors in a form submission

An airline Web site offers a special promotion on discounted flights. The user is asked to complete a simple form that asks for personal information such as name, address, phone number, seating preference and e-mail address. If any of the fields of the form are either not completed or completed incorrectly, an alert is displayed notifying the user which field or fields were missing or incorrect.

Providing multiple cues

The user fails to fill in two fields on the form. In addition to describing the error and providing a unique character to make it easy to search for the fields, the fields are highlighted in yellow to make it easier to visually search for them as well.

Notes

  • Providing information about input errors in text allows users who are blind or colorblind to perceive the fact that an error occurred. (e.g using a legend will help a user understand that an asterisk(*) beside the field label is required.) – This may help people with cognitive, language, and learning disabilities who have difficulty understanding the meaning represented by icons and other visual cues.
  • ARIA-INVALID can be programmatically enabled to indicate errors on the field upon form submission; this will help assistive technologies such as JAWS, NVDA, and Safari Voiceover to notify errors to the user.

Have more questions about accessibility?

get in touch