ACCESIBILIDAD Y USABILIDAD
W3C · DISEÑO UNIVERSAL · DISEÑO WEB ADAPTATIVO
Técnico/a de Función Administrativa – Opción Sistemas y Tecnología de la Información (TFA-STI)
Servicio Andaluz de Salud
1. CONTEXTUALIZACIÓN Y RELEVANCIA PARA TFA-STI SAS
¿Por qué este tema es crítico?
Mira, voy a serte sincero desde el principio. Este tema puede parecer «blando» comparado con otros más técnicos del temario, ¿verdad? Arquitecturas complejas, ciberseguridad, bases de datos… Pero déjame decirte algo: la accesibilidad y usabilidad son la diferencia entre un sistema sanitario que funciona DE VERDAD para todos los andaluces y uno que deja a gente fuera.
El SAS atiende a más de 8 millones de personas. Personas mayores que necesitan consultar sus citas en ClicSalud+. Profesionales sanitarios que trabajan bajo presión en Diraya. Pacientes con diversidad funcional que buscan información en el Portal de Salud.
⚠️ Relevancia Legal
Esto no es teoría. El incumplimiento de accesibilidad puede derivar en sanciones administrativas y reclamaciones patrimoniales. Como TFA-STI, serás responsable de que los desarrollos cumplan estos requisitos.
Marco Normativo Clave
- Real Decreto 1112/2018 de accesibilidad de sitios web y aplicaciones móviles del sector público
- Ley 11/2007 de acceso electrónico (actualizada en Ley 39/2015)
- Directiva (UE) 2016/2102 sobre accesibilidad web
- UNE-EN 301549:2022 (estándar europeo de accesibilidad TIC)
- Real Decreto Legislativo 1/2013 sobre derechos de personas con discapacidad
- Decreto 534/2021 de Administración Electrónica del SAS
Conexión con tu Futuro Puesto
🏥 Sistemas que Gestionarás
- Diraya: historia digital accesible para médicos
- ClicSalud+: portal ciudadano WCAG 2.1 AA
- BPS: interfaces usables bajo presión
- Apps móviles SAS: Salud Responde, Cita Previa
👥 Usuarios Reales
- Personas ciegas con lectores de pantalla
- Profesionales con RSI (sin ratón)
- Pacientes mayores con dificultades visuales
- Usuarios con movilidad reducida
💡 Reflexión clave: ¿Sabes qué pasa cuando un formulario de cita previa no es accesible? Que una persona ciega no puede gestionarla por sí misma. Que alguien con movilidad reducida no puede usar el ratón. Que un profesional mayor tiene que pedir ayuda porque los textos son microscópicos. Y eso, amigo mío, es inaceptable en 2025.
2. INTRODUCCIÓN: POR QUÉ ESTE TEMA ES CRUCIAL
La Idea Base
La accesibilidad y usabilidad no son «extras» ni «mejoras estéticas». Son requisitos legales, éticos y técnicos que garantizan que los sistemas de información sanitarios cumplan su misión: servir a TODAS las personas, independientemente de sus capacidades, dispositivos o contextos de uso.
Desarrolla los estándares que hacen posible la accesibilidad web universal.
Establece los principios filosóficos para crear entornos utilizables por todas las personas.
Proporciona las herramientas técnicas para materializar accesibilidad en todos los dispositivos.
Esquema del Tema
Vamos a estructurarlo así (respira, porque es denso pero lógico):
- Fundamentos conceptuales: qué son accesibilidad y usabilidad, por qué importan
- W3C y sus estándares: WCAG, WAI-ARIA, ATAG, UAAG
- Principios del diseño universal: los 7 principios y su aplicación
- Diseño web adaptativo (RWD): enfoque técnico mobile-first
- Normativa aplicable al SAS: obligaciones concretas
- Implementación práctica: auditorías, herramientas, metodología
- Casos específicos del SAS: Diraya, ClicSalud+, apps móviles
3. FUNDAMENTOS: ACCESIBILIDAD Y USABILIDAD
3.1. Accesibilidad Web: Derecho, No Privilegio
La accesibilidad web es la capacidad de un sitio, aplicación o documento digital para ser percibido, comprendido, navegado y usado por todas las personas, incluyendo aquellas con discapacidades.
👥 Tipos de Discapacidades que Debemos Considerar
- Visuales: ceguera, baja visión, daltonismo
- Auditivas: sordera, hipoacusia
- Motoras: dificultades para usar ratón o teclado
- Cognitivas: dislexia, TDAH, TEA
- Temporales: brazo roto, recuperación postoperatoria
- Situacionales: pantalla al sol, ruido ambiente, conexión lenta
Ejemplo Real en el SAS:
Un médico con RSI (lesión por esfuerzo repetitivo) necesita poder navegar Diraya sin ratón. Una enfermera con baja visión necesita poder ampliar textos sin romper el diseño. Un administrativo mayor necesita interfaces claras y predecibles.
3.2. Usabilidad: La Experiencia Importa
La usabilidad (ISO 9241-11:2018) es el grado en que un sistema puede ser utilizado por usuarios específicos para alcanzar objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso específico.
| Dimensión | Definición | Ejemplo en el SAS |
|---|---|---|
| Efectividad | ¿El usuario logra su objetivo? | Reservar cita, consultar analítica |
| Eficiencia | ¿Cuánto esfuerzo requiere? | Número de clics, tiempo, errores |
| Satisfacción | ¿Cómo se siente el usuario? | Frustrado, confiado, neutral |
📊 Los 5 Componentes de Usabilidad según Jakob Nielsen
- Aprendibilidad: ¿Qué tan fácil es realizar tareas básicas la primera vez?
- Eficiencia: Una vez aprendido, ¿qué tan rápido se realizan las tareas?
- Memorabilidad: Tras un periodo sin usar, ¿se recuerda cómo usarlo?
- Errores: ¿Cuántos errores comete el usuario? ¿Puede recuperarse?
- Satisfacción: ¿Qué tal es la experiencia subjetiva?
3.3. La Intersección: Accesibilidad + Usabilidad
⚠️ Matiz fino para la oposición
No son lo mismo, pero se solapan:
- Un sitio puede ser técnicamente accesible (cumple WCAG) pero poco usable (diseño confuso)
- Un sitio puede ser muy usable para usuarios estándar pero inaccesible para usuarios con lectores de pantalla
El objetivo es lograr ambas. Y en el SAS, donde los usuarios van desde médicos expertos hasta pacientes mayores, esto es crítico.
4. W3C: EL ARQUITECTO DE LA WEB ACCESIBLE
4.1. ¿Qué es el W3C?
El World Wide Web Consortium es el organismo internacional que desarrolla estándares web desde 1994. Lo dirige Tim Berners-Lee (inventor de la Web). Su misión: «Guiar la Web hacia su máximo potencial».
Para accesibilidad, creó la WAI (Web Accessibility Initiative) en 1997. La WAI produce las pautas que todo desarrollador del SAS debe conocer.
4.2. WCAG: Las Pautas de Oro
Las Web Content Accessibility Guidelines (WCAG) son EL estándar internacional. Actualmente vamos por WCAG 2.2 (publicadas en octubre 2023), aunque WCAG 2.1 sigue siendo el requisito legal en la UE.
4.2.1. Los 4 Principios POUR
🎯 Principios Fundamentales de WCAG
Todo contenido web debe cumplir estos 4 principios:
P — PERCEPTIBLE
La información debe poder ser percibida por al menos uno de los sentidos
- Alternativas textuales para contenido no textual (
alten imágenes) - Subtítulos y transcripciones para multimedia
- Contenido adaptable sin pérdida de información
- Suficiente contraste de color (4.5:1 para texto normal, 3:1 para texto grande)
💡 Ejemplo SAS: Los resultados de analíticas en Diraya incluyen gráficos. Esos gráficos DEBEN tener alternativa textual describiendo los valores.
O — OPERABLE
La interfaz y navegación deben ser operables
- Todo funcional desde teclado (sin trampas de teclado)
- Tiempo suficiente para leer/usar contenido
- No diseñar contenido que pueda causar convulsiones (parpadeos <3/segundo)
- Navegación clara y predecible
- Formas alternativas de entrada (no solo ratón)
💡 Ejemplo SAS: El formulario de solicitud de informes en ClicSalud+ debe completarse íntegramente con teclado.
U — COMPRENSIBLE
La información y operación de interfaz deben ser comprensibles
- Texto legible y comprensible (idioma identificado)
- Contenido predecible (navegación consistente)
- Ayuda para evitar y corregir errores
- Instrucciones claras
💡 Ejemplo SAS: Los mensajes de error en BPS deben explicar QUÉ está mal y CÓMO solucionarlo, no solo «Error 404».
R — ROBUSTO
El contenido debe ser interpretable por diversas tecnologías de asistencia
- Marcado válido (HTML semántico)
- Compatible con tecnologías actuales y futuras
- Nombre, función y valor programáticamente disponibles
💡 Ejemplo SAS: Los componentes custom en Diraya deben usar WAI-ARIA para comunicar su función a lectores de pantalla.
4.2.2. Niveles de Conformidad
| Nivel | Criterios | Descripción | Obligatoriedad |
|---|---|---|---|
| Nivel A | 78 | Requisitos básicos | Insuficiente legalmente |
| Nivel AA | 98 (78+20) | Requisitos intermedios | ✅ EXIGIDO POR LEY |
| Nivel AAA | 126 (98+28) | Requisitos avanzados | Recomendado, no exigible |
📌 Importante para el examen: El RD 1112/2018 exige nivel AA para web y apps móviles del sector público. El SAS debe cumplirlo en todos sus desarrollos desde septiembre 2020.
4.2.3. Novedades WCAG 2.2 (octubre 2023)
Añade 9 nuevos criterios, enfocados en:
- Accesibilidad móvil: Tamaños de toque 24×24 CSS pixels mínimo (Criterio 2.5.8 AA)
- Discapacidades cognitivas: Autenticación sin memoria (3.3.8 AA), ayudas consistentes (3.2.6 A), entrada redundante (3.3.7 A)
- Baja visión: Mejoras en contraste y enfoque visible (2.4.11 AA, 2.4.12 AAA, 2.4.13 AAA)
- Gestos complejos: Alternativas a movimientos de arrastre (2.5.7 AA)
Aunque no es legalmente exigible aún, el SAS debería anticiparse. Los tribunales pueden preguntar sobre WCAG 2.2 como conocimiento actualizado.
4.3. WAI-ARIA: Superpoderes para Componentes Complejos
Accessible Rich Internet Applications (ARIA) es una especificación técnica que permite hacer accesibles aplicaciones web dinámicas (SPAs, componentes JavaScript complejos).
🎭 Roles
Qué es el elemento
role="button"role="dialog"role="alert"
⚙️ Propiedades
Características estáticas
aria-labelaria-describedby
📊 Estados
Características dinámicas
aria-expanded="true/false"aria-busy="false"
Ejemplo práctico en Diraya:
<div role="tablist">
<button role="tab" aria-selected="true" aria-controls="panel-historial">
Historial Clínico
</button>
<button role="tab" aria-selected="false" aria-controls="panel-alergias">
Alergias
</button>
</div>
<div role="tabpanel" id="panel-historial" aria-labelledby="tab-historial">
[Contenido del historial]
</div>⭐ Primera regla de ARIA
No uses ARIA si puedes usar HTML nativo.
<button> es mejor que <div role="button">
4.4. Otros Estándares WAI
- ATAG (Authoring Tool Accessibility Guidelines): Pautas para herramientas de autor (CMS, editores visuales)
- UAAG (User Agent Accessibility Guidelines): Pautas para navegadores y reproductores multimedia
5. DISEÑO UNIVERSAL: FILOSOFÍA INCLUSIVA
5.1. Origen y Concepto
El diseño universal (Universal Design) fue acuñado por Ronald Mace (arquitecto con discapacidad) en 1985. Inicialmente aplicado a arquitectura física, se extendió al diseño de productos y entornos digitales.
Definición: Diseño de productos y entornos utilizables por todas las personas, en la mayor medida posible, sin necesidad de adaptación o diseño especializado.
💡 Idea clave: Diseñar DESDE EL PRINCIPIO para la diversidad humana, no añadir «parches» de accesibilidad después.
5.2. Los 7 Principios del Diseño Universal
Principio 1: Uso Equitativo
El diseño es útil y vendible a personas con diversas capacidades.
Pautas:
- Proporcionar los mismos medios de uso para todos
- Evitar segregar o estigmatizar
- Igualdad en privacidad, seguridad y protección
Principio 2: Flexibilidad en el Uso
El diseño se acomoda a un amplio rango de preferencias y habilidades individuales.
Pautas:
- Ofrecer opciones en métodos de uso
- Acomodar acceso y uso diestro o zurdo
- Facilitar precisión del usuario
Principio 3: Uso Simple e Intuitivo
El uso del diseño es fácil de entender, independientemente de experiencia, conocimiento o nivel de concentración.
Pautas:
- Eliminar complejidad innecesaria
- Consistencia con expectativas del usuario
- Organización intuitiva de información
- Retroalimentación efectiva
Principio 4: Información Perceptible
El diseño comunica información efectivamente, independientemente de condiciones ambientales o capacidades sensoriales.
Pautas:
- Usar diferentes modos (pictórico, verbal, táctil)
- Contraste adecuado
- Maximizar legibilidad
- Compatibilidad con técnicas de asistencia
Principio 5: Tolerancia al Error
El diseño minimiza riesgos y consecuencias adversas de acciones accidentales.
Pautas:
- Disponer elementos para minimizar errores
- Proporcionar advertencias
- Ofrecer opciones de recuperación (fail-safe)
Principio 6: Bajo Esfuerzo Físico
El diseño puede usarse eficientemente y cómodamente con mínima fatiga.
Pautas:
- Permitir postura corporal neutral
- Usar fuerzas operativas razonables
- Minimizar acciones repetitivas
- Minimizar esfuerzo físico sostenido
Principio 7: Tamaño y Espacio Apropiados
Se proporciona tamaño y espacio apropiados para aproximación, alcance y manipulación.
Pautas:
- Línea de visión clara
- Alcance cómodo
- Acomodar variaciones en tamaño de mano
- Espacio adecuado para tecnologías de asistencia
5.3. Diseño Universal vs Diseño Accesible
| Enfoque | Características | Cuándo se aplica |
|---|---|---|
| Diseño Accesible | Adaptar un diseño existente para personas con discapacidades (REACTIVO) | Después del desarrollo inicial |
| Diseño Universal | Diseñar desde cero para toda la diversidad humana (PROACTIVO) | Desde la fase de requisitos |
✅ Para la oposición: El diseño universal es más efectivo y económico, pero requiere cambio de mentalidad organizacional.
6. DISEÑO WEB ADAPTATIVO (RESPONSIVE WEB DESIGN)
6.1. Concepto y Evolución
Responsive Web Design (RWD) es una técnica de diseño web que hace que el contenido se adapte fluidamente al dispositivo (móvil, tablet, desktop) sin necesidad de desarrollos separados.
Acuñó el término RWD, revolucionando el desarrollo web.
Antes: Versiones separadas (m.ejemplo.es para móvil)
Después: Una sola base de código que se adapta
6.2. Los 3 Pilares Técnicos
1️⃣ Rejillas Fluidas
Usar porcentajes en vez de píxeles fijos
.container {
width: 90%; /* no 960px */
max-width: 1200px;
}2️⃣ Imágenes Flexibles
Las imágenes escalan proporcionalmente
img {
max-width: 100%;
height: auto;
}3️⃣ Media Queries
Aplicar estilos CSS según características del dispositivo
/* Móvil (por defecto) */
.menu { display: none; }
/* Tablet (≥768px) */
@media (min-width: 768px) {
.menu { display: flex; }
}
/* Desktop (≥1024px) */
@media (min-width: 1024px) {
.menu { justify-content: space-between; }
}6.3. Mobile-First: La Estrategia Correcta
📱 Mobile-First
Significa diseñar primero para móvil, luego expandir para pantallas mayores.
Ventajas:
- Performance: Código base ligero, mejoras progresivas
- Accesibilidad: Móvil obliga a simplificar, beneficia a todos
- Estadísticas: >60% tráfico web es móvil (SAS no es excepción)
6.4. Breakpoints Estándar
| Breakpoint | Dispositivo | Ejemplo |
|---|---|---|
| 320px | Móviles pequeños | iPhone SE |
| 375px | Móviles estándar | iPhone 13 |
| 768px | Tablets verticales | iPad |
| 1024px | Tablets horiz., laptops | iPad Pro |
| 1440px | Desktops | Pantallas grandes |
📌 Importante: El SAS debe definir breakpoints corporativos para consistencia entre aplicaciones.
6.5. RWD y Accesibilidad: Matrimonio Perfecto
- Zoom: Diseños fluidos permiten zoom 200% sin scroll horizontal (criterio WCAG 1.4.10)
- Orientación: Funciona en vertical y horizontal (criterio WCAG 1.3.4)
- Táctil: Elementos suficientemente grandes en móvil benefician a todos
- Simplificación: Móvil obliga a priorizar contenido esencial
⚠️ Cuidado: RWD no garantiza accesibilidad automáticamente. Hay que implementarla conscientemente (HTML semántico, ARIA, contraste…).
7. NORMATIVA Y OBLIGACIONES LEGALES DEL SAS
7.1. Real Decreto 1112/2018: El Marco Legal
📋 Ámbito de Aplicación
Este RD transpone la Directiva (UE) 2016/2102 y establece obligaciones para:
- ✅ Sitios web del sector público (incluido SAS)
- ✅ Aplicaciones móviles oficiales
- ✅ Intranets y extranets desde 23/09/2019
Excepciones (Artículo 3)
- Contenido publicado antes del 20/09/2018 (salvo trámites administrativos)
- Archivos de oficina (PDF, Word) publicados antes de esa fecha
- Multimedia pregrabado antes de esa fecha
- Mapas y cartografía (si info esencial está en formato accesible)
🎯 Ojo tribunal: ClicSalud+ NO puede usar excepciones. Diraya (intranet sanitaria) debe ser accesible desde 2019.
Nivel de Conformidad Exigido
✅ Nivel AA de WCAG 2.1
Aunque el RD menciona WCAG 2.0, la UNE-EN 301549:2022 ya refiere a WCAG 2.1
| Tipo de Sitio | Plazo de Cumplimiento | Estado |
|---|---|---|
| Sitios web nuevos | 20 septiembre 2018 | ✅ Vencido |
| Sitios web existentes | 20 septiembre 2020 | ✅ Vencido |
| Aplicaciones móviles | 23 junio 2021 | ✅ Vencido |
Declaración de Accesibilidad (Artículo 7)
- Grado de cumplimiento (total, parcial, no conforme)
- Partes no accesibles y alternativas
- Fecha de elaboración
- Método de evaluación (automático, experto, ambos)
- Mecanismo de comunicación para reportar problemas
- Enlace al procedimiento de reclamación
7.2. UNE-EN 301549:2022
Norma armonizada europea que especifica requisitos técnicos de accesibilidad para productos y servicios TIC en contratación pública.
⚖️ Relevancia SAS: Cuando el SAS contrata desarrollo de aplicaciones, portales o apps, DEBE incluir en pliegos técnicos conformidad con UNE-EN 301549.
7.3. Decreto 534/2021 del SAS
Artículo 20: Accesibilidad y Usabilidad
Todos los canales electrónicos del SAS deben:
- ✅ Cumplir principios de accesibilidad universal
- ✅ Seguir criterios de usabilidad
- ✅ Respetar estándares abiertos (W3C, UNE)
- ✅ Garantizar neutralidad tecnológica
Esto convierte la accesibilidad en obligación legal específica del SAS.
8. IMPLEMENTACIÓN PRÁCTICA EN EL SAS
8.1. Metodología de Desarrollo Accesible
🔄 Shift-Left: Accesibilidad Desde el Diseño
Significa incorporar accesibilidad en las fases iniciales del ciclo de vida del software, no al final.
1. Requisitos
Historias de usuario con discapacidades
- «Como usuario ciego…»
- «Como usuario con RSI…»
2. Diseño
Diseñadores conocen WCAG
- Paletas con contraste verificado
- Wireframes semánticos
3. Desarrollo
Codificar accesible por defecto
- HTML semántico
- ARIA cuando necesario
4. Testing
QA incluye accesibilidad
- Herramientas automáticas
- Pruebas manuales
Definition of Done Accesible
En Scrum/Kanban, una historia NO está terminada hasta que cumple:
- ✅ Código validado con herramientas automáticas (0 errores críticos)
- ✅ Navegación completa con teclado verificada
- ✅ Contraste 4.5:1 (texto) y 3:1 (UI)
- ✅ Formularios con labels y mensajes de error claros
- ✅ Imágenes con texto alternativo
- ✅ Prueba con lector de pantalla (NVDA/JAWS)
- ✅ Responsive funciona en 320px sin scroll horizontal
8.2. Herramientas de Evaluación
| Herramienta | Tipo | Uso en el SAS |
|---|---|---|
| aXe DevTools | Extensión navegador | Desarrollo diario |
| WAVE | Online/Extensión | Evaluaciones rápidas |
| Lighthouse | Chrome DevTools | Integrar en CI/CD |
| Pa11y | CLI | Escaneos automatizados |
| NVDA | Lector pantalla | Pruebas manuales |
| JAWS | Lector pantalla | QA profesional |
⚠️ Importante: Herramientas automáticas detectan solo ~30-40% de problemas. El resto requiere evaluación manual.
8.3. Casos Prácticos del SAS
🏥 ClicSalud+: Portal Ciudadano
Retos:
- Diversidad de usuarios (0-100+ años)
- Uso frecuente
- Información sensible
- Multi-idioma
- Estructura semántica HTML5
- Formularios con labels asociados
- Notificaciones con
aria-live - Contraste verificado (4.7:1 verde SAS)
💼 Diraya: Historia Digital del Paciente
Retos:
- Complejidad de interfaz profesional
- Velocidad bajo presión
- Datos críticos
- Atajos de teclado (Alt+H, Alt+P, Alt+A)
- Alergias con
role="alert" - Tablas accesibles con
scope - Modo alto contraste
11. CONCLUSIONES
🎯 Ideas Clave para el Examen
- Accesibilidad es derecho, no extra: RD 1112/2018 lo exige legalmente
- WCAG 2.1 nivel AA: Requisito mínimo para todos los desarrollos SAS
- 4 principios POUR: Perceptible, Operable, Comprensible, Robusto
- 7 principios diseño universal: Equitativo, Flexible, Simple, Perceptible, Tolerante, Bajo esfuerzo, Espacio apropiado
- RWD = 3 técnicas: Rejillas fluidas, imágenes flexibles, media queries
- Shift-left: Accesibilidad desde requisitos, no al final
- Testing triple: Automático + manual + tecnologías asistencia
- Declaración obligatoria: Con mecanismo de comunicación
- UNE-EN 301549: Para contratación TIC
- Mobile-first: Diseñar primero para móvil
Estrategia de Estudio
📅 Semana 1
- Lee RD 1112/2018 completo
- Familiarízate con WCAG 2.1
- Revisa 7 principios diseño universal
📅 Semana 2
- Instala NVDA y practica
- Usa aXe en sitios reales
- Practica responsive con DevTools
📅 Semana 3
- Analiza ClicSalud+ accesibilidad
- Identifica problemas y soluciones
- Repasa casos prácticos
📅 Semana 4
- Responde cuestionario
- Crea tu mapa conceptual
- Conecta con otros temas
💪 Mensaje Final
Recuerda: cada línea de código accesible que escribas puede ser la diferencia entre que un ciudadano andaluz pueda o no acceder a su información sanitaria. Esa es la responsabilidad y el privilegio de trabajar en sistemas que tocan millones de vidas.
12. CUESTIONARIO (30 PREGUNTAS TIPO TEST)
Pregunta 1
¿Qué nivel de conformidad WCAG exige el Real Decreto 1112/2018 para sitios web del sector público?
El RD 1112/2018 exige nivel AA de conformidad con WCAG (actualmente 2.1). El nivel A es insuficiente y el AAA no es exigible por ley.
Pregunta 2
¿Cuál de los siguientes NO es uno de los 4 principios POUR de WCAG?
Los 4 principios son: Perceptible, Operable, Comprensible y Robusto. «Portable» no es un principio WCAG.
Pregunta 3
¿Qué contraste mínimo exige WCAG 2.1 nivel AA para texto normal?
Criterio 1.4.3 – Para texto normal, el contraste debe ser al menos 4.5:1. Para texto grande, es 3:1. El nivel AAA requiere 7:1.
Pregunta 4
¿Qué organismo desarrolla los estándares WCAG?
El World Wide Web Consortium (W3C) desarrolla WCAG a través de su iniciativa WAI (Web Accessibility Initiative).
Pregunta 5
En diseño universal, ¿qué principio establece que el diseño debe minimizar riesgos de acciones accidentales?
El principio 5, «Tolerancia al error», minimiza riesgos y consecuencias adversas de acciones accidentales o no intencionadas.
Pregunta 6
¿Cuál es el tamaño mínimo recomendado para áreas táctiles en dispositivos móviles según WCAG 2.2?
WCAG 2.2 (criterio 2.5.8, nivel AA) requiere mínimo 24×24 píxeles CSS. iOS recomienda 44pt, Android 48dp, pero el estándar web oficial es 24×24.
Pregunta 7
¿Qué técnica CSS permite aplicar estilos según características del dispositivo en diseño responsive?
Las Media Queries (
@media) permiten aplicar estilos condicionales según ancho de viewport, orientación, resolución, etc.
Pregunta 8
¿Qué significa WAI-ARIA?
WAI-ARIA son las Accessible Rich Internet Applications desarrolladas por la Web Accessibility Initiative del W3C.
Pregunta 9
¿Cuál es la primera regla de ARIA según las mejores prácticas?
La primera regla de ARIA es: «No uses ARIA si puedes usar HTML nativo». Por ejemplo,
<button> es mejor que <div role="button">.
Pregunta 10
¿Qué estrategia de diseño responsive prioriza el desarrollo para móvil primero?
Mobile-first diseña primero para pantallas pequeñas, luego expande para mayores. Es más eficiente, accesible y alineado con estadísticas actuales (>60% tráfico móvil).
Pregunta 11
¿Qué norma armonizada europea especifica requisitos de accesibilidad para contratación pública TIC?
La UNE-EN 301549:2022 especifica requisitos de accesibilidad para productos y servicios TIC en contratación pública europea.
Pregunta 12
¿Desde qué fecha es obligatorio que las aplicaciones móviles del sector público cumplan accesibilidad según RD 1112/2018?
Apps móviles: desde 23 junio 2021. Sitios nuevos: 20/09/2018. Sitios existentes: 20/09/2020.
Pregunta 13
¿Qué atributo HTML asocia una etiqueta con su campo de formulario?
El atributo
for de <label> debe coincidir con el id del <input> para asociarlos programáticamente.
Pregunta 14
¿Qué herramienta gratuita de auditoría de accesibilidad está integrada en Chrome DevTools?
Lighthouse está integrado nativamente en Chrome DevTools. aXe y WAVE son extensiones. Pa11y es herramienta CLI.
Pregunta 15
¿Qué lector de pantalla gratuito para Windows es más usado en pruebas de accesibilidad?
NVDA (NonVisual Desktop Access) es gratuito, open-source y estándar para pruebas. JAWS es comercial (~40% cuota usuario). VoiceOver es macOS/iOS. TalkBack es Android.
Pregunta 16
En diseño responsive, ¿qué breakpoint se suele usar para tablets verticales?
768px es el breakpoint común para tablets verticales (iPad). 1024px es horizontal/laptop. 320-480px es móvil.
Pregunta 17
¿Qué documento obligatorio debe publicar cada sitio web público según RD 1112/2018?
El artículo 7 del RD 1112/2018 obliga a publicar una declaración de accesibilidad detallada, actualizada y en lugar destacado.
Pregunta 18
¿Cuál de estos NO es un principio del diseño universal de Ronald Mace?
Los 7 principios son: Uso equitativo, Flexibilidad, Simple e intuitivo, Información perceptible, Tolerancia al error, Bajo esfuerzo físico, Tamaño y espacio apropiados. «Interfaz amigable» no es uno de ellos.
Pregunta 19
¿Qué técnica CSS permite layouts flexibles que se adaptan automáticamente al espacio disponible?
Flexbox (CSS Flexible Box Layout) permite layouts flexibles unidimensionales. Grid permite bidimensionales. Float y Position son técnicas antiguas menos flexibles.
Pregunta 20
¿Qué organismo español realiza auditorías periódicas de accesibilidad en sitios públicos?
El Observatorio de Accesibilidad Web (Ministerio de Asuntos Económicos) audita sitios públicos. AEPD es protección de datos. CCN-CERT es ciberseguridad.
Pregunta 21
¿Qué atributo ARIA comunica que un elemento está expandido o colapsado?
aria-expanded="true/false" indica si un elemento desplegable (accordion, menú) está expandido. Usado comúnmente con role="button".
Pregunta 22
¿Qué metodología del W3C guía las auditorías de conformidad web?
WCAG-EM (Website Accessibility Conformance Evaluation Methodology) es la metodología oficial del W3C para auditorías en 5 pasos.
Pregunta 23
¿Qué proporción de problemas de accesibilidad detectan las herramientas automáticas?
Las herramientas automáticas detectan solo ~30-40% de problemas. El resto requiere evaluación manual y pruebas con tecnologías de asistencia.
Pregunta 24
Según el Decreto 534/2021 del SAS, ¿qué principio debe cumplir la administración electrónica sanitaria?
El artículo 20 del Decreto 534/2021 establece que los canales electrónicos del SAS deben cumplir principios de accesibilidad universal y criterios de usabilidad.
Pregunta 25
¿Cuántos criterios de conformidad añade WCAG 2.2 respecto a WCAG 2.1?
WCAG 2.2 (octubre 2023) añade 9 nuevos criterios respecto a WCAG 2.1, enfocados en móviles, discapacidades cognitivas y baja visión.
Pregunta 26
¿Quién acuñó el término «diseño universal» en 1985?
Ronald Mace, arquitecto con discapacidad, acuñó el término «diseño universal» en 1985, inicialmente aplicado a arquitectura física.
Pregunta 27
¿Qué artículo del RGPD exige que la información al interesado sea transparente e inteligible?
El artículo 12 RGPD establece que la información debe proporcionarse de forma concisa, transparente, inteligible y de fácil acceso, lo que implica accesibilidad.
Pregunta 28
¿Qué técnica de diseño web propuso Ethan Marcotte en 2010?
Ethan Marcotte acuñó el término Responsive Web Design (RWD) en 2010, revolucionando el desarrollo web con una sola base de código adaptable.
Pregunta 29
¿Cuál de los siguientes NO es un pilar técnico del diseño responsive?
Los 3 pilares técnicos del RWD son: rejillas fluidas, imágenes flexibles y media queries. JavaScript NO es un pilar, aunque puede mejorar la experiencia.
Pregunta 30
¿Qué criterio WCAG 2.1 exige que el contenido funcione tanto en orientación vertical como horizontal?
El criterio 1.3.4 Orientación (nivel AA) requiere que el contenido no restrinja su vista y operación a una única orientación de pantalla.
13. MAPA CONCEPTUAL
┌─────────────────────────────────────────────────────────────────────────────────┐
│ TEMA 48: ACCESIBILIDAD Y USABILIDAD WEB │
└─────────────────────────────────────────────────────────────────────────────────┘
│
┌───────────────────────┼───────────────────────┐
│ │ │
┌──────▼─────┐ ┌──────▼─────┐ ┌──────▼──────┐
│ CONCEPTOS │ │ W3C Y │ │ DISEÑO │
│FUNDAMENTALES│ │ ESTÁNDARES │ │ UNIVERSAL │
└──────┬─────┘ └──────┬─────┘ └──────┬──────┘
│ │ │
┌───────────┼──────────┐ ┌───┴───┐ ┌───────┴────────┐
│ │ │ │ │ │ │
┌───▼───┐ ┌───▼────┐ ┌──▼──┐ ┌─▼─┐ ┌─▼──┐ ┌───▼────┐ ┌─────▼─────┐
│Accesi-│ │Usabili-│ │ISO │ │WAI│ │WCAG│ │7 Princ.│ │ Ronald │
│bilidad│ │ dad │ │9241-│ │ │ │2.1 │ │Diseño │ │ Mace │
│ Web │ │(Nielsen│ │ 11 │ │ │ │2.2 │ │Universal│ │ 1985 │
└───┬───┘ └───┬────┘ └─────┘ └─┬─┘ └─┬──┘ └────────┘ └───────────┘
│ │ │ │
│ │ │ └─────────┐
│ │ │ │
│ ┌─────┴────────┐ ┌───▼────┐ ┌────▼────────────────────────┐
│ │ 5 Atributos │ │ ARIA │ │ 4 PRINCIPIOS POUR │
│ │ │ │ │ │ ┌────────────────────────┐ │
│ │• Aprendizaje │ │• Roles │ │ │ P - PERCEPTIBLE │ │
│ │• Eficiencia │ │• Props.│ │ │ Alt text, contraste │ │
│ │• Memoria │ │• Estados│ │ ├────────────────────────┤ │
│ │• Errores │ └────────┘ │ │ O - OPERABLE │ │
│ │• Satisfacción│ │ │ Teclado, tiempo │ │
└────┴──────────────┘ │ ├────────────────────────┤ │
│ │ U - COMPRENSIBLE │ │
┌──────────────────────────────────────┐ │ │ Predecible, ayudas │ │
│ DISEÑO WEB ADAPTATIVO (RWD) │ │ ├────────────────────────┤ │
│ │ │ │ R - ROBUSTO │ │
│ Ethan Marcotte 2010 │ │ │ HTML válido, ARIA │ │
│ │ │ └────────────────────────┘ │
│ ┌────────────────────────────────┐ │ └─────────────────────────────┘
│ │ 3 PILARES TÉCNICOS │ │
│ │ ┌──────────────────────────┐ │ │ ┌────────────────────────────┐
│ │ │ 1. Rejillas Fluidas │ │ │ │ NIVELES DE CONFORMIDAD │
│ │ │ (% en vez de px) │ │ │ │ ┌──────────────────────┐ │
│ │ ├──────────────────────────┤ │ │ │ │ A - Básico (78) │ │
│ │ │ 2. Imágenes Flexibles │ │ │ │ │ AA - Requerido (98) │ │
│ │ │ (max-width: 100%) │ │ │ │ │ AAA - Óptimo (126) │ │
│ │ ├──────────────────────────┤ │ │ │ └──────────────────────┘ │
│ │ │ 3. Media Queries │ │ │ └────────────────────────────┘
│ │ │ (@media min-width) │ │ │
│ │ └──────────────────────────┘ │ │
│ │ │ │
│ │ ESTRATEGIA: Mobile-First │ │
│ │ Breakpoints: 320-768-1024px │ │
│ └────────────────────────────────┘ │
└──────────────────────────────────────┘
🎯 OBJETIVO FINAL TFA-STI 🎯
═══════════════════════════════════════════
Sistemas sanitarios que FUNCIONAN para TODOS
los andaluces, sin exclusión por capacidades
═══════════════════════════════════════════
14. REFERENCIAS BIBLIOGRÁFICAS Y NORMATIVAS
14.1. Normativa Legal
- Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público. BOE núm. 227, de 19/09/2018.
- Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público.
- Real Decreto Legislativo 1/2013, de 29 de noviembre, por el que se aprueba el Texto Refundido de la Ley General de derechos de las personas con discapacidad y de su inclusión social.
- Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas.
- Decreto 534/2021, de 21 de diciembre, por el que se regula la administración electrónica en el ámbito del Servicio Andaluz de Salud. BOJA núm. 248, de 28/12/2021.
14.2. Estándares Técnicos
- W3C. Web Content Accessibility Guidelines (WCAG) 2.1. W3C Recommendation, 5 June 2018.
- W3C. Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, 5 October 2023.
- W3C. Accessible Rich Internet Applications (WAI-ARIA) 1.2. W3C Recommendation, 6 June 2023.
- AENOR. UNE-EN 301549:2022. Requisitos de accesibilidad para productos y servicios TIC. Madrid: AENOR, 2022.
- ISO. ISO 9241-11:2018. Ergonomics of human-system interaction — Part 11: Usability: Definitions and concepts.
14.3. Bibliografía Especializada
- Nielsen, Jakob; Loranger, Hoa. Prioritizing Web Usability. Berkeley: New Riders Press, 2006.
- Krug, Steve. Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability. 3ª ed. Berkeley: New Riders, 2014.
- Marcotte, Ethan. Responsive Web Design. 2ª ed. New York: A Book Apart, 2014.
- Henry, Shawn Lawton. Introduction to Web Accessibility. W3C Web Accessibility Initiative (WAI), 2023.
- Horton, Sarah; Quesenbery, Whitney. A Web for Everyone: Designing Accessible User Experiences. Brooklyn: Rosenfeld Media, 2014.
14.4. Herramientas y Recursos
- Observatorio de Accesibilidad Web. Ministerio de Asuntos Económicos y Transformación Digital.
- Fundación ONCE. Centro de Investigación, Desarrollo y Aplicación Tiflotécnica (CIDAT).
- NVDA (NonVisual Desktop Access). NV Access. Lector de pantalla gratuito.
- WebAIM. Web Accessibility In Mind. Utah State University.
- Servicio Andaluz de Salud. Plan de Transformación Digital del SSPA 2022-2027. Sevilla, 2022.