La información y los componentes de la interfaz deben presentarse de manera que todos los usuarios puedan percibirlos.

Tiene que existir una alternativa textual para todo el contenido no textual.

• Todo el contenido no textual que se presenta al usuario tiene una alternativa textual que cumple la misma función, excepto que sea puramente decorativo.

• imágenes informativas con “ALT” (descripción textual que se añade al HTML para los lectores de pantalla o cuando no carga)

• Icon-buttons con nombre accesible, deben soportar aria-label, opcional uso de tooltip.

• gráficos y dashboards con labels, resumenes, descripciones…

• Subtítulos para vídeos pregrabados y en directo.

• Audiodescripción o alternativa textual cuando sea necesaria.

• Alternativas para contenido solo audio o solo vídeo.

• Implicación en diseño: Player con controles claros, subtitulos activables, evitar autoplay, transcripciones disponibles, debe soportar navegación por teclado, screen readers (VoiceOver en iPhone/iPad y TalkBack en Android) u otros dispositivos de asisténcia enternos.

El contenido debe poder adaptarse sin perder estructura ni significado.

• Las relaciones visuales deben existir también semánticamente en la programación.

• El orden de lectura debe tener sentido

• No depender de instrucciones sensoriales (Haz click en el botón rojo)

• El contenido debe funcionar tanto vertical como horizontalmente

• El propósito de los inputs debe poder identificarse programaticamente

• Layouts responsive y flexibles con el zoom: Definir comportamiento responsive i tokens semánticos de spacing

• Jerarquía semántica: Usar estilos semánticos para el texto (H, title, body, etc.)

• Labels visibles en inputs, incluir helper text, error message y estados con contraste AA

El contenido debe poder distinguirse fácilmente

• No depender únicamente del color.

• Contraste mínimo: 4.5:1 texto normal, 3:1 texto grande, 3:1 non-text elements (Texto grande son 18pt(aprox 24px) o 14pt en bold (aprox 18,66px)

• Texto ampliable hasta 200%.

• Reflow: Contendio se presenta si una necesidad excesiva de scroll, especialmente horizontal.

• Text spacing configurable.

• Control de ancho de línea y legibilidad (Nivel AAA pero principio básico de diseño de evitar líneas muy anchas.

• El usuario debe poder pausar audio automático.

• Estados diferenciables: focus, error, hover, pressed, selected o active. Diferenciar en bien el estado “focus” (donde tiene el foco el usuario) del estado “active” (indica que un componente está activo)

• Tipografia escalable: Usar tokens semánticos de texto para font family, weight, size, height y spacing. (no depende de números)

  • Cada plataforma usa su sistema de fuente escalable y adapta los valores:

    • Desktop – rem

    • Android – sp

    • IOS – pt combinado con Dynamic Type

• Color tokens descriptivos: primary, secondary, succes, error, warning, background…

• Buttons con estados perceptibles.

• Labels visibles en inputs, incluir helper text, error message y estados accesibles.

Los componentes de la interfaz de usuario y la navegación deben ser operativos para todos los usuarios. Esto implica que debe funcionar con teclado, tecnologías asistivas, distintos ritmos de interacción, diferentes capacidades motoras y distintos modos de navegación.

Todo debe ser operable mediante teclado. Nota: No se hace referencia a la obligación de otras tecnologías asistivas pero hay un principio que dice que si una web funciona correctamente con teclado, normalmente funcionará con otras tecnologias ya que simulan lla entrada por teclado . (ej: lector de pantalla (JAWS, NVDA, VoiceOver), control per veu (Dragon, Voice Control), commutadors (switch control) eye tracking)

• El usuario no puede quedar atrapado en un componente usando teclado . Ejemplo: modal sin posibilidad de salir con teclado.

• No hay tiempo límite para hacer las acciones por teclado.

• Si se usan atajos simples con una sola tecla (ej: S, M, 1…), facilmente activables por error, se debe poder hacer una de estas opciones una sola tecla deben poder: desactivarse, reconfigurarse o activarse solo cuando el componente al que afecta esté con focus.

• Todos los elementos interactivos tienen que ser accesibles por teclado: Tab, Shift+Tab, Enter, Space, Escape, flechas. (Navegación en dropdowns y menus, permitir salir de los componentes sin quedar atrapados en ellos)

• Se debe mostrar siempre el elemento que tiene el foco en la lectura por teclado

• Diferenciar en componentes el estado “focus” (indica donde tiene el foco el usuario) del estado “active” (indica que un componente está activo)

• No depender sólo del hover (ej: menu visible solo con hover)

• Definir interacción estandar por teclado

Los usuarios deben disponer de suficiente tiempo para interactuar

• Los límites temporales deben ajustarse o desactivarse.

• Las animaciones o contenido en movimiento debe poder pausarse.

• En general evitar información que desaparece o se oculta de manera inesperada.

  • Carrousels con navegación manual y control visible

  • Notifications no una duración mínima razonable

  • Evitar expiranciones agresivas de formularios largos

Evitar contenido que pueda provocar ataques o malestar físico.

• No más de 3 flashes por segundo.

• Permitir desactivar animaciones no esenciales. (AAA)

• Evitar animaciones y transiciones con flashes, parpadeos intensos, movimientos excesivos, o invasivas.

• Componentes animados compatibles con “prefers-reduced-motion”

Los usuarios deben poder navegar y localizar contenido fácilmente.

• Permitir saltar bloques repetitivos. (Ej: “Skip to content”)

• Páginas con títulos claros.

• El orden del focus debe ser lógico. (Ej:-input-link botón-botón)

• Los enlaces deben tener un propósito claro. (Ej. de error: “Haz click aquí”)

• Debe haber varias maneras de encontrar un mismo contenido.

• Headings y labels descriptivos.

• Cuando se usa teclado el elemento con foco tiene que ser visible.

• El elemento con foco no puede quedar oculto por otro elemento. (ej: un popup de publicidad)

• El elemento en foco debe tener un contraste mínimos de 3:1 y ser tan perceptible cómo si tuviera un stroke de 2px alrededor

• Aplica lo comentado en “normativas relevantes”:

  • Focus: El usuario siempre debe saber dónde está, qué está activo (contraste 3:1) y que puede hacer

  • Links: tienen que describir destino o acción

  • Navegación clara, menus comprensibles, labels descriptivos, componentes funcionales por teclado…

Facilitar que el usuario puede interacturar de diferentes maneras y tecnologias asistivas: táctil, mouse, stylus, voz, teclado.

• Dar alternativas simples(clic, doble clic, touch, scroll vertical) para gestos complejos (Drag, swipe, pinch…) ya que requieren precisión motora y pueden fallar con tecnologias asistivas.

• Evitar accions irreversibles con un solo punto en la pantalla o acción simple

• El nombre accesible de un label debe coincidir con el visible

• Las acciones por movimiento deben poder desactivarse.

• Target size mínimo de 24x24px (AA) o 44×44 (AAA)

  • La normativa aplica al espacio mínimo alrededor del elemento clicable sin que el elemento en si tenga que hacer este tamaño.

  • No aplica si su tamaño está restringido por la altura de una línea de texto

  • No aplica si forma parte de un software externo.

• El sistema debe permitir al usuario utilizar diferentes métodos d’entrada o asistivos a la vez excepto cuando sea estrictamente necesario.

• Aplica lo comentado en “normativas relevantes”:

  • Alternativas para gestos complejos

  • Tener en cuenta target size mínimo y cómo aplicarlo. Mantener en componentes área mínimia de 24x24px

  • Labels accesibles igual que los visibles en diseño

La información y el funcionamiento de la interfaz deben ser comprensibles para el usuario.

El contenido textual debe ser legible y comprensible.

• El idioma principal de la página debe estar definido en el código (para lectores de pantalla)

• Los cambios de idioma dentro del contenido deben estar marcados en el código (para lectores de pantalla)

• Las palabras inusuales o muy técnicas deben explicarse. (AAA)

• Las abreviaturas deben ser comprensibles o explicadas. (AAA)

• Si el texto requiere un nivel avanzado de lectura, tendría que existir alguna ayuda (resumenes, indices, imágenes…) o versión simplificada. (AAA)

• Notificaciones, labels, tooltips con mensajes claros y comprensibles evitando abreviaturas y jerga interna o excesivamente compleja.

• Un diseño bien estructurado y claro ayuda a la comprensión

• No mezclar idiomas sin indicarlo en código.

Las interfaces deben comportarse de manera predecible.

• No iniciar cambios de contexto cuando un elemento recibe el foco.

• No cambiar el contexto automáticamente cuando se realizan ajustes si no se ha avisado al usuario. (ej: seleccionar otro idioma y todo cambia sin confirmación (fatal para lectores), formularios con reload instantáneo antes de confirmar) si se permiten cambios dinámicos comprensibles cómo un toggle que activa dark mode.

• Navegación y estructura de la información consistente entre páginas

• Los elementos con una misma función deben ser identificados igual. (ej: evitar un botón de eliminar con diferentes nombres (eliminar, borrar, suprimir…).

• Evitar cambios de contexto si no lo solicita el usuario o hay un botón para desactivar (AAA)

• Ayuda accesible: Si una web ofrece ayuda (contacto, support, chat…) esta ayuda debe estar siempre en el mismo sito.

• Navegación consiste y predecible y no forzar cambios de contexto inesperados

• Acciones que se repiten siempre con el mismo nombre y función

Ayudar al usuario a evitar y corregir errores.

• Los errores deben ser identificados claramente.

• Los inputs deben tener instrucciones o labels claros.

• Se deben sugerir correcciones a los errores cuando sea posible.

• Prevenir errores al validar información con una de estas opciones: la información se puede revisar previamente (input errors), se puede confirmar antes de finalizar o la acción es reversible. (AA para info legal, financiera o datos sensibles y AAA para el resto).

• La ayuda debe ser fácilmente accesible.

• Evitar pedir información repetida innecesariamente.

• Evitar autenticación no accesible basada solo en memoria o lógica compleja.

• Forms con instrucciones claras, notificación de errores, focus en los errores

• Inputs con labels visibles, errores en tiempo real, helper text y succes state si es necesario

• Para acciones críticas doble confirmación, resumen previo o revisión o info reversible.

El contenido debe ser suficientemente sólido para ser interpretado de forma fiable por una amplia variedad de agentes de usuario, incluidas tecnologías asistivas.

Maximizar la compatibilidad con tecnologías actuales y futuras, incluyendo tecnologias asistivas.

• Todos los componentes deben exponer: nombre, rol, y valor o estado de forma accesible.

• Los mensajes de estado deben ser anunciados por tecnologías asistivas sin necesidad de focus. (Ej: mensajes de error o success, snackbars, etc.) Se puede usar el atributo “aria-live” que avisa que cuando un contenido cambie se mande el mensaje de, por ejemplo, “Enviado correctamente”.

Aplica lo comentado en “normativas relevantes”:

• Todo debe funcionar a nivel semántico para ser interpretado por lectores de pantalla: Notificaciones detectables, elementos interactivos a nivel semántico.

• Definir correctamente los nombres, roles y valores o estado usando

• Usar principios de semántica HTML y atributos ARIA.

---

A continuación se resumen las acciones más relevantes que se han citado en la normativa y que hay que llevar a cabo para el cumplimiento del nivel AA de WCG 2.2. Es igualmente imprescindible y complementaria la lectura de las normativas. Las referencias técnicas que se hacen sobre el código sólo aplican al desarrollo web (HTML y atributos ARIA), sin embargo se pueden aplicar los mismos principios de accesibilidad con la técnica correspondiente para Android y iOS.

• No usar únicamente el color para transmitir información.

• Contraste mínimo:

  • 4.5:1 texto normal

  • 3:1 texto grande ( 18pt(aprox 24px) o 14pt en bold (aprox 18,66px))

  • 3:1 componentes e iconografía relevante

  • Focus con contraste mínimo 3:1

• Tokens semánticos de color (Primary, error, surface…)

• Chequear contraste (Stark)

• Texto ampliable al 200%

• Evitar scroll excesivo innecesario, especialmente horizontal

• Contenido bien estructurado y legible (semántica HTML, ARIA y diseño)

• Idioma principal definido en el código e indicar en código cambios de idioma en el contenido

• Explicar palabras muy técnicas, (AAA)y abreviaturas comprensibles o explicadas. (AAA), ayuda cómo resumens, imágenes, indices para textos muy avanzados (AAA)

• Los nombres accesibles (en tecnologias asistivas) deben coincidir con los visibles en diseño

• Tokens semánticos de tipografía e iconografía

• Cada plataforma adapta escalado:

  • Web → rem

  • Android → sp

  • iOS → Dynamic Type + pt

• line-height mínimo ≈ 1.4–1.5

• Evitar líneas excesivamente largas y bloques enormes de texto

• imágenes informativas con “ALT text”. Cuando se trata de una imagen decorativa se añade la etiqueta alt vacía para que los lectores ometan esa imagen, ej: “alt=”””

• Icon-buttons con nombre accesible, deben soportar aria-label, opcional uso de tooltip.

• Gráficos y dashboards con labels, resumenes, descripciones…

• Usar principios de semántica HTML y atributos ARIA. para describir componentes, acciones, etc.(H1, H2, title, aria-label, alt, aria-live, role, aria-expanded…. Priorizar HTML nativo antes que ARIA.

• El contenido debe funcionar: vertical, horizontal, zoom y responsive

• El orden visual y de lectura debe tener sentido.

• Auto-layout, grids fluidos, constraints adaptativos.

• Tokens semánticos de spacing

• Labels siempre visibles y comprensibles y errores visibles con sugerencias si es posible

• Prevenir errores al validar información con una de estas opciones: la información se puede revisar previamente (input errors), se puede confirmar antes de finalizar o la acción es reversible. (AA para info legal, financiera o datos sensibles y AAA para el resto).

• La ayuda debe ser fácilmente accesible.

• Evitar autenticación no accesible basada solo en memoria o lógica compleja.

• Forms con instrucciones claras, notificación de errores, focus en los errores

• Inputs completos: label, helper text, error message, success state.

• Usar principios de semántica HTML y atributos ARIA. para describir componentes, acciones, etc.(H1, H2, title, aria-label, alt, aria-live, role, aria-expanded…. Priorizar HTML nativo antes que ARIA.Navegación e interacción

• Accesible por teclado, lectores de pantalla y tecnologías asistivas.

• Focus siempre visible, no puede quedar oculto.

• Orden lógico de navegación. También con el focus activo

• Links descriptivos.

• No traps de teclado.

• Permitir saltar bloques repetitivos. (Ej: “Skip to content”)

• Target size mínimo de 24x24px (AA) o 44×44 (AAA)

  • La normativa aplica al espacio mínimo alrededor del elemento clicable sin que el elemento en si tenga que hacer este tamaño.

  • No aplica si su tamaño está restringido por la altura de una línea de texto

  • No aplica si forma parte de un software externo.

• Alternativas simples(clic, doble clic, touch, scroll vertical) para gestos complejos (Drag, swipe, pinch…) ya que requieren precisión motora y pueden fallar con tecnologias asistivas.

• Evitar accions irreversibles con un solo punto en la pantalla o acción simple

• El nombre accesible de un label debe coincidir con el visible

• El sistema debe permitir al usuario utilizar diferentes métodos d’entrada o asistivos a la vez excepto cuando sea estrictamente necesario

• Todos los componentes deben exponer: nombre, rol, estado/valor.

• Definir estado focus para los componentes. Puede haber excepciones donde se utilice el estado focus accesible propio del sistema (en css :focus-visible) que suele funcionar bien.

• En todos los sistemas operativos y plataformas en que se trabaje tiene que estar activo el estado focus accesible propio del sistema y se tiene que activar sólo cuando se navega por teclado o otras tecnologías asistivas. Este estado foco es independiente del definido en el diseño. En css se usa :focus-visible

• Evitar activar acciones con hover

• Usar principios de semántica HTML y atributos ARIA. para describir componentes, acciones, etc.(H1, H2, title, aria-label, alt, aria-live, role, aria-expanded…. Priorizar HTML nativo antes que ARIA.

• Subtítulos para vídeos pregrabados y en directo.

• Audiodescripción o alternativa textual cuando sea necesaria.

• Alternativas para contenido solo audio o solo vídeo.

• Posibilidad de parar el movimiento

• No más de 3 flashes/segundo.

• Reduced motion compatible. “prefers-reduced-motion”

• Player con controles claros, subtitulos activables, evitar autoplay, transcripciones disponibles.

• Reducir animaciones complejas, parallas o feedbacks agresivas.

• Usar principios de semántica HTML y atributos ARIA. para describir componentes, acciones, etc.(H1, H2, title, aria-label, alt, aria-live, role, aria-expanded…. Priorizar HTML nativo antes que ARIA.

---

Utiliza etiquetas con significado real en lugar de <div> genéricos para que lectores de pantalla y navegadores entiendan la estructura.

• <header>, <main>, <nav>, <section>, <article>, <footer>, <button>, <form>…

• Jerarquía correcta de <h1> a <h6>

HTML ya incluye accesibilidad nativa para formularios. Utilizar ARIA sólo en casos puntuales que no llega HTML: describir errores o autocompletar complejos.

• <label>, for, id, required, disabled, placeholder, autocomplete…

• alt – Describe imágenes importantes para lectores de pantalla. (No escribir cosas cómo “imagen de”). Cuando se trata de una imagen decorativa se añade la etiqueta alt vacia para que los lectores ometan esa imagen, ej: “alt=”””

• controls, <track>

añaden significado descriptivo, lingüístico o interpretativo al contenido, sin definir la estructura principal del documento.

• lang – Muy importante, define el idioma de la página. También se usa para indicar cambios puntuales de idioma.

• title, datetime , <abbr>, <time>, <cite>

Los atributos ARIA son un conjunto de extensiones para HTML que añaden semántica y mejoran la accesibilidad para tecnologías asistivas cuando HTML no es suficiente.

Guía oficial: ARIA Authoring Practices Guide

Definen qué es un elemento o qué función cumple

• role="dialog", role="alert", role="navigation", role="button", role="tablist"…

Características semánticas permanentes o estructuradas del elemento

• aria-label, aria-labelledby, aria-describedby, aria-hidden, aria-live, aria-invalid, aria-expanded, aria-controls…

Información dinámica que cambia por la interacción del usuario-

• aria-expanded="true" o aria-checked

En Android y iOS no se usa HTML y ARIA ya que tienen sistemas completos de accesibilidad equivalentes

---

Permite controlar la interfície mediante el teclado

• Es la más importante ya que es la base de muchas tecnologias asistivas y harantiza acceso directo al contenido

• Tecnologías relacionadas: teclados adaptados, sticky keys, switch devices

Convierten contenido visual en voz o braille.

• Software más usado: JAWS, NVDA, VoiceOver (Apple), TalkBack (Android), Narrator (Windows)

• Principales usuarios: personas ciegas, baja visión, problemas cognitivos, motrices…

Dispositivos físicos que convierten texto digital a braille táctil.

• Compatibles con JAWS, NVDA, VoiceOver

• Usado por personas ciegas usuarias de braile

Amplían zonas de la pantalla

• Software más usado: ZoomText, Lupa de Windows, Zoom de macOS, Zoom Android/iOS

• Usado por usuarios con baja visión, problemas cognitivos, motrices…

Permite controlar la interfície mediante la voz

• Software más usado: Dragon NaturallySpeaking, Voice Control (Apple), Windows Speech Recognition, VoiceAcces (Android)

• Usado por usuarios con discapacidad motora, fatiga, lesiones…

Control mediante pulsadores físicos.

• Software más usado: Switch Control (Apple), Android Switch Access

• Usado por usuarios con discapacidad motora severa

Control mediante movimiento de ojos.

• Software más usado: Tobii, Eye control Windows

• Usado por usuarios con ELA, parálisis…

Ayuda a comunicarse mediante símbolos, texto o voz sintetizada.

• Software más usado: Proloquo2Go, TD Snap

• Usado por usuarios con autismo, parálisis cerebral, trastornos del habla

Transforman audio en texto.

• Software más usado: Subtítulos automáticos YouTube, Live Captions Windows, Live Captions Android, Subtítulos Apple

• Usado por personas sordas, hipoacusia.

Facilitan comprensión y concentración.

• Usado en Lectura inmersiva Microsoft, Reader Mode navegadores, Texto a voz, Correctores predictivos

• Usuarios con dislexia, TDAH, dificultades cognitivas.

Permite interactuar con dispositivos táctiles de forma simplificada o alternativa, sustituyendo gestos complejos, precisión motora o interacción directa con la pantalla.

• Sofware: AssistiveTouch (Apple),Switch Control (iOS / iPadOS, Touch Assistant (Android), Switch Access (Android)

• Usuarios con dislexia, TDAH, dificultades cognitivas.

---

• Stark

• WEB

  • Lighthouse (DevTools de Chrome) – revisa estructura HTML bàsica, headings (h1-h6), labels en formularis, alt text, ARIA bàsic, contrast, navegació per teclat

  • axe DevTools

• Android

  • Android Accessibility Scanner (Google) -(MUY BÁSICO, MÁS DISEÑO QUE CÓDIGO) (revisa components sense label, contrast insuficient, elements clicables massa petits, problemes bàsics d’accessibilitat

  • Layout Inspector (Android Studio) – Tampoco hace auditoria completa

• iOS

  • Xcode Accessibility Inspector (Apple): labels de elements UI, ordre de focus (VoiceOver), jerarquia d’elements, ARIA-equivalent en UIKit/SwiftUI (accessibilityLabel, traits…)

• WEB

  • NVDA (Gratis muy usado), JAWS (de pago) o Narrator (Windows).

• Android

  • TalkBack

• iOS

  • VoiceOver