Diferencia entre revisiones de «Accesibilidad»

De MoodleDocs
(tidy up)
 
(tidy up)
(No se muestran 17 ediciones intermedias del mismo usuario)
Línea 1: Línea 1:
{{Moodle 2.x}}
{{Acerca de Moodle}}
{{Frequently updated page translation
'''Nota: Esta documentación es para usuarios de Moodle 2.x y 3.x.
|devpagetitle = Accessibility
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]]'''.
'''Nota: Esta documentación es para Moodle 2.x. Si desea ver la documentación para Moodle 1.9 vaya a [[19/Accesibilidad]]'''.


{{Pendiente de traducir}}
'''Accesibilidad: Documentación para usuarios:'''
{{Acerca de Moodle}}


Moodle's goal is to be fully accessible and usable for all users regardless of ability.
La meta de Moodle es ser completamente accesible y usable para todos los usuarios, sin distinción de capacidad.


This page describes the current state of accessibility in Moodle as well as our plans for the future.
Esta página describe el estado actual de la accesibilidad en Moodle y también nuestros planes para el futuro.


== Prácticas establecidas ==
== Prácticas establecidas ==


Moodle core developers spend a lot of time making sure new developments are accessible. Part of the process when building new code in Moodle is to follow established best practices and part of the process for accepting new code into core is to test pages carefully and gather feedback from experts.
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 ==
== Soporte para lectores de pantalla ==


From Moodle 2.7 onwards, [[:dev:Moodle_2.7_release_notes#Screen_reader_support|supported screen-reader/browser configurations]] are described in release notes.
Desde Moodle 2.7 en adelante, [[Notas_de_Moodle_2.7#Soporte_de_lector_de_pantalla| el soporte para lector de pantalla]] está descrito en las notas de las versiones.


== Adecuación a estándares ==
== Adecuación a estándares ==


The Moodle platform is a complex system with many parts. Its code is always evolving. Modules can be enabled and disabled. The interface can be heavily customised using themes and thousands of settings. Actual content can be produced by any teacher or any student. As such it is impossible to say with 100% certainty whether Moodle or any site based on Moodle is absolutely accessible or not. Accessibility is not a state, it is a process of continuous improvement in response to our users and the wider technical environment.
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.


=== [http://www.w3.org/TR/WCAG20 WCAG 2.0] ===
=== [http://www.w3.org/TR/WCAG20 WCAG 2.0] ===


* When deciding how Moodle should present its content for best Web accessibility, the [http://www.w3.org/TR/WCAG20 WCAG 2.0] guidelines is followed.
* Al decidir el cómo Moodle debería de presentar su contenido para una mejor accesibilidad por Web, se siguen las guías de [http://www.w3.org/TR/WCAG20 WCAG 2.0].
* We hope to have document here soon discussing how well Moodle meets WCAG 2.0 requirements.


=== [http://www.w3.org/TR/ATAG20 ATAG 2.0] ===
=== [http://www.w3.org/TR/ATAG20 ATAG 2.0] ===


* As Moodle is a place to construct content (as well as consume content), we also refer to the [http://www.w3.org/TR/ATAG20 ATAG 2.0] guidelines.
* Dado que Moodle es un lugar para construir contenido (y también para consumir contenido), también nos referimos a las guías de [http://www.w3.org/TR/ATAG20 ATAG 2.0].
* In Moodle 2.7 a new editor Atto was added that not only helps to improve how everyone can use the editor itself, but also helps to improve the accessibility of the content produced with it.
* 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.


=== [http://www.w3.org/TR/wai-aria ARIA 1.0] ===
=== [http://www.w3.org/TR/wai-aria ARIA 1.0] ===


* As many parts of the Moodle user interface are dynamic and interactive, we follow the [http://www.w3.org/TR/wai-aria ARIA] recommendations to inform assistive technologies, such as screen-readers.
* Dado que muchas partes de la interfaz del usuario de Moodle son dinámicas e interactivas, nosotros seguimos las recomendaciones de [http://www.w3.org/TR/wai-aria ARIA] para informar a las tecnologías asistivas, tales como los lectores-de-pantalla.


=== Seción 508 (US) ===
=== Seción 508 (US) ===


* As Moodle is used by US Government agencies, the US Section 508 amendment can be relevant to Moodle.
* Dado que Moodle es usado por agencias del gobierno de los Estados Unidos de América, la enmienda ''[https://www.section508.gov/section508-laws US Section 508 amendment]'' pudiera ser relevante a Moodle.
* Moodlerooms (a Moodle Partner) have a [http://www.moodlerooms.com/accessibility VPAT statement] on their web site.
* Moodlerooms (un ''Moodle Partner'') tiene un [http://www.moodlerooms.com/accessibility VPAT statement] en su sitio web.


== Discusiones==
== Discusiones==


One of the main places accessibility work is being carried out right now is on the Moodle Accessibility Collaboration Group mailing list, see http://collaborate.athenpro.org/group/moodle/
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/


There are also many discussion on issues in the [https://tracker.moodle.org/browse/MDL/component/10083/?selectedTab=com.atlassian.jira.jira-projects-plugin:component-issues-panel Moodle Tracker]
También existen muchas discusiones sobre estos asuntos en el  [https://tracker.moodle.org/browse/MDL/component/10083/?selectedTab=com.atlassian.jira.jira-projects-plugin:component-issues-panel Moodle Tracker]


== Problemas conocidos ==
== Problemas conocidos ==


This is [https://tracker.moodle.org/issues/?jql=component%20%3D%20Accessibility%20AND%20project%20%3D%20MDL%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC the main list of accessibility issues], organised by priorityThis list is always changing.
Esta es [https://tracker.moodle.org/issues/?jql=component%20%3D%20Accessibility%20AND%20project%20%3D%20MDL%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC la lista principal de asuntos de accesibilidad], organizada por prioridad. Esta lista siempre está cambiando.


== Áreas en contínuo desarrollo ==
== Áreas en contínuo desarrollo ==


* [https://tracker.moodle.org/browse/MDL-39663 Filepicker]
* [https://tracker.moodle.org/browse/MDL-39663 Selector de archivos (''Filepicker'')]
* [https://tracker.moodle.org/browse/MDL-41773 Forum]
* [https://tracker.moodle.org/browse/MDL-41773 Foro (''Forum'')]
 
== Vea también ==
* [[:dev:Accessibility|Accessibility in the dev docs]]
* [[Diseño accesible del curso]]
* The [https://moodle.org/plugins/block_accessibility 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 [https://moodle.org/plugins/index.php?q=accessibility accessibility related additional plugins] for Moodle
* [http://www.callscotland.org.uk/information/text-to-speech/orato/ Orato]  is a free text reader which can be installed on your PC or run from a USB Pen Drive for portable use.
* [https://moodle.org/mod/forum/discuss.php?d=367206 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==
{{Frequently updated page translation
|devpagetitle = 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|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.
* [http://www.w3.org/WAI/intro/accessibility.php Web Accessibility Initiative's ''Introduction to Web Accessibility'']
* [http://diveintoaccessibility.info/ Mark Pilgrim's ''Dive into Accessibility'']
* [http://joeclark.org/book/ Joe Clark's ''Building Accessible Websites'' book]
 
{{Pendiente de traducir}}
 
== 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 <code>&lt;h1&gt;, &lt;h2&gt;, &lt;h3&gt;...</code>, which are used to form the document's hierarchical structure, and <code>&lt;strong&gt;</code> and <code>&lt;em&gt;</code> 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 <code>alt</code> tags of normal images, but background images are not presented like normal images.
; Image <code>alt</code> and <code>title</code> attributes
* An <code>alt</code> attribute is required (even if empty) on all images.
* If a link is wrapping an <code>&lt;img&gt;</code>, the <code>&lt;img&gt;</code> does not need a <code>title</code> attribute if the link has one.
* The <code>alt</code> for an image and the <code>title</code> for its surrounding link should usually differ. An image <code>alt</code> attribute provides a text equivalent to an image, whereas a <code>title</code> attribute adds supplementary information about the purpose or action associated with an image link. Simply repeating the same text in <code>alt</code> and <code>title</code> 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 [https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role Mozilla Developer Network]
 
== Web standards, guidelines and legislation ==
 
=== International ===
 
* [http://www.w3.org/WAI/ Web Accessibility Initiative]
** [http://www.w3.org/WAI/intro/wcag.php Web Content Accessibility Guidelines (WCAG)]
** [http://www.w3.org/WAI/intro/wcag20 Web Content Accessibility Guidelines 2.0 (draft)]
*** An article on the [http://www.alistapart.com/articles/tohellwithwcag2 problems with WCAG2] from A List Apart
** [http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html Client-side scripting guidelines]
 
* [http://www.w3.org/WAI/intro/aria.php W3C ARIA]
 
* [http://webaim.org/techniques/forms/controls WebAIM Form Accessibility guidelines]
* [http://webaim.org/techniques/aria/ WebAIM ARIA guidelines]
 
=== USA ===
* [http://www.section508.gov/ Section 508]
 
=== UK ===
* [http://www.legislation.gov.uk/ukpga/2010/15/contents Equality Act 2010], in particular:
** [http://www.legislation.gov.uk/ukpga/2010/15/section/20 Section 20 - Duty to make adjustments]
** [http://www.legislation.gov.uk/ukpga/2010/15/section/29 Section 29 - Provision of services, etc.]
** [http://www.legislation.gov.uk/ukpga/2010/15/schedule/25 Schedule 25 - Information society services].
: See also the [http://www.equalityhumanrights.com/uploaded_files/EqualityAct/servicescode.pdf Equality Act 2010 Statutory Code of Practice] (PDF) for Services, public functions and associations.
* [http://www.equalityhumanrights.com/advice-and-guidance/public-sector-equality-duty/ Public sector equality duty] created by the Equality Act 2010.
* [http://www.parliament.the-stationery-office.co.uk/pa/ld200001/ldbills/003/2001003.htm SENDA - Special Educational Needs and Disability Act/Bill]
* [http://www.opsi.gov.uk/acts/acts1995/1995050.htm Disability Discrimination Act 1995] (now merged ino the Equality Act 2010).
* [http://www.southampton.ac.uk/web4all/standards/BS_16steps/ BS 8878:2010 – 16 Steps for an accessible web product]
 
=== Germany ===
* [http://www.einfach-fuer-alle.de/artikel/bitv/ Barrierefreie Informationstechnik-Verordnung - BITV]
===European Union===
* [https://ec.europa.eu/digital-agenda/en/news/proposal-directive-european-parliament-and-council-accessibility-public-sector-bodies-websites Proposal for a Directive of the European Parliament and of the Council] on the accessibility of public sector bodies' websites.
 
== Tools ==
 
=== Firefox extensions ===
* [http://firefox.cita.uiuc.edu/ Firefox Accessibility Extension] by the Illinois Center for Information Technology and Web Accessibility (iCITA)
* [https://docs.moodle.org/dev/Web_developer_extension Web developer extension] for [https://docs.moodle.org/dev/Web_developer_extension Firefox]
* [https://docs.moodle.org/dev/Blank_Your_Monitor_and_Easy_Reading_extension_for_Firefox Blank Your Monitor and Easy Reading Extension] for Firefox
* [http://www.deque.com/products/worldspace-fireeyes/download-worldspace-fireeyes|FireEye plugin for Firebug]
* [https://addons.mozilla.org/en-us/firefox/addon/wcag-contrast-checker|Color contrast plugin for Firefox]
 
=== Chrome extension ===
* [https://chrome.google.com/webstore/detail/color-contrast-analyzer/dagdlcijhfbmgkjokkjicnnfimlebcll Color Contrast Analyzer]
* [https://chrome.google.com/webstore/detail/high-contrast/djcfdncoelnlbldjfhinnjlhdjlikmph High contrast]
 
=== Accessibility validation tools ===
* [https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en Chrome Accessibility Developer Tooks]
* [https://docs.moodle.org/dev/W3C_validation W3C validation] (for [[HTML in Moodle]], [[CSS]] and [[RSS]])
* [http://wave.webaim.org/ Web accessibility evaluation tool]
* [http://cynthiasays.com/ Cynthia Says accessibility checker]
 
=== Screen readers ===
* [http://www.standards-schmandards.com/projects/fangs/ Fangs – the screen reader emulator] for Firefox
* [http://www.nvda-project.org/ NVDA NonVisual Desktop Access] - open source screen reader for Windows
* [http://webaim.org/projects/screenreadersurvey4// WebAIM Screen reader survey] (Predominance of tools, browsers, OSs used by accessibility users)
 
See also this [http://www.w3.org/WAI/ER/tools/complete long list of accessibility tools].
 
See a [http://www.youtube.com/playlist?list=PLmQqs2jGU8Pr7e-3Fz2PoN6AabEkEBRYX live demonstration of a number of accessibility tools].
 
== Resources ==
 
* [http://webstandards.org/action/atf/manifesto/ Web Standards.org's ''Accessibility Task Force Manifesto'']
* [http://alistapart.com/topics/userscience/accessibility/ Accessibility articles from ''A List Apart'']
* [http://diveintomark.org/archives/2003/08/29/semantics Mark Pilgrim's ''Won’t somebody please think of the gerbils?'']
: [http://diveintoaccessibility.org/ Dive Into Accessibility] by Mark Pilgrim
* [http://joeclark.org/access/webaccess/ Joe Clark's writings on accessibility]
: [http://joeclark.org/book/ Building Accessible Websites] by Joe Clark (online version)
* [http://en.wikipedia.org/wiki/Web_accessibility Wikipedia article on ''Web Accessibility'']
* [http://juicystudio.com/article/validity-accessibility.php ''Validity and Accessibility'']
* [http://www.edtec.unsw.edu.au/inter/support/accessibility/access_vids.cfm Videos showing as student accessing another Learning Management System via Screen Reader software]
 
== Vea también ==
* [[Desarrolladores/Accesibilidad]] traducción de la documentación para desarrolladores acerca de Accesibilidad
 
* [[:en:Accessibility|Accessibility statement]] - in current Moodle versions
* [https://docs.moodle.org/dev/Semantic_HTML Semantic HTML]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=85119 New Accessibility Themes] forum discussion
* See [[:en:Usability FAQ]] for the related concept of usability.
* [https://docs.moodle.org/dev/Moodle_Accessibility_Specification Moodle Accessibility Specification] in Developer's Documentation
* http://moodle.org/mod/forum/discuss.php?d=127807#p559951
* The [http://dev.moodle.org/course/view.php?id=2 Introduction to Moodle Programming] provides some extensive information and discussion on accessibility.
* [http://www.easy.pro.br/ EASY: Interface Between The Virtual Environment Moodle Learning and People with Visual Impairments]
* [http://www.bbc.co.uk/blogs/bbcinternet/2008/03/homepage_accessibilty.html BBC blog post on how their Web 2.0 homepage was made accessible]
* [http://www.bbc.co.uk/accessibility/ BBC Accessibility Help]
* [http://tracker.moodle.org/browse/MDL-7396 Accessibility Compliance in Moodle 1.8]
* [http://tracker.moodle.org/browse/MDL-7860 Compliance with Italian Legislation on Accessibility]
 
[[Categoría:Accesibilidad]]


== SVea también ==


[[dev:Accessibility|Accessibility for Moodle Developers]]
[[dev:Accessibility|Accessibility for Moodle Developers]]
* [http://plugins.moodlebites.com Try the Accessibility plugin] on http://plugins.moodlebites.com


[[en:Accessibility]]
[[en:Accessibility]]

Revisión del 14:36 25 may 2018

Nota: Esta documentación es para usuarios de Moodle 2.x y 3.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.

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.0

  • Al decidir el cómo Moodle debería de presentar su contenido para una mejor accesibilidad por Web, se siguen las guías de WCAG 2.0.

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

Web standards, guidelines and legislation

International

USA

UK

See also the Equality Act 2010 Statutory Code of Practice (PDF) for Services, public functions and associations.

Germany

European Union

Tools

Firefox extensions

Chrome extension

Accessibility validation tools

Screen readers

See also this long list of accessibility tools.

See a live demonstration of a number of accessibility tools.

Resources

Dive Into Accessibility by Mark Pilgrim
Building Accessible Websites by Joe Clark (online version)

Vea también


Accessibility for Moodle Developers