Accessibility

Discussion: Defining the Drupal 8 accessibility gate

Conforms to WCAG 2.1 and ATAG 2.0

When is this needed?

When changing the UI. Common accessibility issues and tests are listed below.

Details

The goal for Drupal core is Level AA conformance with WCAG and ATAG 2.0. Use existing UI patterns to minimize the opportunity for accessibility or usability problems. Tag issues that introduce new patterns with "needs accessibility review."

Resources

WCAG 2.0, ATAG 2.0, Drupal Accessibility Statement, and More about Drupal core conformance and UI patterns

HTML structure meets WCAG 2.1

When is this needed?

When introducing new HTML structure or semantics, such as when changing templates or theme functions.

Details

Run an automated checking tool like the WAVE Toolbar. Test before and after a patch to verify that the patch does not introduce new errors.

Resources

WAVE Toolbar and More about Automated Checking

Test color has sufficient contrast

When is this needed?

When introducing new foreground and background combinations, such as when changing CSS.

Details

The WAVE Toolbar & axe both do a great job catching many color contrast issues, but can't catch them all. You may need to use a color contrast tool like Contrast Ratio, or the Accessible Color Picker Chrome extension to check. The Tanaguru Contrast Finder can provide some alternate color combinations which are easier for everyone to see. Visual presentations should meet WCAG 2.1 Level AA contrast conformance.

Resources

Contrast Ratio and More about Contrast.

Form fields are labeled

When is this needed?

When adding forms or changing fields, such as when using Form API.

Details

Every form field needs a correctly associated label. Run a test using the WAVE Toolbar (see above) on any new or changed forms and fix any incorrect labels.

Resources

More about #title and #title_display

JavaScript is keyboard-usable

When is this needed?

When developing new JavaScript UI interactions or Ajax widgets.

Details

Test using only your keyboard (unplug your mouse). Verify that the UI can be fully operated using only a keyboard.

Resources

More about JavaScript accessibility

More about Drupal core conformance and UI patterns

The accessibility goal for Drupal core is WCAG 2.1 and ATAG 2.0 Level AA. We want to reduce barriers to ensure that sites are Perceivable, Operable, Understandable, and Robust (POUR), and provide for the use of a variety of assistive technologies. It is important to think about accessibility when developing new user interfaces and to become familiar with successful and conforming implementations.

UI Patterns.

Following existing user interface patterns already used in Drupal core will reduce the opportunity for accessibility or usability problems. New user interface patterns will likely require review by the accessibility and usability teams.

Problem Patterns.

There are known patterns in core that are highly likely to cause accessibility problems, for example modal dialogs or interactive jQuery calls. If your patch includes one of these known patterns please check with accessibility team by tagging the issue with "needs accessibility review".

Testing is very important when introducing or redeveloping a UI pattern. If you are still unsure after running through the basic testing procedures, please check with accessibility team by tagging the issue with "needs accessibility review." The earlier a new or changed pattern is checked for accessibility, the easier it can be corrected.

More about Automated Checking

Automated checkers do not guarantee accessibility and do not check all WCAG 2.1 criteria. Some criteria require human review and problems may be raised in the issue queue.

The WAVE Toolbar is a recommended checker. Other popular checkers include: axe, FAE, and its Firefox add-on.

Running the automated check before and after applying a proposed patch is important. Some parts of Drupal core cause errors or warnings in WAVE and other tools. New patches should not introduce additional errors.

More about Contrast

See http://drupal.org/node/464500 for background information and other color contrast tools.

More about #title and #title_display

In the Drupal Form API, the new #title_display property allows you to choose the proper location for a form label to be displayed. It prints the label in the chosen location or makes it invisible off-screen while still preserving its accessibility.

See the Form API documentation for #title_display.

It is not accessible to remove the label by emptying the #title property: unset($element['#title']) ... or by using CSS display: none. Both of those techniques were used in Drupal 6 and earlier when there was no built-in support for locating form labels off-screen or as tool-tips.

More about JavaScript Accessibility

Keyboard accessibility is a major concern when creating Javascript-based widgets, UI interactions, and Ajax functionality. "Keyboard only" is when you only use the keyboard to interact with the user interface. Many disabled users cannot use a mouse or other pointing device. Try using each feature of a new interface without using a mouse or trackpad. Problems with keyboard only operations will quickly identify areas to focus on.

Another kind of JavaScript accessibility problem is the visibility of content that is dynamically loaded or updated by Ajax calls. Using existing UI patterns is encouraged to avoid accessibility problems. New user interfaces of this type will likely require design and collaboration with the accessibility and usability teams. Contributors are encouraged to seek design assistance as early in the design cycle as possible by tagging any issue with "needs accessibility review."

Drupal core includes numerous examples of UI patterns that have been made accessible with JavaScript and/or ARIA markup. These include: drag-n-drop tables, vertical tabs, the password strength checker, and auto-complete fields.