WCAG — what it is, Web Content Accessibility Guidelines and AA levels

What is WCAG?

WCAG (Web Content Accessibility Guidelines) is a set of recommendations for ensuring web content accessibility for people with disabilities. The standard has been developed by the W3C Web Accessibility Initiative (WAI) since 1999. WCAG covers blind and visually impaired, deaf and hard of hearing, people with mobility limitations, speech and cognitive impairments, as well as elderly users with age-related changes.

The first version WCAG 1.0 was released in 1999 and contained 14 guiding principles. WCAG 2.0 (2008) became technology-neutral, applicable to HTML, PDF, multimedia, and mobile applications. WCAG 2.1 (2018) added criteria for mobile devices and touch input. WCAG 2.2 (2023) is the current version with new criteria for animation and focus. WCAG is not a law, but many countries reference it in their legislation.

GOST R 52872-2019 in Russia, the European Accessibility Act in the EU, and Section 508 in the US — all require WCAG AA compliance. For corporate and government websites, WCAG AA is a mandatory standard, non-compliance leads to lawsuits. According to UsableNet (2024), over 12,000 web accessibility lawsuits were filed in the US.

WCAG Versions: Comparison

Legal Consequences of Non-Compliance

Non-compliance with WCAG carries serious risks. In 2025, the European Accessibility Act (EAA) came into effect, requiring WCAG 2.1 AA for all public websites and mobile applications in the EU. Fines can reach up to 5% of annual company turnover. The average lawsuit settlement amount in the US is $25,000–$50,000. Accessibility audits should be conducted at every stage of development, not just before release.

Four Principles of WCAG: POUR

POUR is an acronym for four WCAG principles: Perceivable, Operable, Understandable, Robust. Each principle contains guidelines, and guidelines contain testable success criteria. WCAG 2.2 has 13 guidelines and 86 success criteria. Each criterion has level A, AA, or AAA.

Perceivable

The Perceivable principle requires that content be presented in a form that users can perceive. Guidelines: 1.1 Text Alternatives, 1.2 Time-based Media (captions, transcripts), 1.3 Adaptable (content without loss when format changes), 1.4 Distinguishable (contrast 4.5:1, color, sound). Key criterion 1.4.3 Contrast Minimum (AA) is the most frequently violated: 86% of pages do not meet it according to WebAIM.

Operable

The Operable principle requires interface operability. Guidelines: 2.1 Keyboard Accessible, 2.2 Enough Time, 2.3 Seizures, 2.4 Navigable, 2.5 Input Modalities. Criterion 2.1.1 Keyboard (A) is one of the most critical: all functions must be accessible via keyboard without a mouse. Modal windows that close only on click, dropdowns without keyboard navigation — typical violations.

Understandable

The Understandable principle requires comprehensibility of content and interface. Guidelines: 3.1 Readable, 3.2 Predictable, 3.3 Input Assistance. Criterion 3.3.4 Error Prevention is especially important for financial and medical applications: preventing serious consequences of input errors. Criterion 3.2.6 Consistent Help (new in WCAG 2.2) requires help buttons to be in the same locations.

Robust

The Robust principle requires compatibility with assistive technologies. Guideline 4.1 Compatible with key criterion 4.1.2 Name, Role, Value (A): each UI component must have programmatically determinable name, role, and state. ARIA attributes (role, aria-label, aria-expanded) are the main tool. Without them, screen readers cannot determine whether an element is a button, link, or tab.

WCAG Principles Table

WCAG Conformance Levels: A, AA, AAA

WCAG defines three levels: A (minimum), AA (standard), and AAA (maximum). Level A is the mandatory minimum: without it, content is inaccessible to some user categories. AA removes major accessibility barriers. AAA is the highest standard, but cannot be achieved for all content (for example, some sign languages or audio transcripts are not always feasible).

Level A (30 criteria): text alternatives, keyboard operability, sufficient time, no flashing above 3 Hz. Level AA (+24 criteria): contrast ratio 4.5:1, captions for video, text resize up to 200%, clear keyboard focus. Level AAA (+32 criteria): contrast ratio 7:1, sign language, animation disablement (2.3.3), audio transcription. For government websites, AA is sufficient.

WCAG Audit Process

An WCAG accessibility audit includes: automated testing (axe DevTools, WAVE, Lighthouse — finds 30–40% of errors), manual keyboard and screen reader testing (VoiceOver, TalkBack, NVDA), expert audit for complex criteria, and user testing with people with disabilities. The audit report should contain the conformance level and a list of non-conformances for each criterion.

What’s New in WCAG 2.2

WCAG 2.2 added 9 new criteria. Key ones: 2.4.11 Focus Appearance (AA) — focus indicator >= 2px with 3:1 contrast, 2.5.8 Target Size Minimum (AA) — touch target at least 24x24 pixels, 3.3.7 Accessible Authentication (AA) — authentication without CAPTCHA. Criterion 2.3.3 Animation from Interactions (AAA) — disableable animation or no more than 5 seconds.

Focus Appearance is the most important change. Previously, outline: none without replacement was a violation, but there were no clear requirements. WCAG 2.2 established: thickness >= 2px, contrast 3:1 with background, indicator area at least the element’s area. For custom buttons with border-radius, use box-shadow instead of outline.

Focus Appearance in CSS

/* WCAG 2.2 Focus Appearance (2.4.11 AA) */
:focus-visible {
    outline: 3px solid #0066CC;
    outline-offset: 2px;
}

.button:focus-visible {
    outline: none;
    box-shadow:
        0 0 0 3px #FFFFFF,
        0 0 0 6px #0066CC;
}

@media (prefers-color-scheme: dark) {
    :focus-visible { outline-color: #66B2FF; }
}

@media (prefers-contrast: more) {
    :focus-visible { outline: 4px solid #000; outline-offset: 3px; }
}

Styling :focus-visible ensures compliance with the Focus Appearance criterion. An alternative via box-shadow works for elements with border-radius. Dark theme and High Contrast adapt focus colors.

Accessible Authentication

Criterion 3.3.7 Accessible Authentication (AA) is one of the most discussed innovations. CAPTCHA with object recognition, puzzles, slider dragging — now a violation if there is no alternative. Acceptable methods: OTP via email/SMS, biometrics (Face ID, Touch ID), QR codes, Magic link. This makes life easier not only for people with cognitive impairments but also for all users.

WCAG for Mobile Applications

WCAG applies to native iOS and Android applications. The four POUR principles fully cover mobile interfaces. Specific criteria: 2.5.1 Pointer Gestures (gestures without high precision), 2.5.2 Pointer Cancellation (accidental touch cancellation), 2.5.3 Label in Name (button text matches accessibility label). iOS uses UIKit/UIAccessibility, Android uses AccessibilityService and ContentDescription.

Most frequently violated in mobile applications: 1.1.1 Non-text Content — icons without contentDescription, 2.4.3 Focus Order — incorrect navigation order, 2.5.8 Target Size — buttons smaller than 24x24dp, 1.4.3 Contrast — text on background images. iOS provides Accessibility Inspector in Xcode, Android provides Accessibility Scanner for automated auditing.

WCAG-Compliant SwiftUI Code

import SwiftUI

struct AccessibleButton: View {
    let action: () -> Void
    let title: String
    let icon: String

    var body: some View {
        Button(action: action) {
            HStack {
                Image(systemName: icon)
                Text(title)
            }
            .padding(16)
            .background(Color.blue)
            .foregroundColor(.white)
            .cornerRadius(12)
            .frame(minWidth: 48, minHeight: 48)
        }
        .accessibilityLabel(title)
        .accessibilityHint("Click to action")
        .accessibilityAddTraits(.isButton)
    }
}

struct AccessibleForm: View {
    @State private var email = ""

    var body: some View {
        VStack(spacing: 16) {
            VStack(alignment: .leading) {
                Text("Email")
                TextField("Enter email", text: $email)
                    .textContentType(.emailAddress)
                    .keyboardType(.emailAddress)
                    .autocapitalization(.none)
                    .accessibilityLabel("Email input field")
                    .accessibilityHint("Enter email address")
            }
            AccessibleButton(
                action: { },
                title: "Send",
                icon: "paperplane.fill"
            )
        }
        .padding()
    }
}

SwiftUI components with accessibilityLabel, accessibilityHint, and minWidth/minHeight >= 48pt ensure compliance with WCAG 2.5.8 (Target Size) and 2.5.3 (Label in Name). Use Xcode Accessibility Inspector to check VoiceOver focus, navigation order, and touch target sizes. Similar requirements apply to Jetpack Compose via Modifier.semantics.