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
(→‎European Union: added link to informational page)
(14 intermediate revisions by 9 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 [[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.
Moodle is designed to provide equal functionality and information to all people. This means that there should be no barriers for people regardless of disabilities, assistive technologies that are used, different screen sizes and different input devices (e.g. mouse, keyboard and touchscreen).
 
== Moodle Accessibility Collaboration Group ==
 
To improve the accessibility and usability of Moodle, we have established this collaboration group to work together with Moodle developers, accessibility experts, 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.
 
This group meets once a month to discuss accessibility priorities, typically on the first Monday of each month.
 
Visit http://collaborate.athenpro.org/group/moodle to join the email list.
 
To review past meetings or to see upcoming meetings visit http://collaborate.athenpro.org/group/moodle/teleconferences/
 
 
== Authoring features ==
 
Moodle can be used by users to author content for other users. In some cases, accessibility features have been added to the authoring tools so that the content that is produced is as accessible as possible. An example is the “Atto text editor” which includes an “Accessibility checker” and an “Accessibility helper” which provide additional information for content authors on the accessibility of their content (like checks for sufficient contrast). The equations produced by the MathJax content filter have full accessibility enabled so they can be passed directly to the screen reader as maths content.
 
 
== Coding standards ==
 
All components in Moodle need to be available to use by all users. Accessibility needs to be part of the design of every new feature in Moodle.
 
For simple features with no requirement for an advanced user interface, simple adherence to standard HTML5 does provide an accessible feature. In this case, it is better to use no ARIA than it would be to use it incorrectly ([https://www.w3.org/TR/wai-aria-practices/#no_aria_better_bad_aria W3C no Aria]).
 
Bootstrap and Bootstrap components [https://getbootstrap.com/docs/4.0/getting-started/accessibility/#color-contrast do not support accessibility by default] and all features implemented with Bootstrap need to be checked and enhanced where necessary. The Boost theme contains an “aria” javascript module that does add accessibility to some default Bootstrap features (menus).
 
 
=== Colours ===
 
All text that is presented needs to be displayed in a colour with sufficient contrast to its background colour so that the text is legible for all users. The foreground and background colours should meet the [https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html WCAG requirement for contrast], which varies depending on the size of the text. This can be tested with the [https://wave.webaim.org/ WebAIM Web Accessibility Evaluation Tool].
 
Additionally, colour alone cannot be used to imply meaning. An example of a failure for this would be to display error messages in “red” with no other information to convey that this is an error message.
 
[https://www.w3.org/TR/WCAG21/#use-of-color WCAG use of colour]
 
 
=== Icons ===
 
Icons (Images) can be displayed in a variety of ways, and the correct use of icons will depend on the context in which they are used.
 
[https://www.w3.org/TR/WCAG21/#text-alternatives WCAG requirement for text alternatives]
 
 
==== Solitary Icons ====
 
Icons displayed on their own, as part of a link or as informative content must include accessible text to convey the meaning of the icon. For an image tag, this can be the “alt” attribute for the image tag. It can be valid to include both the “alt” attribute and the “title” attribute (shown when hovering with the mouse) so that all users can access the textual meaning of the icon.
 
 
==== Icons and Text ====
 
When an icon is displayed immediately before or after some text that also describes the meaning of the icon, it is redundant to repeat the same text twice. In this case, it is correct to hide the icon from screen readers by setting the “role” attribute to “presentation” or hiding it with the “aria-hidden” attribute set to “true”.
 
 
==== Multiple icons ====
 
When multiple icons are displayed in a row as links, it is important that each icon is large enough and has sufficient space around it so the icon can be easily clicked with the mouse.
 
The minimum valid size for a link target is 44 by 44 pixels.
 
[https://www.w3.org/TR/WCAG21/#target-size WCAG requirement for target size]
 
 
=== Keyboard Support ===
 
All components should be entirely operable through a keyboard-only interface.
 
[https://www.w3.org/TR/WCAG21/#keyboard-accessible WCAG requirement for keyboard accessibility]
 
Some important things to consider is that all components should be focusable with the keyboard (available in the tab sequence), and should allow the focus to be moved away using only the keyboard.
 
The element that currently has focus should have a visual focus indicator. [https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_focus_discernable_predictable ARIA focus management].
 
In some cases, a single component can contain many smaller components. In order to not pollute the page tab sequence, the parent element can exist in the tab sequence once and should maintain focus within its smaller components with arrow key navigation (roving tabindex or active descendant). [https://www.w3.org/TR/wai-aria-practices-1.1/#kbd_general_within ARIA keyboard navigation inside components].
 
 
=== Forms ===
 
Moodle forms created with the standard forms library are designed to be accessible. Any custom (e.g. javascript) form or custom form elements must also be accessible.
 
 
 
*  All form elements must have a label
*  The form must be able to be completed entirely with the keyboard
*  Invalid entries in the form fields should be indicated with the “aria-invalid” attribute set to “true”
*  Warning messages for invalid form fields should be associated with the invalid field using the “aria-describedby” attribute.
 
[https://www.w3.org/TR/WCAG21/#error-identification WCAG error identification]
 
 
=== Presentation Only ===
 
Any component that contains no information or functionality that is not provided by other components on the page can be considered decorative only. Content that meets this description can be hidden from screen readers using a suitable technique (aria-hidden or presentation role).
 
[https://www.w3.org/TR/WCAG21/#dfn-pure-decoration WCAG pure decoration]
 
 
=== Landmark regions ===
 
The layout of each page of content should be separated into valid regions where each region has a unique label and the correct landmark role. This is typically done in the layout files of the theme.
 
[https://www.w3.org/TR/wai-aria-practices-1.1/#aria_landmark ARIA landmarks]
 
 
=== Page Titles ===
 
All pages should have a unique title that describes the current page.
 
[https://www.w3.org/TR/WCAG21/#page-titled WCAG page titled]
 
 
=== Advanced UX Widgets ===
 
When it is determined that an advanced interface is required (typically one that relies on javascript), a minimum set of principles need to be applied to make sure that the feature “provides equal functionality and information to all people”. Each use case is different, but a minimum set of things to be checked are:
 


== Starting points ==


These are some readable introductions to accessibility that cover; what accessibility is, why it is important, as well as practical advice.
*  Does this component work entirely when accessed only via the keyboard?
* [http://www.w3.org/WAI/intro/accessibility.php Web Accessibility Initiative's ''Introduction to Web Accessibility'']
*   Does this component map to any widget from the [https://www.w3.org/TR/wai-aria-practices-1.1/ ARIA Authoring Practices] document and if so, does it implement all of the “Keyboard Interaction” and “WAI-ARIA Roles, States and Properties” listed for that widget?
* [http://diveintoaccessibility.info/ Mark Pilgrim's ''Dive into Accessibility'']
* [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 mailing list.
== External Resources ==
 


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/)
*   [https://www.w3.org/WAI/standards-guidelines/ W3C Accessibility Standards Overview]
* Europe: Looking for leadership and members
*  [https://www.w3.org/TR/wai-aria-1.1/ Accessible Rich Internet Applications (WAI-ARIA) 1.1]
* Asia Pacific: Looking for leadership and members
*  [https://www.w3.org/TR/wai-aria-practices/ WAI-ARIA Authoring Practices 1.1]
* Latin America: Looking for leadership and members
*   [https://www.w3.org/TR/WCAG21/ Web Content Accessibility Guidelines (WCAG) 2.1]
*   [https://www.w3.org/TR/ATAG20/ Authoring Tool Accessibility Guidelines (ATAG) 2.0]
*   [https://www.w3.org/TR/UAAG20/ User Agent Accessibility Guidelines (UAAG) 2.0]


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


== Moodle-related accessibility coding guidelines ==
== Accessibility Tools ==


; Use CSS, but still use headings, strong and emphasis
Moodle officially supports the following screen reader/browser configurations:
: 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
: 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><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
: 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 [https://developer.mozilla.org/en-US/docs/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role Mozilla Developer Network]


== Web standards, guidelines and legislation ==
*  Microsoft Edge, Jaws 15+ (Latest version recommended)
*  Mozilla Firefox, NVDA 2014.1+ (Latest version recommended)


=== International ===
'''Screen readers''':


* [http://www.w3.org/WAI/ Web Accessibility Initiative]
*   [https://www.nvaccess.org/ NVDA Screen Reader] (Windows)
** [http://www.w3.org/WAI/intro/wcag.php Web Content Accessibility Guidelines (WCAG)]
*   [http://www.freedomscientific.com/ JAWS Screen Reader] (Windows)
** [http://www.w3.org/WAI/intro/wcag20 Web Content Accessibility Guidelines 2.0 (draft)]
*   [http://www.chromevox.com/ Chromevox Screen Reader ] (Linux, Chrome OS, Windows, Mac OS X)
*** An article on the [http://www.alistapart.com/articles/tohellwithwcag2 problems with WCAG2] from A List Apart
*   [https://help.gnome.org/users/orca/stable/ Orca Screen Reader] (Linux)
** [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]
'''Accessibility tools''':


* [http://webaim.org/techniques/forms/controls WebAIM Form Accessibility guidelines]
*   [https://wave.webaim.org/extension/ WebAIM Web Accessibility Evaluation Tool] (Chrome, Firefox)
* [http://webaim.org/techniques/aria/ WebAIM ARIA guidelines]
*  [https://developers.google.com/web/tools/chrome-devtools/accessibility/reference Chrome Accessibility Dev Tools] (Chrome)
*   [http://www.w3.org/WAI/ER/tools/complete W3C Accessibility Tool Listing]


=== USA ===
== International Legislation ==
* [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).
* [https://www.access8878.co.uk/getting-started-with-bs-8878/16-steps.aspx BS 8878:2010 – 16 Steps for an accessible web product]


=== Germany ===
=== USA ===
* [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 ==
*  [http://www.section508.gov/ Section 508]


=== Firefox extensions ===
* [http://firefox.cita.uiuc.edu/ Firefox Accessibility Extension] by the Illinois Center for Information Technology and Web Accessibility (iCITA)
* [[Web developer extension]] for [[Firefox]]
* [[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 ===
=== UK ===
* [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 ===
*   [http://www.legislation.gov.uk/ukpga/2010/15/contents Equality Act 2010]
* [https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en Chrome Accessibility Developer Tooks]
*   [http://www.equalityhumanrights.com/advice-and-guidance/public-sector-equality-duty/ Public sector equality duty]
* [[W3C validation]] (for [[HTML in Moodle]], [[CSS]] and [[RSS]])
*   [http://www.parliament.the-stationery-office.co.uk/pa/ld200001/ldbills/003/2001003.htm SENDA - Special Educational Needs and Disability Act/Bill]
* [http://wave.webaim.org/ Web accessibility evaluation tool]
* [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 ===
* [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].
=== Germany ===


See a [http://www.youtube.com/playlist?list=PLmQqs2jGU8Pr7e-3Fz2PoN6AabEkEBRYX live demonstration of a number of accessibility tools].
[http://www.einfach-fuer-alle.de/artikel/bitv/ Barrierefreie Informationstechnik-Verordnung - BITV]


== Resources ==


* [http://webstandards.org/action/atf/manifesto/ Web Standards.org's ''Accessibility Task Force Manifesto'']
=== France ===
* [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]


== See also ==
*  [https://references.modernisation.gouv.fr/rgaa-accessibilite/ Référentiel Général d’Accessibilité des Administrations - RGAA]


* [[:en:Accessibility|Accessibility statement]] - in current Moodle versions
* [[Semantic HTML]]
* See [[Usability FAQ]] for the related concept of usability.
* 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]


[[Category:Coding guidelines|Accessibility]]
=== European Union ===
[[Category:Accessibility]]


[[es:dev/Accesibilidad]]
[https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2015:0615:FIN European Accessibility Act (Detailed proposal)]
[[fr:Accessibilité]]
[https://ec.europa.eu/social/main.jsp?catId=1202 European Accessibility Act (Informational page)]

Revision as of 22:32, 12 June 2019

Moodle is designed to provide equal functionality and information to all people. This means that there should be no barriers for people regardless of disabilities, assistive technologies that are used, different screen sizes and different input devices (e.g. mouse, keyboard and touchscreen).

Moodle Accessibility Collaboration Group

To improve the accessibility and usability of Moodle, we have established this collaboration group to work together with Moodle developers, accessibility experts, 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.

This group meets once a month to discuss accessibility priorities, typically on the first Monday of each month.

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

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


Authoring features

Moodle can be used by users to author content for other users. In some cases, accessibility features have been added to the authoring tools so that the content that is produced is as accessible as possible. An example is the “Atto text editor” which includes an “Accessibility checker” and an “Accessibility helper” which provide additional information for content authors on the accessibility of their content (like checks for sufficient contrast). The equations produced by the MathJax content filter have full accessibility enabled so they can be passed directly to the screen reader as maths content.


Coding standards

All components in Moodle need to be available to use by all users. Accessibility needs to be part of the design of every new feature in Moodle.

For simple features with no requirement for an advanced user interface, simple adherence to standard HTML5 does provide an accessible feature. In this case, it is better to use no ARIA than it would be to use it incorrectly (W3C no Aria).

Bootstrap and Bootstrap components do not support accessibility by default and all features implemented with Bootstrap need to be checked and enhanced where necessary. The Boost theme contains an “aria” javascript module that does add accessibility to some default Bootstrap features (menus).


Colours

All text that is presented needs to be displayed in a colour with sufficient contrast to its background colour so that the text is legible for all users. The foreground and background colours should meet the WCAG requirement for contrast, which varies depending on the size of the text. This can be tested with the WebAIM Web Accessibility Evaluation Tool.

Additionally, colour alone cannot be used to imply meaning. An example of a failure for this would be to display error messages in “red” with no other information to convey that this is an error message.

WCAG use of colour


Icons

Icons (Images) can be displayed in a variety of ways, and the correct use of icons will depend on the context in which they are used.

WCAG requirement for text alternatives


Solitary Icons

Icons displayed on their own, as part of a link or as informative content must include accessible text to convey the meaning of the icon. For an image tag, this can be the “alt” attribute for the image tag. It can be valid to include both the “alt” attribute and the “title” attribute (shown when hovering with the mouse) so that all users can access the textual meaning of the icon.


Icons and Text

When an icon is displayed immediately before or after some text that also describes the meaning of the icon, it is redundant to repeat the same text twice. In this case, it is correct to hide the icon from screen readers by setting the “role” attribute to “presentation” or hiding it with the “aria-hidden” attribute set to “true”.


Multiple icons

When multiple icons are displayed in a row as links, it is important that each icon is large enough and has sufficient space around it so the icon can be easily clicked with the mouse.

The minimum valid size for a link target is 44 by 44 pixels.

WCAG requirement for target size


Keyboard Support

All components should be entirely operable through a keyboard-only interface.

WCAG requirement for keyboard accessibility

Some important things to consider is that all components should be focusable with the keyboard (available in the tab sequence), and should allow the focus to be moved away using only the keyboard.

The element that currently has focus should have a visual focus indicator. ARIA focus management.

In some cases, a single component can contain many smaller components. In order to not pollute the page tab sequence, the parent element can exist in the tab sequence once and should maintain focus within its smaller components with arrow key navigation (roving tabindex or active descendant). ARIA keyboard navigation inside components.


Forms

Moodle forms created with the standard forms library are designed to be accessible. Any custom (e.g. javascript) form or custom form elements must also be accessible.


  • All form elements must have a label
  • The form must be able to be completed entirely with the keyboard
  • Invalid entries in the form fields should be indicated with the “aria-invalid” attribute set to “true”
  • Warning messages for invalid form fields should be associated with the invalid field using the “aria-describedby” attribute.

WCAG error identification


Presentation Only

Any component that contains no information or functionality that is not provided by other components on the page can be considered decorative only. Content that meets this description can be hidden from screen readers using a suitable technique (aria-hidden or presentation role).

WCAG pure decoration


Landmark regions

The layout of each page of content should be separated into valid regions where each region has a unique label and the correct landmark role. This is typically done in the layout files of the theme.

ARIA landmarks


Page Titles

All pages should have a unique title that describes the current page.

WCAG page titled


Advanced UX Widgets

When it is determined that an advanced interface is required (typically one that relies on javascript), a minimum set of principles need to be applied to make sure that the feature “provides equal functionality and information to all people”. Each use case is different, but a minimum set of things to be checked are:


  • Does this component work entirely when accessed only via the keyboard?
  • Does this component map to any widget from the ARIA Authoring Practices document and if so, does it implement all of the “Keyboard Interaction” and “WAI-ARIA Roles, States and Properties” listed for that widget?


External Resources


Accessibility Tools

Moodle officially supports the following screen reader/browser configurations:

  • Microsoft Edge, Jaws 15+ (Latest version recommended)
  • Mozilla Firefox, NVDA 2014.1+ (Latest version recommended)

Screen readers:

Accessibility tools:

International Legislation

USA


UK


Germany


France


European Union