Back to Blog

Web Accessibility Basics: Building Software Everyone Can Use

Accessibility isn't just a nice-to-have. It's a legal requirement in many jurisdictions, good for SEO, and — most importantly — the right thing to do.

Accessibility isn't just a nice-to-have. It's a legal requirement in many jurisdictions, good for SEO, and — most importantly — the right thing to do.

Here's what business owners need to know.

What Is Web Accessibility?

Accessibility means building software that works for people with disabilities:

  • Visual: Blind users, low vision, color blindness
  • Hearing: Deaf and hard-of-hearing users
  • Motor: Users who can't use a mouse or have limited mobility
  • Cognitive: Users with learning disabilities, attention difficulties, or memory issues

About 15-20% of people have some form of disability. That's a significant portion of your users, employees, or customers.

Why It Matters

Legal Requirements

Many jurisdictions require accessible digital services:

  • Canada: Accessible Canada Act, provincial legislation (AODA in Ontario)
  • US: ADA applies to websites, Section 508 for government
  • EU: European Accessibility Act

Lawsuits over inaccessible websites are increasing. It's cheaper to build accessibility in than to remediate later (or defend lawsuits).

Business Benefits

  • Larger audience: 15-20% of population has disabilities
  • Better SEO: Many accessibility practices improve search ranking
  • Better for everyone: Captions help in noisy environments, good contrast helps in sunlight
  • Legal protection: Compliance reduces risk

Ethics

Building software that excludes people is building broken software. Full stop.

The Basics (WCAG)

Web Content Accessibility Guidelines (WCAG) are the standard. Three levels:

  • A: Minimum accessibility (bare minimum)
  • AA: Standard accessibility (most regulations require this)
  • AAA: Maximum accessibility (often not fully achievable)

Most projects should aim for WCAG 2.1 AA compliance.

Key Accessibility Principles

1. Perceivable

Information must be presentable in ways users can perceive.

Examples:

  • Images have alt text (so screen readers can describe them)
  • Videos have captions
  • Sufficient color contrast
  • Text can be resized without breaking layout

2. Operable

Users must be able to operate the interface.

Examples:

  • Everything works with keyboard (not just mouse)
  • No seizure-inducing flashing
  • Users have enough time to read and act
  • Clear navigation and headings

3. Understandable

Users must be able to understand the information and interface.

Examples:

  • Language is clear
  • Navigation is consistent
  • Error messages are helpful
  • Forms explain what's needed

4. Robust

Content must work with various technologies, including assistive technologies.

Examples:

  • Valid HTML
  • Works with screen readers
  • Doesn't break when zoomed
  • Compatible with different browsers

Common Accessibility Issues

Missing Alt Text

Images without descriptions are invisible to screen reader users.

Fix: Every meaningful image needs alt text describing its content.

Poor Color Contrast

Text that's hard to read for low-vision users.

Fix: Minimum 4.5:1 contrast ratio for normal text, 3:1 for large text.

Keyboard Inaccessibility

Interactive elements that only work with mouse.

Fix: Everything clickable should be reachable and operable via keyboard.

Missing Form Labels

Form fields without associated labels confuse screen readers.

Fix: Every input needs a properly associated label.

No Heading Structure

Content without proper heading hierarchy is hard to navigate.

Fix: Use H1, H2, H3, etc. in logical order.

Video Without Captions

Deaf users can't access audio content.

Fix: Caption all video content.

Non-Descriptive Links

"Click here" links mean nothing out of context.

Fix: Link text should describe where it goes: "Download the project brief"

What to Ask Your Development Partner

  1. "What's your approach to accessibility?" (Should have a clear answer)
  2. "What WCAG level are you targeting?" (Usually AA)
  3. "How do you test for accessibility?" (Manual + automated)
  4. "Is accessibility built in or added later?" (Should be built in)
  5. "Can you provide an accessibility statement?"

Red Flags

🚩 "We'll make it accessible at the end" 🚩 "Our framework handles accessibility" 🚩 No mention of WCAG 🚩 No accessibility testing 🚩 "Most of our users don't have disabilities"

Testing Accessibility

Automated Testing

Tools like WAVE, axe, or Lighthouse catch many issues automatically. Quick but not comprehensive.

Manual Testing

  • Navigate entire site with keyboard only
  • Use screen reader (NVDA, VoiceOver)
  • Test with high contrast mode
  • Test with text zoom (200%)

User Testing

Nothing replaces testing with actual users who have disabilities.

Accessibility Costs

Building accessibility from the start: 5-15% additional development time.

Remediating an inaccessible site: Often 30-50% of original cost.

Legal defense: Much more.

Build it in. It's cheaper.

The Bottom Line

Accessibility is:

  • A legal requirement (often)
  • Good for business
  • The right thing to do

Every project should include accessibility consideration. At minimum, WCAG 2.1 AA compliance.


We build software that works for everyone. Let's talk about your project

Have a project in mind?

Let's talk about whether custom software is the right fit for your business.

Get in Touch