Accessibility (a11y) Rules - 5

Video and audio

• Four main types of alternative media types: captions, transcripts, audio descriptions, and sign language interpretation should be included with audio and media files. These alternatives should be based on:

  • The type of media supporting—audio-only, video-only, or video with audio (multimedia) formats
  • Whether the media is live or prerecorded
  • The version and level of WCAG compliance targeting
  • Any additional media-related user needs

Forms

Fields

• Use standard HTML elements and patterns whenever possible, rather than creating custom components with ARIA.

Not Recommended — Custom HTML with ARIA

<div role="form" id="sundae-order-form">
  //form content
</div>

Recommended — Standard HTML

<form id="sundae-order-form">
  //form content
</form>

• Should add HTML autocomplete attributes to the fields.

• Form fields should not produce contextual changes when they receive focus or user input unless the user has been warned about the behaviour before using the component (e.g. a form should not be automatically submitted when a field receives focus or once a user adds content to the field.)

Labels

• Ensure every form field has a clear, accurate, and programmatically associated label.

Descriptions

• Field descriptions are not required for accessibility if the labels or form instructions are descriptive enough.

• Add field descriptions when more information is necessary to prevent user errors. For example, include input requirements like password length or specific date formats (e.g., MM-DD-YYYY).

• Use the aria-describedby attribute to link field descriptions to form elements. This ensures screen readers read both the label and the description, improving clarity for users.

Errors

• When a form error occurs, make the error immediately known. Clearly identify the field where the error happened and provide a concise, descriptive text explaining the error to the user.

• There are different methods for displaying error messages, such as:

  • A modal, inline near where the error occurred
  • A collection of errors grouped in one larger message at the top of the page

• Be sure to pay attention to the keyboard focus and ARIA live region options when announcing errors.

• Whenever possible, offer the user a detailed suggestion on how to fix the error. There are two attributes available to notify users of errors.

  • You can use the HTML requiredattribute. The browser will supply a generic error message based on the filed validation parameters.
  • Or you can use the aria-required attribute to share a customized error message to ATs. Only ATs will receive the message unless you add additional code to make the message visible to all users.

Additional success criteria

Target Size (Minimum)

Consistent Help

Accessible Authentication

Redundant Entry