WCAG — qu'est-ce que c'est, Web Content Accessibility Guidelines et niveaux AA

Qu'est-ce que WCAG ?

WCAG (Web Content Accessibility Guidelines) est un ensemble de recommandations pour garantir l'accessibilité du contenu web aux personnes handicapées. La norme est développée par W3C Web Accessibility Initiative (WAI) depuis 1999. WCAG couvre les aveugles et malvoyants, les sourds et malentendants, les personnes à mobilité réduite, les troubles de la parole et cognitifs, ainsi que les utilisateurs âgés présentant des changements liés à l'âge.

La première version WCAG 1.0 est sortie en 1999 et contenait 14 principes directeurs. WCAG 2.0 (2008) est devenue technologiquement neutre, applicable au HTML, PDF, multimédia et applications mobiles. WCAG 2.1 (2018) a ajouté des critères pour les appareils mobiles et la saisie tactile. WCAG 2.2 (2023) est la version actuelle avec de nouveaux critères pour l'animation et le focus. WCAG n'est pas une loi, mais de nombreux pays y font référence dans leur législation.

GOST R 52872-2019 en Russie, la European Accessibility Act dans l'UE et la Section 508 aux États-Unis — toutes exigent la conformité WCAG AA. Pour les sites web d'entreprises et gouvernementaux, WCAG AA est une norme obligatoire dont le non-respect entraîne des poursuites judiciaires. Selon UsableNet (2024), plus de 12 000 poursuites pour inaccessibilité web ont été déposées aux États-Unis.

Versions de WCAG : comparaison

Conséquences juridiques du non-respect

Le non-respect de WCAG comporte des risques graves. En 2025, la European Accessibility Act (EAA) est entrée en vigueur, exigeant WCAG 2.1 AA pour tous les sites web publics et applications mobiles dans l'UE. Les amendes peuvent atteindre jusqu'à 5 % du chiffre d'affaires annuel de l'entreprise. Le montant moyen de règlement des poursuites aux États-Unis est de 25 000 $ à 50 000 $. Les audits d'accessibilité doivent être effectués à chaque étape du développement, pas seulement avant la sortie.

Quatre principes de WCAG : POUR

POUR est un acronyme pour quatre principes WCAG : Perceivable (perceptible), Operable (utilisable), Understandable (compréhensible), Robust (robuste). Chaque principe contient des directives, et les directives contiennent des critères de succès testables. WCAG 2.2 compte 13 directives et 86 critères de succès. Chaque critère a un niveau A, AA ou AAA.

Perceivable — Perceptible

Le principe Perceivable exige que le contenu soit présenté sous une forme que l'utilisateur peut percevoir. Directives : 1.1 Text Alternatives (alternatives textuelles), 1.2 Time-based Media (sous-titres, transcriptions), 1.3 Adaptable (contenu sans perte lors du changement de format), 1.4 Distinguishable (contraste 4,5:1, couleur, son). Le critère clé 1.4.3 Contrast Minimum (AA) est le plus violé : 86 % des pages n'y sont pas conformes selon WebAIM.

Operable — Utilisable

Le principe Operable exige l'utilisabilité de l'interface. Directives : 2.1 Keyboard Accessible, 2.2 Enough Time, 2.3 Seizures, 2.4 Navigable, 2.5 Input Modalities. Le critère 2.1.1 Keyboard (A) est l'un des plus critiques : toutes les fonctions doivent être accessibles via le clavier sans souris. Fenêtres modales qui se ferment uniquement par clic, menus déroulants sans navigation au clavier — violations typiques.

Understandable — Compréhensible

Le principe Understandable exige la compréhensibilité du contenu et de l'interface. Directives : 3.1 Readable, 3.2 Predictable, 3.3 Input Assistance. Le critère 3.3.4 Error Prevention est particulièrement important pour les applications financières et médicales : prévenir les conséquences graves des erreurs de saisie. Le critère 3.2.6 Consistent Help (nouveau dans WCAG 2.2) exige que les boutons d'aide soient aux mêmes endroits.

Robust — Robuste

Le principe Robust exige la compatibilité avec les technologies d'assistance. Directive 4.1 Compatible avec le critère clé 4.1.2 Name, Role, Value (A) : chaque composant d'interface doit avoir un nom, un rôle et un état déterminables par programmation. Les attributs ARIA (role, aria-label, aria-expanded) sont l'outil principal. Sans eux, les lecteurs d'écran ne peuvent pas déterminer si un élément est un bouton, un lien ou un onglet.

Tableau des principes WCAG

Niveaux de conformité WCAG : A, AA, AAA

WCAG définit trois niveaux : A (minimum), AA (standard) et AAA (maximum). Le niveau A est le minimum obligatoire : sans lui, le contenu est inaccessible pour certaines catégories d'utilisateurs. AA supprime les principaux obstacles d'accessibilité. AAA est la norme la plus élevée, mais ne peut pas être atteint pour tout le contenu (par exemple, certaines langues des signes ou transcriptions audio ne sont pas toujours réalisables).

Niveau A (30 critères) : alternatives textuelles, utilisabilité au clavier, temps suffisant, pas de scintillement au-dessus de 3 Hz. Niveau AA (+24 critères) : rapport de contraste 4,5:1, sous-titres pour vidéo, redimensionnement du texte jusqu'à 200 %, focus clavier clair. Niveau AAA (+32 critères) : rapport de contraste 7:1, langue des signes, désactivation des animations (2.3.3), transcription audio. Pour les sites gouvernementaux, AA est suffisant.

Processus d'audit WCAG

Un audit d'accessibilité WCAG comprend : des tests automatisés (axe DevTools, WAVE, Lighthouse — trouve 30 à 40 % des erreurs), des tests manuels au clavier et avec lecteurs d'écran (VoiceOver, TalkBack, NVDA), un audit expert pour les critères complexes et des tests utilisateurs avec des personnes handicapées. Le rapport d'audit doit contenir le niveau de conformité et une liste des non-conformités pour chaque critère.

Nouveautés de WCAG 2.2

WCAG 2.2 a ajouté 9 nouveaux critères. Principaux : 2.4.11 Focus Appearance (AA) — indicateur de focus >= 2px avec contraste 3:1, 2.5.8 Target Size Minimum (AA) — cible tactile d'au moins 24x24 pixels, 3.3.7 Accessible Authentication (AA) — authentification sans CAPTCHA. Critère 2.3.3 Animation from Interactions (AAA) — animation désactivable ou pas plus de 5 secondes.

Focus Appearance est le changement le plus important. Auparavant, outline: none sans remplacement était une violation, mais il n'y avait pas d'exigences claires. WCAG 2.2 a établi : épaisseur >= 2px, contraste 3:1 avec l'arrière-plan, surface de l'indicateur au moins égale à la surface de l'élément. Pour les boutons personnalisés avec border-radius, utilisez box-shadow au lieu d'outline.

Focus Appearance en 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; }
}

Le style de :focus-visible garantit la conformité au critère Focus Appearance. Une alternative via box-shadow fonctionne pour les éléments avec border-radius. Le thème sombre et High Contrast adaptent les couleurs de focus.

Accessible Authentication

Le critère 3.3.7 Accessible Authentication (AA) est l'une des innovations les plus discutées. CAPTCHA avec reconnaissance d'objets, puzzles, glissement de curseurs — désormais une violation s'il n'y a pas d'alternative. Méthodes acceptables : OTP par email/SMS, biométrie (Face ID, Touch ID), codes QR, Magic link. Cela simplifie la vie non seulement des personnes ayant des troubles cognitifs, mais aussi de tous les utilisateurs.

WCAG pour les applications mobiles

WCAG s'applique aux applications natives iOS et Android. Les quatre principes POUR couvrent entièrement les interfaces mobiles. Critères spécifiques : 2.5.1 Pointer Gestures (gestes sans haute précision), 2.5.2 Pointer Cancellation (annulation de toucher accidentel), 2.5.3 Label in Name (le texte du bouton correspond à l'étiquette d'accessibilité). iOS utilise UIKit/UIAccessibility, Android utilise AccessibilityService et ContentDescription.

Les plus violés dans les applications mobiles : 1.1.1 Non-text Content — icônes sans contentDescription, 2.4.3 Focus Order — ordre de navigation incorrect, 2.5.8 Target Size — boutons de moins de 24x24dp, 1.4.3 Contrast — texte sur images d'arrière-plan. iOS fournit Accessibility Inspector dans Xcode, Android fournit Accessibility Scanner pour l'audit automatisé.

Code SwiftUI conforme WCAG

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("Cliquez pour action")
        .accessibilityAddTraits(.isButton)
    }
}

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

    var body: some View {
        VStack(spacing: 16) {
            VStack(alignment: .leading) {
                Text("Email")
                TextField("Saisissez l'email", text: $email)
                    .textContentType(.emailAddress)
                    .keyboardType(.emailAddress)
                    .autocapitalization(.none)
                    .accessibilityLabel("Champ de saisie d'email")
                    .accessibilityHint("Saisissez l'adresse email")
            }
            AccessibleButton(
                action: { },
                title: "Envoyer",
                icon: "paperplane.fill"
            )
        }
        .padding()
    }
}

Les composants SwiftUI avec accessibilityLabel, accessibilityHint et minWidth/minHeight >= 48pt garantissent la conformité à WCAG 2.5.8 (Target Size) et 2.5.3 (Label in Name). Utilisez Xcode Accessibility Inspector pour vérifier le focus VoiceOver, l'ordre de navigation et les tailles des cibles tactiles. Des exigences similaires s'appliquent à Jetpack Compose via Modifier.semantics.