Accesibilidad

Nota: Esta documentación es para usuarios de Moodle 2.x, 3.x y 4.x. Si desea ver la documentación antigua para Moodle 1.9 vaya a 19/Accesibilidad Si desea ver la documentación para desarrolladores vaya a Desarrolladores/Accesibilidad.

Accesibilidad: Documentación para usuarios:

La meta de Moodle es ser completamente accesible y usable para todos los usuarios, sin distinción de capacidad.

Esta página describe el estado actual de la accesibilidad en Moodle y también nuestros planes para el futuro.

Voluntary Product Accessibility Template (VPAT)

La accesibilidad digital es clave para asegurar que la plataforma Moodle sea accesive e inclusiva para todos los usuarios. Una vista general del desempeño de Moodle con las guías WCAG 2.1 se puede encontrar en nuestro reporte de cumplimiento de accesibilidad].

Prácticas establecidas

Los desarrolladores del núcleo de Moodle invierten mucho tiempo asegurándose de que los nuevos desarrollos sean accesibles. Parte de este proceso al desarrollar nuevo código en Moodle es seguir las mejores prácticas establecidas, y parte del proceso para aceptar código nuevo al núcleo de Moodle es probar cuidadosamente las páginas y recabar retroalimentación de los expertos.

Soporte para lectores de pantalla

Desde Moodle 2.7 en adelante, el soporte para lector de pantalla está descrito en las notas de las versiones.

Adecuación a estándares

La plataforma Moodle es un sistema complejo con muchas partes. Su código está en continua evolución. Se pueden habilitar y deshabilitar módulos. La interfaz puede personalizarse fuertemente usando Temas y miles de configuraciones. El contenido actual puede producirse por cualquier profesor o cualquier estudiante. Por esto, es imposible decir con 100% de certeza si es que Moodle o algún sitio basado en Moodle es absolutamente accesible o no. La accesibilidad no es un estado, es un proceso de mejora continua en respuesta a nuestros usuarios y el mayor ambiente técnico.

WCAG 2.1

When deciding how Moodle should present its content for best Web accessibility, the WCAG 2.1 guidelines are followed.

ATAG 2.0

Dado que Moodle es un lugar para construir contenido (y también para consumir contenido), también nos referimos a las guías de ATAG 2.0.
En Moodle 2.7se añadió un nuevo editor, Atto, que no solamente ayuda a mejorar el cómo cualquiera puede usar el propio editor, sino que también ayuda a mejorar la accesibilidad del contenido producido conél.

ARIA 1.0

Dado que muchas partes de la interfaz del usuario de Moodle son dinámicas e interactivas, nosotros seguimos las recomendaciones de ARIA para informar a las tecnologías asistivas, tales como los lectores-de-pantalla.

Seción 508 (US)

Dado que Moodle es usado por agencias del gobierno de los Estados Unidos de América, la enmienda US Section 508 amendment pudiera ser relevante a Moodle.
Moodlerooms (un Moodle Partner) tiene un VPAT statement en su sitio web.

Discusiones

Uno de los principales trabajos sobre accesibilidad está siendo desarrollado ahora mismo está en la lista de correos del Grupo de Colaboración para la Accesibilidad de Moodle (Moodle Accessibility Collaboration Group) , vea http://collaborate.athenpro.org/group/moodle/

También existen muchas discusiones sobre estos asuntos en el Moodle Tracker

Problemas conocidos

Esta es la lista principal de asuntos de accesibilidad, organizada por prioridad. Esta lista siempre está cambiando.

Áreas en contínuo desarrollo

Vea también

Accessibility in the dev docs
Diseño accesible del curso
The Accessibility block is a Moodle additional plugin that provides options for changing text size and colour scheme. Settings can be saved to persist between sessions. Also integrates ATbar from Southampton University ECS
Other accessibility related additional plugins for Moodle
Orato is a free text reader which can be installed on your PC or run from a USB Pen Drive for portable use.
this forum thread - Another way to look at it is that the Open University, UK, has more disabled students than all other UK universities combined, and we use a lot of Moodle quizzes, and only occasionally do we hear that a student had a problem with the mechanics of answering the quiz.

Accesibilidad: Documentación para desarrolladores

Nota: Esta es una traducción de una página de la documentación para desarrolladores (Developer docs), que se considera particularmente importante, y que en su versión original se actualiza frecuentemente. Por ello, se le recomienda que revise la página original en idioma inglés: Accessibility.

Los sitios Web construidos con accesibilidad en mente son flexibles para cumplir las diferentes necesidades de los usuarios, sus preferencias y situaciones. A pesar de que estos métodos pueden aumentar la usabilidad para todos los usuarios de la Web, a menudo es requerido legalmente que se implementen en un esfuerzo específico para prevenir la discriminación en contra de personas con discapacidades.

Puntos de arranque

Existen algunas introducciones legibles a la accesibilidad que cubren; qué es la accesibilidad, porqué es importante y sugerencias prácticas.

Nota: Pendiente de Traducir. ¡Anímese a traducir esta página!. ( y otras páginas pendientes)

Moodle-related accessibility coding guidelines

Use CSS, but still use headings, strong and emphasis: It is generally a good idea to separate a document's content HTML from how it is presented using CSS. There are some tags that affect a document's presentation but also contribute to the structure and meaning of the content. These tags should remain in HTML. This includes heading tags <h1>, <h2>, <h3>..., which are used to form the document's hierarchical structure, and <strong> and <em> tags, which are used to add meaning to sections of text.
Avoid using background images for important information: Users of non-visual browsers cannot see images. They can read the alt tags of normal images, but background images are not presented like normal images.
Image alt and title attributes

An alt attribute is required (even if empty) on all images.
If a link is wrapping an <img>, the <img> does not need a title attribute if the link has one.
The alt for an image and the title for its surrounding link should usually differ. An image alt attribute provides a text equivalent to an image, whereas a title attribute adds supplementary information about the purpose or action associated with an image link. Simply repeating the same text in alt and title attributes adds little and can be annoying for screen reader users.

Links and buttons should be selectable and easily click-able

An image used as an icon for a user to click should be large enough so that the user can click on it easily.
Users should be able to navigate to all links and buttons using the keyboard.
Generally we should avoid having two buttons/links that achieve the same action in the same area. This can be annoying and confusing for users of screen readers.

Support dynamic interaction with ARIA attributes: Events triggered by AJAX and JavaScript can be less obvious to users of non-visual browsers. ARIA attributes can assist users of such browsers to follow a dynamic change.
Use labels with inputs: Context can easily be lost without a visual presentation. Labels are needed on all input input elements (except button) to describe their purpose in a form. Labels should be unique on a page. Repeated elements should have a unique label that identifies the element within its context.
Use appropriate page titles: A page title is a starting point for a screen reader. Page titles should be unique and should make sense for the page. Avoid generic page titles.
All pages should be navigable using just a keyboard: It should be possible navigate to all points on a page just using a keyboard. Important events triggered by a mouse event should be able to be triggered when the item receives focus through keyboard navigation.
Avoid using colour alone to express meaning: Colour-blind users need additional information to gain meaning if colour is used as the emphasising feature. Also keep in mind that colours can have differing significance in different cultures, so colours should be configurable either through settings or language files.
Role for button-type links: If a link acts as a button (not forwarding to another page, which is often the case when combined with Javascript), it should declare the role attribute button. Also, as a button is usually triggered by the Space bar, the Javascript should add proper event listeners on the link to accept this key. Read more at Mozilla Developer Network