Accessibility: Difference between revisions
From Mahara Wiki
(Created page with "== Policy == Mahara aims to be usable by as many individuals as possible, including those with disabilities or special needs. To this end, any discrepancies from major accessibi…") |
|||
| (20 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
'''Note:''' For developers, please see [[Developer Area/Accessibility Checklist|Accessibility Checklist]] for guidelines on implementing accessibility. | |||
= | === Goal for accessibility === | ||
The Mahara project team aims for inclusion. All people wanting to work with and access content on a Mahara site, including those with (temporary) disabilities or special needs should be able to do so. | |||
Accessibility considerations are not left for follow-on phases, but are part of the development of new and updated features, making them integral part of the software development life cycle. | |||
=== Summary of web content accessibility in Mahara === | |||
The Mahara project team has been paying closer attention to accessibility since 2013 when it conducted its first comprehensive accessibility review. That resulted in the creation of a backlog of issues that were resolved to improve accessibility in areas where it was lacking to achieve WCAG 2.0 compliance. | |||
Creating accessible web content has been a requirement in many countries for several years. In order to provide international guidelines, the Web Content Accessibility Guidelines ([http://www.w3.org/WAI/intro/wcag20 WCAG]) were created. There are three conformance levels under the WCAG 2.1, the latest edition of the guidelines: A, AA, and AAA. Each level requires conformance with previous levels and includes its own specific guidelines for how websites should be made accessible. For example, the accessibility standards of New Zealand, Australia, European Union, and the USA draw from WCAG 2.1 and require at minimum Level AA conformance. | |||
In order to better understand the status quo of accessibility in Mahara, we tested the software against all three WCAG 2.1 levels. | |||
=== | We grouped Mahara screens into three categories: | ||
=== | * screens for viewing web content, | ||
* screens for creating and editing content, | |||
* administration screens. | |||
However, we can only test built-in screens and the basic structure of portfolio pages as it is up to the portfolio authors to ensure the content they upload, i.e. their contributed content, is accessible. Portfolio authors have tools on hand to support them creating accessible content, e.g. to add alt text, to use appropriate heading levels that take page headings into consideration, to downsize uploaded images automatically for bandwidth considerations, keyboard accessible page layouts etc. | |||
==== Screens for viewing, creating, and editing content ==== | |||
Screens that are accessible to majority of account holders and those that would view the site without an account can be navigated via an interacted with the keyboard and screen readers. We prioritise these areas for the web accessibility for the biggest impact as that is where the overwhelming majority of the interactions would be. | |||
====Administration screens==== | |||
Most of the administration screens are accessible via the keyboard and screen readers. However, since administration is the most complex part of Mahara, there are still some pages that may have issues. We are continuing to work on improving the accessibility and aim to address these issues in future versions. | |||
==== Conclusion ==== | |||
Mahara has a good level of accessibility when it comes to viewing and creating content. We are continuing to test the administration pages in order to make them more accessible. With the right configuration, Mahara can be used by organisations that require compliance with WCAG 2.1 Level AA. | |||
We have identified [https://blueprints.launchpad.net/mahara/+spec/wcag2.1 areas in Mahara that are not yet fully compatible with WCAG 2.1] and are working on fixing these for the best experience possible. Some issues can be mitigated with a workaround while a select few may require major work, e.g. providing captions or transcripts for multimedia content if external services are not used. | |||
=== How you can help === | |||
We welcome testing with a focus on accessibility to identify areas that need more work. If you come across an issue in Mahara that prevents you from accessing content due to an accessibility issue, please report it in our [https://bugs.launchpad.net/mahara the bug tracker] and tag it with 'accessibility.' We will review the report and assign it a priority level. | |||
We invite you to test changes as they become available and welcome the insight of accessibility researchers and people who run into accessibility issues so we can look into them and determine a way forward to resolving them. | |||
If you wish to get involved in fixing these issues, either by providing your development time or by providing funding, please [Mailto:[email protected] get in touch with us]. | |||
Latest revision as of 20:46, 10 Ocak 2023
Note: For developers, please see Accessibility Checklist for guidelines on implementing accessibility.
Goal for accessibility
The Mahara project team aims for inclusion. All people wanting to work with and access content on a Mahara site, including those with (temporary) disabilities or special needs should be able to do so.
Accessibility considerations are not left for follow-on phases, but are part of the development of new and updated features, making them integral part of the software development life cycle.
Summary of web content accessibility in Mahara
The Mahara project team has been paying closer attention to accessibility since 2013 when it conducted its first comprehensive accessibility review. That resulted in the creation of a backlog of issues that were resolved to improve accessibility in areas where it was lacking to achieve WCAG 2.0 compliance.
Creating accessible web content has been a requirement in many countries for several years. In order to provide international guidelines, the Web Content Accessibility Guidelines (WCAG) were created. There are three conformance levels under the WCAG 2.1, the latest edition of the guidelines: A, AA, and AAA. Each level requires conformance with previous levels and includes its own specific guidelines for how websites should be made accessible. For example, the accessibility standards of New Zealand, Australia, European Union, and the USA draw from WCAG 2.1 and require at minimum Level AA conformance.
In order to better understand the status quo of accessibility in Mahara, we tested the software against all three WCAG 2.1 levels.
We grouped Mahara screens into three categories:
- screens for viewing web content,
- screens for creating and editing content,
- administration screens.
However, we can only test built-in screens and the basic structure of portfolio pages as it is up to the portfolio authors to ensure the content they upload, i.e. their contributed content, is accessible. Portfolio authors have tools on hand to support them creating accessible content, e.g. to add alt text, to use appropriate heading levels that take page headings into consideration, to downsize uploaded images automatically for bandwidth considerations, keyboard accessible page layouts etc.
Screens for viewing, creating, and editing content
Screens that are accessible to majority of account holders and those that would view the site without an account can be navigated via an interacted with the keyboard and screen readers. We prioritise these areas for the web accessibility for the biggest impact as that is where the overwhelming majority of the interactions would be.
Administration screens
Most of the administration screens are accessible via the keyboard and screen readers. However, since administration is the most complex part of Mahara, there are still some pages that may have issues. We are continuing to work on improving the accessibility and aim to address these issues in future versions.
Conclusion
Mahara has a good level of accessibility when it comes to viewing and creating content. We are continuing to test the administration pages in order to make them more accessible. With the right configuration, Mahara can be used by organisations that require compliance with WCAG 2.1 Level AA.
We have identified areas in Mahara that are not yet fully compatible with WCAG 2.1 and are working on fixing these for the best experience possible. Some issues can be mitigated with a workaround while a select few may require major work, e.g. providing captions or transcripts for multimedia content if external services are not used.
How you can help
We welcome testing with a focus on accessibility to identify areas that need more work. If you come across an issue in Mahara that prevents you from accessing content due to an accessibility issue, please report it in our the bug tracker and tag it with 'accessibility.' We will review the report and assign it a priority level.
We invite you to test changes as they become available and welcome the insight of accessibility researchers and people who run into accessibility issues so we can look into them and determine a way forward to resolving them.
If you wish to get involved in fixing these issues, either by providing your development time or by providing funding, please get in touch with us.