B3-T10: Accesibilidad Web y Diseño Universal

La accesibilidad web es un tema transversal que aparece siempre en el examen TAI. Las preguntas se centran en los 4 principios POUR, los 3 niveles de conformidad WCAG, la legislación española (RD 1112/2018) y WAI-ARIA. Es un tema de alta rentabilidad: pocas páginas, muchos puntos.

MARCO NORMATIVO INTERNACIONAL

Fuente: W3C WAI (w3.org/WAI) — Web Accessibility Initiative. Todos los estándares son públicos.
EstándarOrganismoÁmbitoDescripción
WCAG 2.2W3CContenido webPautas de Accesibilidad para el Contenido Web. 4 principios, 13 pautas, 87 criterios de éxito
ATAG 2.0W3CHerramientas de autoríaPautas para las Herramientas que crean contenido web (CMS, editores, IDE)
UAAG 2.0W3CAgentes de usuarioPautas para Navegadores y reproductores multimedia
WAI-ARIA 1.2W3CAplicaciones web ricasRoles, estados y propiedades para hacer accesibles las aplicaciones dinámicas (SPA)
UNE-EN 301 549ETSI / CEN / CENELECTIC en generalNorma armonizada europea. Incluye WCAG 2.1 nivel AA como requisito para contenido web
Tip examen: WCAG = contenido, ATAG = herramientas de autoría, UAAG = agentes de usuario (navegadores). Los tres forman el marco WAI del W3C.

WCAG 2.2 — PRINCIPIOS POUR

Fuente: W3C WCAG 2.2 (w3.org/TR/WCAG22) — Recomendación W3C, junio 2023.
PrincipioSiglaSignificadoPregunta clave
1. PerceptiblePLa información debe poder ser percibida por los sentidos¿Puede el usuario ver/oír/sentir el contenido?
2. OperableOLa interfaz debe poder operarse con distintos dispositivos¿Puede navegar solo con teclado?
3. ComprensibleULa información y la interfaz deben ser comprensibles¿Entiende el usuario qué hacer?
4. RobustoREl contenido debe ser interpretable por diversas tecnologías de asistencia¿Funciona con lectores de pantalla?

PAUTAS POR PRINCIPIO

PrincipioPautasCriterios clave (examen)
Perceptible1.1 Alternativas textualesalt en imágenes, aria-label en controles
1.2 Medios tempodependientesSubtítulos, audiodescripción, transcripciones
1.3 AdaptableContenido presentable de diferentes formas sin perder información
1.4 DistinguibleContraste mínimo 4.5:1 (AA texto normal), 3:1 (AA texto grande)
Operable2.1 Accesible por tecladoTodo funcionalidad accesible solo con teclado. Sin trampas de foco
2.2 Tiempo suficienteEl usuario puede pausar, detener o ajustar límites de tiempo
2.3 ConvulsionesNada parpadea más de 3 veces por segundo
2.4 NavegableSkip links, títulos de página, orden de foco lógico, propósito de enlaces
2.5 Modalidades de entradaGestos alternativos, cancelación de clic, tamaño mínimo de target (24×24 CSS px en WCAG 2.2)
Comprensible3.1 LegibleIdioma de la página (lang), idioma de partes
3.2 PredecibleNavegación consistente, sin cambios inesperados de contexto
3.3 Ayuda en la entradaIdentificación de errores, etiquetas, sugerencias, prevención de errores
Robusto4.1 CompatibleHTML válido, name/role/value para componentes, mensajes de estado

NIVELES DE CONFORMIDAD WCAG

NivelCriteriosObligatoriedadDescripción
ABásicos (mínimos)Mínimo aceptableSin esto, el contenido es inaccesible para grupos amplios
AAA + intermediosExigido por RD 1112/2018Nivel exigido por la legislación española y la UNE-EN 301 549
AAAA + AA + avanzadosRecomendado (no exigible globalmente)Máximo nivel. No siempre alcanzable para todo el contenido
Pregunta clave: Los niveles son acumulativos: AA incluye todos los criterios de A. El nivel AA es el obligatorio para el sector público en España (RD 1112/2018).

LEGISLACIÓN ESPAÑOLA

Fuente: BOE — RD 1112/2018 (BOE núm. 227, 19/09/2018). Transpone la Directiva (UE) 2016/2102.
NormaÁmbitoRequisito
RD 1112/2018Sector público español (webs y apps móviles)Cumplir UNE-EN 301 549 (que incluye WCAG 2.1 nivel AA)
Directiva (UE) 2016/2102Sector público de toda la UEAccesibilidad de sitios web y apps de organismos públicos
Ley 34/2002 (LSSI)Sociedad de la informaciónObliga a la AAPP a hacer accesibles sus webs
Aspecto RD 1112/2018Detalle
Declaración de accesibilidadObligatoria en todas las webs del sector público. Modelo en el PAe
Mecanismo de comunicaciónEl ciudadano puede comunicar incidencias de accesibilidad
Procedimiento de reclamaciónPlazo de respuesta: 20 días hábiles
Revisiones periódicasMonitorización por el Ministerio (cada 3 años completa, anual simplificada)
Norma técnica de referenciaUNE-EN 301 549 (armonizada con la Directiva UE)
Contenido exentoContenido de terceros no financiado, mapas online (salvo datos de navegación), contenido de intranets/extranets publicado antes del 23/09/2019
Dato clave examen: El plazo de respuesta a reclamaciones de accesibilidad es de 20 días hábiles.

UNE-EN 301 549

AspectoDescripción
Qué esNorma europea armonizada de requisitos de accesibilidad para productos y servicios TIC
OrganismoETSI, CEN y CENELEC. Transpuesta como UNE en España
Capítulo 9 (Web)Incorpora por referencia WCAG 2.1 nivel AA
Capítulo 11 (Software)Requisitos accesibilidad para aplicaciones nativas
Capítulo 12 (Documentación)La documentación y soporte deben ser accesibles
Relación con WCAGNo sustituye WCAG; lo incorpora y añade requisitos para software, hardware, telecomunicaciones

WAI-ARIA

Fuente: W3C WAI-ARIA 1.2 (w3.org/TR/wai-aria-1.2). Accessible Rich Internet Applications.
CategoríaAtributosFunción
Rolesrole="button", role="navigation", role="alert", role="dialog", role="tablist"Qué ES el elemento (su función semántica)
Propiedadesaria-label, aria-labelledby, aria-describedby, aria-requiredCaracterísticas del elemento (etiquetas, descripciones)
Estadosaria-expanded, aria-checked, aria-hidden, aria-disabled, aria-selectedEstado actual del elemento (cambia dinámicamente)
Atributo ARIAUso
aria-live="polite"Anuncia cambios cuando el lector de pantalla está inactivo (notificaciones no urgentes)
aria-live="assertive"Interrumpe al lector para anunciar cambios (alertas urgentes)
aria-hidden="true"Oculta el elemento del árbol de accesibilidad (decorativo o redundante)
aria-label="texto"Etiqueta invisible para tecnologías de asistencia (ej: botón con solo icono)
aria-labelledby="id"Etiqueta referenciando otro elemento visible por su id
Regla fundamental ARIA: "No ARIA is better than bad ARIA". Usar primero HTML semántico nativo (button, nav, main). Solo usar ARIA cuando no exista elemento nativo equivalente.

LANDMARKS (PUNTOS DE REFERENCIA)

Landmark ARIAElemento HTML5 equivalenteFunción
role="banner"<header>Cabecera principal
role="navigation"<nav>Navegación
role="main"<main>Contenido principal
role="complementary"<aside>Contenido complementario
role="contentinfo"<footer>Información de pie de página
role="search"<search> (HTML 5.2+)Área de búsqueda
role="form"<form> (con nombre accesible)Formulario

DISEÑO UNIVERSAL — 7 PRINCIPIOS

Fuente: Center for Universal Design, North Carolina State University (1997). Ronald Mace et al. Principios de dominio público.
#PrincipioDescripciónEjemplo web
1Uso equitativoÚtil para personas con diversas capacidadesMismo contenido para todos (no versión "accesible" separada)
2Flexibilidad de usoSe adapta a diferentes preferencias y habilidadesNavegación por teclado, ratón, voz o touch
3Uso simple e intuitivoFácil de entender independientemente de la experienciaFormularios con etiquetas claras, mensajes de error descriptivos
4Información perceptibleInformación disponible por múltiples canales sensorialesTexto alternativo en imágenes, subtítulos en vídeos
5Tolerancia al errorMinimiza riesgos y consecuencias de acciones accidentalesConfirmación antes de borrar, posibilidad de deshacer
6Bajo esfuerzo físicoPuede usarse eficientemente con mínimo esfuerzoTargets de clic suficientemente grandes, formularios simplificados
7Tamaño y espacio adecuadosEspacio para aproximarse, alcanzar y usarDiseño responsive, zoom hasta 200% sin pérdida

HERRAMIENTAS DE EVALUACIÓN

HerramientaTipoUso
WAVEExtensión navegadorEvaluación visual de errores de accesibilidad
axe-coreLibrería (Deque)Motor de evaluación automática. Integrable en testing
LighthouseChrome DevToolsAuditoría de accesibilidad, rendimiento, SEO
NVDA / JAWS / VoiceOverLector de pantallaTesting manual con tecnología de asistencia real
TAWHerramienta onlineEvaluación automatizada según WCAG (española)
Pa11yCLI / CIEvaluación automatizada en pipeline de desarrollo

WCAG-EM (Metodología de Evaluación)

PasoActividad
1. Definir alcanceDeterminar qué páginas/funcionalidades se evalúan y nivel objetivo (AA)
2. Explorar el sitioIdentificar páginas representativas, tecnologías usadas, funcionalidades
3. Seleccionar muestraPáginas aleatoria + funcionalidades clave (buscador, formularios, login)
4. AuditarEvaluar cada criterio WCAG en cada página de la muestra (automático + manual)
5. InformarInforme con hallazgos, nivel de conformidad alcanzado, recomendaciones


FUENTES PÚBLICAS

Este resumen ha sido elaborado íntegramente a partir de fuentes de dominio público. No se ha utilizado material con copyright de terceros ni material de preparadores.
FuenteTipoReferencia
W3C WCAG 2.2Estándarw3.org/TR/WCAG22
W3C WAI-ARIA 1.2Estándarw3.org/TR/wai-aria-1.2
RD 1112/2018LegislaciónBOE núm. 227, 19/09/2018
Directiva (UE) 2016/2102Legislación UEDOUE L 327, 02/12/2016
UNE-EN 301 549Norma armonizadaETSI / CEN / CENELEC
Center for Universal Design (1997)AcadémicoNC State University (dominio público)

¿Quieres practicar este tema con tests?

MIMIR tiene más de 5.000 preguntas verificadas, simulacros con penalización real y chat IA que resuelve tus dudas sobre este tema.

Abrir MIMIR gratis →