WCAG 2.4.3: Focus Order

What This Rule Means

WCAG 2.4.3 Focus Order is a Level A success criterion under the Operable principle. It states: "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."

In practical terms, this means that when a user presses the Tab key to move through interactive elements on a page — links, buttons, form fields, custom widgets, and any other focusable component — the sequence in which those elements receive focus must make logical sense. Users should not find themselves jumping unexpectedly from the middle of a form to a footer link, then back to a modal button, then off to a navigation menu item.

The criterion applies to sequential keyboard navigation, which is the primary way keyboard-only users and screen reader users traverse a page. The DOM order is the default source of focus order in browsers: elements appear in the tab sequence in the order they appear in the Document Object Model (DOM), unless CSS or JavaScript deliberately alters that order. Problems arise when the visual layout diverges from the DOM order (for example, through CSS Flexbox or Grid reordering), or when tabindex values impose an unnatural sequence.

What counts as a pass: The focus order must be logical and meaningful — not necessarily identical to the visual reading order, but coherent enough that users can understand and operate the page. A modal dialog that moves focus to itself when opened, keeps focus trapped inside while it is open, and returns focus to the triggering element when closed passes this criterion. A multi-step form where Tab progresses through each field in the order a user would fill them in (top to bottom, left to right in left-to-right languages) also passes.

What counts as a fail: Focus jumping from a login form's "Username" field to a completely unrelated promotional banner before reaching the "Password" field fails. A single-page application that opens a dialog but leaves focus on the background page fails. Using positive integer tabindex values (e.g., tabindex='2', tabindex='5') that force an illogical tab sequence across the page fails.

Official exceptions: WCAG explicitly notes that the focus order does not need to match the visual reading order as long as it preserves meaning and operability. There is also an allowance for cases where navigation sequences do not affect meaning or operation — for example, a page with only one focusable element has no sequence to evaluate. Additionally, when there are multiple valid orderings that all preserve meaning, any of those orderings is acceptable.

Key HTML and JavaScript mechanisms that affect focus order include: the natural DOM order of interactive elements, the tabindex attribute (particularly positive integer values), CSS properties that reorder visual layout without changing the DOM (such as order in Flexbox/Grid, position: absolute, and float), JavaScript-driven focus management (calling .focus() on elements), and ARIA dialog patterns that require explicit focus management.

Why It Matters

Focus order is not a minor technical detail — it is the navigational backbone of the web for a significant portion of users. Several distinct disability groups depend on a logical focus sequence to use digital products effectively.

Motor-impaired users who cannot use a mouse rely entirely on the keyboard (or keyboard-equivalent devices such as sip-and-puff switches, head pointers, or eye-tracking systems) to navigate. For these users, a scrambled focus order is not merely inconvenient — it can make a page completely unusable. If the Tab key takes a user to the wrong part of the page, they may have no efficient way to reach the control they need, and they cannot simply move their hand to click elsewhere.

Blind users and low-vision users who use screen readers such as NVDA, JAWS, or VoiceOver hear elements announced as focus lands on them. A logical focus order means the audio stream they receive reflects the intended flow of the interface. When focus jumps erratically, users lose their mental model of where they are on the page. According to the World Health Organization, approximately 2.2 billion people worldwide have some form of vision impairment, and for many of those who use screen readers, focus order is their primary way of experiencing page structure.

Cognitive disability users also benefit from predictable focus sequences. An unexpected focus jump mid-form can cause confusion, force users to restart workflows, or lead them to miss required fields. Users with attention difficulties or short-term memory challenges need consistent, predictable navigation to build confidence in using a site.

A concrete real-world scenario: Imagine a Turkish e-commerce checkout page. The visual design uses CSS Grid to place the order summary on the left and the payment form on the right. However, in the DOM, the payment form comes first and the order summary comes second. The visual layout looks correct for sighted mouse users, but a keyboard user pressing Tab will land in the payment form fields before they have had a chance to review the order summary. They might unknowingly confirm a wrong order. Worse, if a "Confirm Purchase" button receives focus before an "Apply Coupon" field due to positive tabindex mismanagement, a user could accidentally submit a purchase they intended to discount. This is a direct, real financial consequence of a broken focus order.

Beyond accessibility, a logical focus order improves the experience for power users who prefer keyboard navigation for speed. It also indirectly supports SEO: a well-structured DOM that produces a natural focus order tends to reflect meaningful semantic markup, which search engines use to understand content hierarchy and importance.

Related Axe-core Rules

WCAG 2.4.3 requires manual testing for definitive evaluation. Automated tools like axe-core cannot algorithmically determine whether a particular focus sequence "preserves meaning and operability" — that judgment requires a human who understands the page's purpose and content relationships. However, axe-core and related tools can flag certain patterns that are strong indicators of focus order problems:

• tabindex (positive values) — heuristic flag: Some linting and auditing tools warn when elements carry positive integer tabindex values (any value greater than 0). Positive tabindex values override the natural DOM order and place those elements at the front of the tab sequence, which almost always creates an illogical and unpredictable focus order. While axe-core's core ruleset does not include a dedicated "focus-order" automated rule (because the logical correctness of the sequence cannot be computed), tools like axe DevTools Pro and manual audits specifically check for positive tabindex usage as a proxy indicator.
• scrollable-region-focusable: Axe-core includes a rule that flags scrollable regions which are not keyboard-focusable. While not directly a focus-order rule, a scrollable region that cannot receive focus breaks the overall navigational sequence, causing keyboard users to skip over content they need to interact with.
• Manual inspection for CSS-reordered content: Automated tools cannot detect when CSS Flexbox order or Grid placement creates a mismatch between visual order and DOM order. A human tester must visually compare the on-screen layout with the focus sequence observed during keyboard navigation. This is the most common source of 2.4.3 failures in modern responsive designs and is entirely invisible to automated scanners.
• Manual inspection for JavaScript focus management in dynamic content: Single-page applications, infinite scroll implementations, modals, and fly-out menus all require JavaScript to move focus appropriately as content changes. Automated tools run a static snapshot of the DOM and cannot simulate the sequence of user interactions needed to trigger these focus management scenarios. Only manual keyboard testing can verify that focus moves to a newly opened modal, returns to the correct trigger on close, and does not strand the user in an inaccessible background layer.

How to Test

1. Automated scan as a starting point: Run axe DevTools (browser extension) or Google Lighthouse on the page. Look for any warnings about positive tabindex values and flagged scrollable regions. Note that a clean automated result does not mean 2.4.3 is satisfied — manual testing is always required. Record any issues flagged for further investigation.
2. Disconnect your mouse and navigate with Tab only: Starting from the browser address bar or the top of the page, press Tab repeatedly to move through every focusable element. Observe the sequence carefully. Ask yourself: does the focus move in an order that matches the logical reading and interaction flow of the page? Does focus ever jump to an unexpected area? Does it ever become trapped (unable to move forward or backward) except within an intentional dialog?
3. Test dynamic components: Activate any modals, dialogs, dropdown menus, accordions, tab panels, date pickers, or other interactive widgets using the keyboard. Verify that focus moves into the newly revealed content immediately upon activation. After closing a dialog, confirm that focus returns to the element that triggered the dialog — not to the top of the page or some arbitrary location.
4. Test with NVDA + Firefox: Open NVDA, launch Firefox, and navigate to the page. Use Tab to move through interactive elements and listen to the announcements. Verify that the announced sequence makes sense contextually. Use NVDA's Browse Mode (arrow keys) to read through static content and confirm the reading order aligns with the focus order for interactive elements within that content.
5. Test with VoiceOver + Safari (macOS/iOS): Enable VoiceOver and use Tab (desktop) or swipe gestures (iOS) to move through focusable elements. Confirm focus sequence is logical. On iOS, test that modals and overlays trap focus correctly and return focus on dismissal.
6. Test with JAWS + Chrome: Use JAWS's Tab navigation and confirm the announced focus sequence is coherent. Use JAWS's virtual cursor to cross-reference the reading order with the interactive focus order and identify any discrepancies.
7. Inspect the DOM vs. visual layout: Open browser DevTools and examine the DOM structure. Compare the order of interactive elements in the DOM with their visual position on screen. If CSS properties like order, position: absolute, or float are creating significant differences, manually trace the tab sequence to determine if meaning or operability is affected.
8. Check tabindex values in the DOM: In the browser console, run document.querySelectorAll('[tabindex]') to list all elements with explicit tabindex attributes. Investigate any element with a positive integer value and assess whether its placement in the modified tab order is logical.

How to Fix

Positive tabindex values creating illogical order — Incorrect

<!-- Positive tabindex values force an unnatural tab sequence -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab order: Full Name → Phone → Email → Submit
     Visual/logical order: Email → Full Name → Phone → Submit
     This mismatch breaks focus order. -->

Positive tabindex values creating illogical order — Correct

<!-- Remove all positive tabindex values; rely on DOM order.
     Rearrange DOM to match the logical sequence. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab order now follows DOM order: Email → Full Name → Phone → Submit
     Matches logical and visual order. No tabindex needed. -->

CSS visual reordering mismatching DOM order — Incorrect

<!-- DOM has sidebar first, main content second.
     CSS uses flexbox order to visually flip them.
     Keyboard users tab through sidebar links before main content links,
     which does not match what a sighted user sees first. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Visually shown on the right */
  .main    { order: 1; } /* Visually shown on the left */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Focus order: About → Contact → Read Article
     Visual order: Read Article → About → Contact
     Mismatch breaks 2.4.3 -->

CSS visual reordering mismatching DOM order — Correct

<!-- Fix: reorder the DOM to match the intended visual and logical order.
     Remove the CSS 'order' overrides that caused the mismatch. -->
<style>
  .layout { display: flex; }
  /* No 'order' overrides — DOM order determines both visual and tab order */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM order, visual order, and focus order now all match. -->

Modal dialog not managing focus — Incorrect

<!-- Button opens a modal, but focus stays on the background page.
     Keyboard users cannot interact with the dialog. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- When dialog opens, focus remains on #open-modal in the background.
     Tab continues to background page elements, not dialog elements. -->

Modal dialog not managing focus — Correct

<!-- Focus is moved into the dialog on open and returned to trigger on close.
     role='dialog' and aria-modal='true' inform screen readers of the context. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Move focus to first focusable element in dialog
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Return focus to the element that triggered the dialog
    openBtn.focus();
  });
</script>
<!-- Focus order is now logical: trigger → dialog contents → back to trigger. -->

Common Mistakes

• Using positive integer tabindex values (e.g., tabindex='1', tabindex='5') to "control" focus order instead of correcting the DOM structure. Positive tabindex values place elements ahead of all naturally focusable elements in the page, creating a chaotic global tab sequence that is extremely difficult to maintain and almost always introduces errors.
• Applying CSS order in Flexbox or CSS Grid to reorder content visually without reordering the DOM, then failing to test keyboard navigation. The visual layout looks correct to sighted users but the tab sequence follows the DOM order, not the visual order — an invisible but serious discrepancy for keyboard users.
• Opening a modal or dialog without programmatically moving focus into it using JavaScript's .focus() method. Screen reader and keyboard users remain stranded in the background content, often unable to find or interact with the dialog at all.
• Failing to return focus to the triggering element after closing a modal, drawer, or dropdown. Returning focus to the top of the page or leaving it on a now-hidden element forces users to re-navigate from the beginning, losing their place in a potentially long page.
• Inserting dynamically loaded content (e.g., an inline error message, a toast notification, or lazy-loaded section) into the DOM after focusable elements that precede it visually, so keyboard users encounter the new content out of sequence or not at all.
• Using tabindex='-1' to remove elements from the tab sequence without providing an alternative means of keyboard access. While tabindex='-1' itself is a valid tool (it makes an element programmatically focusable but removes it from the natural tab order), misapplying it to controls that users genuinely need to reach effectively hides those controls from keyboard users.
• Building single-page application route transitions that reset focus to the document body or browser chrome instead of moving focus to the new page heading or a skip-navigation landmark. Users are then forced to Tab through the entire navigation on every route change.
• Implementing custom carousel or slider widgets where arrow-key navigation is not implemented and Tab moves focus through each hidden slide, forcing users to Tab through dozens of off-screen elements before reaching subsequent page content.
• Placing an "invisible" skip navigation link in the DOM that is always display:none (rather than visually hidden with a .sr-only / clip technique). A display:none link is removed from the tab order entirely, offering no benefit, while a properly implemented skip link receives focus on Tab and becomes visible, directly supporting logical focus flow to main content.
• Nesting interactive elements inside other interactive elements (for example, a <button> inside an <a> tag), which produces browser-inconsistent tab behavior and can cause focus to land on the same logical control multiple times or skip it entirely.

Relation to Turkey's Accessibility Regulations

WCAG 2.4.3 Focus Order is directly relevant to Turkey's landmark accessibility legislation: Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025. This circular establishes mandatory web accessibility standards for a wide range of public and private sector entities operating in Turkey, requiring conformance with internationally recognized guidelines — including all WCAG 2.x Level A success criteria, of which 2.4.3 is one.

The circular covers a broad set of entity types. Public institutions — including ministries, municipalities, state universities, and government agencies — must achieve full conformance within one year of the circular's publication date. Private sector entities in covered categories must reach the same conformance standard within two years. The covered private sector categories include e-commerce platforms, banks and financial institutions, hospitals and private healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transportation companies, and private schools operating under authorization from the Ministry of National Education (MoNE).

For all of these organizations, a broken or illogical focus order is not merely a usability shortcoming — it is a regulatory non-compliance that can expose the entity to legal and administrative consequences under the circular's enforcement provisions. Consider a Turkish bank's online banking portal where the focus order on the funds transfer screen jumps from the amount field to the confirmation button, bypassing the beneficiary IBAN field. A keyboard-only user — perhaps a customer with a motor disability — could inadvertently initiate a transfer without properly filling in all required fields. This scenario simultaneously represents a WCAG 2.4.3 failure, a breach of the circular's requirements, and a potentially serious financial harm to the user.

Similarly, an e-commerce site covered by the circular that uses CSS Grid reordering to display a visually appealing product page, but whose tab sequence jumps from product images to footer links before reaching the "Add to Cart" button, would be in direct violation of 2.4.3 and therefore non-compliant with the circular. The one- and two-year deadlines mean that organizations should treat focus order remediation as a priority in their accessibility roadmaps — not a deferred enhancement. Given that focus order issues often stem from architectural decisions about DOM structure and JavaScript interaction patterns, addressing them early in the development process is substantially less costly than retrofitting them after launch.

Accsible's overlay SDK supports organizations on their journey toward compliance by providing configurable focus management enhancements, but it is important to note that overlay solutions work best alongside — not instead of — proper semantic HTML structure and responsible focus management in the application's own codebase. Achieving sustainable, auditable conformance with Presidential Circular 2025/10 requires that the underlying product meets 2.4.3 through correct development practices.