WCAG — qué es, Web Content Accessibility Guidelines y niveles AA

¿Qué es WCAG?

WCAG (Web Content Accessibility Guidelines) es un conjunto de recomendaciones para garantizar la accesibilidad del contenido web para personas con discapacidad. El estándar ha sido desarrollado por W3C Web Accessibility Initiative (WAI) desde 1999. WCAG cubre a ciegos y personas con discapacidad visual, sordos y personas con discapacidad auditiva, personas con limitaciones de movilidad, trastornos del habla y cognitivos, así como usuarios mayores con cambios relacionados con la edad.

La primera versión WCAG 1.0 se publicó en 1999 y contenía 14 principios rectores. WCAG 2.0 (2008) se volvió tecnológicamente neutra, aplicable a HTML, PDF, multimedia y aplicaciones móviles. WCAG 2.1 (2018) añadió criterios para dispositivos móviles y entrada táctil. WCAG 2.2 (2023) es la versión actual con nuevos criterios para animación y enfoque. WCAG no es una ley, pero muchos países lo referencian en su legislación.

GOST R 52872-2019 en Rusia, la European Accessibility Act en la UE y la Sección 508 en EE. UU. — todos exigen conformidad WCAG AA. Para sitios web corporativos y gubernamentales, WCAG AA es un estándar obligatorio cuyo incumplimiento conlleva demandas. Según UsableNet (2024), se presentaron más de 12 000 demandas por inaccesibilidad web en EE. UU.

Versiones de WCAG: comparación

Consecuencias legales del incumplimiento

El incumplimiento de WCAG conlleva graves riesgos. En 2025, la European Accessibility Act (EAA) entró en vigor, exigiendo WCAG 2.1 AA para todos los sitios web públicos y aplicaciones móviles en la UE. Las multas pueden alcanzar hasta el 5% de la facturación anual de la empresa. El monto promedio de acuerdo de demandas en EE. UU. es de $25 000–$50 000. Las auditorías de accesibilidad deben realizarse en cada etapa del desarrollo, no solo antes del lanzamiento.

Cuatro principios de WCAG: POUR

POUR es un acrónimo de cuatro principios WCAG: Perceivable (perceptible), Operable (operable), Understandable (comprensible), Robust (robusto). Cada principio contiene pautas, y las pautas contienen criterios de éxito comprobables. WCAG 2.2 tiene 13 pautas y 86 criterios de éxito. Cada criterio tiene nivel A, AA o AAA.

Perceivable — Perceptible

El principio Perceivable exige que el contenido se presente en una forma que el usuario pueda percibir. Pautas: 1.1 Text Alternatives (alternativas textuales), 1.2 Time-based Media (subtítulos, transcripciones), 1.3 Adaptable (contenido sin pérdida al cambiar formato), 1.4 Distinguishable (contraste 4.5:1, color, sonido). El criterio clave 1.4.3 Contrast Minimum (AA) es el más violado: el 86% de las páginas no lo cumplen según WebAIM.

Operable — Operable

El principio Operable exige la operabilidad de la interfaz. Pautas: 2.1 Keyboard Accessible, 2.2 Enough Time, 2.3 Seizures, 2.4 Navigable, 2.5 Input Modalities. El criterio 2.1.1 Keyboard (A) es uno de los más críticos: todas las funciones deben ser accesibles mediante teclado sin ratón. Ventanas modales que se cierran solo con clic, menús desplegables sin navegación por teclado — violaciones típicas.

Understandable — Comprensible

El principio Understandable exige la comprensibilidad del contenido y la interfaz. Pautas: 3.1 Readable, 3.2 Predictable, 3.3 Input Assistance. El criterio 3.3.4 Error Prevention es especialmente importante para aplicaciones financieras y médicas: prevenir consecuencias graves de errores de entrada. El criterio 3.2.6 Consistent Help (nuevo en WCAG 2.2) exige que los botones de ayuda estén en las mismas ubicaciones.

Robust — Robusto

El principio Robust exige compatibilidad con tecnologías de asistencia. Pauta 4.1 Compatible con el criterio clave 4.1.2 Name, Role, Value (A): cada componente de UI debe tener nombre, rol y estado determinables programáticamente. Los atributos ARIA (role, aria-label, aria-expanded) son la herramienta principal. Sin ellos, los lectores de pantalla no pueden determinar si un elemento es un botón, enlace o pestaña.

Tabla de principios WCAG

Niveles de conformidad WCAG: A, AA, AAA

WCAG define tres niveles: A (mínimo), AA (estándar) y AAA (máximo). El nivel A es el mínimo obligatorio: sin él, el contenido es inaccesible para algunas categorías de usuarios. AA elimina las principales barreras de accesibilidad. AAA es el estándar más alto, pero no se puede lograr para todo el contenido (por ejemplo, algunos lenguajes de señas o transcripciones de audio no siempre son factibles).

Nivel A (30 criterios): alternativas textuales, operabilidad con teclado, tiempo suficiente, sin parpadeo superior a 3 Hz. Nivel AA (+24 criterios): relación de contraste 4.5:1, subtítulos para video, redimensionamiento de texto hasta 200%, enfoque de teclado claro. Nivel AAA (+32 criterios): relación de contraste 7:1, lenguaje de señas, desactivación de animaciones (2.3.3), transcripción de audio. Para sitios gubernamentales, AA es suficiente.

Proceso de auditoría WCAG

Una auditoría de accesibilidad WCAG incluye: pruebas automatizadas (axe DevTools, WAVE, Lighthouse — encuentra el 30–40% de errores), pruebas manuales con teclado y lectores de pantalla (VoiceOver, TalkBack, NVDA), auditoría experta para criterios complejos y pruebas con usuarios con discapacidad. El informe de auditoría debe contener el nivel de conformidad y una lista de no conformidades para cada criterio.

Novedades en WCAG 2.2

WCAG 2.2 añadió 9 nuevos criterios. Claves: 2.4.11 Focus Appearance (AA) — indicador de enfoque >= 2px con contraste 3:1, 2.5.8 Target Size Minimum (AA) — objetivo táctil de al menos 24x24 píxeles, 3.3.7 Accessible Authentication (AA) — autenticación sin CAPTCHA. Criterio 2.3.3 Animation from Interactions (AAA) — animación desactivable o no más de 5 segundos.

Focus Appearance es el cambio más importante. Anteriormente, outline: none sin reemplazo era una violación, pero no había requisitos claros. WCAG 2.2 estableció: grosor >= 2px, contraste 3:1 con el fondo, área del indicador al menos el área del elemento. Para botones personalizados con border-radius, use box-shadow en lugar de 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; }
}

La estilización de :focus-visible garantiza el cumplimiento del criterio Focus Appearance. Una alternativa mediante box-shadow funciona para elementos con border-radius. El tema oscuro y High Contrast adaptan los colores de enfoque.

Accessible Authentication

El criterio 3.3.7 Accessible Authentication (AA) es una de las innovaciones más discutidas. CAPTCHA con reconocimiento de objetos, rompecabezas, arrastre de deslizadores — ahora es una violación si no hay alternativa. Métodos aceptables: OTP por email/SMS, biometría (Face ID, Touch ID), códigos QR, Magic link. Esto facilita la vida no solo a personas con trastornos cognitivos, sino también a todos los usuarios.

WCAG para aplicaciones móviles

WCAG se aplica a aplicaciones nativas de iOS y Android. Los cuatro principios POUR cubren completamente las interfaces móviles. Criterios específicos: 2.5.1 Pointer Gestures (gestos sin alta precisión), 2.5.2 Pointer Cancellation (cancelación de toque accidental), 2.5.3 Label in Name (el texto del botón coincide con la etiqueta de accesibilidad). iOS utiliza UIKit/UIAccessibility, Android utiliza AccessibilityService y ContentDescription.

Los más violados en aplicaciones móviles: 1.1.1 Non-text Content — iconos sin contentDescription, 2.4.3 Focus Order — orden de navegación incorrecto, 2.5.8 Target Size — botones menores de 24x24dp, 1.4.3 Contrast — texto sobre imágenes de fondo. iOS proporciona Accessibility Inspector en Xcode, Android proporciona Accessibility Scanner para auditoría automatizada.

Código SwiftUI conforme a 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("Haga clic para accionar")
        .accessibilityAddTraits(.isButton)
    }
}

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

    var body: some View {
        VStack(spacing: 16) {
            VStack(alignment: .leading) {
                Text("Correo electrónico")
                TextField("Ingrese correo electrónico", text: $email)
                    .textContentType(.emailAddress)
                    .keyboardType(.emailAddress)
                    .autocapitalization(.none)
                    .accessibilityLabel("Campo de ingreso de correo")
                    .accessibilityHint("Ingrese dirección de correo electrónico")
            }
            AccessibleButton(
                action: { },
                title: "Enviar",
                icon: "paperplane.fill"
            )
        }
        .padding()
    }
}

Los componentes SwiftUI con accessibilityLabel, accessibilityHint y minWidth/minHeight >= 48pt garantizan el cumplimiento de WCAG 2.5.8 (Target Size) y 2.5.3 (Label in Name). Use Xcode Accessibility Inspector para verificar el enfoque de VoiceOver, el orden de navegación y los tamaños de los objetivos táctiles. Requisitos similares se aplican a Jetpack Compose mediante Modifier.semantics.