WCAG 2.2 AA: The 10 Most Common Errors on Business Websites

Why WCAG 2.2 AA Is Now Mandatory

Since June 28, 2025, Germany's Accessibility Strengthening Act (BFSG) requires businesses to make their digital offerings accessible. The technical benchmark is the European standard EN 301 549, built on the Web Content Accessibility Guidelines (WCAG) 2.2 at conformance level AA. For business websites, this means: if you sell products or services to consumers, you must comply. Violations can result in fines of up to EUR 100,000 (BFSG). At the same time, roughly four out of five tested German online shops are still not accessible (Aktion Mensch). The transition period has expired — market surveillance authorities can now penalize violations and competitors can issue costly cease-and-desist notices.

The business case is at least as compelling as the legal one: accessible websites typically achieve a 19.3% higher conversion rate (Global Conversion Study). The global disability market represents approximately USD 13 trillion in purchasing power (World Economic Forum). Accessibility is not merely a compliance topic but a revenue driver — and an SEO advantage that search engines increasingly reward.

Error 1: Insufficient Color Contrast

Color contrast is by far the most common WCAG issue: 83.9% of all tested websites exhibit contrast errors (WebAIM Million 2026). WCAG criterion 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt+ or 14pt bold). In practice, the most common failures are light gray text on white backgrounds, colored buttons with white text, and placeholder text in form fields.

The solution starts in the design system: define color pairs that meet the required contrast ratio and anchor them as CSS custom properties. This prevents individual decisions in the development process from undermining the standard. The XICTRAQ Accessibility Check detects contrast violations automatically and documents them with the exact ratio value.

Particularly tricky are contrasts in interactive states: hover colors, focus indicators, and disabled buttons are frequently overlooked during testing. WCAG 2.2 tightens requirements with the new criterion 2.4.13 (Focus Appearance), demanding a visible focus indicator with sufficient contrast. For business websites, this means: not just the default state needs testing, but every interactive state of an element.

Error 2: Missing Alt Text on Images

Images without alt text are invisible to screen reader users. 53.1% of surveyed websites have at least one image without an alternative text attribute (WebAIM Million 2026). This affects both informative images that need descriptions and decorative images that should receive an empty alt="" so screen readers skip them.

A frequent mistake is using meaningless alt text like "image" or "IMG_2847.jpg". Good alt text describes what the image shows and why it is relevant in context. For e-commerce pages, this means product images need descriptions with product name, color, and key features — not just the file name.

For content management systems, a mandatory alt text field in the upload dialog is recommended. This prevents missing descriptions at the point of creation rather than requiring retroactive additions. Regular automated scans still catch gaps — such as subsequently embedded images, SVG graphics without a <title> element, or <input type="image"> elements without alt text.

Error 3: Missing Form Labels

51% of websites have form fields without programmatically associated labels (WebAIM Million 2026). A visually placed text next to an input field is not sufficient — the <label> element must be connected to the input's id via the for attribute. Alternatively, the input can be nested inside the <label>.

Login forms and checkout processes are particularly critical: when a screen reader user cannot identify which field is for email and which for the password, the process breaks down. Login flow monitoring helps detect such drop-offs and trace them back to structural issues.

A simple test: click on a form field's label text. If the cursor jumps into the corresponding input field, the association is correct. If it does not, the programmatic connection is missing. For more complex forms with checkbox groups and radio buttons, <fieldset> and <legend> are additionally required to make group membership understandable to screen readers.

Error 4: Empty Links Without Description

46.3% of websites contain links without discernible text (WebAIM Million 2026). Typical triggers are icon links without aria-label, images inside links without alt text, and links whose visible text consists only of whitespace. For screen reader users, such links are unidentifiable — they hear only "link" with no further information.

The fix is usually straightforward: add an aria-label with descriptive text or insert a visually hidden <span class="sr-only">. For social media icons, aria-label="Visit our LinkedIn profile" suffices. Important: link text should describe the destination, not the action — "Product details" rather than "Click here." Also watch for ambiguities: when multiple links on a page carry the same text (such as repeated "Learn more"), a screen reader user cannot distinguish which link leads where. Context-dependent or unique link text solves this problem.

Error 5: Empty Buttons Without Text

30.6% of websites have buttons without an accessible name (WebAIM Million 2026). The issue mirrors empty links: icon buttons like hamburger menus, close crosses, or search magnifiers lack a text equivalent. Screen readers output only "button" without conveying the purpose.

The solution: every <button> needs either visible text, an aria-label, or a <span class="sr-only"> with descriptive content. For the hamburger menu, use aria-label="Open main menu", for the close button aria-label="Close dialog". Test naming by imagining you had to describe the page to someone over the phone.

Error 6: Incorrect ARIA Attributes

ARIA (Accessible Rich Internet Applications) is meant to provide additional context to screen readers. Yet on 82.7% of websites using ARIA, the attributes are incorrectly implemented (WebAIM Million 2026). Common mistakes: aria-labelledby pointing to a non-existent ID, role attributes contradicting the native HTML element, or aria-hidden="true" hiding interactive elements from assistive technologies.

A widespread anti-pattern is so-called "ARIA soup": developers add dozens of ARIA attributes to signal accessibility without understanding their effects. The result is often worse than having no ARIA at all. Validate ARIA usage with the HTTP security headers check combined with an accessibility audit to ensure both technical security and correct semantics.

Error 7: Missing Skip Navigation

Only 17.1% of websites offer a skip navigation link (WebAIM Million 2026). Skip links allow keyboard users to bypass the main navigation and jump directly to the page content. Without this mechanism, a keyboard user must tab through all navigation links on every page before reaching the actual content.

Implementation is straightforward: a link at the top of the page with href="#main-content" and a corresponding id="main-content" on the <main> element. The link can be visually hidden and become visible only when focused via keyboard. These few lines of code have a significant impact on usability for keyboard users. Additionally, landmark roles (<nav>, <main>, <aside>, <footer>) should be used correctly, as screen reader users can also navigate via these elements.

Error 8: Missing Language Declaration

The lang attribute on the <html> tag tells screen readers which language the page content is written in. Without this declaration, screen readers guess the language — often with unintelligible results when an English screen reader reads German text with English pronunciation. For multilingual websites, text sections in other languages must also be marked with lang attributes.

For a German website, <html lang="de"> suffices. For English quotes or technical terms, add <span lang="en">Content Security Policy</span>. This simple measure improves not only accessibility but also automatic translation and SEO evaluation by search engines.

Error 9: Missing Heading Hierarchy

Screen reader users frequently navigate websites via the heading structure. A logical hierarchy — one <h1> per page, followed by <h2>, <h3> without skipping levels — is essential for orientation. In practice, many websites use headings purely for styling: an <h4> is chosen because the font size fits, not because the semantic level is correct.

Separate semantics from styling consistently: use headings for content structure and CSS classes for visual design. A Lighthouse audit reliably uncovers hierarchy issues and shows where headings are skipped or misused.

Error 10: Missing Keyboard Operability

Every interactive element on a website must be reachable and operable via keyboard. In practice, custom widgets are the primary failure point: dropdown menus that respond only to hover, modal dialogs without focus management, and sliders without keyboard controls. Also, div and span elements with click handlers that are not focusable via Tab exclude keyboard users.

The solution: use native HTML elements like <button>, <a>, and <select> that already include keyboard support. Where custom widgets are necessary, implement the WAI-ARIA Authoring Practices: Tab and arrow key navigation, Escape to close, focus trap in modal dialogs. Test every page completely via keyboard — without a mouse.

A systematic keyboard test follows a fixed protocol: Tab through the entire page, verify every interactive element is reachable, test Enter/Space for activation, check Escape for closing dialogs, and verify arrow key navigation in menus and tabs. Document every point where focus is lost or an element is unreachable. This manual testing complements the automated tests of the Accessibility Check with aspects no scanner can detect.

96% of All Errors in Six Categories

The WebAIM Million 2026 study reveals a clear pattern: 96% of all automatically detectable errors fall into just six categories (WebAIM Million 2026). These are the first six errors on this list — contrast, alt text, labels, empty links, empty buttons, and incorrect ARIA attributes. This concentration is both the problem and the opportunity: systematically addressing these six areas eliminates the majority of measurable barriers.

The most efficient approach is cross-page analysis: instead of testing each page individually, first identify the templates and components reused across many pages. A contrast error in the header template affects every page on the website. A missing label in the newsletter form embedded in the footer multiplies across hundreds of pages. By fixing the component rather than individual pages, the error count typically drops dramatically with minimal effort.

Systematically Detect and Fix WCAG Errors

Automated testing is the first step but does not replace manual review. Tools like the XICTRAQ Accessibility Check detect roughly 30-40% of WCAG criteria automatically — including all six main categories from the WebAIM study. For the remaining criteria, such as content comprehensibility or tab order logic, manual testing is required.

1. Run automated scan — Check all pages for the six main categories and prioritize errors by severity
2. Fix template-based — Address reusable components first, as one fix improves hundreds of pages simultaneously
3. Test manually — Check keyboard navigation, screen reader compatibility, and focus management at critical points
4. Set up regression tests — Integrate accessibility checks into the deployment process to catch new errors early
5. Document — Retain audit protocols and progress reports for BFSG compliance documentation

A proven workflow: start with the automated scan, prioritize by severity (contrast and labels first), implement fixes, and re-test. Integrate the accessibility check into your deployment process so new errors surface immediately. Combining it with Content Security Policy (CSP) and SSL monitoring creates a comprehensive security and compliance package.

Accessibility as a Conversion Factor

Accessibility improves usability not only for people with disabilities but for all users. Clear contrasts, comprehensible labels, and a logical page structure reduce cognitive load and simplify navigation. Studies show that accessible websites typically achieve a 19.3% higher conversion rate (Global Conversion Study).

The global disability market represents purchasing power of approximately USD 13 trillion (World Economic Forum). Excluding this audience through barriers means forgoing significant revenue potential. The benefits extend beyond directly affected users: older people, users with temporary impairments (broken arm, bright sunlight on screen), and mobile users benefit equally. Especially in e-commerce, an accessible product page directly influences purchase decisions: clear labels, sufficient touch targets, and comprehensible error messages measurably reduce cart abandonment.

Test, Fix, Monitor Continuously

WCAG compliance is not a one-time project but an ongoing process. Every CMS update, every new plugin, and every design change can introduce new barriers. Without continuous monitoring, you discover regressions only at the next manual audit — or through a legal notice.

XICTRAQ combines the Accessibility Check with Uptime Monitoring, Security Scans, and GDPR Compliance in one platform. This gives you a complete picture of your website's technical quality, allowing you to fix issues before they affect users or authorities. Start with a free trial or explore the live demo.