WCAG 2.1.1 — Interactive Element Not Keyboard Accessible

Who Is Affected

People with motor disabilities who cannot use a mouse, users with tremors or limited fine motor control, users navigating with assistive technologies like switch devices or voice control software, and power users who prefer keyboard navigation for efficiency.

What This Means

Every interactive element on your website — buttons, links, form controls, dropdown menus, accordions, tabs, modal dialogs — must be reachable and operable using only the Tab, Enter, Space, and arrow keys. This is fundamental web accessibility.

Common violations include custom dropdown menus that only open on mouse hover, buttons created from <div> elements without proper keyboard handling, image carousels that require mouse clicks to navigate, and modal dialogs that trap focus incorrectly.

Users should be able to Tab through all interactive elements in logical order, press Enter or Space to activate buttons, and use arrow keys to navigate within grouped controls like tab panels or menu bars.

Fix: CMS / Theme

Many keyboard accessibility issues stem from theme components or custom JavaScript that wasn't built with accessibility in mind.

For Custom Interactive Components

1. Identify the failing element using Tab navigation through your site. Note where Tab stops working or skips interactive elements.

2. Check the HTML structure:

   • Buttons must use <button> elements, not <div> or <span>
   • Links must use <a href=""> elements
   • Form controls must be proper <input>, <select>, <textarea> elements

3. Add missing tabindex attributes:

   • Interactive elements should have tabindex="0" if they're not naturally focusable
   • Remove tabindex="-1" unless intentionally hiding from keyboard navigation

4. Implement keyboard event handlers:

   // Example: Making a custom button keyboard accessible
   element.addEventListener('keydown', function(e) {
     if (e.key === 'Enter' || e.key === ' ') {
       e.preventDefault();
       // Trigger the same action as click
       handleButtonClick();
     }
   });
   

Platform-Specific Fixes

In Joomla:

• Go to Extensions → Modules → find custom modules with interactive elements
• Check template overrides in /templates/your-template/html/
• Consider replacing custom components with Joomla's accessible alternatives

In WordPress:

• Check Appearance → Widgets and Appearance → Customize for custom elements
• Review theme's functions.php for custom JavaScript
• Consider accessible plugin alternatives for complex interactions

Fix: Content Editor

For content-level keyboard accessibility issues:

1. Review custom HTML blocks in your content editor for non-standard interactive elements.

2. Replace inaccessible elements:

   • Change <div onclick="..."> to <button type="button">
   • Ensure all links have proper href attributes
   • Remove tabindex="-1" from elements users need to reach

3. Test your changes:

   • Navigate through the page using only Tab, Enter, and Space keys
   • Verify all interactive elements can be reached and activated
   • Check that Tab order follows logical reading order

4. For embedded content like YouTube videos or social media widgets, ensure they provide keyboard alternatives or use accessible embed codes.

Standard Reference

WCAG 2.1 Success Criterion 2.1.1 — Keyboard, Level A

All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

• W3C Understanding SC 2.1.1
• WCAG Technique G202 — Keyboard support for all functionality
• WCAG Technique H91 — Using HTML form controls and links
• WCAG Technique SCR20 — Using both keyboard and other device-specific functions
• WCAG Failure F54 — Using only pointing-device-specific event handlers
• WCAG Failure F55 — Using script to remove focus when focus is received