JavaScript Accessibility Cheat Sheet for Everyday UI Work

Why this cheat sheet exists

JavaScript is often where accessibility wins (or regressions) happen: focus moves, ARIA updates, keyboard handling and dynamic content all live here. The goal of this post is simple: keep a compact, actionable reference nearby so your UI behavior works for keyboard, screen reader and touch users.

Below is the core cheat sheet. Everything else in this post expands on it with examples and small reminders.

Accessibility cheat sheet (keep this table open)

dialogEl.focus();

[tabindex], button, input, a

opener.focus();

close()

button.setAttribute('aria-expanded', isOpen); panel.hidden = !isOpen;

button

el.addEventListener('keydown', onActivate)

aria-live

<div aria-live="polite">

aria-invalid

aria-describedby

field.setAttribute('aria-invalid', 'true')

tabindex="0"

skipLink.focus(); main.scrollIntoView()

button.hidden = false

IntersectionObserver

trigger.addEventListener('focus', show)

aria-live="off"

Key principles before you write code

1. Native elements first. If you can use <button>, <details>, or <dialog>, do it. You get keyboard handling and semantics for free.
2. Focus is a feature. Any time you open, close, or reorder UI, ask: Where should focus go next?
3. State must be perceivable. If something expands, collapses, or changes state, reflect it in ARIA or visible text.
4. Keyboard parity. Everything you can click should be operable with Tab + Enter/Space.

Patterns you can copy

Accessible disclosure component

Code
const button = document.querySelector('[data-disclosure-button]');
const panel = document.querySelector('[data-disclosure-panel]');

button.addEventListener('click', () => {
  const isOpen = button.getAttribute('aria-expanded') === 'true';
  button.setAttribute('aria-expanded', String(!isOpen));
  panel.hidden = isOpen;
});

Checklist: aria-expanded updates, panel uses hidden and the button remains a real <button> element.

Focus management for modal dialogs

Code
const dialog = document.querySelector('[data-dialog]');
const openButton = document.querySelector('[data-dialog-open]');
const closeButton = dialog.querySelector('[data-dialog-close]');

openButton.addEventListener('click', () => {
  dialog.showModal();
  closeButton.focus();
});

closeButton.addEventListener('click', () => {
  dialog.close();
  openButton.focus();
});

If you cannot use <dialog>, mirror the behavior: add role="dialog", trap focus within the modal and restore focus to the opener when closed.

Live region for async status updates

Code
const status = document.querySelector('[data-status]');

function notify(message) {
  status.textContent = '';
  requestAnimationFrame(() => {
    status.textContent = message;
  });
}

Use a div with aria-live="polite" so screen readers announce updates without taking over.

Common pitfalls and quick fixes

• Pitfall: Adding onClick to a <div> without keyboard support.
  Fix: Use a <button> or add tabindex="0", plus Enter/Space handlers.
• Pitfall: Triggering a dropdown but not telling assistive tech.
  Fix: Add aria-expanded to the trigger and toggle it on click.
• Pitfall: Rerendering a list and losing focus.
  Fix: Keep focus on the selected item and restore it after DOM updates.

How to use this in daily work

• Paste the cheat sheet into your project notes or wiki.
• Run through it when you add a new interactive component.
• Pair it with a quick keyboard pass (Tab, Shift+Tab, Enter, Space, Escape).

Final takeaway

Accessibility is not a separate project; it is a set of tiny decisions. If you can remember to manage focus, keep keyboard parity, and announce state changes, your JavaScript will already outperform most production UIs. Keep the table handy, and you will ship inclusive features faster.