Version
v6.3
Release Date
2024-11-01
This tool listing was updated on 7 December 2024.
Authoring tool user interface accessibility
Web-based functionality is accessible
partially
Description: Wagtail currently targets WCAG 2.2 AA and ATAG 2.0 AA conformance for the administrative interface of the CMS. Though a lot of progress has been made, there are still known conformance issues. See https://wagtail.org/accessibility/ for reports from past audits, and future audit plans.
Non web-based functionality is accessible
not applicable
Alternative content available to editors
partially
Description: Wagtail provides alternative text for all images within the CMS, but in five prominent cases the programmatically-associated text isn’t the best possible one. All icons have appropriate alt text, and Wagtail has no built-in support for videos.
See https://wagtail.org/accessibility/atag-audit/#a211-text-alternatives-for-rendered-non-text-content for specific occurrences where we are aware improvement is needed.
Editing-view presentation can be programmatically determined
partially
Description: 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.
- Fail: Comments in rich text. Comments are displayed as highlighted text within the rich text field. The association isn’t programmatically exposed.
- 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').
Works with keyboard
partially
Description: Though the majority of the authoring tool’s functionality is keyboard accessible, there are six specific areas that aren’t:
- In rich text fields, pin/unpin of the rich text toolbar.
- In rich text fields, Edit functionality for links, documents, images, embeds.
- In image/document/page/task/snippet choosers, the chooser dialog.
- In page listings, manual sorting of pages.
- In image create/edit forms, creation or editing of a focal area.
- In table blocks, editing of the table.
See https://wagtail.org/accessibility/atag-audit/#a311-keyboard-access-minimum for the full status and proposed changes.
Enough time
partially
Description: Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the default session time limit is 2 weeks.
Flashing content optional
no
Content can be navigated by structure
partially
Description: Markup elements in the content aren’t exposed in the CMS. The only editable programmatic relationships are headings and element nesting in rich text fields, which can be navigated via the keyboard.
Content searchable
partially
Description: 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.
Supports display preferences
yes
Previews are accessible
yes
Helps editor prevent and correct mistakes
partially
Description: 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.
(Accessibility) features documented
partially
Description: All features required to meet ATAG 2.0 Part A are documented.
See https://wagtail.org/accessibility/atag-audit/#a422-document-all-features for a full record of which features are and aren’t documented.
Support for producing accessible content
Generates accessible markup
yes
Preserves accessibility information
yes
Accessible content production is possible
partially
Description: 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.
Editors guided
yes
Text alternatives can be managed
yes
Accessible templates available
partially
Description: 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, though there are alternatives available.
For form fields in the form builder, a wide range of fields have accessibility issues with no alternatives available.
See https://wagtail.org/accessibility/atag-audit/#b241-accessible-template-options-wcag for a full record of accessibility issues in content templates
Accessible components/plug-ins available
not applicable
Checks accessibility automatically
partially
Description: 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
All of Wagtail’s checks are pass/fail and as such require no author input. The checks report on the number of issues detected, but the location of the issues can’t be programmatically determined.
Provides suggestions to content editor about accessibility problems
no
Accessibility features prominent
yes
Documentation promotes accessibility
partially
Description: Wagtail has extensive documentation about accessibility features for developers (https://docs.wagtail.org/en/stable/advanced_topics/accessibility_considerations.html), but is lacking documentation for CMS users.