skip to content W3C SVG

Inconsistency

Introduction

An important principle of inclusive design is consistency. Inconsistent interfaces present unnecessary burdens of comprehension to users – especially those who consume HTML semantics, such as screen reader users. In particular, inconsistent navigation schema and page structure can make the user feel disoriented and unsure.

Keyboard users

People who do not use a mouse – perhaps because they have a dexterity (motor) or vision disability – use a keyboard to access websites. In addition to being able to interact with controls on a page, a keyboard user must also be able to find items and follow both programmatic and visual focus. Sometimes the visual indication of focus may not exist or may not match what has programmatic focus, and this has huge implications for accessibility.

When keyboard users tab through focusable items (buttons, links, form elements, custom controls, etc), the order needs to make sense, so they don’t get confused. If a keyboard user – whether sighted or blind – uses the tab key to go through all of the focusable elements, the browser will start with the focusable elements at the top and proceed linearly through all focusable elements until reaching the bottom. The browser ignores all visual formatting and pays attention only to the underlying order that elements appear in the DOM.

WCAG criteria

Scope of the issue

This issue is most severe within the child forms, where navigation between each focusable item is inconsistent due to positive tabindex values. Positive tabindex values have the potential to cause significant problems for keyboard users:

  • A positive tabindex causes a discrepancy between the tab order and the reading order, leading to confusion. As the user starts tabbing through a form, the tab order can be counterintuitive and at odds with what the user expects, especially if they are sighted.
  • A positive tabindex remove items from their natural tab order, and instead places them first in the tab order. Browsers take any element with a positive tabindex value and promote it to the front of the pack for tabbing through the page, rather than proceeding linearly. Only after a browser gets through all elements with a tabindex does it then fall back to source order.

For example, the tab order on the “Alerts Reporting” form under Alerts is as follows (pictured):

C3 "Alerts Reporting" form

  1. “Trust #” input
  2. “Type Code” dropdown
  3. “Responsible” dropdown
  4. “Setup Date Range” input #1
  5. “Setup Date Range” input #2
  6. “Next Occurrence Range” input #1
  7. “Next Occurrence Range” input #2
  8. “Ending Date Range” input #1
  9. “Ending Date Range” input #2
  10. “Print To” dropdown
  11. “Submit” button
  12. “Main Menu” link
  13. “Log Out” link
  14. “Setup Date Range” calendar icon link #1
  15. “Setup Date Range” calendar icon link #2
  16. “Next Occurrence Range” calendar icon link #1
  17. “Next Occurrence Range” calendar icon link #2
  18. “Ending Date Range” calendar icon link #1
  19. “Ending Date Range” calendar icon link #2
  20. “Back” button

Note that the “Search” button next to the “Trust #” input never receives keyboard focus, which is another separate accessibility issue. (See Buttons for more info.)

Fixing the issue

It is recommended that positive tabindex values on the focusable items within the forms are removed, as this leads to inconsistent and unpredictable behavior for keyboard users. When these are removed, the browser will fall back to source order.