Making wagtail.org more accessible
Exploring the measures taken to enhance accessibility on Wagtail's public face
Wagtail is actively taking measures to ensure that all websites built with Wagtail CMS prioritize accessibility — part of this effort includes making this website, wagtail.org, accessible for as many people as possible.
To achieve a more accessible wagtail.org, Wagtail proposed an Outreachy project with the goal of identifying and resolving any accessibility issues present on the site. As part of my involvement in this project, I’ve been working on identifying and resolving these issues.
Auditing wagtail.org
To start off, we needed to understand the state of accessibility on the site. First, we did an audit by reviewing how pages on the site perform against established accessibility standards and best practices.
Approach
Wagtail's general approach to web accessibility involves aiming for compliance with the widely accepted web accessibility standard, Web Content Accessibility Guidelines (WCAG). For this audit, we used the latest version, WCAG version 2.2, and conformance level AA. We also made an effort to follow AAA guidelines wherever applicable.
For the audit strategy, we followed the Website Accessibility Conformance Evaluation Methodology (WCAG-EM), which recommends a sample-based approach that focuses on testing key pages rather than every single page of a website.
Adopting this approach was a reasonable decision for us since it saved time and effort. However, if you’re not familiar with WCAG-EM, you may be concerned about potentially missing issues when performing an audit; we took precautions minimize this risk. The representative sample for testing included all page types on wagtail.org, so we were able to address specific functionalities and content types on every page. Specifically, the audit's sample included the Home, Features, Roadmap, Services, and Blog pages, along with a sample blog post.
Testing the site
We chose to use a combination of different types of tools for testing:
Semi-automated tools
- Sa11y
- Google Lighthouse
- Accessibility Insights
Manual tests
- Screen reader testing (NVDA on Windows, VoiceOver on iOS/MacOS, and TalkBack on Android)
- Keyboard navigation checks
- Mobile touch interaction testing with Android Chrome
- Zoom & magnification testing with Chrome full-page zoom, font-size zoom and macOS Zoom
- Color contrast checks for non-text UI elements and images
- Windows high contrast mode
- Print stylesheets
Note that a combination of tests was chosen because automated accessibility tests can only detect a portion of accessibility issues, so human review is still necessary to ensure thorough testing.
The site performed well according to semi-automated tools: Google Lighthouse gave most pages an average accessibility score of 90+ (which increased to 95+ after implementing fixes! 🎉)
In total, I found 47 issues throughout the audit. Most of these issues were based on established practices not covered by WCAG, such as Windows contrast themes, print styles compatibility, and others. For a breakdown of each issue, you can refer to the Wagtail.org Accessibility Audit Spreadsheet.
Findings and Fixes
Here are some issues from the audit I’d like to note:
Headings
It's important to only use headings purposefully to clearly divide pages into sections. Here's an example of a previous implementation on the site that used multiple headings to define sections:
<div> <h2 class="headline__heading"></h2> <h3 class="headline__subheading"></h3> </div>
Here, using an <h3> element as a subheading after an <h2> element can be confusing for screen reader users, since this doesn't define a new subsection within <h2>. Instead, it acts as a subheading for only one section, which results in two headings being read by the screen reader.
To address this issue, I updated the markup to use an <hgroup> element. According to the MDN Web Docs, <hgroup> represents a heading and its related content, which allows you to group a single <h1>-<h6> element with one or more <p> elements. Here’s the updated implementation:
<hgroup> <h2 class="headline__heading"></h2> <p class="headline__subheading"></p> </hgroup>
Windows High Contrast Mode
Windows High Contrast Mode (WHCM, which is also called "contrast themes" on Windows 11) is an accessibility feature that modifies the appearance of a website by overriding the default stylesheet colors of various elements like backgrounds, buttons, and text, based on the user's chosen color scheme.
While SVGs are typically used for decorative purposes, they also play functional roles on most websites, so it's important that they appear consistent across all versions of a site, regardless of whether a site visitor uses WHCM or not. Here's an example of how wagtail.org used to look when using Chrome's built-in light contrast theme emulation:
Can you spot the issue? 👀
There's no visible close icon, which means people may have difficulty closing the search modal. Here's the updated version:
Now, you can clearly identify the close icon.
Print Stylesheets
While it's less common for people to print web pages nowadays, situations come up where it may be useful. For example, someone with vision problems might print a blog post to read it using a traditional magnifying glass, or perhaps someone might simply want to save the post as a PDF file.
To support these needs, I added print styles to the site. This not only helps with maintaining a readable format when a page is printed, but also contributes to reducing environmental impact by minimizing paper usage, which aligns with Wagtail’s mission in reducing the climate impact of Wagtail CMS.
Wagtail and Beyond
Working on this project, I’ve had the opportunity to witness Wagtail's commitment to accessibility. It’s evident to me that the Wagtail team is determined to set a high standard for accessibility best practices online and to raise awareness about accessibility practices for the web in general.
I’d like to thank my mentors Albina Starykova, Scott Cranfill, Ben Morse, and Thibaud Colas for their support and guidance, and I’d also like to extend my thanks to Meagan Voss for welcoming me into the Wagtail community.
Moving forward, I hope to continue maintaining dedication to accessibility and advocating for inclusive web practices.
This Week in Wagtail
A weeklyish newsletter with Wagtail tips, news, and more.
