Version
v5.1.1
Release Date
2023-08-14
This tool listing was updated on 7 November 2023.
Authoring tool user interface accessibility
Web-based functionality is accessible
partially
Description: Wagtail currently targets WCAG 2.1 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.
question-presentation-programmatically-determined: partially
presentation-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').
Editing-view presentation can be programmatically determined
partially
Works with keyboard
partially
Description: Though the majority of the authoring tool’s functionality is keyboard accessible, there are seven specific areas that aren’t:
- In all forms of content with 'draft' support – access to the 'Publish', 'Submit to moderation', 'Request changes', 'Approve and Publish', 'Approve with comment and Publish'.
- 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.
(Accessibility) features documented
partially
Description: The following functionality would be used to meet Part A and needs to be described either in the documentation or in the user interface:
- Image title fields’ usage as alt text
- Page-level keyboard shortcuts
- 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
- Live preview
- Command palette available commands
The following functionality is described in the user interface:
- Restore revisions
- Markdown keyboard commands for rich text
- Command palette trigger
The following functionality is described in the documentation:
- Comment shortcut
- Rich text keyboard shortcuts
The following functionality is provided by the underlying platform:
- Embeds titles as alt text for embedded content
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
partially
Description: 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: Table markup from TableBlock.
In the following scenarios, markup isn’t accessible out of the box:
- Fail: Image markup for images in other content. By default, Wagtail does not make it possible to change the image’s alt text in context, and doesn’t make it possible to mark images as decorative.
- Fail: Table markup from TypedTableBlock. This is lacking the ability to set row or column headers.
Wagtail provides automatic checking for specific accessibility problems but this checking is only performed when authors use the full-screen live preview, and there is no prompt / suggestion to perform this check (or any other).
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 marking images as decorative / setting alt text in context for image chooser fields. See _B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG)_. This could be worked around by only creating images within rich text fields, which is possible but unlikely.- Missing support for table/row headers with TypedTableBlock. This could be worked around by only creating tables with TableBlock, which is possible but unlikely.
- 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
partially
Description: Though Wagtail provides support for editing alt text everywhere images can be added, it doesn’t provide support for marking images as decorative (set to empty alt text), or changing alt text in context.
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 alrenatives available.
For form fields in the form builder, a wide range of fields have accessibility issues with no alternatives available.
There are known issues with:
- Blockquotes in rich text (no cite field)
- Blockquotes in StreamField (no cite field)
- Images in StreamField (no alt text field)
- TypedTableBlock in StreamField (no caption, no column header or row header support)
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.
There are a number of success criteria that do not have automated checks nor instructions for manual checking:
- 1.1.1 Non-text Content (A) – specifically instructions on correct entry of alt text, and marking images as decorative when appropriate
- 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.