Accessibility Basics for a React UI
Accessibility is not optional. Here are the basics every React UI must have.
Accessibility Basics for a React UI
Accessibility is not optional. Here are the basics every React UI must have.
Semantic HTML
Use the right elements: button for actions, a for links, nav for navigation, main for main content. Semantic HTML gives screen readers the structure for free.
Accessible Names
Every interactive element needs an accessible name. Buttons with only an icon need an aria-label. Images need alt text. Links need descriptive text, not 'click here'.
Keyboard Accessibility
Every interactive element must work with the keyboard. Tab moves between elements, Enter activates, Escape closes modals. If you can only use it with a mouse, it is not accessible.
Focus Management
When a modal opens, move focus into it. When it closes, return focus to the trigger. Menus and dropdowns need similar focus handling, so keyboard users can navigate.
Sufficient Color Contrast
Text must have sufficient contrast against its background. Use a contrast checker; the minimum ratio depends on text size, but aim for at least 4.5:1 for normal text.
ARIA When Needed
Use ARIA only when semantic HTML is not enough. ARIA is a last resort, not a first choice. The wrong ARIA is worse than none, so use it carefully.
Test With a Screen Reader
Test your UI with a screen reader like VoiceOver or NVDA. This catches accessibility issues that automated tools miss and shows you the real experience of screen reader users.
The Takeaway
Make a React UI accessible with semantic HTML, accessible names for interactive elements, keyboard accessibility, focus management for modals and menus, sufficient color contrast, careful ARIA, and testing with a screen reader. These are the basics, not optional extras.
Use semantic HTML, give interactive elements accessible names (aria-label for icon buttons, alt for images), ensure keyboard accessibility, manage focus for modals and menus, ensure sufficient color contrast, use ARIA carefully, and test with a screen reader.
Because it gives screen readers the structure for free, without any extra attributes. A button is a button, a nav is a nav, and a main is a main. Semantic HTML is the foundation of accessibility, before ARIA.
Give them an aria-label. An icon-only button has no visible text, so screen readers have nothing to announce. An aria-label provides the accessible name that describes the button's action.
So keyboard and screen reader users can use the modal. When it opens, move focus into it. When it closes, return focus to the trigger. Without focus management, keyboard users get stuck outside the modal.
Only when semantic HTML is not enough. ARIA is a last resort, not a first choice. The wrong ARIA is worse than none, so use it carefully, and prefer semantic HTML whenever it can do the job.
Ready to master Node.js completely?
Want to upskill yourself, crack your next interview, and get your dream job? Join our comprehensive course to dive deeper with high-quality video tutorials, solve interview questions, and a premium community.
Master Node.js
Want to upskill yourself, crack your next interview, and get your dream job? Join our comprehensive course.