Accessibility in Custom Applications

Accessibility means building applications usable by people with disabilities. This includes visual impairments (blindness, low vision), motor impairments (inability to use a mouse), cognitive impairments (difficulty processing information), and hearing impairments (deafness).

Accessibility is not optional. It's a legal requirement in many jurisdictions. It's also the right thing to do—it expands your audience. And improving accessibility often improves the experience for everyone (captions help people in loud environments, clear structure helps users of screen readers and people skimming content).

Why Accessibility Matters

Consider your users. Some can't see your interface—they use screen readers. Some can't use a mouse—they use keyboards. Some can't distinguish between colors—color alone shouldn't convey information. Some are dyslexic—the page layout and typography matter. Some have tremors—interactive elements need to be large and spaced apart.

In many Western countries, 15-20% of the population has some form of disability. That's not a niche—that's a significant portion of your potential user base. And these aren't just permanent disabilities—anyone can be temporarily or situationally disabled (broken arm, bright sunlight on your screen, noisy environment).

WCAG: The Standard

WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility. The latest version is WCAG 2.1. It has three levels: A (minimum), AA (acceptable), AAA (enhanced). Most organizations target WCAG 2.1 Level AA.

WCAG is organized into four principles: Perceivable (content is perceivable by users), Operable (functionality is operable by keyboard), Understandable (content is understandable), and Robust (compatible with assistive technologies). Within each are specific criteria you must meet.

Understanding WCAG is valuable, but the practical approach is: semantic HTML, keyboard navigation, proper color contrast, and testing with assistive technologies. These address 80% of accessibility issues.

Semantic HTML: 80% of the Work

Using the right element for the right purpose is accessibility's foundation. A button is not a div with a click handler. A link is not a span with JavaScript navigation. A heading hierarchy exists (h1 is the main heading, h2 is a subsection, not a styling choice).

Semantic elements convey meaning to assistive technologies. A screen reader knows a button is clickable and announces it as such. A div with a click handler is just... a div. The user has no idea it's interactive.

Semantic elements for accessibility: button, a, nav, header, main, article, section, form, label, fieldset, legend, table with thead/tbody/th. Use them. They make accessibility nearly automatic.

Keyboard Navigation: Essential

All interactive elements must be reachable and usable via keyboard. Tab moves through interactive elements in order. Enter or Space activates buttons. Arrow keys navigate within components (menu items, radio buttons, tabs).

Test your application with only a keyboard—no mouse. Can you reach everything? Can you activate buttons? Can you navigate forms? If you can't, neither can someone with a motor impairment or someone using a keyboard for preference.

Don't remove the focus outline! That `:focus-visible` blue outline that many developers remove is essential for keyboard users—it shows which element is focused. If you remove it, replace it with something equally visible.

Screen Readers: Testing with Assistive Technology

Screen readers are software that reads web content aloud to users who are blind or have low vision. Common screen readers are NVDA (Windows), JAWS (Windows, expensive), and VoiceOver (Mac/iOS, built-in).

Screen readers read content in order and announce element types ("heading level 2", "button", "navigation region"). They need: semantic HTML, alt text on images, proper heading structure, labels on form inputs, descriptive link text.

Download and test with NVDA (free, Windows) or VoiceOver (built into Mac). You don't need to become a power user—use basic navigation (heading level navigation, landmark navigation, link navigation) to understand how your site sounds.

ARIA: Use Sparingly

ARIA (Accessible Rich Internet Applications) attributes add accessibility information to non-semantic HTML. Role, aria-label, aria-describedby, aria-hidden, aria-live.

ARIA is powerful but should be a last resort. If you can use semantic HTML, do so. Semantic HTML is usually simpler and more reliable than ARIA. The rule: "No ARIA is better than bad ARIA."

Legitimate ARIA uses: describing a complex component that semantic HTML can't express (a custom modal requires role="dialog"), labeling non-text content (aria-label for an icon button without visible text), indicating live regions (aria-live for chat messages or notifications).

Colour Contrast: Critical for Vision

Text must meet minimum contrast ratios. WCAG AA (the standard) requires 4.5:1 for normal text, 3:1 for large text (18px+). For AAA, it's 7:1 and 4.5:1 respectively.

Check contrast with a tool like WebAIM Contrast Checker. Many designs look nice but fail contrast checks. Gray text on white is beautiful to some designers but illegible to people with vision impairments.

Also: don't use colour as the only way to convey information. "Click the red button" is inaccessible if someone can't distinguish red from green (colour blindness is more common than you think—5-8% of males have it). Use colour + text, colour + icons, colour + patterns.

Images and Alt Text

Every image needs alt text (alternate text describing the image). Screen readers read alt text to blind users. If the image is decorative (doesn't convey information), use alt="" (empty alt text tells the screen reader to skip it).

Functional images (buttons with icons, icons that convey meaning) need descriptive alt text. Informational images (charts, diagrams) need alt text that describes the information. The alt text should serve the same purpose as the image.

Bad: alt="image". Good: alt="bar chart showing website traffic increased 50% year-over-year".

Focus Management

Keyboard users rely on visible focus to know where they are. Ensure focus indicators are always visible. If you customize focus styling, make it clear. A subtle colour change isn't enough—use border, outline, or background change.

When opening a modal, move focus into the modal (usually to the first input or close button). When closing it, return focus to the button that opened it. This keeps keyboard users oriented.

Common Accessibility Violations

• Missing alt text on images: Screen reader users have no idea what the image shows.
• Form inputs without labels: Screen reader users don't know what the field is for.
• Colour used as the only indicator: Colourblind users miss important information.
• Poor heading structure: Screen reader users can't navigate via headings if they're not semantic or hierarchical.
• Keyboard inaccessibility: Users without a mouse can't interact with the site.
• Low contrast text: People with vision impairments can't read it.
• Missing focus indicators: Keyboard users don't know which element is focused.
• Auto-playing video/audio: Startles users, difficult for those with hearing impairments.

Accessibility as a Design Discipline

Accessibility should be baked into design, not added as an afterthought. At design time, consider: are elements large enough? Is there sufficient contrast? Are interactions intuitive without icons alone? Are error messages clear?

Include accessibility requirements in your definition of done. A feature isn't shipped until it passes keyboard navigation and screen reader testing.

The investment pays back in a more robust, better-structured application. Semantic HTML and keyboard navigation benefit everyone, not just users with disabilities.