WCAG 2.1.1: Keyboard

What This Rule Means

WCAG 2.1.1 (Keyboard) mandates that every piece of functionality on a web page or application must be operable using a keyboard interface. This means that if a user can click a button, drag an item, hover to reveal a menu, or interact with any other element using a mouse, they must be able to perform the exact same action using only keyboard inputs — typically the Tab, Shift+Tab, Enter, Space, and arrow keys.

The criterion applies to all interactive elements: links, buttons, form controls, custom widgets, modal dialogs, dropdown menus, accordions, carousels, date pickers, drag-and-drop interfaces, canvas-based interactions, and any other component that responds to user input. If content requires a user to perform a drawing path (where the path itself is the input, not just the endpoint), that is the only formally recognized exception in WCAG. Outside of that narrow exception, every other piece of functionality must be keyboard accessible.

A pass means a keyboard-only user can reach every interactive element via Tab or arrow key navigation, activate it with Enter or Space, and complete the intended action without requiring a mouse at any step. A fail occurs when any of the following apply: an interactive element receives no focus at all; focus is received but the element cannot be activated; a function is exclusively triggered by a mouse event such as onmouseover or ondblclick with no keyboard equivalent; or a scrollable container is not reachable by keyboard, trapping content inside it.

It is important to distinguish WCAG 2.1.1 from WCAG 2.1.2 (No Keyboard Trap). Criterion 2.1.1 ensures keyboard users can get to and use everything; criterion 2.1.2 ensures keyboard users are never stuck inside a component. Both must be satisfied for full Level A conformance.

Why It Matters

Keyboard accessibility is not a niche concern. An estimated 1 in 4 adults in the United States lives with some form of disability, and motor impairments — including conditions such as Parkinson's disease, multiple sclerosis, spinal cord injuries, repetitive strain injury (RSI), limb differences, and tremors — frequently prevent users from operating a standard mouse or touchscreen. These users rely entirely on keyboards, switch controls, sip-and-puff devices, head pointers, or other assistive technologies that ultimately emulate keyboard input at the operating system level.

Blind and low-vision users who rely on screen readers such as NVDA, JAWS, or VoiceOver navigate entirely via the keyboard. If an element is not keyboard-reachable, the screen reader will never announce it, making the content completely invisible to that user. According to the World Health Organization, at least 2.2 billion people worldwide have some form of near or distance vision impairment.

Consider a concrete scenario: a user with advanced rheumatoid arthritis in both hands visits an e-commerce checkout page. The site's custom-built payment method selector is implemented as a series of styled <div> elements that respond only to mouse clicks. The user can Tab to the container, but no individual option receives focus and pressing Enter does nothing. They cannot complete the purchase. This is not a minor inconvenience — it is a complete exclusion from a commercial transaction, and it represents both a legal risk and a significant lost-revenue scenario for the business.

Beyond disability, keyboard accessibility benefits power users who prefer keyboard shortcuts for speed, users in enterprise or government settings where mouse use is restricted by policy, and users on non-standard input devices. It also correlates positively with clean, semantic HTML structures that search engines parse more reliably, contributing to better SEO performance and long-term maintainability of the codebase.

Related Axe-core Rules

• scrollable-region-focusable: This rule checks whether any element that has overflow content (i.e., it is scrollable) is reachable via keyboard. When a container has CSS properties such as overflow: auto or overflow: scroll, sighted mouse users can scroll it with a mouse wheel or trackpad. Keyboard users, however, must be able to Tab into the container or use arrow keys to scroll it. The rule flags scrollable regions that have no tabindex attribute and no naturally focusable child element, meaning a keyboard-only user would have no way to access the overflowing content. Automated detection is reliable here because axe can inspect the computed styles and the DOM tree to identify elements with scrollable overflow that lack keyboard focus capability.
• server-side-image-map: This rule flags the use of server-side image maps — HTML <img> elements with the ismap attribute. Server-side image maps send the raw pixel coordinates of a mouse click to the server to determine which link was activated. Because the action depends entirely on pixel coordinates derived from a pointer device, there is no keyboard equivalent mechanism. Unlike client-side image maps (which use <map> and <area> elements and can be made keyboard accessible), server-side image maps are fundamentally incompatible with keyboard-only navigation. Axe flags any <img ismap> element as a keyboard accessibility failure. Manual verification should confirm whether the image map is the only way to access the underlying navigation or functionality.

It is critical to understand that automated tools like axe-core can only catch a subset of keyboard accessibility failures. Many violations require manual testing because they involve custom JavaScript event listeners, dynamic focus management, or complex interaction patterns that static analysis cannot fully evaluate. For example, a button implemented as a <div> with a click event listener may receive focus via tabindex='0' but fail to respond to Enter or Space key presses — a failure that axe cannot always detect without executing the interaction.

How to Test

1. Automated scan with axe DevTools or Lighthouse: Install the axe DevTools browser extension for Chrome or Firefox. Navigate to the page under test and run a full-page scan. Filter results for rules tagged with wcag2a and keyboard. Look specifically for violations of scrollable-region-focusable and server-side-image-map. In Lighthouse (Chrome DevTools), run an Accessibility audit and review the "Keyboard" category. Note that these tools will surface obvious structural failures but will not catch all custom widget issues.
2. Manual keyboard navigation test: Disconnect or set aside your mouse entirely. Starting from the browser address bar, press Tab repeatedly to move forward through all focusable elements on the page. Press Shift+Tab to move backward. For every interactive element — links, buttons, inputs, custom dropdowns, modals, sliders — verify that: (a) it receives a visible focus indicator; (b) pressing Enter or Space activates it as expected; (c) any resulting dialog or panel can also be navigated and dismissed by keyboard. Use arrow keys inside widgets that implement composite patterns (menus, tab lists, radio groups, listboxes).
3. Screen reader + keyboard test with NVDA and Firefox: Launch NVDA (free, Windows) and open Firefox. Use NVDA's Browse Mode (arrow keys) to read through the page and identify all interactive elements. Switch to Focus Mode (Insert+Space or automatic on form fields) to interact with controls. Verify that custom widgets announce their role, state, and name, and that all functionality can be completed without a mouse. Test any scrollable containers by attempting to Tab into them and use arrow keys to scroll.
4. Screen reader test with VoiceOver and Safari (macOS/iOS): Enable VoiceOver (Command+F5 on macOS). Use VO+Right arrow to navigate linearly through the page. Use Tab to move between interactive elements. Confirm that scrollable regions are reachable and that no functionality requires a swipe gesture or pointer interaction without a keyboard-accessible alternative.
5. JAWS and Chrome test: With JAWS running, open Chrome and navigate to the page. Use the JAWS Virtual Cursor to browse content and the Tab key to move between interactive elements. Specifically test any custom JavaScript widgets — accordions, carousels, modal dialogs, custom select boxes — by tabbing to them and attempting full operation via keyboard. Log any element that receives focus but cannot be activated, or any functionality that is only reachable via mouse hover.
6. Scrollable region specific test: Identify all containers on the page with visible scroll bars or that contain more content than their visible area. Attempt to Tab into each container. If Tab does not move focus inside the container and there are no focusable child elements, the container is likely a keyboard accessibility failure. Try pressing arrow keys while the container or a nearby element has focus to see if scrolling is possible.

How to Fix

Scenario 1: Scrollable Container — Incorrect

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scenario 1: Scrollable Container — Correct

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Scenario 2: Server-Side Image Map — Incorrect

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

Scenario 2: Server-Side Image Map — Correct

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

Scenario 3: Custom Widget Using Only Mouse Events — Incorrect

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

Scenario 3: Custom Widget Using Only Mouse Events — Correct

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

Scenario 4: Hover-Only Dropdown Menu — Incorrect

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Scenario 4: Hover-Only Dropdown Menu — Correct

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Common Mistakes

• Using onclick as the sole event handler on a non-native element without adding a corresponding onkeydown or onkeyup handler — mouse clicks trigger onclick but keyboard activation on a <div> or <span> does not.
• Adding tabindex='0' to a custom interactive element but forgetting to add role='button' (or appropriate role), which means screen readers do not communicate the element's purpose to the user.
• Building dropdown navigation that relies exclusively on CSS :hover pseudo-class without a JavaScript-powered keyboard toggle, making submenus invisible and unreachable for keyboard users.
• Implementing drag-and-drop interfaces — sorting lists, kanban boards, file upload zones — without a keyboard-accessible alternative mechanism such as keyboard-triggered move commands or a separate reorder control.
• Creating scrollable containers (such as terms-of-service boxes, chat windows, or data tables inside fixed-height wrappers) without tabindex='0', preventing keyboard users from scrolling to view all content.
• Using <img ismap> for navigation components inherited from legacy codebases without replacing them with client-side image maps or standard navigation links.
• Applying tabindex='-1' to interactive elements to remove them from the natural Tab order without providing a programmatic focus management strategy, resulting in controls that are permanently unreachable by keyboard.
• Triggering functionality exclusively on mouseenter, mouseleave, or mousemove events (tooltips, previews, context menus) without equivalent focus, blur, or keyboard event alternatives.
• Assuming that a modal dialog manages focus automatically — failing to move focus into the dialog when it opens and failing to return focus to the triggering element when it closes, leaving keyboard users disoriented in the page.
• Setting pointer-events: none in CSS on an element that should be keyboard accessible, which, while not directly affecting keyboard behavior, is often paired with JavaScript patterns that also block keyboard interaction.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web accessibility requirements aligned with WCAG 2.1 Level AA. WCAG 2.1.1 (Keyboard) is a Level A criterion, which places it in the highest-priority tier of required compliance. Level A conformance is the absolute minimum baseline — if a site fails Level A criteria, it is considered non-accessible regardless of any other improvements made.

Under the circular, compliance timelines are differentiated by entity type: public institutions and government agencies are required to achieve conformance within one year of the circular's publication date, while private sector entities covered by the regulation have two years to comply.

The entities covered by Presidential Circular 2025/10 include a broad cross-section of Turkish digital services: e-commerce platforms, public institutions and ministries, banks and financial institutions, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, licensed travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE).

For all of these entities, failure to satisfy WCAG 2.1.1 means that keyboard-dependent users — including citizens with motor disabilities, elderly users, and screen reader users — cannot access their core digital services. This is a direct regulatory violation. In practical terms, an e-commerce site where the checkout flow cannot be completed by keyboard, or a hospital patient portal where appointment booking requires mouse interaction, would be in breach of the circular's requirements.

Organizations subject to the circular should conduct a keyboard accessibility audit as a first step in their accessibility remediation program. Because WCAG 2.1.1 failures are often architectural — rooted in the choice of HTML elements, event binding patterns, and component framework defaults — remediating them may require code-level changes rather than configuration adjustments alone. Accsible's overlay SDK can assist in surfacing and patching common keyboard accessibility gaps at the JavaScript layer, but teams should also pursue structural fixes in their source code to achieve robust, auditable conformance that will satisfy regulatory review.