RA5 · verificado

RA5 de Diseño de Interfaces Web · DAW

Desarrolla interfaces Web accesibles, analizando las pautas establecidas y aplicando técnicas de verificación.

Contenido verificado asociado a este RA

Fundamentos de la Accesibilidad Web: Necesidad y Beneficios

Esta unidad introduce la accesibilidad web, explicando su importancia ética, legal y de negocio, y cómo beneficia a todos los usuarios, no solo a personas con discapacidad.

Análisis de la Accesibilidad Web: Metodología, Pautas WCAG y Detección de Errores por Prioridad

Esta unidad desarrolla el proceso de análisis de accesibilidad de documentos web reales, apoyándose en las Pautas de Accesibilidad al Contenido Web (WCAG): sus cuatro principios (Perceptible, Operable, Comprensible, Robusto), los niveles de conformidad (A, AA, AAA) y los criterios de éxito asociados a cada punto de verificación. Incluye un caso práctico de análisis paso a paso de una página web y un procedimiento reproducible para detectar y clasificar errores según su prioridad.

Implementación de la Accesibilidad: Alcanzando Niveles de Conformidad

Esta unidad se centra en la aplicación práctica de las pautas WCAG para desarrollar interfaces web accesibles, cubriendo técnicas de codificación y diseño para alcanzar un nivel de conformidad deseado.

Verificación de la Accesibilidad: Herramientas y Pruebas

Esta unidad aborda las técnicas y herramientas para verificar los niveles de accesibilidad alcanzados, incluyendo test externos automatizados, pruebas manuales y la verificación de la visualización en diferentes entornos.

Conceptos clave

Accesibilidad WebDiscapacidadLIONDAAUNE-EN 301549UsabilidadInclusión digitalAnálisis de accesibilidad de documentos webWCAGPrincipios P.O.C.R. (Perceptible, Operable, Comprensible, Robusto)Criterios de Éxito y niveles de prioridadNiveles de Conformidad (A, AA, AAA)Procedimiento de análisis manual y automatizadoSemántica HTMLAtributo `alt`Contraste de colorNavegación por tecladoEtiquetas de formularioARIA (Accessible Rich Internet Applications)

Errores que conviene evitar

Considerar la accesibilidad como un 'extra' o un 'coste adicional': Esto lleva a posponer su implementación o a tratarla superficialmente, resultando en un producto final que excluye a usuarios y puede generar problemas legales o de reputación. La corrección es integrar la accesibilidad desde las primeras fases del diseño y desarrollo, como un requisito fundamental.
Asumir que 'todos usan el ratón y ven bien': Esta suposición ignora la diversidad de usuarios y tecnologías de asistencia. La corrección es diseñar pensando en la navegación por teclado, lectores de pantalla, lupas, etc., y probar con estas herramientas.
Confundir el análisis de accesibilidad con una simple ejecución de herramienta automática: las herramientas detectan solo un subconjunto de errores. La corrección es combinar siempre revisión manual (teclado, lector de pantalla, contraste) con herramientas automatizadas y análisis de código.
Tratar todos los errores por igual sin priorizar: la corrección es clasificar cada incumplimiento según su nivel (A, AA, AAA) y corregir primero los bloqueantes de Nivel A.
Presentar la exigencia del nivel AA como requisito curricular del módulo: en realidad procede de normativa de accesibilidad ajena al RA/CE evaluado aquí; el criterio curricular exige únicamente saber alcanzar y verificar el nivel de conformidad que el proyecto defina como objetivo.
Usar `div` y `span` para todo y luego intentar añadir accesibilidad con JavaScript: Esto crea una base semántica pobre que es difícil de hacer accesible. La corrección es usar los elementos HTML nativos siempre que sea posible y reservar ARIA para componentes complejos sin equivalente nativo.
Olvidar el foco del teclado: Un usuario de teclado necesita ver dónde está el foco. La corrección es asegurar que el estilo `:focus` sea claro y visible en todos los elementos interactivos.
Aplicar ARIA incorrectamente: Un uso erróneo de ARIA puede ser peor que no usarlo. La corrección es consultar la especificación ARIA y las 'ARIA Authoring Practices Guide' para patrones de diseño accesibles.

Qué se evalúa en este RA

CE a

Se ha reconocido la necesidad de diseñar webs accesibles.

CE b

Se ha analizado la accesibilidad de diferentes documentos Web.

CE c

Se han identificado las principales pautas de accesibilidad al contenido.

CE d

Se han analizado los posibles errores según los puntos de verificación de prioridad.

CE e

Se ha alcanzado el nivel de conformidad deseado.

CE f

Se han verificado los niveles alcanzados mediante el uso de test externos.

CE g

Se ha verificado la visualización del interfaz con diferentes navegadores y tecnologías.