Web accessibility is not an afterthought or a checkbox item — it is a fundamental aspect of building quality software. Roughly 15 percent of the global population lives with some form of disability, and inaccessible websites exclude these users entirely. Beyond the moral imperative, accessibility lawsuits have increased dramatically, and regulatory requirements continue to tighten worldwide.
At StrikingWeb, accessibility is built into our development process from day one. We do not treat it as a separate phase that happens after the design is finalized and the code is written. This guide shares our approach to building WCAG 2.1 compliant websites, the tools we use, and the common pitfalls we help clients avoid.
Understanding WCAG 2.1
The Web Content Accessibility Guidelines (WCAG) 2.1 is the current standard for web accessibility. Published by the W3C, it defines success criteria organized around four principles known by the acronym POUR:
- Perceivable: Information and interface components must be presentable in ways that users can perceive — through sight, hearing, or touch
- Operable: Interface components and navigation must be operable by all users, including those using keyboards, voice commands, or switch devices
- Understandable: Information and the operation of the interface must be understandable, with predictable behavior and clear error messages
- Robust: Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies
WCAG defines three conformance levels: A (minimum), AA (standard), and AAA (enhanced). Most legal requirements and industry standards target Level AA compliance, which is the level we recommend for all production websites.
Semantic HTML — The Foundation
Before reaching for ARIA attributes, ensure your HTML is semantically correct. Semantic HTML provides accessibility for free. A <button> element is automatically focusable, responds to keyboard events, and announces itself as a button to screen readers. A <div onclick="..."> does none of these things without significant additional work.
Document Structure
Every page should have a clear document structure using HTML5 landmarks:
<header>for the site header and navigation<nav>for navigation menus, witharia-labelto distinguish multiple navigation regions<main>for the primary content area (only one per page)<aside>for supplementary content like sidebars<footer>for the site footer<section>and<article>for logical content groupings
Screen reader users navigate by landmarks — they jump directly to the main content, the navigation, or the footer. Without proper landmarks, they must navigate through every element sequentially.
Heading Hierarchy
Headings must follow a logical order without skipping levels. Start with a single <h1> for the page title, followed by <h2> for major sections, <h3> for subsections, and so on. Screen reader users frequently navigate by headings to understand page structure and jump to relevant sections.
ARIA — When HTML Is Not Enough
Accessible Rich Internet Applications (ARIA) attributes extend HTML semantics for complex interactive components that have no native HTML equivalent — modal dialogs, tab panels, tree views, and custom dropdown menus.
The first rule of ARIA is: do not use ARIA if you can use native HTML instead. The second rule is: do not change native semantics unless you absolutely must. ARIA supplements HTML — it does not replace it.
Essential ARIA Patterns
Several ARIA patterns come up repeatedly in modern web applications:
- aria-label and aria-labelledby: Provide accessible names for elements that lack visible text labels, such as icon buttons or form groups
- aria-expanded: Communicates the open or closed state of dropdown menus, accordions, and disclosure widgets
- aria-live: Announces dynamic content changes to screen readers without requiring focus movement — essential for toast notifications, loading states, and real-time updates
- role="dialog" with aria-modal: Creates accessible modal dialogs that trap focus and announce themselves correctly
- aria-describedby: Associates descriptive text with form inputs, providing context beyond the visible label
Managing Focus
Focus management is one of the most overlooked aspects of web accessibility. When a modal opens, focus should move to the first focusable element within it. When it closes, focus should return to the element that triggered it. When a single-page application navigates to a new view, focus should move to the new content.
We implement a focus management utility on every project that handles these transitions consistently. Without deliberate focus management, keyboard and screen reader users get lost when the page content changes dynamically.
Color and Visual Design
Visual accessibility goes beyond screen reader support. Users with low vision, color blindness, or cognitive disabilities need careful attention to visual design.
Color Contrast
WCAG 2.1 Level AA requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (18px bold or 24px regular). We check contrast ratios during the design phase, not after development. Fixing contrast issues after a design is approved and implemented is far more expensive than getting it right initially.
Beyond Color
Information must never be conveyed by color alone. Error states should include icons and text in addition to red highlighting. Charts and graphs need patterns or labels alongside color coding. Links within body text should be underlined or otherwise visually distinguishable beyond color difference.
Forms and Error Handling
Forms are where accessibility issues cause the most user frustration. Every input must have a visible label associated using the for attribute or by wrapping the input in a <label> element. Placeholder text is not a substitute for labels — it disappears when the user begins typing and often has insufficient contrast.
Error Messages
When form validation fails, the approach matters as much as the content:
- Display errors adjacent to the relevant field, not just in a summary at the top of the form
- Use
aria-describedbyto associate error messages with their inputs - Move focus to the first error when the form is submitted
- Use
aria-invalid="true"on fields that contain errors - Provide clear, specific error messages — not generic text like "invalid input"
Testing Tools and Methodology
No single tool catches every accessibility issue. We use a layered testing approach that combines automated scanning, manual keyboard testing, and screen reader verification.
Automated Testing
Automated tools catch approximately 30-40 percent of accessibility issues — primarily structural problems like missing alt text, insufficient contrast, and invalid ARIA attributes. Our standard automated toolkit includes:
- axe-core: The industry-standard accessibility testing engine, integrated into our CI pipeline through jest-axe or Cypress-axe
- Lighthouse: Google's audit tool provides accessibility scores alongside performance metrics
- WAVE: The browser extension provides visual indicators of accessibility issues directly on the page
- Pa11y: Command-line tool for automated accessibility testing, useful for monitoring accessibility across entire sites
Manual Testing
The remaining 60-70 percent of issues require manual testing. Our manual testing checklist includes:
- Navigate the entire application using only the keyboard — Tab, Shift+Tab, Enter, Space, Escape, and arrow keys
- Verify that focus indicators are visible on every interactive element
- Test with a screen reader (VoiceOver on macOS, NVDA on Windows) to verify that content is announced correctly
- Zoom the page to 200 percent and verify that no content is lost or overlapping
- Test with motion preferences set to "reduce motion" to verify that animations respect this setting
Legal Requirements
The legal landscape for web accessibility varies by jurisdiction but is trending toward stricter enforcement globally.
In the United States, the Americans with Disabilities Act (ADA) has been interpreted by courts to apply to websites, particularly for businesses that operate physical locations. The Department of Justice has clarified that websites must be accessible. In Europe, the European Accessibility Act requires digital products and services to meet accessibility standards. In India, the Rights of Persons with Disabilities Act, 2016 mandates accessible information and communication technology.
Accessibility lawsuits — particularly demand letters under ADA Title III — have grown substantially year over year. E-commerce sites, financial services, and healthcare portals are the most frequent targets. The cost of defending a lawsuit far exceeds the cost of building accessibly from the start.
Building Accessibility Into Your Process
Retrofitting accessibility into an existing application is expensive and disruptive. Building it in from the beginning costs a fraction of the effort and produces better results. At StrikingWeb, we integrate accessibility at every stage:
- Design: Verify contrast ratios, focus states, and touch target sizes before any code is written
- Development: Semantic HTML, keyboard interactions, and ARIA patterns are part of every component
- Code review: Accessibility is a review criterion alongside functionality and performance
- Testing: Automated scans run in CI, and manual testing happens before every release
- Monitoring: Post-launch audits catch regressions as new content and features are added
If you are building a new website or improving the accessibility of an existing one, we would welcome the opportunity to help. Accessible websites are better websites — they perform better in search engines, work on more devices, and serve a wider audience.