BeClearDesign
BeClearDesign
AccessibilityMarch 15, 202615 min read

Web Accessibility: A Comprehensive Guide for Business Owners

What WCAG compliance means, why it matters legally and ethically, and what your business needs to do to make your website accessible to everyone.

Web accessibility means making your website usable by everyone, including people with disabilities. It's not a niche concern — over 1.3 billion people worldwide live with some form of disability. In Canada, that's 27% of the population aged 15 and over. These are your potential customers, and if your website isn't accessible, you're excluding them.

What Is Web Accessibility?

Accessibility (often abbreviated as a11y) means designing and developing websites so that people with disabilities can perceive, understand, navigate, and interact with them effectively. Disabilities that affect web use include:

  • Visual — Blindness, low vision, color blindness. Users may rely on screen readers, screen magnifiers, or high-contrast settings.
  • Auditory — Deafness or hearing loss. Users need captions for audio and video content.
  • Motor — Limited fine motor control, paralysis, tremors. Users may navigate with keyboards, switch devices, head pointers, or voice commands instead of a mouse.
  • Cognitive — Learning disabilities, attention disorders, memory issues. Users benefit from clear language, consistent layouts, and predictable navigation.

    • Accessibility also benefits people without permanent disabilities: someone using their phone in bright sunlight, a person with a temporary injury, an elderly user with declining vision, or someone in a noisy environment who can't use audio.

    The Legal Landscape

    Web accessibility isn't just a nice thing to do — it's increasingly a legal requirement:

    Canada — The Accessible Canada Act (ACA) requires federally regulated organizations to identify and remove barriers in their digital services. Several provinces have their own legislation: Ontario's AODA (Accessibility for Ontarians with Disabilities Act) requires WCAG 2.0 AA compliance for organizations with 50+ employees. British Columbia's Accessible British Columbia Act is establishing similar requirements.

    United States — The ADA (Americans with Disabilities Act) has been interpreted by courts to apply to websites. Web accessibility lawsuits have increased dramatically — over 4,000 were filed in 2023 alone, targeting businesses of all sizes including small businesses and e-commerce stores.

    European Union — The European Accessibility Act requires private sector compliance with accessibility standards for products and services, including websites, by June 2025.

    The practical takeaway: If your website is publicly accessible and your business serves customers, you should be working toward WCAG compliance regardless of whether you're technically legally required to. The trend is clear — accessibility requirements are expanding, not shrinking.

    Understanding WCAG

    WCAG (Web Content Accessibility Guidelines) is the international standard for web accessibility. It's organized around four principles, often remembered by the acronym POUR:

    Perceivable — Information and user interface components must be presentable to users in ways they can perceive. This means content can't rely solely on one sense (sight or hearing) — alternatives must exist.

    Operable — User interface components and navigation must be operable. Users must be able to interact with all controls using their preferred input method (keyboard, touch, voice, switch device).

    Understandable — Information and the operation of the user interface must be understandable. The content should be readable, the interface should behave predictably, and users should be helped to avoid and correct errors.

    Robust — Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies. This means using standard HTML semantics, proper ARIA attributes, and avoiding technology that only works in specific browsers.

    WCAG conformance levels:

  • Level A — The absolute minimum. Sites that don't meet Level A have significant barriers that prevent some users from accessing content at all.
  • Level AA — The standard most regulations require. Addresses the most common barriers and is achievable for most websites without compromising design.
  • Level AAA — The highest level. Aspirational for most sites — achieving full AAA compliance is extremely difficult and often impractical for all content.

    • Target Level AA for your website. It's the legal standard in most jurisdictions and the practical standard in the industry.

    Key WCAG Requirements Explained

    Here are the most important accessibility requirements and what they mean for your website:

    Text alternatives (1.1.1)

    Every non-text element — images, icons, charts, videos — needs a text alternative. For images, this means descriptive alt text. For decorative images, empty alt attributes (alt="") so screen readers skip them. For complex graphics (charts, infographics), provide a detailed text description nearby.

    Good alt text: "Bar chart showing revenue growth from $1M in 2023 to $3M in 2025"

    Bad alt text: "chart.png" or "image" or no alt text at all

    Keyboard accessibility (2.1.1)

    Every interactive element — links, buttons, form fields, menus, modals, sliders — must be fully operable using only a keyboard. Users should be able to tab through all interactive elements, activate them with Enter or Space, and navigate without getting trapped in any component.

    This is one of the most commonly violated requirements. Custom JavaScript components (dropdown menus, modal dialogs, accordions, carousels) frequently lack keyboard support because developers only test with a mouse.

    Color contrast (1.4.3)

    Normal text must have a contrast ratio of at least 4.5:1 against its background. Large text (18px bold or 24px regular) needs at least 3:1. This ensures readability for users with low vision or color blindness.

    Light gray text on a white background (#999 on #fff = 2.8:1) fails this requirement. It might look elegant, but it's inaccessible. Use tools like the WebAIM contrast checker to verify your color combinations during the design phase.

    Focus indicators (2.4.7)

    When a user tabs through your site, a visible outline or highlight must indicate which element currently has focus. Many sites remove the default browser focus outline (outline: none) for aesthetic reasons without providing a replacement. This makes keyboard navigation impossible because users can't see where they are.

    Always provide clear, visible focus styles. They can be styled to match your design — they just need to be visible.

    Form labels (1.3.1, 3.3.2)

    Every form input must have a programmatically associated label — not just placeholder text. Labels tell screen reader users what information is expected in each field. Placeholder text alone is not sufficient because it disappears when the user starts typing, and some screen readers don't announce it.

    Use the HTML label element with a for attribute matching the input's id. Or wrap the input inside the label element. Both approaches create the programmatic association that assistive technologies need.

    Error identification (3.3.1)

    Form errors must be clearly identified in text, not just by color. A red border alone isn't sufficient — users who can't perceive color won't know there's an error. Include a text message that describes the error and how to fix it. Ideally, associate the error message with the field using aria-describedby.

    Page structure (1.3.1)

    Use semantic HTML elements to convey document structure: headings (h1–h6), lists (ul, ol, li), landmarks (nav, main, aside, footer), and sections. Screen readers use these elements to create a navigable outline of the page. Without proper structure, screen reader users experience your page as a flat stream of text with no hierarchy.

    Resize and reflow (1.4.4, 1.4.10)

    Content must remain usable when text is resized up to 200% (1.4.4) and when the viewport is narrowed to 320px width without horizontal scrolling (1.4.10). This benefits users who zoom in for readability and users on narrow screens.

    Motion and animation (2.3.1, 2.3.3)

    Flashing content that flashes more than 3 times per second can trigger seizures in users with photosensitive epilepsy. Avoid it entirely. For other animations, respect the prefers-reduced-motion media query — users who have enabled "reduce motion" in their device settings should see a reduced or eliminated animation experience.

    Common Accessibility Failures

    These are the issues we see most frequently on websites we audit:

  • Missing alt text on images — The single most common accessibility failure. Every meaningful image needs descriptive alt text.
  • Insufficient color contrast — Trendy light gray text on white backgrounds fails contrast requirements. Low-contrast text is hard to read for everyone, not just users with vision impairments.
  • No keyboard navigation support — Custom components (dropdowns, modals, sliders) that only work with a mouse. If you can't tab to it and activate it with Enter, it's inaccessible.
  • Missing form labels — Inputs with only placeholder text and no associated label element.
  • Missing focus indicators — The CSS rule :focus { outline: none } without a replacement focus style.
  • Auto-playing media — Videos or audio that play automatically without user control. This is disorienting for screen reader users and annoying for everyone.
  • Missing skip navigation link — Screen reader and keyboard users must tab through your entire navigation before reaching the main content. A "Skip to main content" link at the top of the page lets them bypass the navigation.
  • Incorrect heading hierarchy — Jumping from H1 to H4, or using heading elements for visual styling rather than semantic structure. Headings should create a logical outline: H1 > H2 > H3, in order.
  • Inaccessible PDFs — PDFs posted on your site should be tagged for accessibility. Scanned documents (images of text) are completely inaccessible to screen readers.

    • Testing for Accessibility

    Accessibility testing should combine automated tools with manual testing:

    Automated tools (catch about 30–40% of issues):

  • Lighthouse accessibility audit (built into Chrome DevTools)
  • axe DevTools browser extension
  • WAVE Web Accessibility Evaluator
  • pa11y (command-line tool for CI/CD integration)

    • Manual testing (catches the rest):

  • Tab through every page using only a keyboard. Can you reach and activate every interactive element?
  • Test with a screen reader (VoiceOver on Mac, NVDA on Windows). Does the content make sense when read aloud?
  • Zoom to 200% in the browser. Is all content still visible and usable?
  • Set your display to grayscale. Is information still distinguishable without color?
  • Test with prefers-reduced-motion enabled. Are animations appropriately reduced?

    • User testing:

    The most valuable accessibility testing is done by people with disabilities using their actual assistive technologies. If budget allows, include users with disabilities in your usability testing process.

    Accessibility Overlays: A Warning

    You may have seen companies selling accessibility overlay widgets — JavaScript plugins that add a toolbar to your site with options for font size, contrast, and other adjustments. These overlays are widely criticized by the accessibility community and should be avoided.

    Why overlays don't work:

  • They don't fix the underlying code problems — they apply surface-level CSS changes that often conflict with the site's existing styles
  • They can actually make the site less accessible by interfering with assistive technologies
  • They create a false sense of compliance — having an overlay does not make your site WCAG compliant
  • They've been the subject of legal action themselves — several companies have been sued for relying on overlays instead of actual remediation
  • Major accessibility organizations (including the National Federation of the Blind) have publicly opposed overlay products

    • The right approach is to build accessibility into the code itself, not bolt it on with a widget.

    Building an Accessible Website: The Process

    Accessibility should be considered at every phase of the web development process:

    Discovery — Define accessibility requirements and target conformance level (AA is standard). Identify any legal obligations specific to your jurisdiction and industry.

    Design — Choose colors that meet contrast requirements. Design focus states for interactive elements. Plan layouts that work at different zoom levels. Consider touch target sizes for mobile. Design form layouts with visible labels.

    Development — Use semantic HTML. Implement proper heading hierarchy. Add alt text. Build keyboard navigation support. Include ARIA attributes where semantic HTML isn't sufficient. Implement skip navigation.

    QA — Run automated accessibility tests. Perform manual keyboard and screen reader testing. Test at 200% zoom. Test with prefers-reduced-motion.

    Launch — Include accessibility in your launch checklist. Document known limitations and remediation plans.

    Ongoing — Test new content and features for accessibility as they're added. Include accessibility in your content governance process. Provide accessibility training for content editors.

    Our Approach

    At BeClearDesign, accessibility is not an add-on — it's built into our design and development process from the start. We design with contrast and readability in mind, develop with semantic HTML and keyboard accessibility, and test with real assistive technologies. Our goal is WCAG 2.1 AA compliance on every project, because we believe the web should be usable by everyone.