Outreachy: WCAG 2.2 audit of wagtail.org – Dec 2023 #11305
Replies: 6 comments 3 replies
-
Hi, @albinazs I would like to participate in the Accessibility audit testing. |
Beta Was this translation helpful? Give feedback.
-
Progress to date by @shyusu4:
We’ve decided to skip speech recognition tests for now (unsure which options to use on Windows) |
Beta Was this translation helpful? Give feedback.
-
Just a quick note to say @shyusu4 has completed her wagtail.org accessibility audit, and we’re now switching to fixing of the issues. See for example:
And a first pull request (congrats @shyusu4!): wagtail/wagtail.org#455 |
Beta Was this translation helpful? Give feedback.
-
Sharing @shyusu4’s executive summary for the audit for future reference: WCAG 2.2 Accessibility Audit: Wagtail.orgThis executive summary provides an overview of the purpose, scope, methodology, and findings of the accessibility audit conducted on wagtail.org. The purpose of the audit was to identify any accessibility issues on the website in compliance with Web Content Accessibility Guidelines (WCAG) V2.2 Level AA. ScopeThe audit focused on selected public-facing web pages of the site, including the Home, Features, Roadmap, Services, Blog pages and a sample blog post, "Fix a common Wagtail UX issue in two lines." Pages located on sub-domains were excluded. MethodologyThe site was evaluated using Google Chrome on Windows and Android, and Safari via BrowserStack emulation on Mac and iPhone. The audit methodology incorporated a combination of semi-automated and manual checks to assess accessibility, including Semi-automated checks
Manual checks
Main findingsThe audit has highlighted several key findings, including Discrepancies between screen reader software (TalkBack vs. NVDA and VoiceOver) For instance, in header navigation submenus, links within the toggle menu are being announced by Android TalkBack with "minus" due to the presence of a - element. Android TalkBack also demonstrates multiple instances of variations in announcing elements, particularly links, when compared to other screen readers. This inconsistency may lead to a fragmented user experience for individuals relying on different assistive technologies. The cookie policy modal requires improvement in overall accessibility for screen reader users. There are navigation challenges, since screen reader users typically navigate using headings or links for efficiency, but the modal lacks a heading and relies on non-descriptive link text ("find out more"). Throughout the site, there is a common case of decorative shapes covering text in section heading blocks which hinders readability. ConclusionThe overall state of accessibility on wagtail.org is considered to be in good shape. The majority of problems noted are categorized as minor. Addressing these concerns will ensure the website maintains a high level of accessibility for all users. |
Beta Was this translation helpful? Give feedback.
-
Sharing the audit executive summary by @shyusu4 for future reference: WCAG 2.2 Accessibility Audit: Wagtail.orgThis executive summary provides an overview of the purpose, scope, methodology, and findings of the accessibility audit conducted on wagtail.org. The purpose of the audit was to identify any accessibility issues on the website in compliance with Web Content Accessibility Guidelines (WCAG) V2.2 Level AA. View the full audit findings: Wagtail.org | 2024 accessibility audit spreadsheet ScopeThe audit focused on selected public-facing web pages of the site, including the Home, Features, Roadmap, Services, Blog pages and a sample blog post, "Fix a common Wagtail UX issue in two lines." Pages located on sub-domains were excluded. MethodologyThe site was evaluated using Google Chrome on Windows and Android, and Safari via BrowserStack emulation on Mac and iPhone. The audit methodology incorporated a combination of semi-automated and manual checks to assess accessibility, including Semi-automated checks
Manual checks
Main findingsThe audit has highlighted several key findings, including Discrepancies between screen reader software (TalkBack vs. NVDA and VoiceOver) For instance, in header navigation submenus, links within the toggle menu are being announced by Android TalkBack with "minus" due to the presence of a - element. Android TalkBack also demonstrates multiple instances of variations in announcing elements, particularly links, when compared to other screen readers. This inconsistency may lead to a fragmented user experience for individuals relying on different assistive technologies. The cookie policy modal requires improvement in overall accessibility for screen reader users. There are navigation challenges, since screen reader users typically navigate using headings or links for efficiency, but the modal lacks a heading and relies on non-descriptive link text ("find out more"). Throughout the site, there is a common case of decorative shapes covering text in section heading blocks which hinders readability. StatisticsTotal issues reported: 52 (47 by @shyusu4, 5 by @ShubhamOulkar) Issues reported by testing technique
Issues reported by severity
Issues reported by accessibility guideline
ConclusionThe overall state of accessibility on wagtail.org is considered to be in good shape. The majority of problems noted are categorized as minor. Addressing these concerns will ensure the website maintains a high level of accessibility for all users. |
Beta Was this translation helpful? Give feedback.
-
@shyusu4 is working on a report of her own for the project but in the meantime – here is the project report information we’ve submitted to Outreachy. Summary of the project goals completedPrimary goals:
Secondary goals:
Stretch goals:
Impact the project will have on the open source communityThanks to this project, we have an excellent sense of how accessible our main website is – and a clear path towards fixing all known issues. We’re aware of where there are potential blockers / major issues for us to prioritise, and can use this information to inform future project plans. With all of this work being done in the open, we also have a solid case study of what it looks like to improve the accessibility of a website built with our software, and a good sense of what issues to look out for in other projects. Finally, with Sherry being keen to write a detailed project report and to appear on our community webinar at the end of the project, this will further build up our profile as being an accessibility-focused project. What your intern learned during the internship
|
Beta Was this translation helpful? Give feedback.
-
👋 opening a separate discussion of an upcoming Outreachy project: WCAG audit of wagtail.org. We’re looking for feedback/ suggestions on how we plan the audit, the specifics of the testing, and how we share reports / tackle the issues.
Purpose
Create a backlog of accessibility improvements for wagtail.org
Audit strategy
Target standard
We can start with the most well-established WCAG 2.2 AA-level (Recommendation as of October 2023), and some of AAA-level guidelines (if they seem to be easily solvable), as well as best practice recommendations (such as WHCM, print styles, and readability) as we see fit. We could also attempt to cover a few concepts from draft WCAG 3.0, such as color contrast.
Scope
Ideally, all types of pages on prod + possibly 3rd party forms.
Methodology
Possible options to consider:
Reporting
Could be our standard template
Beta Was this translation helpful? Give feedback.
All reactions