Level A Operable WCAG 2.4.3

What This Criterion Requires

WCAG 2.4.3 requires that if a web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability. This means that when a user tabs through a page, the focus order should follow a logical sequence that matches the visual layout and the intended reading or interaction flow. Focus order issues most commonly arise from misuse of the tabindex attribute with positive values, which overrides the natural DOM order. CSS layout changes that create a visual order different from the DOM order also cause focus order problems. Dynamic content such as modals, popups, and expanding sections must manage focus appropriately -- when a modal opens, focus should move into the modal, and when it closes, focus should return to the triggering element. The criterion does not require a single specific focus order, but the order must preserve both meaning (users can understand the content) and operability (users can complete tasks) when navigating sequentially.

Why It Matters

Keyboard users rely on a predictable, logical focus order to navigate and interact with web content. When the Tab key moves focus in an unexpected order -- jumping from the top of the page to the footer, then back to the middle -- users become disoriented and may miss important content or controls. Users with motor disabilities who use adaptive switches or keyboard alternatives are especially impacted because reorienting after unexpected focus jumps requires significant effort. Screen reader users, who primarily navigate by keyboard, depend on focus order to understand the relationship between elements and to build a mental model of the page layout. An illogical focus order breaks this mental model and makes it extremely difficult to understand the page structure. When focus does not move into modal dialogs upon opening, keyboard users cannot interact with the dialog content. When focus does not return to the trigger element after a dialog closes, users lose their place on the page and must start navigating from an unexpected location.

Common Failures and How to Fix Them

Positive tabindex values creating illogical tab order

Positive tabindex values are assigned to elements, overriding the natural DOM-based tab order and creating an unpredictable focus sequence. This is almost always a mistake and is considered an anti-pattern.

Inaccessible
<form>
  <label for="email">Email</label>
  <input type="email" id="email" tabindex="2">
  <label for="name">Name</label>
  <input type="text" id="name" tabindex="1">
  <label for="phone">Phone</label>
  <input type="tel" id="phone" tabindex="3">
  <button type="submit" tabindex="4">Submit</button>
</form>
<!-- Tab order: Name, Email, Phone, Submit (does not match visual order) -->
Accessible
<form>
  <label for="name">Name</label>
  <input type="text" id="name">
  <label for="email">Email</label>
  <input type="email" id="email">
  <label for="phone">Phone</label>
  <input type="tel" id="phone">
  <button type="submit">Submit</button>
</form>
<!-- Tab order follows DOM order: Name, Email, Phone, Submit -->

Modal dialog that does not receive focus when opened

A modal dialog is displayed on screen but focus remains behind the dialog on the main page. Keyboard users cannot interact with the dialog content and may not even realize the dialog has appeared.

Inaccessible
<button onclick="document.getElementById('modal').style.display='block'">Open Settings</button>
<div id="modal" style="display:none;" class="modal-overlay">
  <div class="modal-content">
    <h2>Settings</h2>
    <label><input type="checkbox"> Enable notifications</label>
    <button onclick="document.getElementById('modal').style.display='none'">Close</button>
  </div>
</div>
<!-- Focus stays on the trigger button after modal opens -->
Accessible
<button id="settings-btn" onclick="openModal()">Open Settings</button>
<dialog id="modal" aria-labelledby="modal-heading">
  <h2 id="modal-heading">Settings</h2>
  <label><input type="checkbox"> Enable notifications</label>
  <button onclick="closeModal()">Close</button>
</dialog>
<script>
  function openModal() {
    const modal = document.getElementById('modal');
    modal.showModal(); // Native dialog manages focus automatically
  }
  function closeModal() {
    const modal = document.getElementById('modal');
    modal.close();
    document.getElementById('settings-btn').focus(); // Return focus to trigger
  }
</script>

How to Test

  1. Tab through the entire page from beginning to end and verify that the focus order follows a logical sequence that matches the visual layout and reading direction.
  2. Search the HTML source for any tabindex attributes with positive values (tabindex='1' or higher) and verify they do not disrupt the logical tab order.
  3. Open all dialogs, menus, and expandable sections and verify that focus moves into them when they appear and returns to the trigger element when they close.
  4. Test focus order after dynamic content changes (AJAX loads, expanded sections, tab panels) to ensure focus is managed appropriately and users are not left in an unexpected position.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

Further Reading

Related WCAG Criteria