Accessibility: Difference between revisions

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.

@@ Line 1: / Line 1: @@
 '''Note:''' For developers, please see [[Developer Area/Accessibility Checklist|Accessibility Checklist]] for guidelines on implementing accessibility.
-== Mahara's goal for accessibility ==
+=== Goal for accessibility ===
-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 accessibility standards, guidelines or legislation shall be logged as defects in [https://bugs.launchpad.net/mahara the bug tracker], and tagged with "accessibility", for inclusion in an appropriate release. We have been working on Mahara's accessibility since version 1.9.
+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.
-== Summary of web content accessibility in Mahara ==
+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.
-Creating accessible web content is a requirement in many countries. 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. The accessibility standards of New Zealand, Australia, Europe and the USA draw from WCAG 2.1 and require at minimum Level AA conformance.
+=== Summary of web content accessibility in Mahara ===
-In order to better understand the status quo of accessibility in Mahara, we tested the software against all three WCAG 2.1 levels.
+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.
-We grouped Mahara's pages into three categories: pages for viewing web content, pages for creating and editing content, and administration pages. However, we can only test built-in pages and the basic structure of portfolio pages as it is up to the users to ensure the content they upload (i.e. the user-generated content) is accessible.
+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.
-===Accessibility features in Mahara===
+In order to better understand the status quo of accessibility in Mahara, we tested the software against all three WCAG 2.1 levels.
-Here are some of the accessibility features in Mahara. These features were first included in Mahara 1.9. They can be found in both pages for creating and editing content and pages for viewing content.
-* Keyboard-accessible controls and elements
-** People who use only the keyboard can now access the dropdown menus in the main navigation.
-** We have also worked on the keyboard accessibility of the controls for creating pages.
-* Descriptive alt text for images: We have provided alt text for images such as those used in pages for viewing content. This is very important for blind users, so that they can understand the overall content of the pages.
-* Properly labelled graphical links and controls
-** Graphical links such as the one for editing the user's profile picture now have alt text. This lets screen reader users know the purpose of the graphical links.
-** Buttons and checkboxes are now labeled. This is especially helpful in complex forms.
-* Use of focus management: In certain pages, focus is moved to the next logical section after the user has activated a specific button or link. This enables users of assistive technology to quickly determine their location on the page and their next step.
-* Text descriptions for screen reader users: The tabs such as the ones in the Profile page now have a textual indicator informing screen reader users about the currently selected tab.
-===Administration Pages===
-Most of the administration pages include the accessibility improvements mentioned above. 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 Mahara's accessibility and we 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.
-For more information on specific issues and their status of investigation, please refer to https://blueprints.launchpad.net/mahara/+spec/accessibility
-We invite people to test changes as they become available and welcome the insight of other accessibility researchers who think there are issues we have not addressed which should be looked into.
-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 via [email protected].
-== Individual jurisdictions ==
-=== New Zealand ===
-[https://www.digital.govt.nz/standards-and-guidance/design-and-ux/accessibility The New Zealand Web Accessibility Standard 1.1] is based on the Web Content Accessibility Guidelines (WCAG) 2.1, the international standard for web accessibility. All public service and non-public service agencies must meet the NZ Government Web Accessibility Standard 1.1.
-=== Australia ===
-According to Australia's [https://www.dta.gov.au/help-and-advice/about-digital-service-standard Digital Service Standard], Australian Government agencies are required to meet the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA. This complies with the Disability Discrimination Act 1992, in which Australian Government agencies are required to ensure that information and services are provided in a non-discriminatory accessible manner. Mahara obtained 2.0 Level AA before December 2014.
-=== European Union ===
-Websites for EU agencies created after January 2010 are expected to comply with WCAG 2.0 Level AA, as stated in the [http://ec.europa.eu/ipg/standards/accessibility/ IPG Web Accessibility rules]. However, existing websites may be gradually improved to this level. We are working to ensure that Mahara remains Level AA conformant.
+We grouped Mahara screens into three categories:
+* screens for viewing web content,
+* screens for creating and editing content,
+* administration screens.
-=== The United Kingdom ===
+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.
-To meet [https://www.gov.uk/service-manual/helping-people-to-use-your-service/making-your-service-accessible-an-introduction#meeting-government-accessibility-requirements government accessibility requirements in the UK], digital services must meet level AA of the Web Content Accessibility Guidelines (WCAG 2.1) as a minimum. The accessibility regulations came into force for public sector bodies on 23 September 2018. Older intranets and extranets (published before 23 September 2019) need to be made accessible when they are updated. Mobile applications need to be accessible by 23 June 2021.
+==== 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====
-=== USA ===
+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.
-[http://section508.gov/ Section 508] of the US Rehabilitation Act is a law which requires the federal government to use accessible web technologies. This legislation is currently being revised and is expected to draw from WCAG 2.0 Level AA when the refresh comes into effect. We will implement any requirements specific to Section 508 when the refresh is made public.
+==== Conclusion ====
-== Other links ==
+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.
-<!-- This section lifted 130923 from Moodle accessibility policy.  If you add references here, please also consider adding them to http://docs.moodle.org/dev/Accessibility -->
-=== International ===
-* [http://www.w3.org/WAI/ Web Accessibility Initiative]
+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.
-** 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]
+=== How you can help ===
-* [http://webaim.org/techniques/forms/controls WebAIM Form Accessibility guidelines]
+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.
-* [http://webaim.org/techniques/aria/ WebAIM ARIA guidelines]
-=== UK ===
+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.
-* [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 ===
+If you wish to get involved in fixing these issues, either by providing your development time or by providing funding, please [Mailto:info@mahara.org get in touch with us].
-* [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.