Clase 14. JavaScript y WAI-ARIA

Comenzamos repasando algunos conceptos básicos del maquetado moderno, como mejora progresiva y la separación apropiada del código cliente en capas de contenido, presentación y comportamiento.

Vimos que para la accesibilidad no debe ocuparnos sólo el DOM sino también el DOM accesible, y como este es expuesto por el navegador al API de accesibilidad, repasando las distintas APIs de cada sistema operativo y su historia.

Pusimos así en contexto el concepto de buffer virtual que usan los lectores de pantalla para hacer navegable el contenido no interactivo de una página Web, y conversamos sobre los desafíos que éste presenta para que nuestro JavaScript sea accesible, dificultando la identificación de cambios en fragmentos del documento.

Comparamos las perspectivas de WCAG 1.0 y 2.0 en cuanto al uso de JavaScript, y repasamos los principios “POUR” de las Pautas, centrándonos en el que trata sobre Robustez y lo que esto implica en la construcción de páginas Web.

Cerramos sobre la importancia de que cada elemento de HTML exponga al API de accesibilidad un nombre, función o rol, valor, propiedades y estado; vimos como WAI-ARIA nos permite salvar deficiencias o limitaciones en el maquetado. Repasamos qué hace un rol de ARIA para el API de accesibilidad, y más importante: que no hace.

Discutimos como en general debemos preferir HTML semántico por sobre atributos ARIA, así como evitar cambiar, pero si mejorar, la semántica de los elementos HTML, y qué excepciones hay a estas regla.

Vimos como validar páginas que usan ARIA, y la relación entre esta recomendación del W3C y HTML5 en el mundo real, teniendo en cuenta distintos navegadores y ayudas técnicas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *