7 April 2023

The new Wagtail accessibility checker is an awesome tool, but you'll still need to actually fix the issues it catches. Here's a quick run-through of what triggers each check.

What the accessibility checker checks

button-name: This check is triggered if there's a button on your page with a <button> tag that has no text label. If you use a cute heart symbol in your button without a text label, someone navigating the page with a screen reader won't know what that heart button actually does.

empty-heading: This rule checks for headings with no text content. Empty headings are confusing to screen reader users and somewhat annoying, so you should try to clean them up.

empty-table-header: Navigating tables with a screen reader or a keyboard is pretty onerous to begin with. Without text in the table header, it will be even harder for those users to determine if going through the table is worth the effort.

frame-title: The <iframe> tag is commonly used for embedding certain types of media or documents within a webpage. Without a text label though, your video or PDF file will be just a chunk of empty space to a user with a screen reader.

heading-order: It's very important for users with accessibility needs that you use headings in a logical order like h1 to h2 to h3. If you jump from h1 to h4 because the h4 heading is the one that uses the pretty purple font you want, you're making the page harder to navigate for people who can't see the pretty font. If you're a content creator and this check keeps popping up, you might want to talk with your designer or developer about updating the heading styles.

input-button-name: When the <input> tag is used to create button elements, there needs to be a text label. Remember from the first rule we discussed that image-only buttons are about as helpful as sunscreen on a cloudy night.

link-name: Providing descriptive labels for your links is pretty helpful to everyone. Links added in the Wagtail Rich Text editor will automatically have a text label. If you add HTML manually to a page though, make sure your <a> link elements have a text label to avoid triggering this check.

p-as-heading: Headings are pretty important signposts for users with accessibility needs, so it's important not to style paragraph tags like heading tags. If this check keeps showing up, then the designer or developer on your team should make some adjustments.

More rules will be added over time. To keep track of them, bookmark the accessibility checker section of the Wagtail documentation.

Have rules you want added to the checker?

Tell us in our accessibility checker discussion

🚨 Security patches available 🚨

Security releases Wagtail 4.1.4 and 4.2.2 are now available. These fix two security defects, both with severity "moderate", along with several other bugfixes. Here are the release notes:

• 4.1.4 release notes
• 4.2.2 release notes

And here are some additional details, including advice on workarounds for older releases in case you're unable to upgrade:

• Stored XSS attack via ModelAdmin views
• Denial-of-service via memory exhaustion when uploading large files

Latest chirps

• Wagtail package downloads data: Package and data nerds will love this Gist from Thibaud Colas that collects the PyPI downloads of Wagtail-related packages over the past seven days
• Using Unpoly with Django: Community member Serafeim has written an extensive follow-up guide on his ongoing experimentation with combining Unpoly and Django
• Building a Django app for finance professionals: US-based Six Feet Up shared a case this week that included a shoutout for Wagtail, especially the snippets feature

Package Updates

• wagtail-autocomplete
• wagtail-sharing
• wagtail-modelchooser
• wagtail-spa-integration
• wagtail_formation
  

Until next time, thank you for reading! If you have a news item to contribute or a package release to report, please reach out to us through our Slack community or email us.

Need help with Wagtail? Find it here.