Introduction: Accessibility as a Core Requirement
Web accessibility ensures that websites and applications are usable by everyone, including people with disabilities. This isn't just an ethical imperative—it's often a legal requirement and always good business practice. Accessible sites reach larger audiences, improve SEO, and often provide better experiences for all users.
At TetraNeurons, accessibility is a core requirement for all our projects. From Heritage Lanka's cultural archives to Agrilanka's farming tools, we design for diverse users with varying abilities. This guide shares the principles and practices that drive our accessibility work.
Understanding Disabilities and Assistive Technologies
Disabilities affecting web use include visual impairments (blindness, low vision, color blindness), hearing impairments, motor disabilities affecting keyboard or mouse use, and cognitive disabilities affecting understanding and navigation.
Users employ various assistive technologies. Screen readers (JAWS, NVDA, VoiceOver) convert visual content to speech or braille. Screen magnifiers enlarge portions of the screen. Voice control software enables hands-free navigation. Switch devices provide alternatives to standard input devices.
Understanding how these technologies interact with web content guides accessible development. Screen readers navigate by headings, landmarks, and links. Keyboard users need focus management. Voice control users need visible, speakable targets. Design with these interaction patterns in mind.
WCAG: The Accessibility Standard
The Web Content Accessibility Guidelines (WCAG) provide the international standard for web accessibility. Current version 2.1 defines success criteria at three levels: A (minimum), AA (recommended), and AAA (enhanced). Most regulations require AA compliance.
WCAG organizes requirements around four principles—POUR. Perceivable: content must be presentable in ways users can perceive. Operable: interface components must be operable by all users. Understandable: content and interface must be understandable. Robust: content must work with current and future technologies.
Each principle contains guidelines with specific success criteria. Rather than memorizing all criteria, understand the principles and consult specific criteria when addressing particular components.
Semantic HTML: The Foundation
Semantic HTML uses elements that convey meaning, not just appearance. A button element is recognized as interactive by assistive technologies. A div styled to look like a button isn't—unless you add extensive ARIA attributes and keyboard handling.
Use appropriate elements: nav for navigation, main for primary content, article for self-contained content, aside for tangential content, header and footer for their obvious purposes. These landmarks help screen reader users navigate efficiently.
Heading hierarchy matters enormously. Screen reader users often navigate by headings, expecting a logical outline. Skip levels (h1 to h3) or misuse for styling confuses this navigation. Use CSS for visual styling, not heading levels.
Images and Alternative Text
Images need alternative text that conveys their content or function. Decorative images get empty alt attributes (alt="") to be skipped by screen readers. Informative images get descriptions of their content. Functional images (like buttons) describe their purpose.
Writing good alt text requires judgment. "Image of a chart" is useless. Describing every detail of a complex chart is overwhelming. Focus on the information the image conveys in context. What would someone miss if they couldn't see it?
Complex images like charts, diagrams, and infographics may need more extensive descriptions. Long descriptions can be provided through aria-describedby referencing hidden text, linked separate pages, or expanded details components.
Forms and Input
Forms present significant accessibility challenges. Every input needs an associated label—either through for/id association or wrapping the input in the label element. Placeholder text isn't a substitute; it disappears on focus.
Error handling needs special attention. Errors should be associated with their inputs through aria-describedby. Error messages should be clear and actionable. When errors occur on submit, focus should move to the first error for immediate awareness.
Required fields need indication beyond color (asterisks, "required" text). Form validation should provide immediate feedback while avoiding excessive interruption. Success and error states need programmatic announcement for screen reader users.
Keyboard Navigation
All functionality must be operable via keyboard. This means: interactive elements are focusable, focus order is logical, focus is visible, and custom components handle appropriate key events.
The tab key moves between focusable elements. Enter activates buttons and links. Space activates buttons and checkboxes. Arrow keys navigate within composite widgets (menus, tabs, radio groups). Escape closes overlays and cancels operations.
Focus trapping is appropriate for modals—focus should cycle within the modal until it's closed. Skip links let keyboard users bypass repetitive navigation. Focus management after dynamic updates ensures users aren't lost.
ARIA: Enhancing Semantics
ARIA (Accessible Rich Internet Applications) provides attributes that enhance accessibility when HTML semantics aren't sufficient. But ARIA is easily misused—the first rule of ARIA is don't use ARIA if native HTML suffices.
ARIA roles define what an element is: button, dialog, menu, tab, etc. States indicate current conditions: aria-expanded, aria-selected, aria-checked. Properties provide additional information: aria-label, aria-describedby, aria-labelledby.
ARIA live regions announce dynamic content changes. Setting aria-live="polite" on a container causes screen readers to announce updates when convenient. aria-live="assertive" interrupts immediately—use sparingly for critical updates.
Color and Contrast
Color must not be the only way to convey information. Links need more than color to distinguish them from text. Error states need icons or text, not just red coloring. Charts need patterns or labels, not just different colors.
Contrast ratios ensure readability. WCAG requires 4.5:1 for normal text and 3:1 for large text at AA level. Tools like WebAIM's Contrast Checker verify compliance. Design systems should include accessible color combinations.
Consider users with color vision deficiencies. Red-green colorblindness is common. Test with simulation tools to ensure your interface works for these users.
Motion and Animation
Motion can cause discomfort for users with vestibular disorders. The prefers-reduced-motion media query lets users indicate they prefer minimal animation. Respect this preference by reducing or eliminating motion.
Flashing content can trigger seizures in users with photosensitive epilepsy. WCAG prohibits content that flashes more than three times per second. Avoid rapid flashing entirely—the risk isn't worth any visual benefit.
Auto-playing content (videos, carousels) can be disorienting. Provide controls to pause, stop, or hide moving content. Carousels should pause on hover or focus. Videos shouldn't auto-play with sound.
Testing for Accessibility
Automated testing catches some issues but misses many. Tools like axe, Lighthouse, and WAVE identify missing alt text, contrast violations, and ARIA misuse. Run these tools regularly, but don't consider passing automated tests sufficient.
Manual testing is essential. Navigate your site by keyboard alone. Use a screen reader—VoiceOver on Mac, NVDA on Windows—to experience how blind users encounter your content. Test with zoom at 200% for low vision simulation.
User testing with people who have disabilities provides irreplaceable insights. No simulation replaces actual experience. If possible, include users with various disabilities in your testing process.
Accessibility in Development Workflow
Accessibility works best when integrated throughout development, not bolted on at the end. Design reviews should include accessibility considerations. Component libraries should build in accessibility. Code reviews should check for accessibility issues.
Accessibility linting (eslint-plugin-jsx-a11y for React) catches issues during development. CI pipelines can run automated accessibility tests. But these are safety nets, not substitutes for accessibility-first development.
Documentation should cover accessibility. Component APIs should explain ARIA usage. Pattern libraries should demonstrate accessible implementations. This knowledge sharing builds accessibility competence across teams.
Common Patterns Done Right
Modals need proper implementation: focus trapping, escape to close, return focus to trigger on close, aria-modal attribute, accessible name and description.
Tab interfaces need roving tabindex (one tab focusable at a time), arrow key navigation, proper ARIA roles (tablist, tab, tabpanel), and association between tabs and panels.
Dropdown menus need focus management, arrow key navigation within the menu, escape to close, and proper ARIA for expanded/collapsed state.
Accordions need clear expand/collapse indication, proper button triggers, appropriate ARIA attributes, and keyboard operability.
Conclusion: Accessibility as Quality
Accessibility isn't a feature—it's a quality attribute like performance or security. Accessible applications are better applications. The constraints of accessibility often lead to cleaner markup, clearer design, and more maintainable code.
At TetraNeurons, we've found that prioritizing accessibility improves our work overall. The discipline of considering diverse users expands our thinking. The technical requirements of accessibility align with best practices generally.
Building accessible applications is challenging but achievable. Start with semantic HTML. Test with keyboard and screen reader. Address issues as they're found. Continuous improvement beats perfection-paralysis. Every accessibility improvement makes the web more inclusive.