keyboard accessibility Archives /Tag

Why ARIA Alone Won’t Fix Your Website’s Accessibility
ARIA (Accessible Rich Internet Applications) has become a mainstay in modern front-end work, giving us a way to make complex interfaces more usable for people relying on assistive tech. But here’s the catch: despite how widely it’s used now, accessibility issues on the web haven’t actually gone down. In fact, reports like the annual WebAIM Million consistently show that pages using ARIA often rack up more accessibility errors than those that don’t. That’s a red flag—and it raises an important question: if ARIA is meant to improve accessibility, why does more ARIA so often lead to worse outcomes?

What ARIA Is—and What It’s Supposed to Do

At its core, ARIA is just a spec for adding semantic meaning where HTML alone doesn’t cut it. When we build custom UI components—think tab lists, modals, or live regions—ARIA roles and attributes tell screen readers what those elements are, how they behave, and when their state changes.

For example, aria-live lets us announce new content to screen readers without forcing a page reload. aria-label gives an accessible name to elements that don’t have visible text. Using role="tablist" clarifies the relationship between grouped tab controls. When used correctly, these attributes bridge the gap between how something looks visually and how it’s experienced non-visually.

When Is It Necessary?

There are valid cases where ARIA is the right tool—like custom widgets that don’t exist in native HTML, dynamic content that needs to be announced, or modal dialogs that require managing focus. In these edge cases, it can give essential context to assistive tech users. The trick is restraint: only reach for ARIA when HTML alone can’t deliver the behavior you need.

Why It Shouldn’t Be the Default Tool

The W3C’s first rule of ARIA is dead simple: “Don’t use ARIA if you can use native HTML.” There’s a reason for that. Semantic elements like <button>, <nav>, and <input> come with baked-in keyboard support, focus behavior, and screen reader semantics.

Replacing these with <div>s or <span>s and trying to patch on ARIA roles is a recipe for trouble. It adds complexity we have to maintain, and it increases the cognitive load on assistive tech users, who now have to deal with custom keyboard logic or missing states that native elements would have handled out of the box.

Common ARIA Misuse That Breaks Accessibility

Misusing ARIA is the fastest way to make things worse. Some of the most common mistakes we see:
- Redundant ARIA: e.g. adding role="button" on a native <button>, which can confuse announcements.
- Incorrect roles or attributes: like using aria-checked on something that’s not checkable.
- Static ARIA states: setting aria-expanded="true" and never updating it when the element collapses.
- Overriding native behavior : trapping focus or breaking expected tab order.
- Misused aria-hidden: This one’s especially nasty. It hides content from assistive tech, which is fine for decorative icons or offscreen helper text. But if you throw it on meaningful content like links or form controls, it removes them from the accessibility tree entirely. That creates “empty” focusable elements and violates the rule that aria-hidden="true" must never be on focusable items.
Take a link that only has an SVG icon with aria-hidden="true". Visually it looks fine, but to a screen reader, it’s just an empty link with no name. Compare that to a native <button> with either visible text or an aria-label—it automatically conveys its purpose. Misusing it like this doesn’t just fail to help; it strips meaning away.

Why ARIA Usage Correlates with More Errors

The WebAIM Million keeps showing the same trend: pages with ARIA average almost twice as many detectable errors as those without. That doesn’t mean ARIA is inherently bad—it means it’s often used wrong.

Here’s why that happens so often:
- More moving parts: Every ARIA attribute is another thing that has to stay in sync as the UI changes.
- Misunderstood implementation: Developers sometimes add it without fully understanding how screen readers will interpret it. For instance, putting aria-hidden on a logo or nav link effectively removes it from the experience for assistive tech users.
- No real testing: There’s a tendency to assume that if ARIA is present, accessibility is solved. Without testing, it’s easy to miss that it’s actually broken.
The Real Fix: Manual Testing and Developer Discipline

Automated tools are useful for catching low-hanging fruit like missing alt text, color contrast issues, or syntax errors. But they can’t tell you if your ARIA actually works. They’ll detect if aria-expanded is present—but not if it updates correctly when toggled.

Same thing with aria-hidden: they’ll warn you that it’s there, but not if you used it correctly. Maybe the hidden element is decorative (fine) or maybe it’s essential (not fine). Only a human can tell. Most ARIA issues are about behavior and context, which tools can’t judge.

Testing It in the Real World

To know your ARIA implementation works, you’ve got to test it like real users would:
- Keyboard-only navigation: Make sure everything interactive is reachable by tab, focus order makes sense, and keys like Enter, Space, and Arrow keys behave as expected.
- Screen reader testing: Try NVDA on Windows, VoiceOver on macOS, or JAWS if you’re in enterprise. Confirm that roles, labels, and states are being announced correctly—and that hidden content stays hidden without killing important info.
- User testing: If possible, bring in assistive tech users or trained accessibility testers to see how your UI holds up in practice.
Doing this builds confidence that your ARIA-enhanced components are actually usable.

Build a Feedback Loop Into the Dev Process

Accessibility shouldn’t be a post-launch patch job. Bake it into your development flow. Do accessibility checks during code reviews, QA, and design iterations. When you add ARIA, document the behavior you expect, and get feedback from teammates or AT users to verify it works.

Practical Guidelines for Responsible ARIA Use

If you want to use it safely, stick to a few core habits:
- Follow the WAI-ARIA Authoring Practices (APG): They provide vetted patterns and working code examples.
- Use ARIA only when you have to: Lean on semantic HTML first, and treat it as a fallback.
- Test thoroughly: Validate behavior with keyboard and screen readers, not just automated checkers.
- Review aria-hidden usage carefully: Only hide decorative or duplicate content. Never hide focusable items, form controls, or nav links.
- Document your decisions: Leave comments or README notes explaining why it was added and how it’s supposed to work.
- Make accessibility a team effort: It’s not just the job of one dev or QA engineer. Everyone owns it.
ARIA Isn’t a Shortcut—It’s a Responsibility

ARIA is powerful, but it’s not magic. Used carelessly, it creates new barriers and frustrates the very people it’s meant to support. Used deliberately—with a “native first” mindset, real testing, and team buy-in—it can make complex interfaces accessible without breaking usability.

Respect ARIA’s complexity, but don’t fear it. Real accessibility comes from thoughtful use of semantic HTML, strategic ARIA when it’s actually needed, and consistent real-world testing.

If you want to level up your accessibility practices and cut risk, 216digital offers ADA briefings built specifically for dev teams. Schedule one today and start building better, more inclusive code.
Greg McNeil

September 12, 2025

How-to Guides, Legal Compliance

Accessibility, ARIA, keyboard accessibility, WCAG, web developers, web development, Website Accessibility
Shift Happens—But Not On Focus
You press Tab into the first field of a form, and suddenly the page submits. Or you click into a dropdown and, without warning, a new window pops up. Frustrating, right? Now imagine how much more disruptive that is for someone who relies on a screen reader or uses only a keyboard. Sudden shifts don’t just annoy—they break concentration, cause errors, and force users to start over.

That’s the purpose of WCAG’s Success Criterion 3.2.1 On Focus. It makes sure that receiving focus doesn’t trigger unexpected changes. In short: don’t move the user, reload a page, or submit a form just because something got focus. Users should always stay in control.

In this article, we’ll unpack SC 3.2.1, look at common pitfalls, explore best practices, and share testing strategies so your site feels consistent, trustworthy, and usable.

Understanding Success Criterion 3.2.1 – On Focus

The official wording says: When any user interface component receives focus, it does not initiate a change of context.

What this really means is that putting focus on an element—whether by tabbing, shift-tabbing, or clicking—should not be treated as an automatic “go” button.

A change of context includes things like:
- Submitting a form when a field receives focus
- Opening a modal or new window on focus
- Navigating to a new page when a menu item gains focus
- Programmatically moving focus somewhere else the moment you land on an element
This rule is designed to stop those surprises. Changes should only happen when users take action—pressing Enter, clicking a button, or making a choice—not just by landing on something.

Why On Focus Matters

Predictable focus builds trust. Users know where they are, what’s happening, and how to move forward without being thrown off track.

For users with cognitive or visual disabilities, avoiding sudden shifts prevents confusion. For those navigating with a keyboard, a smooth and logical tab order makes it possible to move efficiently through content. Screen readers also benefit from a stable focus path, since consistency allows the technology to announce content clearly. And people with motor impairments are spared the frustration of accidentally triggering submissions or navigations they didn’t intend.

But accessibility isn’t just about a specific group. Predictability benefits everyone. Consistent behavior builds trust and lowers friction, making your site feel polished and respectful of users’ time and effort.

Common Pitfalls (and Why They Break On Focus)

Despite the clear intent of SC 3.2.1, developers often run into familiar traps. A few of the most common include:
- Auto actions on focus: Submitting a form, opening a modal, or swapping pages the instant an input or link gets focus.
- Focus jumps: Using scripts that automatically call element.focus() on load or on focus, dragging the user to an unexpected spot.
- Navigation on focus: Menus that redirect as soon as an item is focused, rather than waiting for activation.
- Broken tab order: Overuse of tabindex—especially with values greater than 0—can create confusing and illogical navigation paths.
- Inconsistent patterns: Mixing models, where some elements act on focus while others require activation, leads to unnecessary confusion.
All of these problems do the same thing: they break user flow, create confusion, and increase errors.

How to Achieve Compliance (and Design a Better Experience)

Preventing these issues comes down to designing focus behavior intentionally and sticking to a few reliable practices.

From there, keep a few best practices in mind:
- Be thoughtful with focus management. If you use element.focus(), do it to genuinely help the user (for example, moving focus into an opened dialog) and respect lifecycle rules.
- Preserve the natural tab order whenever possible. Use tabindex="0" only when necessary to include custom controls, and avoid positive values.
- Be cautious with ARIA. Roles like menu, menuitem, tab, and dialog come with built-in interaction expectations. If you implement them, follow the complete pattern—or stick with native controls.
- Keep patterns consistent. Buttons should submit, links should navigate, and tabs should switch panels only when activated. Uniformity across components builds confidence.
Small details make a big difference. For example, always include a “Skip to main content” link that becomes visible on focus, and ensure it works correctly by pointing to a landmark or an element with tabindex="-1". Likewise, don’t rely on hover or color changes alone to signal interactivity; provide clear focus styles that work for both keyboard and touch users.

Testing Strategies for On Focus

Testing is where theory meets practice. A few methods will quickly reveal whether your site is compliant:

Manual testing
- Tab through every interactive element. Nothing should submit, navigate, or open on focus alone.
- Shift+Tab backward to confirm the reverse path is just as stable.
- Use Enter or Space to activate controls—only then should real actions occur.
- In DevTools, run document.querySelector('#el').focus() and verify that no context change happens.
Assistive Technology Testing

Screen readers like NVDA (Windows) and VoiceOver (macOS/iOS) are essential. Navigate with Tab, rotor, and quick keys to check that focus remains predictable. On mobile, connect an external keyboard and confirm the behavior is consistent with desktop experiences.

Automated Checks

Tools such as Google Lighthouse or WAVE can flag tabindex issues, missing roles, or poor focus order. Automation won’t catch the “surprise factor.” Always back it up with manual and assistive tech testing.

Bad vs. Good: Concrete Examples

Bad: Form Submits on Focus
```
<form action="/submit" method="post">
  <label for="name">Name:</label>
  <input id="name" type="text" onfocus="this.form.submit()">
</form>
```
Issue: The form submits as soon as the field gains focus—a clear violation.

Good: Form Submits Only on Activation
```
<form action="/submit" method="post">
  <label for="name">Name:</label>
  <input id="name" type="text">
  <button type="submit">Submit</button>
</form>
```
Fix: The form submits only when the user explicitly activates the button.

Bad: Navigation on Focus
```
<nav>
  <a href="/pricing" onfocus="window.location=this.href">Pricing</a>
</nav>
```
Good: Navigation Only on Activation
```
<nav>
  <a href="/pricing">Pricing</a>
</nav>
```
Tip: It’s fine to expand a menu on focus for discoverability, but don’t redirect until activation.

Good Example: Custom Control with Predictable Focus
```
<button aria-expanded="false" aria-controls="filters" id="filterToggle">
  Filters
</button>
<div id="filters" hidden>
  
</div>
```
This pattern ensures that nothing happens on focus. Activation (click, Enter, or Space) toggles the state, while ARIA reflects the change.

Frequently Asked Questions

What’s the primary goal of SC 3.2.1 On Focus?
To make sure that receiving focus doesn’t cause unexpected context changes. Users, not scripts, decide when to act.

Is onfocus always forbidden?
Not necessarily. You can use it for subtle cues like highlighting an element. Just don’t trigger navigation, submissions, or new windows.

Can focus ever be moved programmatically?
Yes—if it matches user expectations. For example, moving focus into a modal when it opens, or pointing to an inline error message after a failed form submission, are acceptable.

How should I handle dynamic components like tabs or accordions?
Stick to activation-based behavior. Use arrow keys to move between tabs, but only switch panels when a tab is activated, following WAI-ARIA Authoring Practices.

Build Predictable Experiences (and Trust)

At its core, SC 3.2.1 is about respect. Focus should never feel like a trap door. By preventing context changes on focus, you protect users from confusion, reduce errors, and make your interface feel stable and reliable.

Accessible design isn’t just about checking a box—it builds trust. Predictable interactions show users that their time and attention are valued, whether they’re navigating with a screen reader, a keyboard, or a mouse. And when people can move through your site without fear of surprises, they’re more likely to stay, engage, and return.

If you’re unsure whether your site meets this success criterion—or you’d like expert guidance on weaving accessibility into everyday development—schedule an ADA briefing with 216digital. We’ll review your patterns, coach your team, and help you create consistent, user-friendly experiences that people can rely on.
Greg McNeil

September 8, 2025

How-to Guides, Testing & Remediation

Accessibility, digital accessibility, How-to, keyboard accessibility, On Focus, Web Accessibility, web developers, web development, Website Accessibility
Web Accessibility: More Than Screen Readers

Most teams begin their accessibility work with screen readers. It’s a sensible place to start, and it teaches good habits—clear headings, useful labels, predictable focus. But if you watch how people actually move through the web, the story quickly widens. Someone turns on captions in a quiet office. Another tabs through every link because the mouse hurts their wrist. A shopper zooms text to 200% on a small screen. Others flip on “reduce motion” or prefer calmer layouts that don’t flicker or jump.

Accessibility is shaped by all of those moments. Screen readers matter, but they’re only one piece of a much larger puzzle. When you consider the full range of human needs—and how different kinds of assistive technology come into play—you end up with digital spaces that feel open, intuitive, and usable for far more people.

Screen Readers Matter—Just Not Alone

JAWS, NVDA, and VoiceOver transform what’s on the screen into speech or braille. If your site ignores them, people with vision disabilities get pushed out. Many developers learn a lot by testing with a screen reader: headings need to make sense, labels need to be clear, and focus has to move in a logical path.

Still, a site can sound fine and feel wrong. Someone who magnifies text might meet a broken layout. A keyboard user might fall into a modal they can’t escape. That gap is the real problem to solve.

A Wider View of Assistive Technology

Disability is common, not rare. The World Health Organization estimates that about 1.3 billion people—roughly 16% of the world—live with a significant disability. Only a small slice are blind (about 0.5%), and around 3.7% have moderate-to-severe vision loss. Vision matters, absolutely. But the web serves far more needs than vision alone.

Auditory Access

Deaf and hard-of-hearing people need accurate captions and transcripts for video and audio. As more sites publish reels, demos, and webinars, captions move from “nice to have” to “basic courtesy.”

Motor Access

Precise mouse movement is tough for many users, and sometimes impossible. Keyboard support is the baseline. Some people navigate by voice or eye-tracking. Real buttons and links—rather than clickable <div>s—make those tools work as expected.

Cognitive and neurological access. Dense walls of text, busy layouts, surprise pop-ups, and flashing animation raise the mental load. Clear headings, steady patterns, and plain language help people focus and finish tasks.

Speech Access

Some users rely on text-based or symbol-based communication. Well-labeled forms, predictable flows, and forgiving error messages make participation possible.

And here’s a useful twist: not everyone who uses a screen reader identifies as disabled. WebAIM’s 2024 survey found about one in ten regular users said they didn’t use it due to a disability. Preference and context matter, too.

When a “Pass” Still Leaves People Out

You can pass a quick check and still miss real-world barriers. Text that won’t resize to 200% without breaking the layout shuts out people with low vision. A menu that can’t be reached—or dismissed—by keyboard blocks shoppers who never touch a mouse. Color-only cues hide errors from users with color-vision differences. Dense, academic language can drain energy from anyone with memory or attention challenges.

A familiar story: a developer confirms that a form “reads fine,” then a teammate tries it with only Tab and Shift+Tab and can’t reach the submit button. The fix isn’t complicated. The habit is. Test with and without assistive technology, and try the settings your customers actually use.

Build For Real Use, Not Just Audits

Automated tools catch a lot, but they cannot tell you if the interaction makes sense. People need to know where they are, what just changed, and what to do next. If something looks like a button, it should behave like one. If an error appears, it should be specific, announced to the right place, and easy to fix. That’s usability and accessibility working together, not two separate tracks.

Practical Steps That Respect Assistive Technology

Start with semantic HTML. Headings in order. Real lists. Labels tied to inputs. Landmarks that map the page.

Make the keyboard a first-class path. Every interactive element should accept focus, show a visible focus style, and respond to expected keys like Enter, Space, and Escape.

Keep visuals readable. Meet contrast guidelines. Let text scale to at least 200% without hiding content or controls. Never rely on color alone to convey meaning; pair it with text or an icon.

Use everyday language. Short sentences help. Active voice helps. Concrete verbs help. Jargon is fine when you must use it—just define it once and move on.

Invite real users into the loop. Include people who rely on assistive technology for sign-in, search, checkout, and support flows. A one-hour session with three users can reveal more truth than a week of back-and-forth about edge cases.

Baking these habits into design reviews, code reviews, and QA lowers risk and stress. Teams ship calmer products when inclusion isn’t a last-minute scramble.

Good Usability Helps Everybody

Design choices aimed at one group often lift all boats. Captions help Deaf users and anyone watching a video on mute. High contrast helps people with low vision and anyone standing in bright sun. Keyboard access helps users with motor disabilities and power users who never take their hands off the keys. The same is true for people using assistive technology on small screens, old laptops, or slow connections—clear structure and predictable behavior make sites feel fast even when networks aren’t.

Tools That Talk, Design That Listens

Screen readers changed the web for millions, but they are one part of a broader story. If your site also supports magnification, keyboard navigation, clear language, steady layouts, and strong contrast—while playing well with a variety of assistive technology—you open the door to far more people and far fewer surprises.

If you’re ready to go beyond the basics, 216digital offers ADA briefings tailored to web teams. These sessions give you space to ask questions, identify gaps, and build an action plan with experts who understand accessibility from both a human and business perspective.

Greg McNeil

August 8, 2025

Testing & Remediation, The Benefits of Web Accessibility

assistive technology, keyboard accessibility, screen readers
Lost in Focus? Blame Keyboard Traps
You’ve probably been there. You build a custom modal or some fancy dropdown, tab into it to test, and suddenly you’re stuck. Focus won’t move. The Tab key feels broken, Shift+Tab does nothing, and Escape isn’t helping either. That’s not a bug in your laptop—it’s a keyboard trap.

And honestly? They’re way more common than we like to admit. WebAIM has been flagging them as one of the top accessibility failures for over a decade, and the problem hasn’t really improved. The thing is, you don’t need to be an accessibility specialist to fix them. You just need to understand how they occur, how the Web Accessibility Guidelines (WCAG) addresses them, and how to integrate prevention into your regular workflow. Let’s talk through it, developer to developer.

What Are Keyboard Traps?

A keyboard trap happens when focus moves into a component but can’t get back out using standard keyboard navigation. That usually means Tab and Shift+Tab stop working, Escape is ignored, and the user is stuck.

According to WCAG Success Criterion 2.1.2 (“No Keyboard Trap”), any element that takes focus must also provide a way to exit using only the keyboard. In other words: if your widget can grab focus, it must also let go of it.

For developers, this is more than a compliance checkmark. A trap breaks assumptions about how users move through a page. It disrupts assistive tech like screen readers and can fail QA instantly. Even if the rest of your site is clean, one trap in a modal or custom control can undo the entire user journey.

Who’s Affected (And Why You Should Care)

It’s easy to think of accessibility in the abstract, but keyboard traps create very real roadblocks:
- Motor-impaired users rely on the keyboard because a mouse isn’t practical.
- People with temporary injuries—a broken wrist, for example—may need keyboard-only navigation for weeks.
- Screen reader users follow focus to know where they are. If it never moves, the reader has nothing more to say.
- Developers themselves—many of us use the keyboard for speed. If you’ve ever hit Tab to check your own work and gotten stuck, you know how disruptive it feels.
Bottom line: if your component can trap you, it can trap someone who doesn’t have another option.

So where do these traps usually show up? More often than not, in the places where we customize behavior.

Where Keyboard Traps Hide

Traps aren’t usually intentional. They sneak in where custom code overrides native behavior. Here are the usual suspects:

Modals, Popovers, and Dialogs

A modal with div role="dialog" looks great until focus disappears inside. The fix is to intentionally loop focus only while the modal is open and let Escape close it:
```
function trapFocus(modalEl) {
  const focusable = modalEl.querySelectorAll(
    'a[href], button:not([disabled]), input, textarea, select, [tabindex]:not([tabindex="-1"])'
  );
  const first = focusable[0];
  const last = focusable[focusable.length - 1];
  modalEl.addEventListener("keydown", e => {
    if (e.key === "Tab") {
      // If Shift+Tab on first element, wrap back to last
      if (e.shiftKey && document.activeElement === first) {
        e.preventDefault();
        last.focus();
      }
      // If Tab on last element, wrap back to first
      else if (!e.shiftKey && document.activeElement === last) {
        e.preventDefault();
        first.focus();
      }
    } else if (e.key === "Escape") {
      // Allow users to close with Escape and return focus
      closeModal();
    }
  });
}
```
This follows WAI-ARIA practices: focus a meaningful element on open, loop safely, and return focus when closing.

Forms and Custom Inputs

Date pickers or masked inputs often intercept arrow keys, Enter, or Tab. Without an Escape handler, the user is locked. Keep event listeners scoped:
```
datePickerEl.addEventListener("keydown", e => {
  switch (e.key) {
    case "ArrowLeft": /* move date */ break;
    case "ArrowRight": /* move date */ break;
    case "Escape":
      // Escape should always close and release focus
      closeDatePicker();
      break;
    default:
      return; // Don’t block Tab or Shift+Tab
  }
});
```
Also keep aria-expanded updated so assistive tech knows when a picker is open or closed.

Media Players

Custom video players sometimes swallow every keydown. Space, arrows, and Tab all get blocked. That’s a recipe for keyboard traps. Instead:
```
playerEl.addEventListener("keydown", e => {
  if (e.key === " " || e.key.startsWith("Arrow")) {
    // Map keys to playback controls (play, pause, seek, etc.)
    e.stopPropagation(); // Stop event bubbling, but don’t block Tab
  }
  // Important: Don’t block Tab!
});
```
For YouTube iframes, use ?disablekb=1 to disable its shortcuts and implement your own accessible ones.

JavaScript-Enhanced Links

Sometimes developers add keydown handlers to links or buttons that override Tab. If you call preventDefault() on Tab, you’ve created a trap.

Rule of thumb: only intercept Space or Enter for activation. Let Tab do its job.

Testing for Keyboard Traps

Automation tools like WAVE or Lighthouse can catch some violations, but many traps slip through. Manual checks are essential:
- Start at the browser address bar.
- Press Tab repeatedly.
- Watch the focus ring. Does it keep moving or stall?
- Use Shift+Tab to go backward.
- Open components like modals, menus, or players. Try Escape. Does it close and return focus?
Build this into your QA flow. Think of it as a “keyboard-only smoke test.” It takes two minutes and can save your users hours of frustration.

Best Practices for Trap-Safe Code

To keep keyboard traps out of your codebase:
- Use native elements whenever possible—buttons, links, selects. They come with keyboard behavior for free.
- Follow ARIA Authoring Practices when building custom components. They define expected key behavior for dialogs, menus, and more.
- Centralize focus-trap utilities. Don’t reinvent it in every modal.
- Document the behavior. A hint like “Press Escape to close” in a dialog helps everyone.
- Add accessibility checks in your Storybook or Cypress tests. Press Tab in your stories. Does it cycle correctly?
A Safe Dropdown in Action

Here’s a minimal example of a dropdown that avoids keyboard traps:
```
<button id="dropdown-trigger" aria-expanded="false" aria-controls="dropdown-menu">
  Options
</button>
<ul id="dropdown-menu" role="menu" hidden>
  <li role="menuitem"><a href="#">Profile</a></li>
  <li role="menuitem"><a href="#">Settings</a></li>
  <li role="menuitem"><a href="#">Logout</a></li>
</ul>
```
With the right ARIA attributes and by leaving Tab behavior untouched, this dropdown stays safe and accessible.

Build Trap Prevention into Your Workflow

Don’t treat accessibility like a last-minute patch. Bake it into your process:
- Add “keyboard-only test” to your pull request checklist.
- Run axe-core or similar tools on staging builds.
- Train QA and PMs to check focus flows during reviews.
- Pair with design: ask early, “How would this work without a mouse?”
These habits don’t just prevent keyboard traps—they build a culture of inclusive development.

Focus on What Matters

Accessibility slips often come from the smallest details—like a single missing Escape handler or an overzealous preventDefault(). But those little choices ripple out into real-world barriers. The upside is, once you start looking for them, traps are one of the easiest things to fix—and the payoff is huge.

If you’re looking to strengthen your accessibility practices and reduce risk, 216digital offers ADA briefings tailored specifically for development teams. These sessions go beyond checklists—they walk through real code examples, explain how WCAG applies in day-to-day work, and give your team a clear roadmap for building components that won’t leave users stuck. It’s a chance to ask questions, get practical guidance, and bring accessibility into your workflow in a way that lasts.

Schedule an ADA briefing today and start building better, more inclusive code.
Greg McNeil

August 4, 2025

How-to Guides

Accessibility, How-to, keyboard accessibility, Keyboard Navigation, Keyboard traps, web developers, web development, Website Accessibility
Keyboard Accessibility: A Guide for Web Developers
Think about the last time you visited a website with a complex menu or a long list of links. If you tried navigating without a mouse—maybe because you found it faster to use the Tab key—you might have encountered invisible outlines, a random tab order, or even getting stuck in a popup with no clear way out. These problems highlight why keyboard accessibility is essential.

When websites are built so that every button, link, and form field is accessible via keyboard, it becomes easier for everyone to navigate and complete tasks.

What Is Keyboard Accessibility?

At its core, keyboard accessibility ensures that everything on a website can be reached and used without a mouse. This is crucial for people with motor impairments who rely on keyboards or assistive devices, as well as users with visual impairments who navigate with screen readers. Even power users benefit, often finding keyboard shortcuts and navigation faster than using a mouse.

Beyond improving usability, proper keyboard accessibility leads to better-organized code and a more logical page structure—benefits that search engines reward with better SEO rankings. Simply put, improving keyboard accessibility benefits both users and website owners. However, achieving it comes with challenges.

Common Keyboard Accessibility Challenges

Despite its importance, keyboard accessibility is often overlooked. Many websites suffer from poor focus visibility, illogical tab orders, and keyboard traps that frustrate users. Addressing these pitfalls is key to creating a smooth, user-friendly experience.

Below are three of the most common keyboard accessibility issues—and how to fix them.

1. Designing Effective Focus Indicators

Focus indicators visually highlight which element is currently selected when navigating with a keyboard. They help users track their position as they move through a webpage using the Tab key.

Why Focus Indicators Matter

Imagine navigating a website solely by keyboard. If you press Tab but can’t see where you are because the focus highlight is too faint—or missing altogether—you’re left guessing. This creates confusion and frustration. Clear, high-contrast focus indicators ensure users always know where they are on the page.

Best Practices for Focus Indicators
- Outline thickness: At least 2 CSS pixels
- Outline offset: Keep at least 2 CSS pixels between the outline and the element’s edge
- Contrast ratio: A minimum of 3:1 between the focus indicator and the background
Understanding the :focus-visible Pseudo-Class

The :focus selector applies styles whenever an element gains focus, including when it’s clicked with a mouse. But :focus-visible applies focus styles only when an element is navigated via keyboard, keeping the interface clean for mouse users while ensuring keyboard users get clear visual cues.

Example:
```
*:focus-visible {
  border: 2px solid black; /* Ensure noticeable contrast */
  outline-offset: 2px;
}
```
2. Maintaining a Logical Navigation Order

Users navigate websites sequentially using the Tab key. The focus order should match the visual layout to avoid confusion. A mismatch disrupts the browsing experience, making it difficult for users to predict what comes next.

Tips for Logical Navigation
- Use proper HTML structure: Semantic elements like headers (<h1> – <h6>), lists, and landmarks guide screen readers and browsers to interpret content correctly.
- Avoid positive tabindex values: Manually setting a positive tabindex can force elements into an unnatural order, leading to confusion.
- Provide “Skip to Main Content” links: These allow users to bypass repetitive navigation and jump straight to the main content.
- Beware of keyboard traps: Ensure users can always navigate away from popups, modals, or embedded elements using only the keyboard.
3. Proper tabindex Implementation

The tabindex attribute controls how elements receive focus. While useful in some cases, it’s often misused.

What tabindex Does
- tabindex="0": Inserts the element into the default tab order based on its position in the DOM. Ideal for custom interactive elements like <div> buttons.
- tabindex="-1": Removes an element from sequential keyboard navigation but allows focus via scripting. Useful for modals or hidden elements.
- Positive values (e.g., tabindex="1"): Best avoided, as forcing a custom order can break the expected tab sequence and frustrate users.
Best Practices
- Use semantic HTML (<button>, <a>), which is naturally keyboard-accessible.
- Avoid adding tabindex to non-interactive elements like text or static images.
- Use negative tabindex for hidden or modal content that should only receive focus under certain conditions.
- Stick to the natural tab order whenever possible—custom focus orders should be a last resort.
Testing Your Website’s Keyboard Accessibility

Even with best practices in place, testing is essential to catch issues before they impact users. A combination of manual and automated testing provides the most reliable results.

Manual Testing
- Navigate using only a keyboard: Use the Tab key to move through all interactive elements. Press Enter (or Space) to activate buttons and links.
- Check focus visibility: Ensure focus indicators are always clear and meet contrast requirements.
- Verify logical tab order: Does the sequence make sense based on how someone would naturally read or navigate your page?
- Watch for keyboard traps: Ensure modals, dropdowns, and embedded content allow users to navigate away freely.
Automated Testing Tools

Browser-Based Tools
- Firefox Accessibility Inspector: Displays how the browser interprets focusable elements.
- Chrome DevTools (Accessibility Panel): Helps analyze the site’s structure.
- WAVE Evaluation Tool: Flags potential accessibility issues directly in the browser.
While these tools are powerful, nothing replaces real user feedback. Testing with people who rely on keyboard navigation often reveals hidden issues automated tools miss.

Conclusion

Keyboard accessibility is a fundamental part of inclusive web design. Making sure users can navigate your site without a mouse ensures better usability for everyone—including people with disabilities who rely on keyboard navigation. Plus, it improves SEO, usability, and compliance, making it a win-win for both users and businesses.

The best practices covered here—such as customizing focus indicators, maintaining a logical tab order, and using tabindex responsibly—are essential steps toward a more accessible website. Regular testing, both manual and automated, helps ensure your site meets WCAG guidelines and delivers a smooth experience for all users.

For expert guidance, consider working with accessibility professionals like 216digital. Specialists can help you implement strategies that go beyond basic compliance, ensuring long-term usability and inclusivity. When you prioritize keyboard accessibility, you create a more welcoming web for everyone—and that’s a goal worth striving for.
Greg McNeil

March 13, 2025

How-to Guides

Accessibility, keyboard accessibility, Keyboard Navigation, tabindex, Web Accessibility, web developers, web development
Keyboard Navigation: A Guide to Accessible Web Testing
Have you ever tried using the internet without a mouse?

For millions of people, that’s not just a thought experiment—it’s how they navigate the internet every day. Whether it’s because of physical limitations, visual impairments, or using assistive tech, the keyboard is their main tool. But here’s the thing: if your website doesn’t work smoothly with a keyboard, you’re not just creating a frustrating experience—you’re leaving people behind.

So, how does your site stack up? Let’s dive into why keyboard navigation matters and how it plays a key role in building an accessible web.

Why Keyboard Navigation Matters

Keyboard navigation is a lifeline for users who can’t rely on a mouse due to physical limitations, visual impairments, or the use of assistive technologies. Moreover, it’s an excellent starting point for testing overall web accessibility. If your website works seamlessly with a keyboard, you’re likely on track to create an inclusive experience for all users.

How to Navigate a Website with Keyboard Shortcuts

Before you start testing your website’s accessibility, it’s helpful to understand the most common keyboard shortcuts users rely on. These shortcuts allow people to move through links, buttons, forms, and other interactive elements.
- Tab Key: Moves focus to the next interactive element.
- Shift + Tab: Moves focus to the previous element.
- Enter or Spacebar: Activates a focused element, such as clicking a link or button.
- Arrow Keys: Scroll through pages or navigate dropdown menus.
- Escape (Esc): Closes modals, dropdowns, or pop-ups.
- Ctrl + F: Opens a search bar (in most browsers) to find specific content on the page.
For Mac users on Safari, enabling full keyboard navigation is a quick adjustment:
1. Open Safari Preferences.
2. Go to the Advanced tab.
3. Check the box next to “Press Tab to highlight each item on a webpage.”
With these basics in mind, you’re ready to put your website to the test.

Testing Your Website for Keyboard Navigation

Keyboard testing doesn’t require fancy tools—just a keyboard, a browser, and a little know-how. Follow this step-by-step guide to evaluate your site’s accessibility.

Start with the Basics: Can You Navigate Without a Mouse?

Unplug your mouse and navigate through your homepage and other key pages using only the keyboard. Can you access all essential features and content?

Check Focus Indicators

Focus indicators are crucial for users who rely on visual cues. As you use the Tab key, ensure there’s a visible outline around the element currently in focus. Check for the following:
- The focus indicator is easy to see and contrasts well with the background.
- The focus moves logically through elements in the order they appear on the page.
If the focus jumps around or disappears, it creates a frustrating experience for users.

Test Interactive Elements

Interactive elements like buttons, links, and form fields should be fully accessible. Specifically:
- Can you submit a form using the Enter or Spacebar key?
- Can you open and close modals or dropdown menus with the keyboard?
- Do navigation menus function seamlessly?
Verify Skip Navigation Links

Skip navigation links allow users to bypass repetitive elements, like menus, and jump straight to the main content. To check this:
- Ensure the skip navigation link is present and functional.
- Verify it’s one of the first focusable elements when using the Tab key.
Watch Out for Keyboard Traps

Keyboard traps occur when users get stuck in an element, like a modal or widget, and can’t move forward. Ensure users can exit these areas by pressing the Escape key or tabbing out.

Tips for Better Keyboard Navigation

Creating an accessible website doesn’t happen by accident. Here are a few tips to enhance keyboard navigation for all users:
- Design with Focus in Mind: Use CSS to style focus outlines for clarity and visibility. Avoid removing focus outlines entirely.
- Ensure Logical Focus Order: Use semantic HTML (e.g., <button> and <a>) and avoid custom elements that might disrupt natural focus flow.
- Leverage ARIA Roles and Labels: Use ARIA (Accessible Rich Internet Applications) roles and labels to make custom components like sliders or dropdowns keyboard accessible.
- Test Regularly: Accessibility is not a one-and-done task. Regular testing ensures your website stays accessible as it evolves.
Common Challenges and How to Address Them

Even with the best intentions, challenges may arise. Here are some common issues and solutions:
- Invisible Focus: Use the :focus pseudo-class in CSS to style interactive elements for better visibility.
- Complex Widgets: Components like carousels or accordions can lack keyboard support. Build these elements with accessibility in mind or use accessible libraries.
- Poorly Labeled Links: Ensure all links and buttons have clear, descriptive text or labels so users know what action they’ll perform.
Why Focus on Keyboard Navigation?

Beyond accessibility, testing your website for keyboard navigation improves overall user experience and usability. Keyboard accessibility is often a foundation for ensuring compatibility with screen readers and other assistive technologies. If your website works well for a keyboard user, it’s likely on its way to meeting broader accessibility standards like WCAG 2.1.

Next Steps: Make Your Website Keyboard-Accessible

Keyboard navigation is more than just a best practice—it’s a cornerstone of inclusive design that invites everyone to participate fully on the web. By ensuring your site is keyboard-accessible, you create a welcoming experience for users of all abilities, reinforce your brand’s commitment to accessibility, and lay a strong foundation for broader ADA compliance.

If you’re ready to take the next step toward digital inclusion, reach out to 216digital to schedule an ADA briefing. We’ll help you assess your website, develop a tailored plan, and guide you through the process of building an online presence that works for everyone. Don’t wait—contact us today and let’s make the internet a more accessible place together.
Greg McNeil

December 24, 2024

How-to Guides, Testing & Remediation

Accessibility testing, keyboard accessibility, Keyboard Navigation, User Experience, Web Accessibility
The Importance of Keyboard Accessibility & Why ARIA Widgets Don’t Work
Keyboard accessibility is a fundamental part of creating an accessible web experience. For many people, including those with motor impairments, the ability to navigate a website using only a keyboard is essential. Unfortunately, not all website interactive elements are designed with keyboard users in mind. This is where ARIA (Accessible Rich Internet Applications) widgets often come into play—intended to improve accessibility but frequently falling short when misused.

Understanding the principles of keyboard accessibility and the limitations of ARIA widgets can help website owners, developers, and content creators deliver a more inclusive user experience. Let’s explore the most common keyboard accessibility issues, why ARIA widgets often miss the mark, and how you can design your website to meet Web Content Accessibility Guidelines (WCAG) standards.

Why Keyboard Accessibility Matters

Keyboard accessibility ensures that all interactive elements on a website—like buttons, forms, links, and menus—are reachable and usable without needing a mouse. Many users, such as those with motor disabilities or vision impairments, rely on keyboards, screen readers, or other assistive devices to navigate web content.

Without keyboard accessibility, people using assistive technology can encounter significant barriers, preventing them from completing tasks or navigating the site. For instance, a checkout form that only allows interaction through mouse clicks will stop a keyboard user in their tracks, impacting their ability to purchase a product or service.

Common Barriers to Keyboard Accessibility

Some of the most common obstacles that keyboard users face on websites include:

Lack of Focus Indicators
- Problem: Without visible focus indicators, keyboard users may not know where they are on the page. This becomes particularly frustrating when navigating forms or interactive menus.
- Solution: Use CSS to style focus indicators and make them highly visible, such as by changing the border color, background, or outline. Here’s an example:
```
button:focus, a:focus {
	outline: 3px solid #005fcc;
	background-color: #f0f8ff;
}
```
Improper Tab Order
- Problem: Elements on a page need to logically match the visual layout. Without a logical tab order, users may be taken through an erratic sequence, which can lead to confusion and missed information.
- Solution: Arrange your elements in HTML to follow the intended visual order and limit use of the tabindex attribute. By default, elements will follow the document’s source order, so it’s best to organize your code this way.
Focus Traps
- Problem: Focus traps occur when users can’t tab away from a particular element, like a popup or modal. Once they’re stuck, the rest of the page becomes inaccessible until they can close the focus-trapped section.
- Solution: Ensure focus returns to the main content once the user dismisses the popup or modal, using JavaScript if necessary:
```
// Example of returning focus after modal close
document.getElementById("closeModalButton").addEventListener("click", function() {
  document.getElementById("mainContent").focus();
});
```
ARIA Widgets and Their Challenges

ARIA (Accessible Rich Internet Applications) is a set of attributes that help improve the accessibility of web applications, particularly for screen readers. However, ARIA widgets—such as dropdowns, sliders, and modals—often don’t work as expected for keyboard users if not implemented carefully. ARIA can enhance accessibility, but it can’t “fix” poor coding practices or make non-native elements fully functional on its own.

Why ARIA Widgets Often Fail

ARIA widgets can be highly effective but only if they’re properly coded, tested, and consistently used with accessibility in mind. Here are some common pitfalls:

Reliance on ARIA Without Semantic HTML

ARIA is not a replacement for HTML5 elements; it’s meant to enhance them. Using ARIA on elements that don’t support native keyboard interactions (like <div> for a button) means the widget might lack inherent keyboard functionality.

For example, instead of creating a clickable div with ARIA, use a <button> tag. Buttons come with native keyboard functionality and don’t require extra scripting or attributes to work as expected.

Overuse of role and tabindex Attributes

Misusing role attributes can disrupt how screen readers interact with elements. For instance, assigning a role= "button" to a div won’t make it work the same way as a real button.

Similarly, improper use of tabindex can cause elements to jump around in an illogical order. Stick to the natural flow of the DOM, using tabindex= "0" only when absolutely necessary to keep the order in sync.

JavaScript-Dependent Behavior

ARIA widgets often rely on JavaScript to replicate native interactions, but these scripts must be meticulously coded and tested. A JavaScript error could render an entire widget inaccessible.

Testing your scripts thoroughly with keyboard-only navigation is essential, especially for ARIA widgets. Missing key events like “Enter” or “Escape” can trap users in a widget or make it difficult to interact with.

Best Practices for Creating Keyboard-Accessible Interactive Elements

To avoid these pitfalls and ensure that your site is truly keyboard accessible, follow these best practices:

Prioritize Native HTML Elements

Whenever possible, use native HTML elements for interactivity (like <button>, <a>, <input>, and <select>). They come with built-in accessibility and keyboard support, reducing the need for complex ARIA attributes or custom JavaScript.

Use ARIA Judiciously

Use ARIA only when there’s no HTML equivalent, like custom dropdowns or sliders. And if you do need ARIA attributes, implement them carefully with an understanding of their purpose. For example, use aria-expanded to indicate the open or closed state of a dropdown menu:
```
<button aria-expanded="false" aria-controls="menu">Menu</button>
<ul id= "menu" hidden>
  <li><a href="#home">Home</a></li>
  <li><a href="#about">About</a></li>
</ul>
```
Enable Logical Focus Management

Ensure that interactive elements maintain a logical and intuitive focus order. When creating modals or popups, use JavaScript to trap focus within the modal until it’s closed and then return focus to the last element interacted with:
```
const modal = document.getElementById("modal");
const lastFocus = document.activeElement;
// Trap focus within modal
modal.addEventListener("keydown", (e) => {
  if (e.key === "Tab") {
    // Logic to keep focus within modal
  }
});
// Restore focus after modal close
modal.addEventListener("close", () => {
  lastFocus.focus();
});
```
Include Skip Links

Skip links are simple yet effective. They allow keyboard users to jump directly to the main content, bypassing repetitive navigation menus. Add a skip link that appears when focused, like this:
```
<a href="#mainContent" class="skip-link">Skip to main content</a>
<main id="mainContent">
  
</main>
```
The Importance of Testing for Keyboard Accessibility

Testing is critical to achieving real keyboard accessibility. Use keyboard-only navigation to interact with your site, ensuring that each element responds to the Tab, Enter, and Escape keys appropriately. Here are a few tips for testing:
1. Turn Off Your Mouse: Try navigating your site using only the keyboard. See if you can reach every interactive element and complete all tasks.
2. Use Assistive Technology Simulators: There are free screen readers (such as NVDA or VoiceOver) that let you experience your website as a keyboard-only user would.
3. Run Accessibility Audits: Automated tools like Google Lighthouse or WAVE can catch many keyboard accessibility issues, but a manual review is still necessary.
Conclusion

Keyboard accessibility is a must for ensuring inclusivity on your website. By avoiding ARIA misuse and sticking to native HTML elements where possible, you’ll reduce barriers for keyboard users and create a smoother experience. Remember, ARIA attributes can enhance interactivity, but they aren’t a substitute for accessible design principles.

Testing with keyboard-only navigation will confirm that your site meets WCAG standards and shows your commitment to creating a web experience that everyone can enjoy—just in time for all your visitors to get the most out of your content and promotions. Reach out to 216digital using the contact form below if you’re unsure if your website is keyboard navigable.
Bobby

October 29, 2024

How-to Guides

ARIA, How-to, keyboard accessibility, web developers, web development

Why ARIA Alone Won’t Fix Your Website’s Accessibility

What ARIA Is—and What It’s Supposed to Do

When Is It Necessary?

Why It Shouldn’t Be the Default Tool

Common ARIA Misuse That Breaks Accessibility

Why ARIA Usage Correlates with More Errors

The Real Fix: Manual Testing and Developer Discipline

Testing It in the Real World

Build a Feedback Loop Into the Dev Process

Practical Guidelines for Responsible ARIA Use

ARIA Isn’t a Shortcut—It’s a Responsibility

Shift Happens—But Not On Focus

Understanding Success Criterion 3.2.1 – On Focus

Why On Focus Matters

Common Pitfalls (and Why They Break On Focus)

How to Achieve Compliance (and Design a Better Experience)

Testing Strategies for On Focus

Manual testing

Assistive Technology Testing

Automated Checks

Bad vs. Good: Concrete Examples

Bad: Form Submits on Focus

Good: Form Submits Only on Activation

Bad: Navigation on Focus

Good: Navigation Only on Activation

Good Example: Custom Control with Predictable Focus

Frequently Asked Questions

Build Predictable Experiences (and Trust)

Web Accessibility: More Than Screen Readers

Screen Readers Matter—Just Not Alone

A Wider View of Assistive Technology

Auditory Access

Motor Access

Speech Access

When a “Pass” Still Leaves People Out

Build For Real Use, Not Just Audits

Practical Steps That Respect Assistive Technology

Good Usability Helps Everybody

Tools That Talk, Design That Listens

Lost in Focus? Blame Keyboard Traps

What Are Keyboard Traps?

Who’s Affected (And Why You Should Care)

Where Keyboard Traps Hide

Modals, Popovers, and Dialogs

Forms and Custom Inputs

Media Players

JavaScript-Enhanced Links

Testing for Keyboard Traps

Best Practices for Trap-Safe Code

A Safe Dropdown in Action

Build Trap Prevention into Your Workflow

Focus on What Matters

Keyboard Accessibility: A Guide for Web Developers

What Is Keyboard Accessibility?

Common Keyboard Accessibility Challenges

1. Designing Effective Focus Indicators

Why Focus Indicators Matter

Best Practices for Focus Indicators

Understanding the :focus-visible Pseudo-Class

2. Maintaining a Logical Navigation Order

Tips for Logical Navigation

3. Proper tabindex Implementation

What tabindex Does

Best Practices

Testing Your Website’s Keyboard Accessibility

Manual Testing

Automated Testing Tools

Browser-Based Tools

Conclusion

Keyboard Navigation: A Guide to Accessible Web Testing

Why Keyboard Navigation Matters

How to Navigate a Website with Keyboard Shortcuts

Testing Your Website for Keyboard Navigation

Start with the Basics: Can You Navigate Without a Mouse?

Check Focus Indicators

Test Interactive Elements

Verify Skip Navigation Links

Watch Out for Keyboard Traps

Tips for Better Keyboard Navigation

Common Challenges and How to Address Them

Understanding the `:focus-visible` Pseudo-Class

3. Proper `tabindex` Implementation