Published October 4, 2026

WCAG 2.1.1 Keyboard, Level A

Can a website meet WCAG if it only works with a mouse?

No. Success criterion 2.1.1 says all functionality of the content must be operable through a keyboard interface. It is Level A. WCAG 2.1 and 2.2 Level AA include every Level A criterion, so a control that works only with a pointer fails AA as well. The criterion is in the W3C WCAG 2.2 Recommendation. The exception is narrow: the underlying function itself requires a path of movement, such as drawing a signature by hand. A menu, a button, a date picker, and a checkout step are not that exception.

What does “operable through a keyboard” mean?

A person who does not use a mouse has to be able to reach the control, operate it, and move on. On a web page that usually means Tab and Shift+Tab move focus, Enter or Space activates the control, and arrow keys move inside a composite widget such as a menu or a tab list. The W3C explanation is in Understanding Success Criterion 2.1.1.

Click-only handlers fail this test. A div with an onClick and no keyboard handler is not a button. A custom dropdown that opens on hover and has no key for each option fails too. Extra content that appears on hover or focus also has to be dismissible, hoverable, and persistent under 1.4.13, covered on the content on hover or focus page. The accessible name of that control is a separate requirement, covered on the accessible names page. The sequence of those keyboard stops has to preserve meaning and operability under 2.4.3, covered on the focus order page.

When is focus allowed to stay inside a dialog?

Success criterion 2.1.2 No Keyboard Trap is also Level A. If keyboard focus can be moved to a component, it must be movable away with the keyboard. A dialog may keep focus inside while it is open. It still needs a keyboard way to close, usually Escape or an explicit close control, and focus must return to the control that opened it. The text is at 2.1.2 No Keyboard Trap. A widget that captures Tab and never releases it fails even if a mouse user can click outside.

Does the focus indicator have to be visible?

Yes at Level AA. Success criterion 2.4.7 Focus Visible requires a mode of operation where the keyboard focus indicator is visible. Removing the browser outline with CSS, and not drawing a replacement, hides the only signal of where focus is. The criterion is 2.4.7 Focus Visible. WCAG 2.2 adds 2.4.11 Focus Not Obscured and 2.4.13 Focus Appearance on top of 2.1. The differences are on the WCAG 2.1 versus 2.2 page. A scanner often misses a custom control whose focus style is missing. That limit is explained on the scanner page.

Which tasks should be checked from the keyboard first?

• Open the menu, move through it, and activate a link without a pointer.
• Search, then move to a result.
• Complete a form, including the error state. Labels and errors are on the forms page.
• Open a dialog, close it, and confirm focus returns.
• Play a video and reach captions. Captions are on the video page.
• Finish checkout or the account task the site exists to provide.

Does the Title II web rule include keyboard access?

Yes. The Department of Justice rule for state and local government websites names WCAG 2.1 Level AA. That level includes 2.1.1 and 2.1.2. A government template that only works with a mouse does not meet the rule. Deadlines and who is covered are on the Title II web rule page. Private businesses open to the public are Title III. ADA.gov’s web guidance is about access to the same content, and a mouse-only path is not that access. An audit records the page, the criterion, and the change. The fix belongs in the template, which is remediation, not a widget added after the page loads.