Accessibility for Developers
Building accessible web applications means writing markup, styles, and interactions that work for everyone — including people using screen readers, keyboard navigation, voice control, and other assistive technologies.
The NYSDS components handle many accessibility patterns for you: ARIA attributes, keyboard interactions, focus management, and screen reader announcements. But components alone do not make an accessible page. You are responsible for the structure and content that surrounds them.
What You Are Responsible For
Even when using NYSDS components, your pages need:
- Logical heading hierarchy — One
h1per page, followed byh2,h3, etc. in order. Do not skip levels. - Landmark regions — Use
<main>,<nav>,<header>,<footer>, and<aside>so screen readers can navigate by region. - Meaningful link text — "Apply for benefits" instead of "Click here." Links should make sense out of context.
- Alternative text — Descriptive alt text on informational images. Empty
alt=""on decorative images. - Visible focus indicators — Do not remove the default focus outline with
outline: noneunless you replace it with an equally visible indicator. - Language attribute — Set
lang="en"(or the appropriate language) on the<html>element. - Page titles — Every page needs a unique, descriptive
<title>. - Skip navigation — Use the
nys-skipnavcomponent to let keyboard users bypass repetitive navigation.
Testing Tools
Automated tools catch roughly 30-40% of accessibility issues. Manual testing catches the rest. Use both.
Primary Recommended Tools
Accessibility Insights (Microsoft) — The best single tool for starting accessibility testing. Accessibility Insights combines automated checks, guided manual testing workflows, and detailed reporting. It works in Chrome and Edge and includes both quick scans for common issues and comprehensive assessments. Start here.
NVDA — Free screen reader for Windows. NVDA is the most common screen reader among users and is essential for understanding how your content sounds when read aloud. Navigate your pages using only the keyboard and screen reader — do not look at the screen.
Additional Automated Testing Tools
Run these during development to catch common issues:
- Deque Axe — Chrome and Firefox extension for quick in-browser accessibility scans.
- Google Lighthouse — Built into Chrome DevTools. Runs accessibility audits alongside performance.
- Wave — Browser extension that visually overlays accessibility errors and warnings on your page.
- HTML CodeSniffer — Bookmarklet that checks the current page against WCAG criteria in real time.
- a11y.css — A CSS file that highlights potential accessibility issues by flagging problematic markup visually.
CI/CD Integration
Incorporate automated checks into your build pipeline:
- Pa11y — Command-line tool for running WCAG checks in CI. Supports multiple reporters.
- accessibility-checker — IBM's Node.js module for automated accessibility scanning. Works in test frameworks.
Other Screen Readers
Beyond NVDA, test with:
- VoiceOver — Built into macOS and iOS. Activate with Cmd+F5 on Mac.
- TalkBack — Built into Android devices.
Test at minimum with NVDA on Windows and VoiceOver on macOS.
Coding Techniques
Forms
NYSDS form components (Text Input, Select, Checkbox, Radio Button, Textarea) handle label association, error messaging, and required field announcements automatically. When building custom form patterns:
- Always associate labels with inputs using
for/idpairs or wrapping the input in a<label>. - Group related fields with
<fieldset>and<legend>. - Announce errors in context — place error text next to the field and link it with
aria-describedby. - Never rely on color alone to indicate errors. Include text and, where appropriate, an icon.
See Creating Accessible Forms (WebAIM) for a thorough reference.
Dynamic Content
When content changes without a full page reload:
- Use
aria-liveregions to announce updates to screen readers. Usearia-live="polite"for non-urgent updates andaria-live="assertive"sparingly for critical alerts. - Manage focus intentionally. When a modal opens, move focus into it. When it closes, return focus to the element that triggered it. NYSDS components like
nys-modalhandle this automatically. - Avoid moving focus unexpectedly. If a user action triggers a content change, let the user initiate the next navigation step.
Images and Media
- Informational images:
<img src="chart.png" alt="Bar chart showing 2024 application processing times by county"> - Decorative images:
<img src="decorative-wave.svg" alt="" role="presentation"> - Complex images (charts, diagrams): provide a text summary in the alt attribute and a detailed description nearby or linked.
- Video: include synchronized captions and a transcript.
NYS internal resources
The following guidance, tools, and courses are available to New York State staff:
Further Reading
- WCAG 2.2 Quick Reference — The filterable, practical version of the full guidelines.
- WAI-ARIA Authoring Practices — Patterns and examples for complex interactive widgets.
- Deque University: Accessibility for Front-End Developers (SLMS login) — NYS-available online course.
- See our Learning Resources page for additional courses and references.
Edit this page on GitHub (Permissions required)
Last updated: May 28, 2026