Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Accessibility: Difference between revisions

From MoodleDocs
(Adding and updating accessibility guidelines)
(Added link to see also * [https://moodle.org/mod/forum/discuss.php?d=367206 this forum thread])
(41 intermediate revisions by 17 users not shown)
Line 1: Line 1:
Websites built with '''accessibility''' in mind are flexible in meeting different user needs, preferences and situations. Though these methods can increase [[Development:Usability|usability]] for everyone who uses the Web they are often legally required to be implemented in a specific effort to prevent discrimination against people with disabilities.
Websites built with '''accessibility''' in mind are flexible in meeting different user needs, preferences and situations. Though these methods can increase [[Usability|usability]] for everyone who uses the Web they are often legally required to be implemented in a specific effort to prevent discrimination against people with disabilities.


== Starting points ==
== Starting points ==
Line 5: Line 5:
These are some readable introductions to accessibility that cover; what accessibility is, why it is important, as well as practical advice.
These are some readable introductions to accessibility that cover; what accessibility is, why it is important, as well as practical advice.
* [http://www.w3.org/WAI/intro/accessibility.php Web Accessibility Initiative's ''Introduction to Web Accessibility'']
* [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://diveintoaccessibility.info/download/diveintoaccessibility.pdf Mark Pilgrim's ''Dive into Accessibility (Archived pdf)'']
* [http://joeclark.org/book/ Joe Clark's ''Building Accessible Websites'' book]
* [http://joeclark.org/book/ Joe Clark's ''Building Accessible Websites'' book]
== Moodle Accessibility Collaboration Group ==
To improve the accessibility/usability of this learning management system, we have established this collaboration group to work together with Moodle developers, administrators, IT professionals, and other interested entities and individuals. We welcome anyone who is interested in improving the accessibility of Moodle to join this group. You don’t need to be a technical guru or accessibility expert to join; however, it is expected that you are familiar with the basics of accessibility and are willing to dedicate a few hours each month to this collaboration effort.
Visit http://collaborate.athenpro.org/group/moodle to join the email list.
We meet in regional groups once a month to discuss accessibility priorities for each region. Regions meet at the following times:
* North America: We meet on the 1st Monday of each month at 10am USA Pacific Daylight Saving Time/5pm UTC. (Time zone converter: http://www.worldtimebuddy.com/)
* Europe: Looking for leadership and members
* Asia Pacific: Looking for leadership and members
* Latin America: Looking for leadership and members
To review past regional meetings or to see up coming meetings visit http://collaborate.athenpro.org/group/moodle/teleconferences/


== Moodle-related accessibility coding guidelines ==
== Moodle-related accessibility coding guidelines ==


; Use CSS, but still use headings, strong and emphasis
; 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.
: 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><h1>, <h2>, <h3>...</code>, which are used to form the document's hierarchical structure, and <code><strong></code> and <code><em></code> tags, which are used to add meaning to sections of text.
; Avoid using background images for important information
; 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.
: 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 should differ
; Image <code>alt</code> and <code>title</code> attributes
: An image <code>alt</code> tag 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. Simply repeating the same text in <code>alt</code> and <code>title</code> attributes adds little and can be annoying for screen reader users.
* An <code>alt</code> attribute is required (even if empty) on all images.
* If a link is wrapping an <code><img></code>, the <code><img></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
; 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.
: 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.
Line 24: Line 44:
; All pages should be navigable using just a keyboard
; 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.
: 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.
; Use sufficient color contrast when adding color to text. See Tracker ticket MDL 522391: https://tracker.moodle.org/browse/MDL-52391.
; 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 ==
== Web standards, guidelines and legislation ==
Line 33: Line 58:
** [http://www.w3.org/WAI/intro/wcag20 Web Content Accessibility Guidelines 2.0 (draft)]
** [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
*** 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 ===
=== USA ===
Line 38: Line 69:


=== UK ===
=== 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.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]  
* [http://www.opsi.gov.uk/acts/acts1995/1995050.htm Disability Discrimination Act 1995] (now merged ino the Equality Act 2010).
* [https://www.access8878.co.uk/getting-started-with-bs-8878/16-steps.aspx BS 8878:2010 – 16 Steps for an accessible web product]
 
=== Germany ===
=== Germany ===
* [http://www.einfach-fuer-alle.de/artikel/bitv/ Barrierefreie Informationstechnik-Verordnung - BITV]
* [http://www.einfach-fuer-alle.de/artikel/bitv/ Barrierefreie Informationstechnik-Verordnung - BITV]
=== France ===
* [https://references.modernisation.gouv.fr/rgaa-accessibilite/ Référentiel Général d’Accessibilité des Administrations - RGAA]
===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 ==
== Tools ==
Line 52: Line 96:
* [http://www.deque.com/products/worldspace-fireeyes/download-worldspace-fireeyes|FireEye plugin for Firebug]
* [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]
* [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]
* [https://chrome.google.com/webstore/detail/chromelens/idikgljglpfilbhaboonnpnnincjhjkd/related ChromeLens]
* [https://chrome.google.com/webstore/detail/see/dkihcccbkkakkbpikjmpnbamkgbjfdcn SEE]
* [https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb Accessibility developer tools]


=== Accessibility validation tools ===
=== Accessibility validation tools ===
* [https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en Chrome Accessibility Developer Tooks]
* [[W3C validation]] (for [[HTML in Moodle]], [[CSS]] and [[RSS]])  
* [[W3C validation]] (for [[HTML in Moodle]], [[CSS]] and [[RSS]])  
* [http://wave.webaim.org/ Web accessibility evaluation tool]
* [http://wave.webaim.org/ Web accessibility evaluation tool]
* [http://cynthiasays.com/ Cynthia Says accessibility checker]
* [http://cynthiasays.com/ Cynthia Says accessibility checker]
* [https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd AXE]
* [https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh WAVE]


=== Screen readers ===
=== Screen readers ===
Since 2.7, Moodle officially supports the following screen reader/browser configurations (MDL-44002):
{| class="nicetable"
|-
! Browser
! Screen reader
! Minimum version
! Recommended version
|-
| [http://windows.microsoft.com/en-AU/internet-explorer/download-ie Microsoft Internet Explorer]
| [http://www.freedomscientific.com/products/fs/jaws-product-page.asp Jaws]
| 15
| Latest
|-
| [http://www.mozilla.org/en-US/ Mozilla Firefox]
| [http://www.nvaccess.org/ NVDA]
| 2014.1
| Latest
|}
Other tools and resources:
* [http://www.standards-schmandards.com/projects/fangs/ Fangs – the screen reader emulator] for Firefox
* [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)
* [http://www.chromevox.com/index.html ChromeVox] - Available in several languages for Linux, Windows and Mac OS, only on Chrome browser. (Android mobile users can use [https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback TalkBack])


See also this [http://www.w3.org/WAI/ER/tools/complete long list of accessibility tools].
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 ==
== Resources ==
Line 78: Line 155:
== See also ==
== See also ==


* [[:en:Accessibility|Accessibility statement]] - in current Moodle versions
* [[Semantic HTML]]
* [[Semantic HTML]]
* [http://moodle.org/mod/forum/view.php?f=820 Accessibility forum on Moodle.org]
* [[Moodle Accessibility Specification]]
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=85119 New Accessibility Themes] forum discussion
* See [[Usability FAQ]] for the related concept of usability.
* See [[:en:Usability FAQ]] for the related concept of usability.
* http://moodle.org/mod/forum/discuss.php?d=127807#p559951 (Old, 2009, might not be relevant any more)
* [[:en:Moodle Accessibility Specification]]
* 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.
* 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.easy.pro.br/ EASY: Interface Between The Virtual Environment Moodle Learning and People with Visual Impairments]
Line 90: Line 166:
* [http://tracker.moodle.org/browse/MDL-7396 Accessibility Compliance in Moodle 1.8]
* [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]
* [http://tracker.moodle.org/browse/MDL-7860 Compliance with Italian Legislation on Accessibility]
 
* [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20Accessibility%20ORDER%20BY%20affectedVersion%20DESC Open accessibility issues on the Tracker]
* [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.
[[Category:Coding guidelines|Accessibility]]
[[Category:Coding guidelines|Accessibility]]
[[Category:Accessibility]]
[[Category:Accessibility]]
[[es:dev/Accesibilidad]]
[[fr:Accessibilité]]

Revision as of 16:26, 16 March 2018

Websites built with accessibility in mind are flexible in meeting different user needs, preferences and situations. Though these methods can increase usability for everyone who uses the Web they are often legally required to be implemented in a specific effort to prevent discrimination against people with disabilities.

Starting points

These are some readable introductions to accessibility that cover; what accessibility is, why it is important, as well as practical advice.

Moodle Accessibility Collaboration Group

To improve the accessibility/usability of this learning management system, we have established this collaboration group to work together with Moodle developers, administrators, IT professionals, and other interested entities and individuals. We welcome anyone who is interested in improving the accessibility of Moodle to join this group. You don’t need to be a technical guru or accessibility expert to join; however, it is expected that you are familiar with the basics of accessibility and are willing to dedicate a few hours each month to this collaboration effort.

Visit http://collaborate.athenpro.org/group/moodle to join the email list.

We meet in regional groups once a month to discuss accessibility priorities for each region. Regions meet at the following times:

  • North America: We meet on the 1st Monday of each month at 10am USA Pacific Daylight Saving Time/5pm UTC. (Time zone converter: http://www.worldtimebuddy.com/)
  • Europe: Looking for leadership and members
  • Asia Pacific: Looking for leadership and members
  • Latin America: Looking for leadership and members

To review past regional meetings or to see up coming meetings visit http://collaborate.athenpro.org/group/moodle/teleconferences/

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

,

,

..., which are used to form the document's hierarchical structure, and and 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.
Use sufficient color contrast when adding color to text. See Tracker ticket MDL 522391
https://tracker.moodle.org/browse/MDL-52391.
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

France

European Union

Tools

Firefox extensions

Chrome extension

Accessibility validation tools

Screen readers

Since 2.7, Moodle officially supports the following screen reader/browser configurations (MDL-44002):

Browser Screen reader Minimum version Recommended version
Microsoft Internet Explorer Jaws 15 Latest
Mozilla Firefox NVDA 2014.1 Latest

Other tools and resources:

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)

See also