Blog
    Web Design9 min

    Web Accessibility and WCAG 2.2 Compliance: A Practical Guide for Business Websites and Landing Pages in 2026

    July 9, 2026Team 42bites
    Web AccessibilityWCAGEuropean Accessibility ActWebsiteUX

    Since June 2025 the European Accessibility Act (EAA) has been fully in force across the EU, and for thousands of SMBs web accessibility has moved from 'nice to have' to a legal requirement with real consequences: administrative fines, mandatory remediation and, in many cases, automatic exclusion from public tenders that require WCAG 2.2 AA compliance. On top of that sits a huge, often ignored market: roughly 1 billion people worldwide — 15% of the global population — live with some form of disability, and a site that ignores them loses customers before it has even tried to sell them anything. This guide explains, in practical terms, what it actually takes to make a business website or landing page accessible and compliant in 2026.

    Why Web Accessibility Matters Now, Not Later

    For years accessibility was treated as a niche concern for public-sector sites. The European Accessibility Act changes that: it covers e-commerce, banking, transport and telecoms, and — indirectly, through tender and procurement requirements — a large share of B2B and B2C business sites that work with public administrations or large corporate clients. Penalties vary by country but can reach tens of thousands of euros for serious violations, on top of the reputational damage of being flagged as discriminatory.

    The ignored market is just as concrete: 1 billion people with disabilities worldwide, hundreds of billions of euros in estimated purchasing power in Europe alone, and a rapidly aging population mean that vision, hearing and fine-motor issues are becoming common even among 'ordinary' customers. An accessible site doesn't just serve a minority — it improves the experience for everyone, including mobile users in poor light or on slow connections.

    European Accessibility Act: What Actually Changes for SMBs

    The EAA doesn't force every single SMB into immediate, blanket compliance, but its scope keeps expanding: companies selling online, operating in transport or telecoms, or bidding for public tenders and serving large clients with accessible-procurement policies are already expected to demonstrate WCAG 2.2 AA compliance, often via a formal accessibility statement. Ignoring the topic today means risking a rushed rebuild tomorrow under tender-deadline pressure or a client demanding certification.

    Accessibility designed in from the start costs a fraction of retrofitting it later. Integrating WCAG principles into the design and development process — rather than bolting them on as a last-minute patch — can cut remediation time by 60-70% compared to a post-hoc review.

    WCAG Levels: A, AA, AAA and Why AA Is the De Facto Standard

    The Web Content Accessibility Guidelines (WCAG), now at version 2.2, define three levels of conformance. Level A covers the bare minimum (alt text for images); level AA adds requirements that fix the most common, high-impact barriers (color contrast, keyboard navigation, text resizing); level AAA includes very strict requirements rarely achievable across an entire site without design compromises, which is why it's seldom required as a general standard.

    Level AA is the de facto standard adopted by nearly every relevant regulation, including the EAA. For an SMB that wants to be compliant without over-investing, targeting AA across the site's main pages — home, product/service pages, contact forms and checkout — is the best balance of effort, cost and legal coverage.

    The 4 POUR Principles: Perceivable, Operable, Understandable, Robust

    All WCAG guidelines rest on four principles, summarized as POUR. Understanding them is more useful than memorizing hundreds of technical criteria, because they let you quickly evaluate any new feature with the same yardstick.

    Perceivable

    Information and interface components must be presentable in ways users can perceive, regardless of the sensory channel available: alt text for every informational image, captions for video content, a minimum 4.5:1 contrast ratio between text and background, and no information conveyed by color alone.

    Operable

    Every component and feature must be usable without a mouse: all navigation — menus, forms, buttons, modals — must work with the keyboard alone, in a logical tab order, with a visible focus indicator at all times. Keyboard traps, where focus gets stuck and navigation can't continue, must be avoided entirely.

    Understandable

    Content and interface must be understandable: clear language, form labels explicitly and correctly associated with their fields, error messages that explain what to fix (not a generic 'invalid field'), and predictable behavior from interactive components, with no unexpected context changes on focus.

    Robust

    Code must be written so it's correctly interpreted by a wide range of present and future assistive technologies — screen readers like JAWS, NVDA and VoiceOver, voice-recognition software, alternative keyboards. Valid semantic HTML and correctly used ARIA attributes are the foundation of robustness.

    Technical Checklist: What to Check Before Launch

    • Color contrast of at least 4.5:1 for normal text (3:1 for large text and UI components)
    • Descriptive alt text for every informational image, empty alt for purely decorative images
    • Full keyboard navigation with a visible focus indicator and a logical tab order
    • ARIA attributes (aria-label, aria-expanded, aria-live) used only where semantic HTML isn't enough
    • Accessible forms: explicit labels tied to their fields, clear error messages linked to the relevant field
    • Captions and transcripts for all video and audio content

    Automated Audit Tools: Useful but Not Enough

    Tools like axe DevTools, WAVE, Lighthouse and PageSpeed Insights quickly and cheaply catch a large share of accessibility issues: insufficient contrast, missing alt text, invalid markup, missing form labels. They're a great first filter to wire into a CI/CD pipeline, but on average cover only 30-40% of the relevant WCAG criteria — the rest needs a human eye.

    The limits are structural: a tool can check that an image has an alt attribute, not whether the alt text actually describes the content usefully; it can confirm a button has a visible focus state, not whether the tab order makes logical sense to a real user. That's why manual testing with screen readers (NVDA, VoiceOver) and, where possible, sessions with real assistive-technology users are essential — they're the only way to surface the barriers no algorithm can catch.

    Accessibility and SEO: A Closer Link Than It Looks

    Accessibility and technical SEO share much of the same foundation: correct semantic HTML, a hierarchical heading structure, descriptive alt text and well-formed markup are simultaneously WCAG requirements and SEO best practice. A Google crawler 'reads' a page not that differently from a screen reader — both rely on semantic structure to understand what's a heading, a link, or a purely decorative image.

    Core Web Vitals intertwine with accessibility too: a high CLS, with elements shifting as the page loads, isn't just a performance issue — it's a real obstacle for users with motor impairments who risk clicking the wrong button. Companies that invest in accessibility often see a side benefit in organic rankings, simply because they're fixing the exact same technical elements Google rewards.

    Common Mistakes (and How to Avoid Them)

    • Conveying information through color alone (e.g. 'red fields are required', with no other indicator)
    • Meaningless alt text on decorative images that confuses screen reader users
    • Modals that trap keyboard focus with no obvious way to close them
    • Icon buttons with no text label or aria-label, unreadable by assistive technology
    • Autoplaying video with no visible controls and no captions
    • Forms that use placeholders instead of labels, which disappear the moment a user starts typing

    Conclusion: Accessibility as an Investment, Not a Cost

    In 2026, web accessibility is no longer a niche technical topic or a public-sector-only requirement: it's an expanding legal obligation, a concrete risk factor for anyone bidding on tenders, an often-overlooked market of 1 billion people, and a direct ally of SEO. SMBs that treat accessibility as part of the design process — not a last-minute audit — arrive in 2026 with sites that are more compliant, faster, more indexable and simply more usable by everyone.

    Make Your Website Accessible and WCAG 2.2 Compliant

    We run complete accessibility audits and build sites and landing pages compliant with WCAG 2.2 and the European Accessibility Act, without compromising on design or performance.