Building for Everyone: Web Accessibility

I have a disability that makes it hard to differentiate between similar colors. Sometimes I'll stare at a webpage for minutes, squinting and adjusting my screen brightness, trying to figure out which text is clickable and which isn't. I'll miss important buttons because they blend into the background, or struggle to read error messages displayed in red text that looks identical to the black text around it.

If this is my daily reality—and I can see the screen—imagine what it's like for someone who can't see it at all.

Picture Sarah trying to pay her electric bill online before the deadline. She's been blind since birth and navigates the web like a pro with her screen reader—usually. But today, she hits a wall that I'd never even notice. The payment button exists visually, but it has no accessible label. Her screen reader announces it as "button" with no context whatsoever. She tries tabbing through the form fields, but the focus jumps erratically, skipping crucial elements entirely. After twenty frustrating minutes of what should be a two-minute task, she gives up and calls the utility company, where she'll wait on hold for another hour.

This isn't some hypothetical scenario. It's Tuesday for Sarah and millions of others. And here's what gets me—it's completely preventable with basic consideration that costs virtually nothing to implement.

After spending the last eight years building web applications and watching teams struggle with accessibility, I've learned something crucial: accessibility isn't something you add at the end like a coat of paint. It's woven into every decision you make, from choosing your color palette to writing your first component.

The massive market you're ignoring

Let's talk numbers, because they're staggering. In the American context, the CDC reports that 61 million adults in the United States live with a disability. That's 26% of the population; 1 in every 5 - roughly equivalent to the entire populations of California and Texas combined. Break it down further: 20.2 million people have trouble seeing, 7.6 million have a hearing difficulty, and 13.7 million have a serious difficulty walking or climbing stairs.

But here's what really opened my eyes: disability isn't just permanent conditions. It's also temporary and situational. That person with a broken arm trying to navigate your site one-handed? They need the same keyboard accessibility as someone with limited mobility. The user in a noisy coffee shop who can't hear your video's audio? They need captions just like someone who's deaf. The executive squinting at their phone in bright sunlight? They benefit from high contrast design just like someone with low vision.

Microsoft's inclusive design methodology calls these permanent, temporary, and situational disabilities. When you design for the permanent - the person who's blind - you end up helping everyone in similar circumstances.

The economic impact is massive too. The disability market represents $13 trillion in annual disposable income globally. In the US alone, people with disabilities have $490 billion in disposable income annually. When your website is inaccessible, you're not just excluding people - you're walking away from serious money.

Beyond screen readers: What accessibility actually covers

Most people think accessibility means "make it work with screen readers," and while that's important, it's just the tip of the iceberg. Real accessibility touches every aspect of user experience.

Visual accessibility goes far beyond blindness. It includes people with low vision, color blindness (affecting 1 in 12 men and 1 in 200 women), light sensitivity, and conditions like dyslexia that affect reading. This means thinking about color contrast, font choices, text size, spacing, and how information is presented visually.

Motor accessibility covers a huge range of needs. Some people can't use a mouse at all and rely entirely on keyboards or specialized input devices. Others have tremors that make precise clicking difficult, or limited mobility that makes complex gestures impossible. Your interface needs to work with keyboard-only navigation, have click targets that are large enough, and not require precise timing or complex motions.

Cognitive accessibility might be the most overlooked area. It includes people with ADHD, autism, memory issues, learning disabilities, and anyone who gets overwhelmed by complex interfaces. This means clear navigation, consistent patterns, simple language, and interfaces that don't punish mistakes.

Hearing accessibility affects how you handle audio and video content, but also things like error notifications that rely only on sound, or audio CAPTCHAs that have no alternative.

Each of these areas has dozens of specific considerations, and they often overlap in complex ways.

The legal landscape is shifting fast

Remember when GDPR caught everyone off guard? Accessibility compliance is having a similar moment, except the consequences can be even more serious.

The landmark cases started piling up around 2017. Target settled for $6 million after a class-action lawsuit over their inaccessible website. Netflix faced multiple lawsuits over lack of closed captions (subtitles). Domino's fought their accessibility case all the way to the Supreme Court - and lost. The court essentially said that the Americans with Disabilities Act absolutely applies to digital spaces.

But it's not just big corporations getting hit. I've seen small businesses face lawsuits over basic accessibility issues - missing alt text, forms that don't work with screen readers, videos without captions. The average settlement is around $50,000, but legal fees can easily double that.

The regulatory environment is tightening globally. The European Accessibility Act takes effect in 2025, requiring digital accessibility for a wide range of services. Canada's Accessible Canada Act is ramping up enforcement. Individual states are passing their own laws - California's Unruh Civil Rights Act has been used successfully in digital accessibility cases.

Here's what's really driving the increase in lawsuits: it's not just about compliance anymore. Plaintiff attorneys have figured out that accessibility violations are easy to find and document. They use automated scanning tools to identify problematic sites, then file cases in bulk. Some law firms are filing hundreds of accessibility lawsuits per year.

Start early or pay exponentially more

I've been on both sides of this equation - building accessibility in from the start, and trying to retrofit it after launch. The difference in cost and effort is astronomical.

When you plan for accessibility from day one, it becomes part of your natural workflow. Your designers learn to check color contrast as automatically as they check font sizes. Your developers write semantic HTML because that's just how they write HTML. Your content creators add alt text because it's part of their checklist.

But when you try to add accessibility after the fact? Everything becomes a special case. That dropdown menu you built with divs and JavaScript? Now you need to completely rebuild it with proper ARIA attributes, keyboard handling, and focus management. Those custom form controls that look great but don't announce properly to screen readers? Time for a complete redesign.

I worked on one project where the client wanted to add accessibility to an existing e-commerce site. What should have been a two-week project turned into four months of fundamental rewrites. We had to rebuild the shopping cart, redesign the checkout flow, restructure the navigation, and rewrite most of the JavaScript interactions. The final cost was about six times the original estimate.

Compare that to a similar project where we planned for accessibility from the beginning. The extra time for accessibility considerations? Maybe 15% additional development time, most of which was learning and establishing patterns that sped up later work.

The hidden benefits that make it worthwhile

Here's where accessibility gets really interesting—the benefits extend far beyond compliance and inclusion.

Performance improvements are dramatic. Accessible sites tend to have cleaner HTML, which means faster load times. Semantic markup reduces the need for complex CSS and JavaScript workarounds. I've seen page load times improve by 20-30% when teams clean up their HTML for accessibility.

SEO benefits are substantial. Search engines are essentially very sophisticated screen readers. They rely on the same semantic markup, heading structures, and descriptive text that make sites accessible. Sites with good accessibility practices consistently rank better in search results.

Conversion rates improve. This one surprised me initially, but it makes sense when you think about it. Accessible forms are clearer and easier to complete. Accessible navigation is more intuitive. Accessible content is easier to understand. All of these factors reduce friction and abandonment.

Support costs plummet. When interfaces are clear and consistent—key accessibility principles—users make fewer mistakes and need less help. One client saw their support ticket volume drop by 40% after implementing accessibility improvements, particularly around form design and error handling.

Code quality improves across the board. Teams that think about accessibility write more semantic HTML, create better component APIs, and build more robust error handling. These practices make codebases more maintainable and less prone to bugs.

Why smart teams still struggle

The biggest barrier isn't technical knowledge—it's organizational. Most teams I work with understand the importance of accessibility intellectually, but they struggle with implementation because of structural issues.

The ownership problem is pervasive. Designers think developers will handle the technical implementation. Developers assume designers have considered the accessibility implications of their designs. QA teams test for functionality but not for accessibility. Product managers prioritize features over accessibility improvements. Everyone assumes someone else is covering it.

Budget allocation is backwards. Teams budget for feature development but treat accessibility as overhead. They'll spend weeks building a complex animation but won't allocate time for proper keyboard navigation. This creates a cycle where accessibility always feels like extra work rather than core functionality.

Knowledge gaps compound over time. Accessibility requires understanding user needs, technical implementation, legal requirements, and testing methodologies. Most team members are strong in one area but weak in others. Without someone who can bridge these gaps, accessibility efforts become fragmented and ineffective.

Tool limitations create false confidence. Automated accessibility testing catches maybe 30% of real accessibility issues. Teams run these tools, see green checkmarks, and assume they're good to go. Meanwhile, users with actual disabilities still can't complete basic tasks on their sites.

The expertise bottleneck is real. Many teams want to "hire an accessibility expert" to solve the problem, but accessibility experts are rare and expensive. More importantly, accessibility can't be delegated to one person—it needs to be embedded in everyone's workflow.

A practical roadmap for getting started

Instead of trying to solve everything at once, focus on building accessibility into your existing processes.

For business leaders: Stop treating accessibility as a nice-to-have. Make it a business requirement with real consequences. Allocate budget specifically for accessibility work—typically 10-15% of your development budget is a good starting point. Establish accessibility goals in your metrics dashboard alongside performance and conversion metrics.

Most importantly, get executive buy-in by connecting accessibility to business outcomes. Don't just talk about compliance—talk about market reach, risk mitigation, and brand differentiation.

For product and project managers: Build accessibility into your definition of done. A feature isn't complete until it works for everyone. Include accessibility acceptance criteria in your user stories. Plan for accessibility testing in your QA cycles.

Create accessibility personas alongside your regular user personas. Meet Sarah, who uses a screen reader. Meet Marcus, who has limited mobility and navigates primarily with keyboard. Meet Elena, who has ADHD and gets overwhelmed by complex interfaces. When you make decisions, think about how they affect these users.

Track accessibility metrics like you track performance metrics. How many of your key user flows work with keyboard-only navigation? What percentage of your images have meaningful alt text? How many form errors are clearly communicated to screen readers?

For designers: Learn the accessibility implications of your design decisions. Understand that color alone can't convey information. Know that interactive elements need to be at least 44px in size for touch targets. Realize that complex layouts can be confusing for screen reader users.

Start using accessibility-focused design tools. Stark for Figma checks color contrast in real-time. Able for Sketch simulates various visual impairments. Include accessibility annotations in your design specs—not just visual specs, but behavioral ones too.

Create and maintain an accessible design system. Build accessibility into your components from the start. Document not just how components look, but how they behave with assistive technology.

For developers: Master semantic HTML before you reach for JavaScript frameworks. Learn ARIA, but understand that good semantic markup reduces the need for ARIA attributes. Implement keyboard navigation patterns consistently across your application.

Set up automated accessibility testing in your build process. Tools like axe-core can catch obvious issues early. But also learn manual testing techniques—navigate your site with only a keyboard, use a screen reader, test with high contrast mode enabled.

Build accessibility into your component library. Create reusable patterns for common interactions like modals, dropdowns, and form validation. Make the accessible choice the easy choice for other developers.

For testers: Expand your testing toolkit beyond automated scanners. Learn to use actual assistive technologies—VoiceOver on Mac, NVDA on Windows, mobile screen readers. Test with real users who have disabilities when possible.

Create accessibility-specific test scenarios. Can users complete the checkout process using only a keyboard? Do error messages make sense when heard out of context by a screen reader? Can users with cognitive disabilities navigate your interface without getting lost?

Document accessibility bugs with the same rigor as functional bugs. Include details about which assistive technologies are affected and specific steps to reproduce issues.

Tools that actually make a difference

The accessibility tool landscape has exploded in recent years, but quality varies wildly. Here are the tools that have proven most valuable in real projects:

For automated testing: axe-core is the gold standard. It's free, accurate, and integrates with virtually every testing framework. Lighthouse includes accessibility audits in its performance reports. WAVE provides excellent visual feedback for identifying issues.

For manual testing: Learn the built-in screen readers first—VoiceOver (Mac/iOS), Narrator (Windows), TalkBack (Android). For Windows, NVDA is free and widely used. Don't forget about browser zoom and high contrast modes. And there are hidden gems like ANDI (a tool provided by Social Security Administration of the US government)(https://www.ssa.gov/accessibility/andi/help/install.html).

For design: Stark integrates with Figma and Sketch to check color contrast in real-time. Colour Contrast Analyser is a free desktop tool for testing color combinations. WebAIM's contrast checker is reliable for quick online checks.

For ongoing monitoring: Tenon.io provides automated monitoring and detailed reports. AccessiBe and similar overlays are controversial and not recommended—they often create more problems than they solve. Paid applications like SiteImprove gives valuable insights into the day-to-day state of accessibility of your websites. (SiteImprove, Endorsed... I am waiting for your cheque 😄)

The key is using multiple tools in combination. Automated tools catch obvious issues, manual testing reveals usability problems, and real user feedback validates your solutions.

Learning accessibility: Certifications and structured education

Ok... you can read this section as one from many of my "unmaterialized" dreams - getting certified in A11y! Also my recommendations root from the mistakes I made in learning accessibility.

If you're serious about building accessibility expertise-whether for yourself or your team-the learning landscape has matured significantly in recent years. But here's the thing: not all accessibility education is created equal.

The gold standard certifications actually matter. The International Association of Accessibility Professionals (IAAP) offers three levels of certification that employers increasingly recognize and respect. The Certified Professional in Accessibility Core Competencies (CPACC) covers foundational knowledge-disability types, assistive technologies, and legal frameworks. It's perfect for product managers, designers, and anyone who needs to understand the big picture.

The Web Accessibility Specialist (WAS) certification gets technical. It focuses specifically on WCAG implementation, testing methodologies, and remediation strategies. This one's essential for developers and QA professionals who need hands-on skills.

For those managing accessibility programs, the Certified Professional in Web Accessibility (CPWA) combines strategic thinking with technical depth. It's newer but gaining traction among accessibility consultants and enterprise teams.

University programs are catching up. A few standout programs actually get it right. The University of Washington's Master's in Human Centered Design & Engineering has an excellent accessibility track. Georgia Tech's Master of Science in Human-Computer Interaction includes substantial accessibility coursework. These aren't just theoretical-they emphasize real-world application and user research with disabled communities.

Online learning that doesn't suck. Most accessibility courses are painfully dry, but some break the mold. Deque University offers practical, hands-on training that mirrors real development workflows. Their courses include actual screen reader demonstrations and coding exercises with immediate feedback. SiteImprove's Frontier (formerly known as SiteImprove Academy) also gives training materials.

WebAIM's training workshops remain some of the best available, especially their screen reader training sessions. They're not cheap, but they're taught by people who actually use these technologies daily.

Udacity's Web Accessibility course, created with Google, is free and surprisingly comprehensive. It includes real user interviews and practical exercises that go beyond checkbox compliance.

What to focus on learning first. Don't try to memorize WCAG guidelines-that's like trying to learn programming by memorizing syntax. Instead, start with user needs. Spend time watching screen reader users navigate websites. Understand how people with different disabilities actually use technology.

Learn semantic HTML deeply before touching ARIA. Most accessibility problems stem from poor HTML, not lack of fancy attributes. Master keyboard navigation patterns—they're the foundation of accessible interactions.

Study color and contrast not just as technical requirements, but as design principles. Learn to test with actual assistive technologies, not just automated tools.

Building internal expertise vs. hiring consultants. Here's what I've learned from teams that succeed long-term: you need internal champions, not just external experts. Consultants can audit your site and provide recommendations, but sustainable accessibility requires people on your team who understand both the technical implementation and the user impact.

The most effective approach combines external training with internal mentorship. Bring in accessibility experts to train your team, then have team members practice and teach each other. This builds distributed knowledge instead of creating single points of failure.

Red flags in accessibility education. Avoid courses that focus primarily on automated testing tools or treat accessibility as a checklist. Be skeptical of "accessibility overlay" vendors who claim their JavaScript widgets can make any site accessible-they can't, and often make things worse.

Skip training that doesn't include actual disabled users or real assistive technology demonstrations. Accessibility isn't theoretical-it needs to be grounded in real user experiences.

The certification question for teams. Should you require accessibility certifications for your team? It depends on your context. For specialized accessibility roles, absolutely. For general developers and designers, certifications demonstrate commitment but aren't substitutes for practical experience.

What matters more is creating a culture where accessibility knowledge is valued and shared. Regular lunch-and-learns about accessibility topics, internal accessibility audits, and user testing with disabled participants often teach more than formal certifications.

The goal isn't to turn everyone into accessibility experts-it's to make accessibility knowledge distributed and actionable across your entire team.

The compound benefits of getting it right

When teams fully embrace accessibility, something remarkable happens-it changes how they think about all user experience problems.

Teams that understand cognitive accessibility build clearer interfaces for everyone. Teams that master keyboard navigation create more logical interaction flows. Teams that write good alt text become better at all content strategy.

I've watched accessible design patterns become the foundation for better responsive design, clearer error handling, and more intuitive navigation. The skills transfer because accessibility forces you to think systematically about user needs and edge cases.

The business benefits compound too. Accessible brands build stronger relationships with their users. They face fewer legal risks. They tap into underserved markets. They build products that work better for everyone.

But the most important outcome is cultural. Teams that prioritize accessibility create more inclusive work environments. They ask better questions about user needs. They build more thoughtful products. They remember that technology should serve people, not the other way around.

Stop treating people like edge cases

Here's what I want you to take away from all of this: accessibility isn't about compliance checklists or legal risk management. It's about remembering that the people using your products are real humans with diverse needs and capabilities.

That means moving beyond the minimum viable accessibility—meeting WCAG guidelines—to actually usable accessibility. It means testing with real users, not just automated tools. It means considering accessibility in every design decision, not just retrofitting it later.

The web was designed to be universal from the beginning. Tim Berners-Lee said it best: "The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect."

We've spent the last two decades making the web faster, more beautiful, and more powerful. Now it's time to make sure it actually works for everyone who wants to use it.

To make web accessible, it takes more than technical expertise. One needs "Compassion". And my dear friend, that will make you a "Superman". All superheroes don't have capes. Some come with keyboards and mice 😄.

Your users—all of them—are counting on it.