accessibility

As a representation of the state of Wagtail’s WCAG 2.1 AA conformance, here is a summary of WCAG 2.2 AA and best practice issues across releases, for the page editor UI (tested with Welcome to the Wagtail bakery!):

Version	Total	Color contrast	`nested-interactive`	`aria-valid-attr-value`	`aria-input-field-name`	Links purpose	Empty heading	Heading order	`region`	Landmark unique
6.3	2	0	0	0	2	0	0	0	0	0
6.2	2	0	0	0	2	0	0	0	0	0
6.1	2	0	0	0	2	0	0	0	0	0
6.0	2	0	0	0	2	0	0	0	0	0
5.2	6	2	0	1	2	0	0	0	0	1
5.1	6	2	0	1	2	0	0	0	0	1
5.0	7	2	0	1	2	2	0	0	0	0
4.2	13	8	0	1	2	2	0	0	0	0
4.1	12	7	0	1	2	2	0	0	0	0
4.0	7	1	0	1	2	2	1	0	0	0
3.0	24	16	0	2	2	2	1	1	0	0
2.16	30	16	3	3	2	2	1	1	1	0

Suggested next steps:

More test coverage for automated accessibility tests
More feedback from users of assistive technologies

References:

Most recent major improvement: Enhanced contrast admin theme.
WCAG 2.2 & ATAG 2.0 CMS admin
Living accessibility audit (last update: December 2024)

Full list of 21 currently-documented accessibility issues in GitHub:

There have been 19 issues fixed since the last ATAG 2.0 audit:

A.1.2. (For the authoring tool user interface) Ensure that non-web-based functionality is accessible

See Implementing A.1.2.

A.1.2.1 Accessibility Guidelines

(Level A). See Implementing A.1.2.1.

Not applicable. Wagtail is a web-based CMS.

A.1.2.2 Platform Accessibility Services

(Level A). See Implementing A.1.2.2.

Not applicable. Wagtail is a web-based CMS.

A.2. Editing-views are perceivable

A.2.1. (For the authoring tool user interface) Make alternative content available to authors

See Implementing A.2.1.

A.2.1.1 Text Alternatives for Rendered Non-Text Content

(Level A). See Implementing A.2.1.1.

Fail. For icons within the CMS, all have appropriate alt text. For CMS-managed images, Wagtail renders non-text content in nine scenarios, five of which are related to editing views and would require changes:

Fail: Image upload fields in the image edit/create form. The image’s title displays as a field next to the visuals. The title acts as alt text by default in Wagtail. This is missing a programmatic association between the title or description text, and the image.
- Example: Wagtail 6.3 - Editing image Boston Cream Pie
- Current: The alt text is permanently set to the contents of the Title field on page load.
- Proposed actions:
  - The image could be more clearly associated with the live title and description fields with an aria-labelledby.
  - The description field could have help text to clarify its use as the image’s alt text (at least in the CMS).
Fail: Image chooser fields in forms. The selected image’s title displays next to the visuals. The description acts as alt text by default in Wagtail. This is missing a programmatic association between the title text and image.
- Example: Wagtail 6.3 - Editing Blog Page: Desserts with Benefits, Image field
- Current: Alt text set to alt="", with title displayed after the image.
- Proposed actions:
  - Associate the visible text with the image with aria-labelledby.
  - Switch to the description field as alt text in the CMS.
Fail: Image chooser fields with a custom alt text field next to them. The custom alt text field is not programmatically associated with the image.
- Example (with Caption field): Wagtail 6.3 - Editing Blog Page: Desserts with Benefits, Image block
- Alt text set to alt="", with title displayed after the image, and custom field further down.
- Proposed actions:
  - Implement this pattern in the bakerydemo website, based on the new Wagtail 6.3 ImageBlock.
  - Associate both the title of the image, and the custom field, with aria-labelledby, or a combination of it and aria-describedby.
Fail: Images within rich text fields. Here the image’s title is displayed in a tooltip associated with the image, but there is no programmatic association.
- Example: unavailable
- Proposed actions:
  - Add demo content following this pattern in bakerydemo.
  - Add a programmatic association between tooltip text and image with aria-labelledby.
  - Make sure the image has alt text accessible even when the tooltip is closed.
Fail: Embeds within rich text fields. Here we display the embed’s thumbnail if there is one. The embed’s title is displayed in a tooltip associated with the embed, but there is no programmatic association.
- Example: Wagtail 6.3 - Editing Blog Page: Desserts with Benefits, Paragraph block
- Current: Alt text set to alt="", with no text displayed near the image.
- Proposed actions:
  - Add a programmatic association between tooltip text and image with aria-labelledby.
  - Make sure the thumbnail image has alt text accessible even when the tooltip is closed.

Outside editing views (possibly not part of ATAG requirements), Wagtail renders images in the following scenarios:

Revisions comparison with images. The image’s title is used as alt text. The title should be visible to the user in the UI, but it is not.
- Example: Wagtail 6.3 - Comparing Bread and Circuses
- Current: the image title is used as alt attribute.
- Proposed actions:
  - Add demo content following this pattern in bakerydemo.
  - Display the images’ titles in the UI, with programmatic aria-labelledby associations.
  - Switch to the description field as alt text.
Revisions comparison with images or embeds in rich text: currently unimplemented.
Snippets listings. When there is an image column, its alt text is set but invisible in the UI.
- Example: Wagtail 6.3 – Snippets People
- Current: the image title is used as alt attribute.
- Proposed actions:
  - Display the images’ titles in the UI, with programmatic aria-labelledby associations.
  - Switch to the description field as alt text.
Image gallery. Here we display the title underneath the image as alt text, in a figcaption.
- Example: Wagtail 6.3 – Images
- Current: Alt text set to alt="", but the image is within a figure with the image’s title as figcaption.
- Proposed actions:
  - Associate the text and the image with aria-labelledby.
  - Switch to the description field as alt text.

Recommendation for Wagtail: Consider how best to sign-post the Description field as the image’s alt text in the CMS, and potentially also in the frontend (with clear options to mark images as decorative or define alt text in context).

Reference: RFC 97: Alt Text Capabilities.

A.2.1.2 Alternatives for Rendered Time-Based Media

(Level A). See Implementing A.2.1.2.

Fail. Wagtail’s only time-based media is animated GIFs. Their text alternatives work identically to other images in Wagtail, with the same characteristics listed in SC A.2.1.1.

A.2.2. (For the authoring tool user interface) Ensure that editing-view presentation can be programmatically determined

See Implementing A.2.2.

A.2.2.1 Editing-View Status Indicators

(Level A). See Implementing A.2.2.1.

Fail. Wagtail uses the following status indicators in editing views:

Fail: Comments on fields. Comments are displayed as a “speech bubble” icon next to the field they are associated with. The association isn’t programmatically exposed. Even visually, the presence of a comment can only be identified on hover/focus within the field’s area.
- Example: Editing Home Page: Welcome to the Wagtail bakery!
- Proposed actions:
  - Add a programmatic association between fields and their comment presence indicator
  - Make the comment presence indicator visible at all times, either for all users or users of “prefers contrast” theming.
  - (WCAG issue) Make the comment addition buttons visible at all times in commenting mode.
Fail: Comments in rich text. Comments are displayed as highlighted text within the rich text field. The association isn’t programmatically exposed.
- Example: none available
- Proposed actions:
  - Add demo content following this pattern in bakerydemo.
  - Research how other WYSIWYG interfaces programmatically associate comments with runs of text.
Pass: Character count for rich text fields. The character count is displayed as a number next to the field it is associated with. The association is programmatically exposed with aria-describedby (“Character count: 18/120”).
- Example Editing Recipe page: Southern Cornbread, Preface field
Pass: Concurrent editing notifications. The notification status is associated with a aria-label and tooltip on the status button.
TBC (work in progress): content quality checks within page editor.

Outside editing views (possibly not part of ATAG requirements), Wagtail renders status indicators in the following scenarios:

Accessibility checks in Wagtail userbar. They are currently not programmatically associated with the content they are for.

A.2.2.2 Access to Rendered Text Properties

(Level AA). See Implementing A.2.2.2.

Not applicable. Wagtail doesn’t allow editing of any text properties associated with the content.

A.3. Editing-views are operable

A.3.1. (For the authoring tool user interface) Provide keyboard access to authoring features

See Implementing A.3.1.

A.3.1.1 Keyboard Access (Minimum)

(Level A). See Implementing A.3.1.1.

Fail. Though the majority of the authoring tool’s functionality is keyboard accessible, there are specific areas that aren’t:

In rich text fields, pin/unpin of the rich text toolbar.
- Example: Wagtail 6.3 - Editing Blog Page: Tracking Wild Yeast
- Proposed actions:
  - Research how other WYSIWYG interfaces allow keyboard interactions with all toolbar controls.
In rich text fields, Edit functionality for links, documents, images, embeds.
- Examples:
  - Links: Wagtail 6.3 - Editing Standard page: About
  - Documents: Wagtail 6.3 - Editing Recipe page: Southern Cornbread
  - Images: no example
  - Embeds: Wagtail 6.3 - Editing Blog page: Desserts with Benefits
- Proposed actions:
  - Research how other WYSIWYG interfaces allow keyboard interactions with all toolbar controls.
  - Possibly support selection of all those content types and press “Enter” to move focus to their UI.
  - See Rich text ctrl + K keyboard shortcut should open the link or document tooltip #11627
In image/document/page/task/snippet choosers, the chooser dialog.
- See Making Wagtail Accessible for users with disabilities #4199
- See also Implement focus management for chooser modals #5338
- Examples:
  - Images: Wagtail 6.3 - Editing Bread page: Arepa
  - Snippets: Wagtail 6.3 - Editing Bread page: Arepa
  - Documents: no example
  - Pages: Wagtail 6.3 - Editing workflow Moderator approval
  - Tasks: Wagtail 6.3 - Editing workflow Moderator approval
- Proposed actions:
  - Complete Re-implement chooser modals with new design #9246
In image create/edit forms, creation or editing of a focal area.
- Current: it’s impossible to set a focal area without a mouse.
- Example: Wagtail 6.3 - Editing Boston Cream Pie
- Proposed actions:
  - Add keyboard support with a new implementation
  - Factor in possible requirements for other types of image manipulation.
In table blocks, editing of the table.
- Example: Wagtail 6.3 – Editing Recipe page: Hot Cross Bun

A.3.1.2 No Keyboard Traps

(Level A). See Implementing A.3.1.2.

Pass. There are no known keyboard traps in the administrative interface.

A.3.1.3 Efficient Keyboard Access

(Level AA). See Implementing A.3.1.3.

Pass. The administrative interface provides the following mechanisms to improve keyboard navigation:

A skip link, across all views, to skip the sidebar.
Collapsible sections on long views to avoid having to tab through all of the content.
A mechanism to link to specific collapsible sections, for direct access via bookmarks.
A “Collapse/expand all sections” button on long forms to navigate more easily to a specific section.
The “minimap” skip-menu on long forms to navigate more easily to a specific section.

A.3.1.4 Keyboard Access (Enhanced)

(Level AAA). See Implementing A.3.1.4.

Fail. See A.3.1.1 Keyboard Access. We would expect addressing all aspects listed in A.3.1.1 to also address this criterion.

A.3.1.5 Customize Keyboard Access

(Level AAA). See Implementing A.3.1.5.

Fail. None of Wagtail’s keyboard commands can be customized.

Proposed actions:

Implement a “key map” for Wagtail’s keyboard commands and-or command palette, with a way to upload a new key map as JSON.

A.3.1.6 Present Keyboard Commands

(Level AAA). See Implementing A.3.1.6.

Pass. Across specific areas:

Pass: In rich text fields, Markdown keyboard commands or keyboard shortcuts are displayed within tooltips for specific toolbar buttons.
Pass: In rich text fields, “command palette” commands are displayed in the block chooser, and the command palette trigger is displayed in the fields’ placeholder.
Pass: Wagtail’s other traditional “key combinations” keyboard shortcuts are displayed in the “Keyboard shortcuts” dialog. This includes:
- Save draft
- Preview

Proposed actions:

View possible improvements in Keyboard shortcut documentation for editor in the Wagtail UI #12050
Consider a “Command palette” concept for Wagtail

A.3.2. (For the authoring tool user interface) Provide authors with enough time

See Implementing A.3.2.

A.3.2.1 Auto-Save (Minimum)

(Level A). See Implementing A.3.2.1.

Fail. Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the default session time limit is 2 weeks. See Autosave #24 on the Wagtail roadmap.

A.3.2.2 Timing Adjustable

(Level A). See Implementing A.3.2.2.

Pass. For Wagtail sites, the default session time limit is 2 weeks.

A.3.2.3 Static Input Components

(Level A). See Implementing A.3.2.3.

Pass. There are no moving input components in the CMS.

A.3.2.4 Content Edits Saved (Extended)

(Level AAA). See Implementing A.3.2.4.

Fail. Wagtail doesn’t provide auto-save functionality. See A.3.2.1 Auto-Save (Minimum). We expect the same approach to be followed for both SCs.

A.3.3. (For the authoring tool user interface) Help authors avoid flashing that could cause seizures

See Implementing A.3.3.

A.3.3.1 Static View Option

(Level A). See Implementing A.3.3.1.

Fail. Animated GIFs auto-play when rendered, with no option to pause them.

Proposed actions:

Research accessibility best practices on animated GIFs
Design a new interface for how CMS users interact with animated GIFs
Implement the new interface according to ATAG, WCAG standards, and accessibility best practices.

See Implementing A.3.4.

A.3.4.1 Navigate By Structure

(Level AA). See Implementing A.3.4.1.

Not applicable. Markup elements aren’t exposed in the CMS.

A.3.4.2 Navigate by Programmatic Relationships

(Level AAA). See Implementing A.3.4.2.

Pass. The only editable programmatic relationships are headings and element nesting in rich text fields, which can be navigated via the keyboard.

A.3.5. (For the authoring tool user interface) Provide text search of the content

See Implementing A.3.5.

A.3.5.1 Text Search

(Level AA). See Implementing A.3.5.1.

Fail. Wagtail supports browsers’ built-in text search which meets all criteria, but only allows searching within the currently-active tab of the editing view. For example, for pages, content under the “Promote” tab will only be searchable when this tab is active.

Proposed actions:

Implement hidden=”until-found”.
Research how other content management systems cater for this requirement.
Fix Activating a tab based on the URL hash should also set focus to the corresponding tabpanel #8483

A.3.6. (For the authoring tool user interface) Manage preference settings

See Implementing A.3.6.

A.3.6.1 Independence of Display

(Level A). See Implementing A.3.6.1.

Pass. All of Wagtail’s UI settings can be adjusted without modifying the content.

A.3.6.2 Save Settings

(Level AA). See Implementing A.3.6.2.

Pass. Specific settings are saved differently. The following settings are persistent for a given user profile, across all sessions of said user:

Language
Time zone
Notification settings
Admin interface theme
UI density
Contrast theme

The following settings are persistent for a given browser, across all sessions within said browser:

Sidebar expanded/collapsed
Rich text toolbar pinned/unpinned
Minimap opened/closed
Currently-open side panel

A.3.6.3 Apply Platform Settings

(Level AA). See Implementing A.3.6.3.

Pass. Wagtail’s language, time zone, and theme settings default to respecting platform settings until set to a specific value by the user.

A.3.7. (For the authoring tool user interface) Ensure that previews are at least as accessible as in-market user agents

See Implementing A.3.7.

A.3.7.1 Preview (Minimum)

(Level A). See Implementing A.3.7.1.

Pass. Wagtail’s live preview for pages and snippets and its draft renders within the user’s browser.

A.3.7.2 Preview (Enhanced)

(Level AAA). See Implementing A.3.7.2.

Pass. Wagtail’s live preview for pages and snippets can only display within the user’s browser, but all saved draft content can be previewed in any browser/device the user is logged in.

A.4. Editing-views are understandable

A.4.1. (For the authoring tool user interface) Help authors avoid and correct mistakes

See Implementing A.4.1.

A.4.1.1 Content Changes Reversible (Minimum)

(Level A). See Implementing A.4.1.1.

Fail. Though a large number of authoring actions are reversible, not all are. The following actions are reversible:

Plain text and rich text content editing within specific fields, reversible until the user submits the form.
Editing of page or snippets content supporting revisions, reversible for the whole page/snippet at any later point in the site’s history.

The following actions are not reversible but do require confirmation to proceed:

Permanent deletion of any content which has its own dedicated creation/editing views.
Unpublishing of pages and snippets.
Deletion of comments within page content.

The following actions are not reversible and do not require confirmation to proceed:

StreamField / InlinePanel block-based content editing, reversible only as part of support for content revisions.
- Consider implementing an in-browser undo-redo stack for those interactions.
Image / Document / Page / Task / Snippet / Embed chooser fields, reversible only as part of support for content revisions.
- Consider implementing an in-browser undo-redo stack for those interactions.
Authoring actions on content that does not support revisions such as images, documents, etc.
- Implement either a confirmation step for those actions, or revisions/versioning support.
Reordering of pages within list views
- Implement either a confirmation step for those actions, or revisions/versioning support.

A.4.1.2 Settings Change Confirmation

(Level A). See Implementing A.4.1.2.

Pass. All of Wagtail’s UI settings saved at the browser level can be reversed by the user directly within the UI. All of the settings saved at the user profile level can be set to an “unset” default value.

Recommendation for Wagtail:

Reset all browser-level settings when users intentionally log out (not on session timeouts)
Add a way to “Reset preferences” – reverse all browser-level and user profile settings to their default value within the user’s profile form.

A.4.1.3 Content Changes Reversible (Enhanced)

(Level AAA). See Implementing A.4.1.3.

Pass. Reversible plain text and rich text content changes can be reversed sequentially while the user remains on the page. Content supporting revisions can be restored at any point in the content’s history.

A.4.2. (For the authoring tool user interface) Document the user interface, including all accessibility features

See Implementing A.4.2.

A.4.2.1 Describe Accessibility Features

(Level A). See Implementing A.4.2.1.

Pass. The following functionality would be used to meet Part A and needs to be described either in the documentation or in the user interface:

The following functionality is described in the user interface:

Restore revisions
Command palette trigger
Keyboard shortcuts
- Page-level keyboard shortcuts
- Rich text formatting
- Markdown commands for rich text
- Comment in rich text

The following functionality is described in the documentation:

Images’ alt text management
Skip link
Collapsible sections
Link to specific collapsible sections
Collapse/expand all
Minimap
Session time limit
Editing of headings and elements nesting in rich text fields
Text search
Browser-level UI settings
- Sidebar expanded/collapsed
- Rich text toolbar pinned/unpinned
- Minimap opened/closed
- Currently-open side panel
Profile-level UI settings
- Language
- Time zone
- Notification settings
- Admin interface theme
- Density
- Contrast theme
Live preview
Command palette available commands
Keyboard shortcuts
- Page-level keyboard shortcuts
- Rich text formatting
- Markdown commands for rich text
- Comment in rich text

The following functionality is provided by the underlying platform:

Embeds titles as alt text for embedded content

A.4.2.2 Document All Features

(Level AA). See Implementing A.4.2.2.

Fail. Here is a high-level record of whether given functionality is documented. As a summary:

For 19 high-level functional areas, 9 are partially documented and 4 are fully documented.
For 145 specific features, 52 are documented.

This record does not cover functionality provided by the underlying platform (for example; automated embed creation) or unused by authors.

Functionality	Documented?
Global	Partial
Skip link	Yes
No-JS warning message	No
Sidebar	Yes
Header	No
Messages	No
Relative date	No
Status tag	Yes
Table listing	No
Pagination	No
Dashboard	Yes
Unauthorized access (403)	No
Page not found (404)	No
Accessibility checker	No
Wagtail userbar	No
Pages	Partial
Pages explorer	Yes
Add child page	Yes
Page type usage	Yes
Privacy	Yes
Move pages	No
Copy	Yes
Delete	No
Publish	No
Unpublish	No
View all revisions	Yes
Compare revisions	No
Review revision	Yes
Create	Yes
Edit	Yes
Edit - Promote tab	No
Preview	No
Scheduled publishing	Yes
Explorer - Bulk actions	Yes
Explorer - Bulk move	No
Explorer - Bulk delete	No
Explorer - Bulk publish	No
Explorer - Bulk unpublish	No
Explorer - View child pages	Yes
Explorer - View child pages - Reorder child pages	No
Explorer - View child pages - Sort by column	No
Explorer - Root level	No
Search	Yes
Search - Filtered	No
Images	Partial
View all	No
Search	No
Search - Filtered	No
Edit	Yes
Add an image	No
Add multiple images	No
Delete	No
Image URL generator	No
Bulk actions	Yes
Bulk add tags	No
Bulk add to collection	No
Bulk add delete	No
Documents	Partial
View all	No
Search	No
Search - Filtered	No
Edit	Yes
Add a document	No
Add multiple documents	No
Delete	No
Bulk actions	Yes
Bulk add tags	No
Bulk add to collection	No
Bulk add delete	No
Snippets	Partial
View all types	Yes
View all	No
Search snippets	No
Edit	Yes
Add	No
Delete	No
Bulk delete	No
Publish	No
Unpublish	No
Preview	No
Scheduled publishing	No
View all revisions	No
Compare revisions	No
Review revision	No
Forms	No
View all	No
View submissions	No
Reports	Yes
Locked Pages	Yes
Workflows	Yes
Workflow tasks	Yes
Site history	Yes
Aging pages	Yes
Page types usage	Yes
Workflows	Partial
View all	Yes
Add	No
Usage	No
Edit	Yes
Workflow tasks	Partial
View all	Yes
Add	Yes
Edit	No
Disable	No
Users	Partial
View all	Yes
Search	No
Edit	No
Edit - Edit roles	No
Add	No
Add - Add roles	No
Delete	No
Bulk actions	Yes
Bulk delete	No
Bulk set active state	No
Bulk assign role	No
Groups	No
View all	No
Search	No
Add a group	No
Edit	No
Delete	No
Group users	No
Sites	No
View all	No
Edit	No
Add a site	No
Delete	No
Locales	No
View all	No
Edit	No
Add a locale	No
Delete	No
Collections	Partial
View all	Yes
Edit	No
Add a collection	Yes
Privacy	Yes
Redirects	Yes
View all	Yes
Search	Yes
Import redirects	Yes
Add	Yes
Export Redirects	Yes
Edit	Yes
Delete	Yes
Promoted search	Yes
View all	Yes
Search	Yes
Edit	Yes
Add results	Yes
Delete	Yes
User account	Yes
Account profile	Yes
Account notifications	Yes
Styleguide	No
Styleguide	No
Auth	No
Login	No
Password reset	No
Password reset done	No

B. Support the production of accessible content

B.1. Fully automatic processes produce accessible content

B.1.1. Ensure that automatically-specified content is accessible

See Implementing B.1.1.

B.1.1.1 Content Auto-Generation After Authoring Sessions (WCAG)

(Level A / AA / AAA). See Implementing B.1.1.1.

Pass. Evaluated as: Level AAA. Wagtail doesn’t automatically generate content after authoring sessions. Processes that operate after authoring sessions and could alter the content are scheduled publishing and search index updates, but in both cases any automatically-generated content would already be present during the session.

B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG)

(Level A / AA / AAA). See Implementing B.1.1.2.

Pass. Evaluated as: Level AA. Wagtail automatically generates content in a few scenarios. In the following scenarios, markup is accessible without further work:

Pass: Links markup for links to pages, documents, external URLs, email addresses, phone numbers, and internal anchors within rich text fields.
Pass: Embeds for external resources within rich text fields.
Pass: Embeds for external resources in StreamField.
Pass: Image markup for images in rich text fields. Images are rendered with alt text from an editable field, and a checkbox to mark the image as decorative.
Pass: Image markup for images in StreamField. The Image block is rendered with alt text from an editable field, and a checkbox to mark the image as decorative.
Pass: Table markup from TableBlock.
Pass: Table markup for TypedTableBlock.

Proposed actions:

Consider enforcing all editor accessibility-checks have to pass before publishing content.

B.1.2. Ensure that accessibility information is preserved

See Implementing B.1.2.

B.1.2.1 Restructuring and Recoding Transformations (WCAG)

(Level A / AA / AAA). See Implementing B.1.2.1.

Not applicable. Evaluated as: Level AA. The only transformation present in Wagtail is processing of clipboard paste information in rich text fields to sanitize the content, which preserves accessibility semantics for preserved content, but isn’t considered a content transformation per ATAG.

If it was considered a content transformation – rich paste processing preserves all formatting supported in rich text fields. Heading levels, bullet lists, and image alt text are preserved in particular.

B.1.2.2 Copy-Paste Inside Authoring Tool (WCAG)

(Level A / AA / AAA). See Implementing B.1.2.2.

Pass. Evaluated as: Level AA. Wagtail supports copy-paste of rich text content, which is fully preserved when copy-pasting between fields configured to support the same formatting. Fields configured differently will accordingly have their formatting stripped as needed.

B.1.2.3 Optimizations Preserve Accessibility

(Level A). See Implementing B.1.2.3.

Not applicable. Wagtail doesn’t perform any optimizations that would affect accessibility.

B.1.2.4 Text Alternatives for Non-Text Content are Preserved

(Level A). See Implementing B.1.2.4.

Not applicable. See B.1.2.1 Restructuring and Recoding Transformations (WCAG).

B.2. Authors are supported in producing accessible content

B.2.1. Ensure that accessible content production is possible

See Implementing B.2.1.

B.2.1.1 Accessible Content Possible (WCAG)

(Level A / AA / AAA). See Implementing B.2.1.1.

Fail. Evaluated as: Level AA. Wagtail places extensive restrictions on the production of web content, which all nonetheless allow for the production of accessible content, with the exception of:

Missing support for setting lang attributes within rich text. This could be worked around by using other types of content modeling for multilingual content, which is possible but unlikely.

Proposed actions:

Implement Feature request: Support for declaring language on elements in rich text. #4694

B.2.2. Guide authors to produce accessible content

See Implementing B.2.2.

B.2.2.1 Accessible Option Prominence (WCAG)

(Level A / AA / AAA). See Implementing B.2.2.1.

Pass. Evaluated as: Level AA. Where text styling options are available, they are presented alongside semantic formatting options such as headings. This is for example the case in rich text formatting options.

For StreamField block formats, the order is up to each site implementer to decide on. There are no built-in formats that are automatically included.

B.2.2.2 Setting Accessibility Properties (WCAG)

(Level A / AA / AAA). See Implementing B.2.2.2.

Not applicable. Evaluated as: Level AAA. Wagtail doesn’t support setting web content attribute values. This has been discussed extensively for links, as well as an option to set aria-label, but hasn’t been implemented yet.

See:

B.2.3. Assist authors with managing alternative content for non-text content

See Implementing B.2.3.

B.2.3.1 Alternative Content is Editable (WCAG)

(Level A / AA / AAA). See Implementing B.2.3.1.

Pass. Evaluated as: Level AA. All areas where images can be used support providing alt text. This includes:

Global alt text via the built-in “Description” field.
Contextual alt text within rich text via the “Alt text” field and “Decorative” checkbox.
Contextual alt text in blocks via the “Alt text” field and “Decorative” checkbox.

B.2.3.2 Automating Repair of Text Alternatives

(Level A). See Implementing B.2.3.2.

Pass. Wagtail doesn’t attempt to repair text alternatives. It does use the image’s file name as the default value for the image’s title field when creating a new image, which is used for alt text, but this is part of the upload/editing process (In-Session Repairs) and not an automated process. Said file name is filtered by default to remove the file extension.

B.2.3.3 Save for Reuse

(Level AAA). See Implementing B.2.3.3.

Fail. By default, Wagtail saves each image’s text alternative and reuses it everywhere the image is reused (“Save and Suggest”). It is possible to replace this text alternative with a new one, but it isn’t possible to delete it.

Suggested action: incorporate this requirement into the contextual alt text support.

B.2.4. Assist authors with accessible templates

See Implementing B.2.4.

B.2.4.1 Accessible Template Options (WCAG)

(Level A / AA / AAA). See Implementing B.2.4.1.

Fail. Evaluated as: Level AA. With rich text formatting and StreamField blocks, Wagtail provides templates for basic text content as well as complex formatting like tables. Wagtail also provides templates for form fields within its forms module. Specific templates have accessibility issues.

Rich text formats

Note: Blockquote formatting does not support the optional blockquote cite attribute or <cite> element.

Field block types

Template	Accessibility issues with output
CharBlock	None
TextBlock	None
EmailBlock	None
IntegerBlock	None
FloatBlock	None
DecimalBlock	None
RegexBlock	None
URLBlock	None
BooleanBlock	None
DateBlock	None
TimeBlock	None
DateTimeBlock	None
RichTextBlock	None
RawHTMLBlock	None
BlockQuoteBlock	None
ChoiceBlock	None
MultipleChoiceBlock	None
PageChooserBlock	None
DocumentChooserBlock	None
ImageBlock	None
ImageChooserBlock	None
SnippetChooserBlock	None
EmbedBlock	None
TableBlock	None
TypedTableBlock	None

Note: BlockQuoteBlock does not support the optional blockquote cite attribute or <cite> element.

Structural block types

Structural block types do not render any content and as such have no accessibility issues.

Template	Accessibility issues
StaticBlock	None
StructBlock	None
ListBlock	None
StreamBlock	None

Form builder field types

All form builder fields suffer from the same issue: Error messages aren’t programmatically associated with the field.

Template	Accessibility issues
Single line text	Errors association with fields.
Multi-line text	Errors association with fields.
Email	Errors association with fields.
Number	Errors association with fields.
URL	Errors association with fields.
Checkbox	Errors association with fields.
Checkboxes	Errors association with fields.
Drop down	Errors association with fields.
Multiple select	Errors association with fields.
Radio buttons	Errors association with fields.
Date	Errors association with fields.
Date/time	Errors association with fields.
Hidden field	None

This may be addressed in the future, via improvements in Django. See:

Proposed actions:

Support improvements in Django

B.2.4.2 Identify Template Accessibility

(Level AA). See Implementing B.2.4.2.

Pass. Wagtail’s template selection mechanism is the block chooser (or field chooser for form builder fields). In both cases, there would be no options defined unless configured by site implementers, which can customize block icons or labels / names to indicate accessible block types.

B.2.4.3 Author-Created Templates

(Level AA). See Implementing B.2.4.3.

Not applicable. Wagtail doesn’t allow authors to create custom block templates.

B.2.4.4 Accessible Template Options (Enhanced)

(Level AAA). See Implementing B.2.4.4.

Fail. Some of Wagtail’s template options aren’t accessible. See B.2.4.1 Accessible Template Options.

B.2.5. Assist authors with accessible pre-authored content

See Implementing B.2.5.

B.2.5.1 Accessible Pre-Authored Content Options

(Level AA). See Implementing B.2.5.1.

Not applicable. Wagtail doesn’t provide pre-authored content.

B.2.5.2 Identify Pre-Authored Content Accessibility

(Level AA). See Implementing B.2.5.2.

Not applicable. Wagtail doesn’t provide pre-authored content.

B.3. Authors are supported in improving the accessibility of existing content

B.3.1. Assist authors in checking for accessibility problems

See Implementing B.3.1.

B.3.1.1 Checking Assistance (WCAG)

(Level A / AA / AAA). See Implementing B.3.1.1.

Pass. Evaluated as: Level A. There are a number of formatting / content entry options in the CMS that can lead to accessibility issues. The built-in accessibility checker provides automated tests for a number of possible issues, but not all. Available checks are:

button-name: <button> elements must always have a text label.
empty-heading: This rule checks for headings with no text content. Empty headings are confusing to screen readers users and should be avoided.
empty-table-header: Table header text should not be empty
frame-title: <iframe> elements must always have a text label.
heading-order: This rule checks for incorrect heading order. Headings should be ordered in a logical and consistent manner, with the main heading (h1) followed by subheadings (h2, h3, etc.).
input-button-name: <input> button elements must always have a text label.
link-name: <a> link elements must always have a text label.
p-as-heading: This rule checks for paragraphs that are styled as headings. Paragraphs should not be styled as headings, as they don’t help users who rely on headings to navigate content.
alt-text-quality: A custom rule ensures that image alt texts don’t contain anti-patterns like file extensions and underscores.

There are a number of success criteria that do not have automated checks nor instructions for manual checking:

2.4.4 Link Purpose (In Context) (AA) – instructions and potentially limited automated checks on correct link text (avoid “click here”)
1.4.5 Images of Text (AA) – instructions on avoiding images of text except for scenarios where there is no alternative
2.4.9 Link Purpose (Link Only) (AAA) – see above
1.4.9 Images of Text (No Exception) (AAA) – see above
3.1.5 Reading Level (AAA) – instructions for manual checking or automated checks
2.4.10 Section Headings (AAA) – instructions for manual checking or automated checks
3.3.5 Help (AAA) – instructions for manual checking or automated checks for the form builder

Proposed actions:

Implement more automated checks for WCAG SCs in question. Content quality checkers #11063
Implement a manual check process for WCAG SCs in question. Content quality checkers #11063
Roadmap: Readability checks #50
Content quality API integrations for text quality and image computer vision
Improve options for organizations to embed their own instructions within the CMS, via HelpBlock and help text.

B.3.1.2 Help Authors Decide

(Level A). See Implementing B.3.1.2.

Not applicable. Currently all of Wagtail’s automated checks are pass/fail with no author input required. Discussion on further checks: Content quality checkers #11063

B.3.1.3 Help Authors Locate

(Level A). See Implementing B.3.1.3.

Not applicable. Currently all of Wagtail’s automated checks are pass/fail with no author input required. Those checks do indicate which elements they are flagging. Proposed improvements:

Content quality checkers #11063
Accessibility checker in page editor #10136
Correct identification of Wagtail content so errors are only reported on CMS-managed content

B.3.1.4 Status Report

(Level AA). See Implementing B.3.1.4.

Pass. Wagtail’s accessibility checker reports on the number of detected issues, and upon interaction lists all rules that detected problems and where on the page.

Possible improvements:

Content quality checkers #11063 – making this data available in more readily accessible reports
Consider making the information easily copy-pasteable

B.3.1.5 Programmatic Association of Results

(Level AA). See Implementing B.3.1.5.

Fail. Currently the association isn’t programmatic, due to expected compatibility issues.

Possible resolution: Correct identification of Wagtail content so errors are only reported on CMS-managed content.

B.3.2. Assist authors in repairing accessibility problems

See Implementing B.2.3.

B.3.2.1 Repair Assistance (WCAG)

(Level A / AA / AAA). See Implementing B.3.2.1.

Fail. Evaluated as: Level A. Currently Wagtail’s 9 rules report the presence of a problem but do not suggest specific solutions.

Proposed improvements:

Content quality checkers #11063
Correct identification of Wagtail content so errors are only reported on CMS-managed content

B.4. Authoring tools promote and integrate their accessibility features

B.4.1. Ensure the availability of features that support the production of accessible content

See Implementing B.4.1.

B.4.1.1 Features Active by Default

(Level A). See Implementing B.4.1.1.

Pass. Wagtail’s accessibility checker is on by default and cannot be turned off unless site implementers make CMS customizations in code.

B.4.1.2 Option to Reactivate Features

(Level A). See Implementing B.4.1.2.

Pass. See B.4.1.1 Features Active by Default.

B.4.1.3 Feature Deactivation Warning

(Level AA). See Implementing B.4.1.3.

Pass. See B.4.1.1 Features Active by Default.

B.4.1.4 Feature Prominence

(Level AA). See Implementing B.4.1.4.

Pass. Wagtail currently has no features relating to invalid markup, syntax errors, spelling errors, grammar errors. Possible future changes:

Implement more automated checks for WCAG SCs in question. Content quality checkers #11063
Implement a manual check process for WCAG SCs in question. Content quality checkers #11063
Roadmap: Readability checks #50

B.4.2. Ensure that documentation promotes the production of accessible content

See Implementing B.4.2.

B.4.2.1 Model Practice (WCAG)

(Level A / AA / AAA). See Implementing B.4.2.1.

Fail. Evaluated as: Level AA. Wagtail’s documentation for content authors does not demonstrate accessible authoring practices. The documentation for developers does: Accessibility considerations.

Proposed actions:

Accessibility features documentation #69
Add accessibility criteria to contributor documentation for documentation writing
Review developer documentation for accessibility improvements in examples

B.4.2.2 Feature Instructions

(Level A). See Implementing B.4.2.2.

Pass. Wagtail’s accessibility checker, heading levels, and alt text implementation are documented in the guide for content authors. The documentation for developers also cover this.

Proposed actions:

Create a single page summarizing all accessibility-related information.

B.4.2.3 Tutorial

(Level AAA). See Implementing B.4.2.3.

Fail. Wagtail’s accessibility features doesn’t have a tutorial.

Proposed actions:

Create a written tutorial in addition to how-to material.
Create a video tutorial in addition to the user guide website.

B.4.2.4 Instruction Index

(Level AAA). See Implementing B.4.2.4.

Fail. Wagtail’s documentation for content author does not have such an index. The documentation for developers does.

Proposed actions:

Add an index of accessibility features to the user guide.
Outreachy: Accessibility features documentation