Can each script be controlled with the keyboard and any pointing device (except in special cases)?
A user who navigates only by keyboard, whether blind, quadriplegic, or simply without a mouse, must be able to trigger every JavaScript feature on your page. If your dropdown menu only opens on mouse hover, it is inaccessible to them. Completely.
This criterion covers two distinct obligations. First obligation: every element bearing a JavaScript event handler (click, mouseover, touch, focus, blur…) must be reachable and activatable by keyboard, and usable with any pointing device. Second obligation: keyboard focus must never be removed by a script. Test 7.3.2 verifies this specifically.
A .blur() triggered on focus receipt is the classic error of test 7.3.2. The keyboard user gives focus to an element and that focus disappears. They no longer know where they are on the page. It is an invisible trap.
Use native elements (<button>, <a>) whenever possible. Their keyboard behavior is built in without a single line of extra code. When you must use an interactive <div>, add tabindex="0", the appropriate role, and an onkeydown handler that listens for Enter and Space.
2 tests to verify that each script is keyboard usable
Keyboard and pointer accessibility of scripts
Identify all elements that trigger a JavaScript action (onclick, onmouseover, ontouch, onfocus, onblur, onkeydown…). The "Event Listeners" tab in DevTools helps you identify them without reading all the code.
For each element, verify keyboard access:
- Is the element reachable by Tab?
- Simple action (open, validate): does it activate with Enter?
- Complex action (slider, carousel): do arrow keys work?
- If the element itself is not accessible by keyboard: does another element on the page allow the same action by keyboard?
Verify access by pointing device: 5. Does the element respond to mouse, touch, and stylus? 6. Otherwise: does another element allow the same action with a pointing device?
The test is validated if points 1 to 3 (or point 4) AND point 5 (or point 6) are satisfied.
Absence of focus removal by script
Navigate by keyboard (Tab) across the entire page and give focus to each interactive element, one after another.
- At each focused element, verify that the focus indicator remains visible and the element truly remains focused.
- Look for any behavior that would move focus or call
.blur()immediately after focus receipt.
The test is validated if no script removes focus after an element has received it.
Examples
❌ Non-compliant : Interactive element inaccessible by keyboard
<div class="menu-trigger" onmouseover="openDropdown()" onclick="openDropdown()">
Our services
</div>This <div> is not in the tab flow: no tabindex, no interactive role. A keyboard user cannot reach it with Tab. Even if they reach it by another means, Enter would not trigger anything on a <div>. The onmouseover completely excludes keyboard users and may cause problems on touchscreen where hover does not exist.
✅ Compliant : Interactive element correctly accessible
<button type="button" class="menu-trigger" onclick="openDropdown()" aria-expanded="false" aria-controls="dropdown-services">
Our services
</button>A <button> is natively focusable by Tab, activatable with Enter and Space, and works with all pointing devices. No extra tabindex or onkeydown handler is needed. The aria-expanded attribute informs screen readers of the open or closed state of the menu.
❌ Non-compliant : Focus removal by JavaScript
<div id="zone-info"
tabindex="0"
onfocus="document.getElementById('zone-info').blur()">
Additional information
</div>As soon as the keyboard user reaches this element, the script immediately removes focus from it. The cursor disappears without explanation. This technique, sometimes used to "disable" an element visually, is a direct violation of test 7.3.2. An element to be disabled must receive the disabled attribute or be removed from the tab flow, not be emptied of its focus by script.
Tips and pitfalls
⚠️ onmouseover without onfocus equivalent
Menus that open only on hover (onmouseover) are among the most frequent errors in audits. Every mouse handler must have a keyboard counterpart: onmouseover → onfocus, onmouseout → onblur, onmousedown → onkeydown. Without these equivalents, any keyboard interaction with the component is blocked.
💡 Native elements do the work for you
A <button> is focusable, activatable with Enter and Space, and compatible with all pointing devices without additional configuration. A <div role="button" tabindex="0"> requires a manual onkeydown handler for each expected key. Always prefer the native element: less code, less risk of omission, better compatibility with assistive technologies.
⚠️ Features without universal equivalent: criterion not applicable
Some interactions are physically impossible to reproduce by keyboard or with a standard pointing device. A freehand drawing application, a virtual instrument controlled by pressure, a complex gesture-based game. In these specific situations, criterion 7.3 is not applicable. Note it in your report with explicit justification: the exception applies only if no standard technique allows the interaction to be reproduced.
⚠️ The alternative can be provided by another element
Test 7.3.1 does not require the same element to be accessible by both keyboard and mouse. An interactive map manipulable only by mouse can be compliant if zoom and pan buttons accessible by keyboard are present on the page. Functional equivalence matters: the feature must be reachable, not necessarily through the same trigger.
⚠️ Positive tabindex breaks focus order
A tabindex="1" or tabindex="2" causes an element to come before all elements in the DOM order. Result: focus jumps unpredictably. Keyboard users lose the thread of their navigation. Use only tabindex="0" to include an element in the natural flow, or tabindex="-1" to make it focusable only by script. Positive values systematically create violations discovered in audits.
Frequently asked questions
What keyboard accessibility limitations does onclick on a <div> present in RGAA?
None. onclick on a <div> responds to the mouse, but the <div> is not in the tab flow and Enter does not trigger anything on it natively. For a <div> to be keyboard accessible, three attributes are mandatory: tabindex="0" to include it in the flow, role="button" (or appropriate role) for assistive technologies, and an onkeydown handler for Enter and Space. Direct solution: replace the <div> with a <button> and the problem disappears.
How do you audit criterion 7.3 RGAA without analyzing every line of JavaScript?
Unplug the mouse and navigate only by keyboard. Tab to move forward, Shift+Tab to move back, Enter to activate. Any action available with the mouse must also be available by keyboard. To identify elements with event handlers, DevTools (Elements → Event Listeners) list all attached handlers. Focus on rich components: dropdowns, carousels, tabs, modals. These are the ones that fail most often.
How do you make a swipe-controlled carousel keyboard accessible according to RGAA?
Yes, unless swipe constitutes an interaction without a standard equivalent, which is rarely the case for a carousel. Previous/Next buttons accessible by keyboard constitute the expected alternative. Swipe can remain as an additional gesture for touch users, but navigation must be achievable without it. The exception to criterion 7.3 only covers interactions physically impossible to translate, such as freehand drawing or variable pressure.
Why does loss of visual focus indicator constitute a violation of criterion 7.3 RGAA?
Not of criterion 7.3.2. This test verifies that focus is not removed by JavaScript, meaning the element truly remains focused in the DOM. Visibility of the indicator falls under criterion RGAA 10.7. The two issues often coexist: an outline: none hides focus visually while a .blur() removes it technically. Report each under its own criterion in your report.
How do you make a complex component like a slider or datepicker keyboard accessible?
Follow the patterns described in the ARIA Authoring Practices Guide (APG). A slider (role="slider") must respond to arrow keys, Home, and End. A datepicker must allow calendar navigation with arrows and validation with Enter. Each ARIA role has its defined keyboard interactions. Implement them manually or use a library that respects them, such as Radix UI, Headless UI, or Adobe React Aria.