I spent years writing JavaScript that worked for me—on my screen, with my mouse, in my quiet office. Then I watched a colleague who is blind try to use one of my forms. He tabbed through the fields, heard nothing useful, and gave up. That moment changed everything. Accessibility isn’t a checklist or a moral badge. It’s a technical reality. If your code can’t be operated by someone who can’t see, or who never touches a mouse, you’ve built a wall where there should be a door.
These seven patterns are the tools I now use to tear down those walls. They’re not optional extras. They’re the difference between an application that excludes and one that includes. Let me show you how I built them, one piece at a time.
The first pattern is dynamic ARIA attribute management. When your interface changes—a button toggles a menu, a form submits, a modal appears—screen readers need to know. You can’t just change the visual state and hope for the best. You must update the accessibility attributes that announce those changes.
I like to think of ARIA attributes as the sign language of web interfaces. They tell assistive technologies what’s happening. aria-expanded says whether a dropdown is open. aria-label provides a textual alternative for an icon. aria-live signals that content has changed and needs to be announced.
Here’s a utility I wrote for updating a live region. It forces the screen reader to speak a message, even if the same text appears again later. That’s important because many screen readers skip repeated identical announcements.
function updateLiveRegion(element, message, priority = 'polite') {
element.setAttribute('aria-live', priority);
element.textContent = '';
requestAnimationFrame(() => {
element.textContent = message;
});
}
// Usage inside a form submission handler
const statusRegion = document.getElementById('form-status');
updateLiveRegion(statusRegion, 'Your data has been saved successfully', 'assertive');
The trick I learned the hard way is the empty string before setting the content. Without that, if the same message appears twice in a row, the screen reader won’t announce it again. The requestAnimationFrame gives the browser time to register the change.
When I first used this pattern, I saw a user’s face light up. She heard “Your data has been saved” and nodded. That’s the goal—no guesswork, no silence.
Focus trapping is the pattern that keeps keyboard users inside modal dialogs, popovers, and sidebars. Without it, pressing Tab sends focus flying into the background, confusing everyone. When a modal opens, focus must be moved inside, and keyboard navigation must loop through only the modal’s interactive elements.
I designed this simple focus trap for a confirmation dialog. It remembers which element opened the modal, so when you close it, focus returns to where it was. That’s critical for keeping navigation predictable.
function createTrapFocus(container) {
const focusableElements = container.querySelectorAll(
'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
);
const firstFocusable = focusableElements[0];
const lastFocusable = focusableElements[focusableElements.length - 1];
const handleTab = (event) => {
if (event.key === 'Tab') {
if (event.shiftKey && document.activeElement === firstFocusable) {
event.preventDefault();
lastFocusable.focus();
} else if (!event.shiftKey && document.activeElement === lastFocusable) {
event.preventDefault();
firstFocusable.focus();
}
}
};
return {
activate(originElement) {
this.previousFocus = originElement || document.activeElement;
container.style.display = 'block';
firstFocusable.focus();
container.addEventListener('keydown', handleTab);
},
deactivate() {
container.style.display = 'none';
container.removeEventListener('keydown', handleTab);
if (this.previousFocus) {
this.previousFocus.focus();
}
}
};
}
// Usage
const modal = document.getElementById('confirm-modal');
const trap = createTrapFocus(modal);
document.getElementById('delete-btn').addEventListener('click', (e) => {
trap.activate(e.target);
});
One mistake I made early on: I forgot to remove the event listener when the modal closed. That caused residual handlers to pile up and break focus logic on subsequent opens. Always clean up your listeners.
Keyboard navigation patterns make custom widgets behave like native controls. A custom select element, for example, should respond to arrow keys, Enter, Escape, and Tab in ways that match the operating system’s conventions. The WAI-ARIA Authoring Practices guide gives specific keyboard mappings for each widget type.
I built a CustomSelect class that implements those mappings. The button opens the listbox. Arrow keys move focus through options. Enter selects and closes. Escape closes without selecting. Tab moves out of the widget. Every action has a corresponding ARIA attribute update.
class CustomSelect {
constructor(element) {
this.button = element.querySelector('.select-button');
this.listbox = element.querySelector('.select-listbox');
this.options = Array.from(this.listbox.querySelectorAll('[role="option"]'));
this.currentIndex = -1;
this.button.addEventListener('click', () => this.toggle());
this.button.addEventListener('keydown', (e) => this.handleButtonKey(e));
this.listbox.addEventListener('keydown', (e) => this.handleListKey(e));
}
handleButtonKey(event) {
switch (event.key) {
case 'ArrowDown':
case 'ArrowUp':
event.preventDefault();
this.open();
break;
case 'Enter':
case ' ':
event.preventDefault();
this.toggle();
break;
}
}
handleListKey(event) {
switch (event.key) {
case 'ArrowDown':
event.preventDefault();
this.focusNext();
break;
case 'ArrowUp':
event.preventDefault();
this.focusPrevious();
break;
case 'Enter':
event.preventDefault();
this.select();
break;
case 'Escape':
event.preventDefault();
this.close();
break;
}
}
focusNext() {
this.currentIndex = (this.currentIndex + 1) % this.options.length;
this.options[this.currentIndex].focus();
}
focusPrevious() {
this.currentIndex = (this.currentIndex - 1 + this.options.length) % this.options.length;
this.options[this.currentIndex].focus();
}
toggle() {
this.listbox.hidden ? this.open() : this.close();
}
open() {
this.listbox.hidden = false;
this.button.setAttribute('aria-expanded', 'true');
if (this.currentIndex === -1) this.currentIndex = 0;
this.options[this.currentIndex].focus();
}
close() {
this.listbox.hidden = true;
this.button.setAttribute('aria-expanded', 'false');
this.button.focus();
}
}
Testing this pattern with only the keyboard taught me to never assume what “obvious” means. I fat-fingered the arrow keys many times before I got the loop logic right. But once it worked, I could navigate through 50 options without once looking at the screen.
Announcing dynamic content is about keeping screen reader users informed of changes they can’t see. Toast notifications, progress bars, and search results that appear without a page reload need to be spoken. The aria-live region is the mechanism.
I wrote a small factory function that creates a hidden live region and exposes an announce method. You can choose between “polite” (waits for the current sentence to finish) and “assertive” (interrupts immediately). I always use “polite” for search results and “assertive” for errors.
function createAnnouncer() {
const region = document.createElement('div');
region.setAttribute('aria-live', 'polite');
region.setAttribute('aria-atomic', 'true');
region.style.cssText = 'position: absolute; width: 1px; height: 1px; overflow: hidden; clip: rect(0,0,0,0);';
document.body.appendChild(region);
return {
announce(message, priority = 'polite') {
region.setAttribute('aria-live', priority);
region.textContent = '';
requestAnimationFrame(() => {
region.textContent = message;
});
},
destroy() {
region.remove();
}
};
}
// Usage inside a search input with debounce
const announcer = createAnnouncer();
searchInput.addEventListener('input', debounce(async () => {
const results = await fetchResults(searchInput.value);
const count = results.length;
announcer.announce(
count ? `${count} results found for "${searchInput.value}"` : 'No results found'
);
}, 300));
The aria-atomic="true" attribute tells the screen reader to treat the entire region content as a single unit, rather than reading only the changed part. Without it, you might hear only the new characters appended to the old text.
I use this pattern in a real-time dashboard. Every time new data streams in, the live region announces the update summary. Users told me they stopped wondering “Did anything happen?”—they now know.
Color contrast validation might seem like a design concern, but JavaScript can check it programmatically. When building a theming system or a color picker, you need to ensure text meets WCAG contrast ratios. I wrote a utility that calculates relative luminance and returns the ratio.
function getContrastRatio(hex1, hex2) {
const luminance = (hex) => {
const r = parseInt(hex.slice(1, 3), 16) / 255;
const g = parseInt(hex.slice(3, 5), 16) / 255;
const b = parseInt(hex.slice(5, 7), 16) / 255;
const srgb = [r, g, b].map(c =>
c <= 0.03928 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4)
);
return 0.2126 * srgb[0] + 0.7152 * srgb[1] + 0.0722 * srgb[2];
};
const l1 = luminance(hex1);
const l2 = luminance(hex2);
const lighter = Math.max(l1, l2);
const darker = Math.min(l1, l2);
return (lighter + 0.05) / (darker + 0.05);
}
function validateTextColor(foreground, background) {
const ratio = getContrastRatio(foreground, background);
const passesAA = ratio >= 4.5; // Normal text
const passesAAA = ratio >= 7; // Enhanced
return { ratio, passesAA, passesAAA };
}
I integrated this into a theme editor. When a user picks a text color that fails against the background, a red outline appears and a tooltip warns them. It saved several themes from shipping with invisible text. One designer told me, “I never realized how bad my color choices were until I saw the numbers.”
Skip navigation links are the oldest pattern in the accessibility book, but still the most forgotten. They give keyboard users a direct path to the main content, bypassing long navigation menus. The link is visually hidden until it receives focus, then appears at the top of the page.
I wrote a setup function that creates the skip link on page load, manages its visibility on focus and blur, and moves focus to the target element when clicked. The trick is to set tabindex="-1" on the target so it can receive focus, then remove it after the first blur to avoid messing up tab order.
function setupSkipLink() {
const skipLink = document.createElement('a');
skipLink.href = '#main-content';
skipLink.textContent = 'Skip to main content';
skipLink.className = 'skip-link';
skipLink.style.cssText = `
position: absolute;
top: -40px;
left: 0;
background: #000;
color: #fff;
padding: 8px 16px;
z-index: 100;
transition: top 0.1s;
`;
document.body.prepend(skipLink);
skipLink.addEventListener('focus', () => {
skipLink.style.top = '0';
});
skipLink.addEventListener('blur', () => {
skipLink.style.top = '-40px';
});
skipLink.addEventListener('click', (e) => {
e.preventDefault();
const target = document.querySelector(skipLink.hash);
if (target) {
target.setAttribute('tabindex', '-1');
target.focus();
target.addEventListener('blur', () => {
target.removeAttribute('tabindex');
}, { once: true });
}
});
}
document.addEventListener('DOMContentLoaded', setupSkipLink);
I remember the first time I watched a keyboard-only tester use this. He pressed Tab once, saw the link, hit Enter, and was instantly at the article body. He smiled and said, “You have no idea how refreshing this is.” That’s why I never skip skip links.
Automated accessibility testing catches regressions before they reach production. I integrate axe-core into my CI pipeline. Every pull request triggers a Puppeteer scan of the rendered page. If violations appear—like missing alt text or insufficient contrast—the build fails.
const { AxePuppeteer } = require('@axe-core/puppeteer');
const puppeteer = require('puppeteer');
async function runAccessibilityTests(url) {
const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.setBypassCSP(true);
await page.goto(url, { waitUntil: 'networkidle0' });
const results = await new AxePuppeteer(page)
.withTags(['wcag2a', 'wcag2aa', 'best-practice'])
.analyze();
await browser.close();
if (results.violations.length > 0) {
console.error(`Found ${results.violations.length} accessibility violations:`);
results.violations.forEach(violation => {
console.log(` - ${violation.help} (${violation.id})`);
violation.nodes.forEach(node => {
console.log(` Target: ${node.target.join(', ')}`);
});
});
process.exit(1);
} else {
console.log('No accessibility violations found.');
}
}
// Integration in CI script
// node run-a11y-tests.js https://staging.example.com
This pattern saved me from shipping a form that had no visible labels—only placeholder text. The scan caught it instantly. I added proper labels and the build turned green. Automated checks don’t catch everything, but they catch the easy mistakes that manual testing might miss.
These seven patterns are the hammer, saw, and level of accessible JavaScript. They don’t cover every edge case, but they build a foundation. When I apply them consistently, my applications become places where more people can do their work without fighting the interface.
I still test with real users, because no automated tool can replicate the experience of someone who relies on a screen reader every day. But the patterns give me a starting point—a way to write code that feels less like a barrier and more like an invitation.
Every time I add a focus trap or an ARIA update, I think of that colleague who gave up on my form years ago. He’s no longer frustrated. He’s using my application, and he’s productive. That’s the only metric that matters.
