Accesibilidad en el Aula Virtual Institucional (AVI)

**ESTA PÁGINA ESTA EN CONSTRUCCIÓN. LOS DATOS AQUÍ INCLUÍDOS NO SON LOS FINALES**

La información contenida en esta página es una traducción* parcial del sitio web https://docs.moodle.org/39/en/Accessible_course_design el cual contiene algunas recomendaciones para hacer que los cursos diseñados en el AVI tengan algunos elementos de accesibilidad. El Aula Virtual de la UNA está basado en el sistema MOODLE para la gestión del aprendizaje, por lo que los elementos de accesibilidad que tenga el sistema MOODLE , están también disponibles en el Aula Virtual Institucional.

Accesibilidad

Moodle está diseñado para brindar la misma funcionalidad e información a todas las personas. Esto significa que no debe haber barreras para las personas independientemente de las discapacidades, las tecnologías de asistencia que se utilicen, los diferentes tamaños de pantalla y los diferentes dispositivos de entrada (por ejemplo, mouse, teclado y pantalla táctil).

El Enfoque de Accesibilidad en MOODLE

Moodle trabaja continuamente para mejorar la accesibilidad y recientemente ha estado trabajando con un auditor externo para revisar la plataforma. Las páginas clave dentro de Moodle fueron auditadas con herramientas automatizadas y pruebas de recorrido del usuario. Los hallazgos de esta auditoría se están abordando y una gran cantidad de estas mejoras de accesibilidad son parte de Moodle 3.9 (fecha de lanzamiento el 15 de junio de 2020) y también se han actualizado a las versiones estables existentes. Donde sea posible, se implementan mejoras en toda la plataforma. Esto es parte de nuestro compromiso continuo de proporcionar una plataforma accesible y mejorar continuamente nuestro cumplimiento con WCAG 2.1 Nivel AA

 

Características de Autoría

Los usuarios pueden utilizar Moodle para crear contenido para otros usuarios. En algunos casos, se han agregado funciones de accesibilidad a las herramientas de creación para que el contenido que se produce sea lo más accesible posible. Un ejemplo es el "editor de texto Atto", que incluye un "Comprobador de accesibilidad" y un "Asistente de accesibilidad" que proporcionan información adicional a los autores de contenido sobre la accesibilidad de su contenido (como comprobaciones de contraste suficiente). Las ecuaciones producidas por el filtro de contenido MathJax tienen total accesibilidad habilitada para que se puedan pasar directamente al lector de pantalla como contenido matemático.

Estándares de codificación

Todos los componentes de Moodle deben estar disponibles para que los usen todos los usuarios. La accesibilidad debe ser parte del diseño de cada nueva característica de Moodle.

Para funciones sencillas sin necesidad de una interfaz de usuario avanzada, el simple cumplimiento de HTML5 estándar proporciona una función accesible. En este caso, es mejor no utilizar ARIA que utilizarlo incorrectamente (W3C no Aria).

Los componentes Bootstrap y Bootstrap no admiten la accesibilidad de forma predeterminada y todas las funciones implementadas con Bootstrap deben verificarse y mejorarse cuando sea necesario. El tema Boost contiene un módulo javascript "aria" que agrega accesibilidad a algunas funciones predeterminadas de Bootstrap (menús).

Colores

Todo el texto que se presenta debe mostrarse en un color con suficiente contraste con su color de fondo para que el texto sea legible para todos los usuarios. Los colores de primer plano y de fondo deben cumplir con el requisito de contraste de WCAG, que varía según el tamaño del texto. Esto se puede probar con la herramienta de evaluación de accesibilidad web de WebAIM.

Además, el color por sí solo no puede utilizarse para implicar significado. Un ejemplo de una falla para esto sería mostrar mensajes de error en "rojo" sin ninguna otra información para transmitir que se trata de un mensaje de error.

Iconos

Los iconos (imágenes) se pueden mostrar de diversas formas, y el uso correcto de los iconos dependerá del contexto en el que se utilicen.

 

Iconos y texto

Cuando se muestra un icono inmediatamente antes o después de un texto que también describe el significado del icono, es redundante repetir el mismo texto dos veces. En este caso, es correcto ocultar el icono de los lectores de pantalla estableciendo el atributo "rol" en "presentación" u ocultándolo con el atributo "aria-hidden" establecido en "verdadero".

Soporte de teclado

Todos los componentes deben ser completamente operables a través de una interfaz de solo teclado.

Algunas cosas importantes a considerar es que todos los componentes deben poder enfocarse con el teclado (disponible en la secuencia de tabulación) y deben permitir que el enfoque se aleje usando solo el teclado.

El elemento que actualmente tiene el foco debe tener un indicador de foco visual. Gestión de focos ARIA.

En algunos casos, un solo componente puede contener muchos componentes más pequeños. Para no contaminar la secuencia de pestañas de la página, el elemento padre puede existir en la secuencia de pestañas una vez y debe mantener el foco dentro de sus componentes más pequeños con la navegación con la tecla de flecha (tabindex itinerante o descendiente activo).

Formularios

Los formularios de Moodle creados con la biblioteca de formularios estándar están diseñados para ser accesibles. Cualquier formulario personalizado (por ejemplo, javascript) o elementos de formulario personalizados también debe ser accesible.

Todos los elementos del formulario deben tener una etiqueta El formulario debe poder completarse íntegramente con el teclado Las entradas no válidas en los campos del formulario deben indicarse con el atributo "aria-invalid" establecido en "true" Los mensajes de advertencia para campos de formulario no válidos deben asociarse con el campo no válido utilizando el atributo "aria-describedby".