Back to blog
7 min read
UX / Accessibility

Keyboard accessibility and ARIA: the legal obligation that becomes a business advantage

Since June 2025, the European Accessibility Act requires digital accessibility for most online services. Test #35 detects the keyboard navigation issues that put sites at risk.

Key Takeaways
  • Test #35 analyses HTML signals for keyboard accessibility: tabindex misuse, missing focus styles, skip links, and ARIA conflicts. A score below 60 means critical navigation barriers exist
  • The European Accessibility Act (EAA) has been in force since June 2025 — businesses selling to EU consumers must ensure keyboard-navigable interfaces or face penalties
  • For agencies, accessibility audits are a new recurring revenue stream: legal obligation means guaranteed demand, and fixes require ongoing maintenance

Keyboard accessibility is one of those topics that most web professionals acknowledge as important — and then promptly ignore. The reasoning is always the same: "our users use a mouse." But that assumption is wrong, and since June 2025, it is also illegal for a growing number of businesses in the European Union.

The European Accessibility Act (EAA, Directive 2019/882) requires that products and services sold to consumers — including websites and mobile apps — be accessible to people with disabilities. Keyboard navigation is one of the foundational pillars of web accessibility. If a user cannot Tab through your interface, activate buttons, or navigate menus without a mouse, your site fails the most basic accessibility criterion.

Orilyt test #35 analyses static HTML signals to detect the most common keyboard accessibility issues: negative tabindex values that remove elements from the tab order, focus styles disabled via CSS, missing skip links, and ARIA attributes that conflict with focusable elements. It is not a full WCAG audit — but it catches the issues that matter most.

Keyboard accessibility audit: tab navigation, focus indicators, skip links, and ARIA role detection

Test #35: What does Orilyt check?

Test #35 performs a static analysis of the page HTML and inline CSS to detect keyboard accessibility signals. It checks six specific indicators:

  1. Negative tabindex — elements with tabindex="-1" are removed from the natural tab order. This is sometimes intentional (modals, off-screen elements), but when overused it creates invisible barriers. Any occurrence lowers the score to 60
  2. Positive tabindex — values like tabindex="5" force a custom tab order that almost always breaks the logical reading flow. The test flags these as a warning signal
  3. Focus outline disabled — if the CSS contains outline: none without a corresponding :focus or :focus-visible rule providing an alternative style, keyboard users cannot see where they are on the page. Score drops to 60
  4. Skip link detection — a "Skip to content" link (targeting #main, #content, or similar anchors) lets keyboard users bypass the navigation. Its presence is a positive signal that raises confidence
  5. ARIA-hidden conflicts — elements marked aria-hidden="true" that contain focusable children (links, buttons, inputs) create a dangerous trap: screen readers hide the element, but keyboard focus can still land on it
  6. Focus CSS presence — the test checks whether the page includes any :focus or :focus-visible CSS rules, indicating the developer has considered keyboard navigation styling

A clean page with no obvious blockers scores 80. The test cannot exceed 80 because static HTML analysis alone cannot fully validate keyboard navigation — real tab-through testing is still needed. If issues are found, the score drops to 60 or 55 depending on severity.

Keyboard accessibility is invisible until you need it. And the people who need it cannot tell you it is broken — because they cannot reach the feedback form.

The European Accessibility Act: what changed in June 2025

The EAA was adopted in 2019 but member states had until 28 June 2025 to transpose it into national law. Since that date, businesses providing services to consumers in the EU must comply with accessibility requirements that align closely with WCAG 2.1 Level AA.

The scope is broad: e-commerce sites, banking services, transport ticketing, e-books, and any digital service sold to consumers. Micro-enterprises (fewer than 10 employees and under 2 million euros in turnover) are exempt, but the threshold is low — most agencies' clients fall within scope.

Penalties vary by member state but include fines, injunctions, and mandatory corrective action. More importantly, the regulation creates a compliance market: businesses need audits, remediation plans, and ongoing monitoring — services that agencies can sell.

Keyboard navigation is not the only WCAG criterion, but it is the one that fails most spectacularly. A user who cannot Tab past the navigation, or who gets trapped in a modal with no Escape key handler, experiences a total breakdown of the interface. It is the first thing auditors check.

The 5 most common keyboard accessibility failures

In practice, most keyboard accessibility issues fall into five categories. Each one is detectable and fixable:

  1. Custom components without keyboard support — dropdown menus, accordions, carousels, and modals built with <div> and JavaScript but no keyboard event handlers. They work with a mouse click but are completely invisible to Tab navigation. Fix: use semantic HTML (<button>, <details>) or add proper keydown handlers and ARIA roles
  2. Missing focus indicators — CSS resets or design systems that include outline: none or outline: 0 globally without providing an alternative :focus-visible style. Keyboard users literally cannot see where they are. Fix: define a visible focus ring in your CSS — a 2px solid outline in a contrasting colour works for most designs
  3. Tab traps — modal dialogs or embedded widgets that capture focus and provide no way to escape with the keyboard. The user is stuck. Fix: implement focus trapping that cycles within the modal and releases focus on Escape
  4. Incorrect tab order — positive tabindex values (tabindex="1", tabindex="99") that override the natural DOM order. The tab sequence becomes unpredictable. Fix: remove positive tabindex values entirely and rely on DOM order
  5. Missing skip links — on pages with complex navigation, keyboard users must Tab through every link in the header before reaching the main content. A "Skip to content" link at the top of the page solves this in one line of HTML

How to fix keyboard accessibility issues

The good news: most keyboard accessibility fixes are straightforward and do not require a redesign. They fall into three categories:

  1. Use semantic HTML — replace <div onclick="..."> with <button>, use <a> for navigation, use <details>/<summary> for expandable sections. Semantic elements are keyboard-accessible by default
  2. Add focus styles — define a :focus-visible rule in your CSS. A simple outline: 2px solid #2563EB with an offset provides visibility without affecting mouse users. Never use outline: none without an alternative
  3. Test with the Tab key — the most effective accessibility test costs nothing: unplug your mouse and navigate your site with Tab, Shift+Tab, Enter, and Escape. If you get stuck, your users will too

For WordPress sites specifically, the most common culprit is the theme. Premium themes often prioritise visual design over accessibility. Check the theme's navigation menus, contact forms, and any JavaScript-powered components (sliders, lightboxes, mega menus).

Accessibility as a business opportunity for agencies

For freelancers and agencies, the EAA has created a compliance market that did not exist before June 2025. The business case is compelling:

  1. Legal obligation = guaranteed demand — every client with an e-commerce site or consumer-facing service in the EU needs an accessibility audit. This is not optional. It is the law
  2. Recurring revenue — accessibility is not a one-time fix. Sites change, new pages are published, plugins are updated. Ongoing monitoring and periodic re-audits are necessary for sustained compliance
  3. Low competition — most web agencies still do not offer accessibility services. Being early creates positioning advantage. The agencies that move now will own this market segment

In the Orilyt report, test #35 generates a clear FIA recommendation when issues are found. A score of 55 or 60 on keyboard accessibility is a conversation starter with any client. The recommendation explains what was found (e.g. "Focus outline disabled without alternative"), where it occurs, and what to do about it.

The European Accessibility Act did not create the need for accessible websites. It created the budget.

From legal constraint to competitive edge

Keyboard accessibility is not a niche concern. It affects motor-impaired users, power keyboard users, screen reader users, and anyone with a broken trackpad on a Tuesday afternoon. The EAA has made it a legal requirement for millions of EU businesses.

Test #35 does not replace a full WCAG audit — but it detects the signals that indicate whether keyboard accessibility has been considered at all. Missing focus styles, negative tabindex abuse, and ARIA-hidden conflicts are the red flags that predict deeper problems.

For agencies, this is a market opportunity with a built-in sales argument: "Your site is legally required to be accessible. Here is what our audit found. Here is how we fix it." The law did the selling for you.

Check keyboard accessibility on any site in 2 minutes
Run a free audit and see how test #35 evaluates keyboard navigation signals — alongside 56 other tests covering performance, SEO, and security.
Launch a free audit
Previous GDPR: legal pages, third-party trackers and cookie banners under the microscope Next Accessibilité web 2026 : ce que change l'European Accessibility Act