1. INTRODUCCIÓN Y ALCANCE

La accesibilidad y la usabilidad determinan si un servicio digital puede ser utilizado de forma autónoma, segura y eficaz por la población a la que se dirige. En el ámbito sanitario esta afirmación adquiere especial intensidad. Una barrera en un portal de cita, en una aplicación móvil, en un documento clínico descargable o en una interfaz profesional puede impedir el ejercicio de un derecho, retrasar una actuación asistencial, aumentar el riesgo de error o trasladar a terceras personas una tarea que el usuario debería poder realizar por sí mismo.

La accesibilidad digital persigue que los productos, contenidos y servicios puedan ser percibidos, comprendidos, navegados y operados por personas con capacidades diversas, incluidas las que utilizan tecnologías de apoyo. La usabilidad analiza en qué medida usuarios especificados alcanzan objetivos especificados con eficacia, eficiencia y satisfacción en un contexto de uso determinado. Ambas disciplinas se relacionan, pero no son equivalentes: un producto puede cumplir formalmente numerosos requisitos de accesibilidad y seguir siendo confuso, y puede resultar cómodo para un grupo de usuarios mientras excluye a quienes navegan con teclado, lector de pantalla, ampliador, control por voz o con dificultades cognitivas.

El epígrafe oficial añade el W3C, el diseño universal y el diseño web adaptativo. Estos cuatro bloques forman una cadena coherente. El W3C produce estándares y documentación técnica; las WCAG concretan requisitos de accesibilidad del contenido web; el diseño universal establece una filosofía preventiva e inclusiva; y el diseño adaptativo o responsive aporta técnicas para que la interfaz responda a diferentes pantallas, orientaciones, niveles de zoom, preferencias y métodos de interacción.

Para un TFA-STI no basta memorizar siglas. Debe saber convertirlas en requisitos verificables, incorporarlas a pliegos, historias de usuario y criterios de aceptación, revisar diseños, organizar pruebas, interpretar informes de conformidad y gestionar excepciones. También debe distinguir entre cumplimiento normativo, calidad técnica y experiencia real. Una herramienta automática puede detectar que falta un atributo, pero no decidir por sí sola si un texto alternativo comunica correctamente la información clínica o si el orden de lectura de una pantalla resulta lógico.

Este tema adopta una perspectiva técnica y de oposición. Explica conceptos, normas, criterios de conformidad, patrones de implementación, evaluación y aplicación en servicios públicos sanitarios. Se evita atribuir a aplicaciones concretas del SAS tecnologías o niveles de conformidad no verificados; el enfoque se centra en las obligaciones, los métodos y las evidencias que deben exigirse a cualquier servicio digital sanitario.

2. ACCESIBILIDAD, USABILIDAD Y EXPERIENCIA DE USUARIO

2.1. Accesibilidad

La accesibilidad es la cualidad que permite que un producto o servicio sea utilizado por personas con la gama más amplia posible de capacidades. En la web comprende el contenido, la estructura, la presentación, la interacción, los documentos descargables, el audio y vídeo, la autenticación, la firma, el pago y cualquier proceso digital que forme parte del servicio. No se limita a la ceguera ni a la compatibilidad con lectores de pantalla.

La accesibilidad debe analizarse frente a barreras visuales, auditivas, motoras, del habla, cognitivas, neurológicas y combinadas. También beneficia a personas mayores, usuarios con lesiones temporales, quienes trabajan con una mano, personas en entornos ruidosos, pantallas bajo luz intensa, conexiones deficientes o dispositivos de pequeño formato. Esta extensión no diluye la finalidad principal: las personas con discapacidad deben poder acceder en condiciones de igualdad y no discriminación.

2.2. Usabilidad

ISO 9241-11:2018 relaciona la usabilidad con usuarios, objetivos, recursos y entorno. Sus resultados principales son eficacia, eficiencia y satisfacción. La eficacia valora si la tarea se completa correctamente; la eficiencia relaciona el resultado con tiempo, esfuerzo y recursos; y la satisfacción comprende respuestas físicas, cognitivas y emocionales derivadas del uso.

La definición exige describir el contexto de uso: perfiles de usuario, tareas, equipamiento, entorno físico, social y organizativo. Una pantalla puede ser usable para un profesional experto en un puesto fijo y no serlo para un paciente ocasional desde un móvil. Del mismo modo, una interfaz utilizada en urgencias debe soportar presión temporal, interrupciones, guantes, ruido y consecuencias clínicas del error.

2.3. Experiencia de usuario y conceptos relacionados

La experiencia de usuario o user experience es más amplia que la usabilidad. Incluye percepciones y respuestas antes, durante y después del uso: expectativas, confianza, utilidad, identidad, emociones, soporte, reputación y continuidad entre canales. La accesibilidad y la usabilidad son componentes esenciales de una buena experiencia, pero no la agotan.

También conviene distinguir utilidad, aceptación y calidad de uso. Un producto puede ser fácil de manejar pero no resolver una necesidad relevante. Puede ser técnicamente útil y, sin embargo, no adoptarse por falta de confianza, apoyo, integración con el proceso o compatibilidad con el dispositivo. En sistemas sanitarios, la seguridad, la privacidad, la continuidad y la interoperabilidad condicionan la experiencia, pero no sustituyen la evaluación de accesibilidad y usabilidad.

2.4. Relación y diferencias

La accesibilidad fija condiciones para que las personas no queden excluidas por el diseño. La usabilidad mide la calidad del uso en un contexto. Un botón sin nombre accesible impide que un lector de pantalla identifique su función: es una barrera de accesibilidad. Un proceso de treinta pantallas con mensajes ambiguos puede ser operable técnicamente, pero poco usable. La solución correcta es diseñar para ambas desde el inicio y probar con personas representativas, incluidas personas con discapacidad.

3. PERSONAS, CAPACIDADES, CONTEXTOS Y BARRERAS

El enfoque contemporáneo no sitúa el problema exclusivamente en la persona. La discapacidad aparece en la interacción entre capacidades, tareas, productos y entorno. Una interfaz que exige distinguir rojo y verde crea una barrera para personas con deficiencia de visión del color; una sesión que expira sin aviso afecta a quien necesita más tiempo; un control que solo responde a arrastre excluye a quien no puede realizar movimientos precisos.

3.1. Diversidad visual

Incluye ceguera, baja visión, pérdida de campo visual, sensibilidad al contraste y alteraciones en la percepción del color. Las respuestas de diseño comprenden estructura semántica, alternativas textuales, contraste suficiente, ampliación sin pérdida, reflujo, indicadores de foco visibles, ausencia de dependencia exclusiva del color y compatibilidad con lectores y magnificadores.

3.2. Diversidad auditiva

Las personas sordas o con hipoacusia necesitan alternativas a la información sonora. Los vídeos pregrabados deben ofrecer subtítulos cuando corresponda; el audio relevante puede requerir transcripción; los avisos no deben comunicarse únicamente mediante sonido. En videollamadas y atención remota deben analizarse subtitulado, calidad de imagen, compatibilidad con lengua de signos cuando proceda y canales alternativos.

3.3. Diversidad motora y del habla

Puede afectar precisión, alcance, fuerza, velocidad o capacidad de utilizar un dispositivo apuntador. Algunas personas navegan con teclado, pulsadores, barrido, control ocular, voz o dispositivos adaptados. Son esenciales el acceso completo por teclado, el foco gestionado, objetivos táctiles adecuados, alternativas a gestos complejos, ausencia de límites de tiempo rígidos y posibilidad de deshacer acciones.

3.4. Diversidad cognitiva, lingüística y neurológica

Incluye dificultades de atención, memoria, comprensión, lectura, planificación, orientación o regulación sensorial. El diseño debe utilizar lenguaje claro, jerarquía predecible, instrucciones próximas a la tarea, ayudas consistentes, prevención de errores, autenticación que no dependa exclusivamente de recordar o transcribir información y reducción de estímulos innecesarios. Las animaciones y parpadeos pueden provocar malestar o crisis en personas sensibles.

3.5. Discapacidad temporal y limitaciones situacionales

Una mano inmovilizada, fatiga, migraña, una pantalla rota, ruido ambiental o iluminación intensa pueden reproducir barreras similares a una discapacidad permanente. El valor del diseño inclusivo es que una misma solución —subtítulos, teclado, contraste, lenguaje claro, controles grandes— sirve a grupos muy diversos sin crear versiones separadas.

3.6. Tecnologías de apoyo

4. W3C Y WEB ACCESSIBILITY INITIATIVE

4.1. W3C

El World Wide Web Consortium es una organización internacional que desarrolla estándares abiertos para la Web mediante grupos de trabajo, revisión pública, implementación y consenso. Fue fundado en 1994 por Tim Berners-Lee. Sus especificaciones abarcan tecnologías como HTML, CSS, SVG, Web APIs, internacionalización, privacidad y accesibilidad. El W3C no es un legislador ni una autoridad de certificación pública: sus recomendaciones adquieren fuerza jurídica cuando una norma o contrato las incorpora.

4.2. WAI

La Web Accessibility Initiative coordina el trabajo de accesibilidad del W3C. Produce estándares, técnicas, patrones, materiales de formación y métodos de evaluación. Su arquitectura clásica distingue tres componentes: contenido, herramientas de autor y agentes de usuario. La accesibilidad efectiva depende de la interacción entre ellos y de las tecnologías de apoyo.

4.3. Documentos normativos y documentos de apoyo

En el ecosistema W3C debe distinguirse la especificación normativa de los recursos explicativos. Las WCAG contienen principios, pautas, criterios de conformidad y requisitos de conformidad. Los documentos Understanding WCAG explican la intención; Techniques ofrece técnicas suficientes, recomendables y fallos conocidos; Quick Reference permite filtrar criterios y técnicas. Las técnicas no son la única forma válida de cumplir un criterio, salvo que una norma o contrato imponga una tecnología concreta.

WAI-ARIA aporta roles, estados y propiedades que se exponen a la API de accesibilidad. La Authoring Practices Guide presenta patrones orientativos para widgets como diálogos, pestañas, menús y árboles. Los ejemplos no deben copiarse sin comprender teclado, foco, semántica y estados, porque una implementación parcial puede empeorar la accesibilidad.

4.4. Accesibilidad como sistema

La cadena explica por qué un defecto puede originarse fuera de la página. Un CMS que elimina atributos, una biblioteca de componentes inaccesible, un visor de documentos sin teclado o un reproductor sin subtítulos generan barreras aunque el equipo editorial conozca WCAG. La gobernanza debe abarcar plataforma, componentes, contenido y mantenimiento.

5. WCAG 2: ESTRUCTURA, PRINCIPIOS Y CONFORMIDAD

5.1. Versiones y compatibilidad

WCAG 2.0 fue publicada como Recomendación W3C en 2008; WCAG 2.1 en 2018; y WCAG 2.2 en 2023, con actualización editorial posterior. Las versiones 2.x mantienen una arquitectura común y son acumulativas: WCAG 2.1 añadió requisitos a 2.0 y WCAG 2.2 añadió requisitos a 2.1. W3C recomienda utilizar la versión más reciente, pero la exigencia jurídica concreta depende de la norma técnica incorporada por la legislación aplicable.

En agosto de 2026, WCAG 2.2 es el estándar W3C más reciente y estable de la familia 2.x. Sin embargo, la norma armonizada europea EN 301 549 V3.2.1 sigue basando sus requisitos web en WCAG 2.1. Por tanto, deben distinguirse dos decisiones: el mínimo exigible por el marco europeo vigente y el objetivo técnico recomendado para nuevos desarrollos. Adoptar WCAG 2.2 permite cubrir los requisitos anteriores y anticipar la evolución normativa, pero no autoriza a afirmar que toda obligación europea ya se ha actualizado automáticamente a 2.2.

5.2. Principios, pautas y criterios

WCAG 2 se estructura en cuatro principios conocidos por el acrónimo POUR: perceptible, operable, comprensible y robusto. Bajo los principios se organizan pautas generales y criterios de conformidad verificables. Cada criterio tiene un nivel A, AA o AAA. La separación permite expresar objetivos amplios y, al mismo tiempo, establecer condiciones que pueden evaluarse.

5.3. Niveles A, AA y AAA

El nivel A contiene barreras fundamentales cuya ausencia suele impedir el acceso. El nivel AA añade requisitos que afectan de forma significativa al uso y es el nivel de referencia habitual en legislación y contratación pública. El nivel AAA incorpora objetivos más exigentes, pero W3C advierte que no se recomienda exigir conformidad AAA a sitios completos como política general, porque algunos contenidos no pueden satisfacer todos sus criterios.

La conformidad es acumulativa: para declarar AA deben cumplirse todos los criterios A y AA aplicables. No existe una conformidad “parcial AA” del sitio completo. Puede documentarse que determinadas páginas o contenidos no conforman, pero la declaración debe ser precisa y no presentar como cumplimiento lo que solo constituye un avance o una puntuación de herramienta.

5.4. Requisitos de conformidad

Además de satisfacer criterios, WCAG exige que la conformidad alcance páginas completas y procesos completos. Si un trámite se compone de identificación, formulario, firma y justificante, no basta con que la portada sea accesible. Las tecnologías utilizadas deben emplearse de forma compatible con accesibilidad y la no conformidad de contenido ajeno no debe bloquear el acceso al resto cuando sea posible.

Una declaración de conformidad puede indicar versión, nivel, alcance y tecnologías empleadas, pero no debe confundirse con la declaración de accesibilidad exigida por el Real Decreto 1112/2018. Esta última incluye situación de cumplimiento, contenidos no accesibles, mecanismo de comunicación y procedimiento de aplicación, conforme al modelo europeo correspondiente.

5.5. WCAG no es una lista de tecnologías

WCAG es tecnológicamente neutral. Puede aplicarse a HTML, documentos, aplicaciones web y otros formatos con técnicas apropiadas. Utilizar HTML5, CSS, JavaScript o ARIA no garantiza conformidad. El criterio es el resultado accesible: información disponible, operación posible, comportamiento comprensible y compatibilidad suficiente. Una implementación nativa y sencilla suele ofrecer mejor base que un componente personalizado que intenta reconstruir semántica y teclado.

6. CRITERIOS WCAG ESENCIALES

6.1. Alternativas textuales y contenido no textual

El criterio 1.1.1 exige alternativas textuales para contenido no textual, con tratamiento diferente según su función. Una imagen informativa necesita un equivalente que comunique su propósito; una imagen decorativa debe ignorarse mediante un texto alternativo vacío en HTML; un control gráfico requiere un nombre que describa su acción; un CAPTCHA necesita alternativas para distintas capacidades. El texto alternativo no debe limitarse a repetir “imagen de” ni describir detalles irrelevantes.

<img src="resultado.png"
     alt="Evolución de glucemia: descenso de 180 a 120 mg/dL entre enero y marzo">

<img src="separador.svg" alt="">

Los gráficos complejos pueden requerir una descripción próxima, tabla de datos o enlace a una explicación ampliada. En información sanitaria debe priorizarse el significado clínico y evitar que la alternativa introduzca interpretaciones no validadas.

6.2. Estructura, relaciones y secuencia

Los criterios 1.3.1 y 1.3.2 exigen que la información, estructura y relaciones comunicadas visualmente estén disponibles programáticamente y que el orden de lectura sea significativo. Encabezados, listas, tablas, grupos de formulario y regiones deben utilizar elementos semánticos adecuados. No es suficiente simular un título aumentando tamaño y negrita.

Las tablas de datos necesitan cabeceras asociadas y no deben emplearse para maquetación. Los formularios deben relacionar cada etiqueta con su control. La secuencia del DOM debe seguir la secuencia lógica, incluso cuando CSS cambie la presentación visual. Reordenar columnas con propiedades visuales puede provocar que el lector de pantalla y el foco recorran un orden distinto del que ve el usuario.

6.3. Uso del color y contraste

El color no puede ser el único medio para transmitir información. Un error marcado solo en rojo, una leyenda basada exclusivamente en colores o un enlace distinguido únicamente por tono pueden resultar invisibles para parte de la población. Deben añadirse texto, iconos con significado accesible, patrones o subrayado.

En nivel AA, el contraste mínimo del texto normal es 4,5:1 y el del texto grande es 3:1. El texto grande se define, de forma simplificada, como al menos 18 puntos o 14 puntos en negrita, considerando la conversión a píxeles CSS. Los componentes de interfaz y objetos gráficos necesarios requieren 3:1 frente a colores adyacentes. Los logotipos y elementos inactivos tienen tratamientos específicos.

6.4. Redimensionado, reflujo y espaciado

El texto debe poder ampliarse hasta el 200 % sin pérdida de contenido o funcionalidad, salvo excepciones. El criterio de reflujo exige que, al equivaler a una anchura de 320 píxeles CSS, el contenido no necesite desplazamiento en dos dimensiones para leer y operar, excepto elementos que por naturaleza requieren dos dimensiones, como mapas o tablas complejas. Esta condición se relaciona con diseños fluidos, pero no equivale simplemente a “tener versión móvil”.

El usuario también debe poder modificar ciertos valores de espaciado de texto sin que el contenido se corte o solape. Por ello deben evitarse contenedores de altura fija, textos convertidos en imagen y dependencias rígidas entre tipografía y caja.

6.5. Teclado, foco y navegación

Toda funcionalidad debe ser operable mediante teclado cuando la tarea no dependa esencialmente de un trazado libre. El foco no puede quedar atrapado, debe seguir un orden coherente y ser visible. Los usuarios necesitan identificar dónde están, saltar bloques repetidos, comprender el propósito de enlaces y localizar páginas mediante más de una vía cuando proceda.

<a href="#contenido">Saltar al contenido principal</a>

<button type="button" aria-expanded="false" aria-controls="panel-ayuda">
  Mostrar ayuda
</button>

Un indicador de foco eliminado con outline: none sin alternativa visible crea una barrera. WCAG 2.2 refuerza la protección frente a foco oculto por cabeceras fijas, diálogos o elementos superpuestos.

6.6. Tiempo, movimiento y destellos

Cuando existe un límite de tiempo, el usuario debe poder desactivarlo, ajustarlo o ampliarlo, salvo excepciones justificadas. Los contenidos en movimiento, parpadeo o actualización automática deben poder pausarse cuando interfieran. Ningún contenido debe destellar más de los umbrales establecidos, porque puede desencadenar crisis fotosensibles.

La preferencia prefers-reduced-motion permite respetar a quienes reducen animaciones en su sistema. No sustituye todos los requisitos WCAG, pero constituye una técnica útil para evitar transiciones intensas, desplazamientos automáticos y efectos vestibulares.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms;
    animation-iteration-count: 1;
    scroll-behavior: auto;
    transition-duration: 0.01ms;
  }
}

6.7. Idioma, consistencia y errores

El idioma principal debe declararse y los cambios de idioma identificarse cuando afectan a pronunciación o comprensión. La navegación y los componentes con la misma función deben ser consistentes. Los errores deben identificarse en texto, explicar cómo corregirlos y asociarse con el campo correspondiente. Para operaciones con consecuencias jurídicas, financieras o de datos, se requieren mecanismos de revisión, confirmación o reversión según el criterio aplicable.

6.8. Nombre, función, valor y mensajes de estado

Los componentes deben exponer programáticamente su nombre, función, estados y valores. Los mensajes de estado importantes deben anunciarse a tecnologías de apoyo sin obligar a mover el foco. Un resultado de búsqueda, una confirmación de guardado o un error asíncrono puede comunicarse mediante regiones de estado apropiadas, evitando anuncios excesivos.

7. WCAG 2.2 Y EVOLUCIÓN FUTURA

7.1. Finalidad de WCAG 2.2

WCAG 2.2 incorpora nueve criterios respecto de WCAG 2.1, con especial atención a baja visión, movilidad y dificultades cognitivas. Mantiene los cuatro principios y la compatibilidad hacia atrás. Además, declara obsoleto el criterio 4.1.1 de análisis sintáctico o Parsing, porque los navegadores modernos y las APIs de accesibilidad gestionan de forma diferente los errores de marcado. Esto no significa que el HTML inválido sea una buena práctica: la validez sigue facilitando mantenibilidad, interoperabilidad y detección de defectos.

7.2. Nuevos criterios

El tamaño mínimo de 24 por 24 píxeles CSS admite excepciones, entre ellas separación suficiente, controles equivalentes, presentación determinada por el agente de usuario o casos esenciales. No debe confundirse con el criterio AAA 2.5.5 de 44 por 44 píxeles CSS. En aplicaciones móviles, las guías de plataforma pueden recomendar áreas mayores por razones de ergonomía.

7.3. Autenticación accesible

La autenticación es una fuente frecuente de barreras. Recordar una contraseña, resolver un acertijo, transcribir caracteres o reconocer imágenes puede constituir una prueba cognitiva. WCAG 2.2 permite mecanismos de apoyo como gestores de contraseñas, pegado, autenticación mediante enlace, biometría o alternativas que no exijan memorizar o transformar información. Bloquear el pegado en campos de contraseña suele perjudicar seguridad y accesibilidad.

7.4. WCAG 3

W3C desarrolla WCAG 3 como borrador de trabajo orientado a un alcance más amplio y a nuevos métodos de evaluación. En agosto de 2026 no es una Recomendación W3C ni sustituye a WCAG 2. La oposición puede preguntar por su existencia y orientación, pero no debe utilizarse como base normativa de conformidad ni confundirse con una versión definitiva.

8. HTML SEMÁNTICO, WAI-ARIA Y TECNOLOGÍAS DE APOYO

8.1. Semántica nativa primero

HTML incorpora elementos con comportamiento, semántica y teclado conocidos: botones, enlaces, campos, listas, tablas, encabezados y regiones. Deben utilizarse antes de recrearlos con elementos genéricos. Un button recibe foco, se activa con teclado y expone su función; un div con un manejador de clic no ofrece esas propiedades automáticamente.

<!-- Preferible -->
<button type="button">Guardar</button>

<!-- Insuficiente sin reconstruir semántica y teclado -->
<div onclick="guardar()">Guardar</div>

La primera regla práctica de ARIA se resume así: si existe un elemento HTML nativo con la semántica y comportamiento necesarios, debe preferirse. ARIA no modifica por sí sola la presentación ni implementa interacción. Declarar role="button" obliga todavía a gestionar foco, activación por teclado, estado y estilo.

8.2. Roles, estados y propiedades

WAI-ARIA define roles como dialog, tab, status o navigation; estados como aria-expanded, aria-selected o aria-checked; y propiedades como aria-label, aria-labelledby y aria-describedby. Su finalidad es exponer información a la API de accesibilidad para que el agente de usuario y la tecnología de apoyo la comuniquen.

El nombre accesible debe ser estable, breve y coherente con la etiqueta visible. En control por voz, una discrepancia entre texto visible y nombre programático impide que el usuario active el elemento pronunciando lo que ve. Es preferible que el texto visible forme parte del nombre accesible.

8.3. Gestión del foco

Las interfaces dinámicas deben mover el foco solo cuando el cambio de contexto lo exige. Al abrir un diálogo, el foco se sitúa dentro; la tabulación queda contenida mientras está abierto; Escape puede cerrarlo cuando proceda; y al cerrar se devuelve el foco al control que lo abrió. Mover el foco ante cada mensaje menor desorienta y rompe la secuencia de trabajo.

8.4. Regiones vivas y mensajes de estado

Las regiones vivas anuncian cambios asíncronos. role="status" resulta apropiado para información no urgente; role="alert" para mensajes que requieren atención inmediata. Su uso indiscriminado produce interrupciones y repeticiones. El contenido debe existir o actualizarse de modo que el agente pueda detectar el cambio.

<div id="resultado" role="status" aria-live="polite"></div>

8.5. Árbol de accesibilidad

El navegador transforma el DOM y las propiedades de estilo en un árbol de accesibilidad con nombres, roles, estados y relaciones. Las tecnologías de apoyo consultan ese árbol. Por ello una interfaz puede parecer correcta visualmente y estar vacía o mal estructurada para un lector de pantalla. Las herramientas de desarrollo permiten inspeccionar esta representación y detectar nombres ausentes, roles incorrectos o elementos ocultos.

8.6. Errores frecuentes con ARIA

• Añadir roles que contradicen la semántica nativa.
• Utilizar aria-hidden="true" en un elemento que contiene controles enfocables.
• Definir un estado visual sin actualizar el estado ARIA correspondiente.
• Crear componentes con ratón y olvidar teclado o foco.
• Usar aria-label para ocultar una etiqueta visible incoherente.
• Copiar un patrón sin implementar todas sus interacciones.

9. DISEÑO UNIVERSAL Y DISEÑO PARA TODAS LAS PERSONAS

9.1. Concepto

El diseño universal persigue concebir productos y entornos utilizables por todas las personas, en la mayor extensión posible, sin necesidad de adaptación o diseño especializado. El término se asocia a Ronald Mace y al trabajo del Center for Universal Design. En Europa y España se emplean también expresiones como diseño para todas las personas y accesibilidad universal.

El diseño universal no promete que una única solución cubra absolutamente todas las necesidades. Debe complementarse con productos de apoyo, configuraciones personales y ajustes razonables cuando sean necesarios. Su aportación principal es preventiva: evita crear una solución estándar excluyente y una adaptación secundaria para quienes quedaron fuera.

9.2. Los siete principios

9.3. Diseño universal, accesibilidad y ajustes razonables

La accesibilidad universal es una condición que deben cumplir entornos, procesos, bienes y servicios para ser comprensibles, utilizables y practicables en seguridad y comodidad. El diseño universal es la estrategia de concepción. El ajuste razonable es una modificación necesaria y adecuada para un caso particular cuando no impone una carga desproporcionada. Son conceptos complementarios: diseñar universalmente reduce la necesidad de ajustes, pero no la elimina.

En una aplicación sanitaria, permitir texto ampliable, navegación por teclado y mensajes claros forma parte del diseño general. Configurar una forma específica de entrada o proporcionar apoyo individual puede constituir un ajuste. El equipo TIC debe evitar que la existencia de un canal telefónico se utilice como excusa para mantener inaccesible el canal digital cuando este forma parte del servicio público.

9.4. Diseño inclusivo y co-diseño

El diseño inclusivo pone énfasis en comprender exclusiones y aprender de personas diversas. El co-diseño incorpora usuarios y partes interesadas a la definición, prototipado y evaluación. No consiste en solicitar una opinión al final, sino en compartir problemas, decisiones y pruebas. Las organizaciones representativas de personas con discapacidad aportan experiencia colectiva, pero no sustituyen automáticamente la prueba con usuarios del producto real.

9.5. Beneficios y límites

El diseño universal amplía mercado y cobertura, reduce adaptaciones tardías, mejora mantenibilidad y suele beneficiar a todos. Subtítulos ayudan en entornos ruidosos; lenguaje claro reduce errores; buen contraste mejora lectura al sol; teclado favorece a usuarios expertos. No obstante, una justificación basada solo en beneficio general puede ocultar el fundamento de derechos. La accesibilidad debe cumplirse aunque el retorno económico inmediato sea difícil de calcular.

10. INGENIERÍA DE USABILIDAD Y DISEÑO CENTRADO EN LAS PERSONAS

10.1. Diseño centrado en las personas

ISO 9241-210:2019 describe principios y actividades de diseño centrado en las personas para sistemas interactivos. El proceso parte de comprender y especificar el contexto de uso, definir requisitos de usuario, producir soluciones de diseño y evaluarlas frente a los requisitos. Es iterativo y multidisciplinar. La participación de usuarios no se limita a validar una solución terminada; informa decisiones desde la investigación inicial.

La iteración debe ser dirigida por evidencia. Cambiar colores o mover controles sin hipótesis, métricas y observación puede producir actividad sin mejora. Los requisitos de usabilidad deben ser medibles: porcentaje de tareas completadas, tiempo, errores críticos, necesidad de ayuda y puntuación de satisfacción para perfiles y contextos concretos.

10.2. Investigación de usuarios

Las técnicas incluyen entrevistas, observación contextual, análisis de incidencias, diarios, encuestas, revisión de analítica, mapas de recorrido y talleres. En sanidad, observar el trabajo real resulta especialmente importante porque los procedimientos documentados no siempre reflejan interrupciones, atajos, cambios de turno, dispositivos compartidos y dependencias entre profesionales.

Las personas participantes deben representar diversidad funcional, edad, alfabetización, experiencia digital, idioma, dispositivo y contexto. Un panel compuesto solo por usuarios expertos no revela barreras de incorporación; un estudio exclusivo con ciudadanos jóvenes no representa a personas mayores o con baja competencia digital.

10.3. Requisitos y escenarios

Los escenarios describen quién realiza qué tarea, con qué objetivo y en qué condiciones. Permiten transformar necesidades en criterios de aceptación. Por ejemplo: “Una persona con baja visión, desde un móvil en orientación vertical y con zoom elevado, puede consultar y descargar el justificante sin desplazamiento horizontal general ni pérdida de controles”.

Las historias de usuario deben complementarse con requisitos no funcionales. La fórmula “como usuario quiero…” no garantiza accesibilidad. Son necesarios criterios sobre teclado, foco, nombre accesible, contraste, mensajes de error, reflujo, idioma, autenticación y pruebas.

10.4. Prototipos

Los prototipos de baja fidelidad permiten explorar estructura y flujo; los de alta fidelidad permiten evaluar contenido, interacción y presentación. Un prototipo visual no siempre tiene semántica accesible, por lo que no debe presentarse como prueba de conformidad. Las herramientas de diseño deben documentar encabezados, orden de lectura, etiquetas, estados, foco y comportamiento responsive para facilitar una implementación correcta.

10.5. Heurísticas de Nielsen

Las diez heurísticas de Jakob Nielsen son reglas generales para revisar interfaces: visibilidad del estado, correspondencia con el mundo real, control y libertad, consistencia, prevención de errores, reconocimiento antes que recuerdo, flexibilidad y eficiencia, diseño minimalista, ayuda para reconocer y recuperar errores, y ayuda/documentación. Son útiles para inspección, pero no sustituyen WCAG ni las pruebas con usuarios.

10.6. Métricas y pruebas de usabilidad

Una prueba moderada permite observar a participantes mientras realizan tareas. La persona facilitadora evita enseñar la solución y registra conducta, comentarios, tiempos, errores y recuperación. Las pruebas remotas no moderadas permiten mayor escala, pero ofrecen menos contexto. El método debe adaptarse a la criticidad y a la fase del proyecto.

El cuestionario System Usability Scale proporciona una puntuación global a partir de diez ítems, pero no diagnostica por sí solo las causas. Debe combinarse con éxito de tarea, tiempo, errores, entrevistas y observación. Las métricas agregadas pueden ocultar desigualdad: una tasa global alta puede coexistir con fracaso sistemático de personas que usan teclado o ampliación.

10.7. Carga cognitiva, seguridad y eficiencia

La simplificación no consiste en eliminar información necesaria. Debe reducirse la carga extrínseca: pasos redundantes, terminología inconsistente, opciones irrelevantes y memoria innecesaria. En decisiones clínicas o administrativas complejas, la interfaz puede organizar información progresivamente sin ocultar riesgos ni condiciones.

Usabilidad y seguridad pueden reforzarse. Una confirmación clara evita acciones irreversibles; una lista ordenada reduce selección errónea; una sesión segura puede avisar antes de expirar y conservar borradores. Diseños de seguridad difíciles inducen atajos, contraseñas compartidas o anotaciones inseguras. La solución no es eliminar controles, sino diseñarlos con proporcionalidad y apoyo.

11. DISEÑO WEB ADAPTATIVO Y RESPONSIVE WEB DESIGN

11.1. Conceptos

En español, “diseño web adaptativo” se utiliza a veces como traducción amplia de responsive web design, aunque técnicamente puede distinguirse entre diseño responsive y diseño adaptive. El responsive utiliza una base flexible que responde de forma continua a las características disponibles; el adaptive suele seleccionar diseños discretos o plantillas para intervalos definidos. Ambos pueden ser accesibles o inaccesibles según su implementación.

Ethan Marcotte popularizó en 2010 el término responsive web design y sus tres ingredientes clásicos: rejillas fluidas, imágenes flexibles y media queries. La evolución de CSS ha añadido Flexbox, Grid, funciones fluidas, consultas de contenedor y preferencias de usuario. El objetivo no es “encoger escritorio”, sino preservar contenido, jerarquía y funcionalidad en diferentes condiciones.

11.2. Viewport y base fluida

<meta name="viewport" content="width=device-width, initial-scale=1">

La configuración del viewport permite que el ancho CSS siga el dispositivo. No debe impedirse el zoom con valores como user-scalable=no o límites restrictivos. Las dimensiones relativas, max-width, Grid y Flexbox facilitan adaptación. Las unidades deben elegirse según función: porcentajes y fracciones para distribución; rem para tipografía y espacios escalables; píxeles CSS cuando un criterio exige una referencia concreta.

.layout {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 18rem), 1fr));
  gap: 1rem;
}

img, video {
  max-width: 100%;
  height: auto;
}

11.3. Mobile-first

Mobile-first define primero la experiencia para condiciones restringidas y añade mejoras con consultas de anchura mínima. Puede favorecer rendimiento, priorización y claridad, pero no garantiza accesibilidad. Una versión móvil que oculta funciones esenciales o convierte tablas en tarjetas sin relaciones semánticas puede empeorar el servicio.

.acciones {
  display: block;
}

@media (min-width: 48rem) {
  .acciones {
    display: flex;
    gap: 1rem;
  }
}

11.4. Breakpoints basados en contenido

No existen breakpoints universales obligatorios de móvil, tableta y escritorio. Deben introducirse cuando el contenido deja de funcionar: líneas demasiado largas, controles solapados, tabla ilegible o navegación inoperable. Diseñar para modelos de dispositivo concretos envejece rápidamente y no cubre ventanas redimensionadas, zoom o modo multiventana.

Las consultas de contenedor permiten adaptar un componente según el espacio de su contenedor, no solo el viewport. Son útiles en sistemas de diseño reutilizables, aunque requieren pruebas de compatibilidad y degradación progresiva.

11.5. Imágenes responsive

srcset y sizes permiten seleccionar recursos adecuados a densidad y tamaño. picture permite dirección artística o formatos alternativos. La selección visual no altera la obligación de proporcionar texto alternativo equivalente. Las imágenes de texto deben evitarse, salvo excepciones, porque escalan peor y no se personalizan.

<img src="centro-800.jpg"
     srcset="centro-480.jpg 480w, centro-800.jpg 800w, centro-1600.jpg 1600w"
     sizes="(max-width: 40rem) 100vw, 50vw"
     alt="Entrada principal del centro de salud">

11.6. Tablas y datos densos

Las tablas complejas no deben transformarse automáticamente en bloques que pierdan relaciones entre cabeceras y celdas. Las estrategias incluyen priorizar columnas, ofrecer vistas resumidas y detalladas, permitir desplazamiento local claramente indicado o proporcionar un formato alternativo. El criterio de reflujo exceptúa contenidos que necesitan presentación bidimensional, pero la excepción no permite hacer inaccesible la navegación o los controles.

11.7. Preferencias y condiciones del usuario

Las media queries pueden detectar orientación, contraste forzado, esquema de color y reducción de movimiento. Deben respetarse preferencias sin suponer que equivalen a una discapacidad concreta. El modo oscuro necesita contraste propio; el modo de alto contraste de Windows puede eliminar fondos e iconos si dependen de imágenes CSS; los controles deben conservar límites y estados.

@media (forced-colors: active) {
  .boton {
    border: 1px solid ButtonText;
  }
}

@media (prefers-color-scheme: dark) {
  :root {
    color-scheme: dark;
  }
}

11.8. Rendimiento y accesibilidad

Una página pesada perjudica especialmente a usuarios con dispositivos antiguos, datos limitados o tecnologías de apoyo. Deben optimizarse imágenes, fuentes, JavaScript y carga de terceros. El rendimiento no es sinónimo de accesibilidad, pero influye en disponibilidad práctica, tiempo de tarea y estabilidad. Los cambios de diseño inesperados pueden mover controles mientras el usuario intenta activarlos.

12. COMPONENTES, FORMULARIOS, CONTENIDO Y MULTIMEDIA ACCESIBLES

12.1. Encabezados, regiones y navegación

Los encabezados describen la estructura y permiten navegación rápida. Deben seguir una jerarquía lógica, sin elegir nivel por apariencia. Las regiones como cabecera, navegación, principal y pie ayudan a localizar partes. Cuando existen varias regiones del mismo tipo, necesitan nombres distinguibles. El enlace de salto evita recorrer menús repetidos en cada página.

12.2. Enlaces y botones

Un enlace navega a un recurso; un botón ejecuta una acción. Intercambiarlos produce expectativas y teclado inconsistentes. El propósito debe ser comprensible por el texto y contexto. Expresiones repetidas como “pinche aquí” dificultan la lista de enlaces de un lector de pantalla. Los botones con solo icono necesitan nombre accesible y estado cuando corresponda.

12.3. Formularios

Cada control necesita etiqueta visible y programáticamente asociada. El placeholder no sustituye a la etiqueta: desaparece al escribir, suele tener contraste bajo y no expresa siempre el propósito. Los campos relacionados pueden agruparse con fieldset y legend. Los atributos de autocompletado ayudan a introducir datos personales y apoyan necesidades cognitivas.

<label for="correo">Correo electrónico</label>
<input id="correo" name="correo" type="email"
       autocomplete="email" aria-describedby="ayuda-correo error-correo">
<p id="ayuda-correo">Se utilizará para enviar el justificante.</p>
<p id="error-correo"></p>

La validación debe producirse sin borrar datos válidos. El resumen de errores puede recibir foco al enviar, y cada mensaje debe enlazar con el campo. No debe dependerse solo de color o icono. Las instrucciones sobre formato deben aparecer antes de que el usuario cometa el error cuando el requisito no sea evidente.

12.4. Autocompletado y datos previamente introducidos

Los propósitos de campos comunes pueden identificarse programáticamente mediante autocomplete. WCAG 2.2 limita la entrada redundante dentro de un proceso: si el sistema ya conoce un dato, debe rellenarlo o permitir seleccionarlo, salvo razones de seguridad, necesidad o cambio. En sanidad debe equilibrarse comodidad con privacidad y verificación de identidad, evitando mostrar datos sensibles a la persona equivocada.

12.5. Diálogos, pestañas y acordeones

Los componentes compuestos requieren patrones de teclado definidos. En pestañas, las teclas de flecha suelen cambiar entre pestañas y Tab entra en el panel; en un acordeón, cada cabecera se implementa como botón con aria-expanded y aria-controls. En un diálogo modal, el contenido exterior queda inerte y el foco se gestiona. Estas reglas deben documentarse en el sistema de diseño.

12.6. Notificaciones, errores y carga

Los indicadores de carga deben comunicar estado sin bloquear innecesariamente. Una barra de progreso puede exponer valor, mínimo y máximo. Las notificaciones temporales deben permanecer tiempo suficiente y ser recuperables si contienen información importante. Un mensaje de éxito no debe desaparecer antes de que un lector de pantalla lo anuncie.

12.7. Audio, vídeo y contenido temporal

Los vídeos pregrabados con audio necesitan subtítulos en nivel A; la audiodescripción o alternativa equivalente se aplica según criterio y nivel. Las transcripciones facilitan búsqueda y acceso. Los controles del reproductor deben ser accesibles por teclado y exponer estado. La reproducción automática con sonido debe evitarse y, si existe audio prolongado, debe poder pausarse o controlarse independientemente.

12.8. Documentos descargables

El ámbito del Real Decreto 1112/2018 incluye documentos y formularios descargables cuando forman parte del servicio, con excepciones concretas. Un PDF accesible necesita texto real, idioma, título, orden de lectura, etiquetas estructurales, encabezados, listas, tablas y alternativas. Escanear un documento como imagen no crea un documento accesible; el reconocimiento óptico puede ser un paso, pero requiere revisión.

Cuando se ofrece un documento, debe indicarse formato y tamaño, y proporcionar versión HTML cuando resulte adecuada. La firma electrónica o un sello no justifican una estructura inaccesible. Los generadores de documentos deben configurarse y probarse, porque una plantilla accesible puede degradarse al exportar.

12.9. Lenguaje claro y contenido

La comprensibilidad depende de redacción, no solo de código. Deben utilizarse frases directas, términos consistentes, explicaciones de siglas, instrucciones concretas y títulos informativos. El lenguaje claro no implica eliminar precisión técnica o jurídica; organiza la información para que el usuario encuentre, comprenda y utilice lo necesario.

13. EVALUACIÓN, AUDITORÍA Y PRUEBAS

13.1. Evaluación automática, manual y con usuarios

La evaluación de accesibilidad combina métodos. Las herramientas automáticas detectan patrones verificables: ausencia de textos alternativos, contraste calculable, identificadores duplicados, etiquetas no asociadas o determinados usos de ARIA. No existe un porcentaje universal y estable de problemas que detecten; su cobertura depende de la herramienta, la tecnología y el contenido. Muchos criterios requieren juicio humano.

La revisión manual comprueba teclado, foco, orden, propósito, alternativas, mensajes, zoom, reflujo, contenido dinámico y compatibilidad. Las pruebas con tecnologías de apoyo revelan la experiencia del árbol de accesibilidad. Las pruebas con personas muestran si el servicio resulta comprensible y usable. Ningún método sustituye a los demás.

13.2. WCAG-EM

La Website Accessibility Conformance Evaluation Methodology del W3C organiza una evaluación en cinco etapas: definir alcance; explorar el sitio; seleccionar una muestra representativa; auditar la muestra; y registrar resultados. La muestra debe incluir páginas comunes, páginas esenciales, tipos de contenido y procesos completos. Seleccionar solo páginas sencillas invalida la representatividad.

En aplicaciones de página única, el concepto de página debe interpretarse mediante vistas, estados y rutas. Es necesario cubrir autenticación, errores, diálogos, carga asíncrona, permisos, variantes responsive y contenido generado. La auditoría debe especificar navegador, tecnología de apoyo, resolución, zoom y versión.

13.3. Revisión simplificada y revisión en profundidad

El marco europeo de seguimiento distingue métodos simplificados y en profundidad. El simplificado identifica incumplimientos en una selección de requisitos mediante pruebas generalmente automatizables o semi-automatizadas. El profundo revisa un conjunto más amplio y puede incluir procesos. Para gestión interna, una revisión rápida sirve como control frecuente, pero no debe presentarse como auditoría completa.

13.4. Herramientas

Entre las herramientas habituales se encuentran validadores y analizadores integrados en navegadores, axe, Lighthouse, WAVE, Accessibility Insights, comprobadores de contraste y validadores de HTML. Para documentos existen comprobadores de PDF y de suites ofimáticas. Deben configurarse y mantenerse; una puntuación alta no equivale a conformidad.

NVDA y JAWS son lectores de pantalla frecuentes en Windows; VoiceOver está integrado en sistemas Apple; TalkBack se utiliza en Android. Las combinaciones deben elegirse según población y entorno. Probar exclusivamente con lector de pantalla tampoco cubre baja visión, movilidad, cognición, sordera o control por voz.

13.5. Pruebas manuales mínimas

1. Recorrer todas las funciones con teclado y verificar foco visible y orden lógico.
2. Ampliar texto y zoom, comprobar reflujo y ausencia de pérdida.
3. Revisar contraste, uso del color y estados.
4. Inspeccionar estructura de encabezados, regiones, listas, tablas y formularios.
5. Probar nombres, roles, estados y mensajes con árbol de accesibilidad y lector.
6. Evaluar orientación, objetivos táctiles, gestos y movimiento.
7. Comprobar errores, tiempos, autenticación y recuperación.
8. Revisar multimedia y documentos descargables.

13.6. Severidad y priorización

Los hallazgos deben registrar criterio, evidencia, localización, usuarios afectados, impacto, frecuencia, recomendación y responsable. La prioridad no depende solo del nivel WCAG. Una barrera A en un proceso secundario y una barrera AA que bloquea la cita pueden tener diferente urgencia operativa. Debe considerarse impacto sobre derechos, seguridad, volumen, alternativas y coste de reparación.

13.7. Integración continua

Los analizadores pueden ejecutarse en pruebas unitarias, de componentes y extremo a extremo. Los umbrales deben impedir introducir defectos conocidos, sin confiar únicamente en la automatización. Un catálogo de componentes accesibles reduce repetición. Las regresiones deben incluirse en la definición de terminado y en los controles previos al despliegue.

pipeline de calidad
├── lint y validación
├── pruebas unitarias de componentes
├── reglas automáticas de accesibilidad
├── pruebas de teclado y foco
├── pruebas visuales y responsive
├── auditoría manual de muestra
└── pruebas con usuarios en hitos críticos

14. MARCO JURÍDICO Y TÉCNICO APLICABLE

14.1. Convención y legislación general

La Convención de Naciones Unidas sobre los Derechos de las Personas con Discapacidad reconoce la accesibilidad como condición para la vida independiente y la participación. En España, el Real Decreto Legislativo 1/2013 aprueba el texto refundido de la Ley General de derechos de las personas con discapacidad y de su inclusión social, incluyendo accesibilidad universal, diseño para todas las personas, igualdad de oportunidades y ajustes razonables.

El Real Decreto 193/2023 regula condiciones básicas de accesibilidad y no discriminación para el acceso y utilización de bienes y servicios a disposición del público. La Ley 11/2023 incorporó al ordenamiento español requisitos vinculados al Acta Europea de Accesibilidad para determinados productos y servicios, ampliando el contexto más allá del sector público.

14.2. Directiva (UE) 2016/2102

La Directiva regula la accesibilidad de sitios web y aplicaciones móviles de organismos del sector público. Establece requisitos comunes, declaración de accesibilidad, mecanismo de comunicación, procedimiento de aplicación y seguimiento por los Estados. La finalidad es aproximar legislaciones y mejorar el funcionamiento del mercado, garantizando acceso a personas con discapacidad.

Los actos de ejecución europeos concretan el modelo de declaración y la metodología de seguimiento. La Decisión de Ejecución (UE) 2018/1523 establece el modelo de declaración; la Decisión (UE) 2018/1524 regula metodología de seguimiento y presentación de informes, posteriormente actualizada para referenciar la versión armonizada correspondiente.

14.3. Real Decreto 1112/2018

El Real Decreto 1112/2018 transpone la Directiva al ordenamiento español. Su objeto es garantizar requisitos de accesibilidad de sitios web y aplicaciones móviles de organismos del sector público y otros sujetos incluidos. Define accesibilidad como principios y técnicas que deben respetarse al diseñar, construir, mantener y actualizar para garantizar igualdad y no discriminación, especialmente de personas con discapacidad y mayores.

Su ámbito objetivo incluye información textual y no textual, documentos y formularios descargables, multimedia pregrabado, interacción bidireccional y procesos de identificación, autenticación, firma y pago. Contiene exclusiones y condiciones específicas, como determinados archivos, mapas o contenidos de terceros no financiados ni controlados, que deben interpretarse restrictivamente.

El artículo 5 exige que contenidos sean perceptibles, operables, comprensibles y robustos, y que la accesibilidad se tenga presente de forma integral en diseño, gestión, mantenimiento y actualización. El artículo 6 establece presunción de conformidad mediante normas armonizadas publicadas en el Diario Oficial de la Unión Europea.

14.4. Carga desproporcionada

La excepción por carga desproporcionada no permite excluir un sitio completo por conveniencia. Requiere evaluación escrita de tamaño, recursos, costes, beneficios y frecuencia de uso, revisión al menos anual y declaración de los contenidos que no se cumplen. Deben ofrecerse alternativas accesibles cuando proceda. No puede invocarse falta de prioridad, tiempo o conocimientos como justificación automática.

14.5. Declaración, comunicaciones y reclamaciones

Los sitios y aplicaciones deben publicar declaración de accesibilidad detallada, exhaustiva y clara, actualizada periódicamente. Las personas pueden comunicar incumplimientos, solicitar información accesible o formular quejas. Debe existir un procedimiento de aplicación cuando la respuesta sea insatisfactoria. La gestión de estas comunicaciones es parte del gobierno del servicio y aporta datos para priorizar mejoras.

14.6. Unidad Responsable de Accesibilidad

Cada entidad debe disponer de una unidad responsable de garantizar cumplimiento, coordinar revisiones, atender información, formar y elaborar informes. La accesibilidad no recae exclusivamente en desarrollo. Participan contratación, comunicación, responsables funcionales, edición, soporte, seguridad y dirección.

14.7. EN 301 549 y UNE-EN 301549:2022

EN 301 549 es la norma europea de requisitos de accesibilidad para productos y servicios TIC. Su alcance incluye hardware, software, web, documentos, servicios de soporte y telecomunicaciones. La versión armonizada EN 301 549 V3.2.1 (2021-03) incorpora WCAG 2.1 para contenido web y requisitos adicionales, y su adopción española se identifica como UNE-EN 301549:2022.

La norma no debe reducirse a WCAG. Para aplicaciones no web, documentos, software cerrado, biometría, comunicación en tiempo real o soporte existen requisitos específicos. En contratación pública permite expresar requisitos verificables y pedir evidencias de conformidad del producto completo.

14.8. Marco andaluz

La Ley 4/2017 de los Derechos y la Atención a las Personas con Discapacidad en Andalucía integra accesibilidad universal y diseño para todas las personas, e incluye su consideración en la calidad de centros, actividades y servicios sanitarios públicos. El Decreto 622/2019 regula administración electrónica, simplificación y racionalización organizativa de la Junta de Andalucía y exige que sedes y servicios se organicen conforme a los principios y requisitos aplicables, incluida accesibilidad.

14.9. Nivel exigible y objetivo recomendado

La presunción de conformidad vigente se apoya en EN 301 549 V3.2.1 y WCAG 2.1. Para nuevos productos es razonable exigir además WCAG 2.2 nivel AA como objetivo técnico, identificando que constituye una mejora sobre el mínimo armonizado actual. El contrato debe evitar fórmulas ambiguas como “cumplirá estándares W3C” y especificar versión, nivel, alcance y evidencias.

15. INTEGRACIÓN EN CONTRATACIÓN Y CICLO DE VIDA

15.1. Gobierno y responsabilidades

La accesibilidad requiere patrocinio, política, roles y recursos. El responsable funcional define servicio y contenido; arquitectura selecciona patrones y plataformas; diseño produce interacción inclusiva; desarrollo implementa; pruebas evalúan; contratación exige; edición mantiene; soporte atiende barreras; y la Unidad Responsable de Accesibilidad coordina. La responsabilidad compartida no debe convertirse en responsabilidad difusa.

15.2. Requisitos y pliegos

Los pliegos deben referenciar Real Decreto 1112/2018, EN 301 549 V3.2.1 o UNE-EN 301549:2022, y el nivel WCAG aplicable. Deben exigir componentes, contenido, documentos, aplicaciones móviles y procesos completos, no solo plantillas. Es conveniente pedir matriz de conformidad, metodología de prueba, corrección de defectos, formación, documentación y ausencia de regresiones.

Una declaración genérica del proveedor no es evidencia suficiente. Puede solicitarse informe de auditoría independiente, resultados reproducibles, documentación de componentes, pruebas con tecnologías de apoyo y compromiso de subsanación. La aceptación debe reservar parte del pago o del hito a la corrección de incumplimientos.

15.3. Diseño y sistema de componentes

Un sistema de diseño accesible documenta colores, tipografía, espaciado, foco, estados, patrones de teclado, nombres y mensajes. Los componentes deben tener pruebas y ejemplos. Centralizar reduce defectos, pero una biblioteca accesible puede utilizarse mal: el producto debe comprobar composición, contenido y flujo.

15.4. Desarrollo

El desarrollo debe utilizar mejora progresiva, semántica nativa, dependencias evaluadas, gestión del foco y pruebas automatizadas. Las excepciones se documentan. Los marcos JavaScript no son accesibles o inaccesibles por naturaleza; el resultado depende de componentes, renderizado, navegación y actualización de estados.

15.5. Contenido y formación

Las personas editoras necesitan formación sobre encabezados, enlaces, alternativas, tablas, multimedia y documentos. Los flujos de publicación pueden impedir guardar contenido sin campos esenciales, pero deben permitir excepciones justificadas. La guía editorial debe incluir lenguaje claro y revisión de documentos.

15.6. Pruebas y aceptación

Los criterios de aceptación deben cubrir tareas críticas y perfiles. La auditoría previa a producción utiliza muestra representativa, pero los procesos completos más importantes deben probarse de extremo a extremo. Los defectos bloqueantes impiden aceptación. Los restantes se registran con plan, fecha y responsable.

15.7. Operación y mantenimiento

Después del despliegue, nuevos contenidos, actualizaciones de librerías y cambios de navegador pueden introducir regresiones. Deben existir revisiones periódicas, monitorización, canal de comunicación y métricas. La declaración de accesibilidad se actualiza cuando cambia el estado. Las incidencias comunicadas por usuarios deben analizarse como defectos de servicio, no como excepciones individuales.

15.8. Deuda de accesibilidad

La deuda aparece cuando se posponen defectos o se construye sobre componentes inaccesibles. Debe inventariarse como deuda técnica con impacto, coste y plan. Las prioridades atienden procesos esenciales y barreras bloqueantes. Una migración gradual puede ser válida si ofrece alternativas efectivas y fechas, pero no una tolerancia indefinida.

15.9. Indicadores

16. APLICACIÓN PRÁCTICA EN SERVICIOS DIGITALES SANITARIOS

16.1. Servicios a la ciudadanía

Los portales y aplicaciones de salud deben contemplar usuarios ocasionales, personas mayores, baja alfabetización, diversidad lingüística y discapacidad. Las tareas pueden incluir identificación, cita, consulta de información, descarga de documentos, comunicación y gestión de preferencias. La accesibilidad debe abarcar todas las etapas, incluidos proveedores de identidad, firma y visores externos integrados.

La información sanitaria exige lenguaje comprensible sin alterar exactitud. Un resultado clínico puede necesitar explicación y contexto proporcionados por el área competente. El diseño debe evitar alarmas injustificadas, pero no ocultar información. Los documentos deben ser accesibles y conservar integridad y autenticidad.

16.2. Sistemas para profesionales

Las aplicaciones profesionales se utilizan con alta frecuencia y bajo presión. La eficiencia importa, pero no justifica excluir. Deben soportar teclado, densidad de información configurable, foco visible, alertas distinguibles, prevención de selección errónea y recuperación. Los atajos pueden beneficiar a usuarios expertos si no reemplazan la operación estándar y están documentados.

En un entorno clínico compartido, la privacidad puede requerir bloqueo, tiempo de sesión y autenticación. Estos controles deben avisar, permitir continuidad segura y evitar pérdida de trabajo. Un acceso accesible no puede basarse en cuentas genéricas ni en debilitar trazabilidad.

16.3. Aplicaciones móviles

Las apps del sector público están incluidas en el Real Decreto 1112/2018. Además de requisitos de contenido, deben funcionar con servicios de accesibilidad de la plataforma, escalado de texto, orientación, contraste, objetivos táctiles y gestos alternativos. Los componentes nativos suelen exponer semántica adecuada, pero los controles personalizados requieren implementación específica.

16.4. Teleconsulta y atención remota

La videocomunicación debe considerar subtítulos, compatibilidad con teclado, calidad de audio, mensajes de conexión y alternativas cuando el canal no sea adecuado. La persona debe poder solicitar apoyo. La accesibilidad incluye el proceso previo de instalación, permisos, prueba de dispositivos y recuperación de errores, no solo la pantalla de llamada.

16.5. Cuadros de mando y visualización

Los cuadros de mando combinan colores, gráficos, filtros y tablas. Deben proporcionar alternativas textuales o tabulares, no depender del color, mantener orden de foco y anunciar filtros aplicados. La visualización accesible no consiste en narrar cada píxel, sino en comunicar tendencias, comparaciones y valores necesarios para decidir.

16.6. Casos prácticos

16.7. Papel del TFA-STI

El TFA-STI traduce normativa y necesidades a decisiones técnicas. Puede elaborar requisitos, revisar prototipos, participar en contratación, validar entregables, coordinar auditorías, gestionar defectos y asegurar que la accesibilidad se integra en arquitectura y operación. Debe saber cuándo necesita apoyo especializado y evitar aprobar por una puntuación automática.

17. IDEAS CLAVE Y MAPA CONCEPTUAL

17.1. Ideas clave

1. Accesibilidad y usabilidad se relacionan, pero no son sinónimos.
2. La usabilidad se evalúa mediante eficacia, eficiencia y satisfacción en un contexto de uso.
3. WAI coordina WCAG, ATAG, UAAG y WAI-ARIA.
4. WCAG se organiza en perceptible, operable, comprensible y robusto.
5. Para nivel AA deben cumplirse todos los criterios A y AA aplicables.
6. La conformidad comprende páginas y procesos completos.
7. WCAG 2.2 añade nueve criterios y W3C recomienda utilizarla.
8. La norma armonizada europea vigente sigue utilizando WCAG 2.1.
9. WCAG 3 es borrador y no sustituye a WCAG 2.
10. HTML nativo debe preferirse a reconstruir controles con ARIA.
11. ARIA comunica semántica; no implementa por sí sola teclado o comportamiento.
12. Diseño universal reduce exclusión desde el origen y se complementa con ajustes.
13. Responsive implica adaptación fluida, no mera reducción visual.
14. Los breakpoints deben responder al contenido, no a una lista rígida de dispositivos.
15. Automatización, revisión manual, tecnologías de apoyo y usuarios son complementarios.
16. El Real Decreto 1112/2018 exige accesibilidad integral, declaración y mecanismos de comunicación.
17. EN 301 549 abarca más que contenido web y es clave en contratación TIC.
18. La accesibilidad debe mantenerse durante operación y evolución.

17.2. Trampas frecuentes

• Confundir nivel A con el nivel de referencia AA.
• Suponer que AAA es obligatorio para todo el sitio.
• Afirmar que una herramienta automática certifica conformidad.
• Usar color como único medio o eliminar el foco visible.
• Tratar placeholder como etiqueta.
• Añadir ARIA a controles nativos sin necesidad.
• Considerar responsive equivalente a accesible.
• Aplicar breakpoints fijos como estándar universal.
• Olvidar documentos, autenticación, firma y procesos completos.
• Citar el inexistente Decreto 534/2021 del SAS.

17.3. Mapa conceptual