Accessibility Report for Wagtail

About the Evaluation

Tool Name
Wagtail
Website
https://wagtail.org/
Conformance Target
AAA
Report Identifier
Tue Oct 31 2023
Evaluator
Thibaud Colas
Organization
Wagtail

Executive Summary

Wagtail’s first comprehensive ATAG audit, with the goal of driving next year’s roadmap for accessibility. A lot of progress has been made over the years, in particular recently with the addition of an accessibility checker built into the CMS.

High-level results conformance results:

All of the audit was conducted on Static Wagtail 5.1 demo unless indicated otherwise.

The full audit is available at wagtail.org/accessibility/atag-audit/


This audit was conducted as part of Roadmap item #27: WCAG 2.1 AA for Wagtail admin, to inform upcoming roadmap items:

Results

Summary

Reported on 63 of 63 Success Criteria.

All Results

Success Criterion Result Observations
A.1.1.1: Web-Based Accessible (WCAG) (evaluated as Level AA) Failed

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.

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

  • v5.2: 6 issues
  • v5.1: 6 issues
  • v5.0: 7 issues
  • v4.2: 13 issues
  • v4.1: 12 issues
  • v4.0: 7 issues
  • v3.0: 24 issues
  • v2.16: 30 issues

For a full tabular view of types of issues per release, see A.1.1.1 Web-Based Accessible (WCAG) - Wagtail ATAG 2.0 report

Suggested next steps:

References:

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

A.1.2.1: Accessibility Guidelines (Level A) Not applicable

Wagtail is a web-based CMS.

A.1.2.2: Platform Accessibility Services (Level A) Not applicable

Wagtail is a web-based CMS.

A.2.1.1: Text Alternatives for Rendered Non-Text Content (Level A) Failed

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 text and image.
    • Example: Wagtail 5.1 - 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 field with an aria-labelledby.
      • The title field could have help text to clarify its use as the image’s alt text (at least in the CMS).
      • Take CMS users into account in RFC 51: Contextual alt text
      • Research alt text requirements for CMS users with disabilities with ATAG experts.
  • Fail: Image chooser fields in forms. The selected image’s title displays next to the visuals. The title acts as alt text by default in Wagtail. This is missing a programmatic association between the title text and image.
  • 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 5.1 - 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.
      • Take CMS users into account in RFC 51: Contextual alt text
      • Associate both the title of the image, and the custom field, with aria-labelledby, or a combination of it and aria-describedby.
      • Research alt text requirements for CMS users with disabilities with ATAG experts.
  • 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.

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 5.1 - 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.
  • 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 5.1 – 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.
  • Image gallery. Here we display the title underneath the image as alt text, in a figcaption.
    • Example: Wagtail 5.1 – 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.

Recommendation for Wagtail: Consider whether to sign-post the Title field as the image’s alt text in the CMS, or add another mandatory "default alt text" to the image model, which can be used as alt text whenever images are rendered 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 51: Contextual alt text

A.2.1.2: Alternatives for Rendered Time-Based Media (Level A) Failed

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.1: Editing-View Status Indicators (Level A) Failed

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.
      • (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").
  • 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) Not applicable

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

A.3.1.1: Keyboard Access (Minimum) (Level A) Failed

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

A.3.1.2: No Keyboard Traps (Level A) Passed

There are no known keyboard traps in the administrative interface.

A.3.1.3: Efficient Keyboard Access (Level AA) Passed

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) Failed

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) Failed

None of Wagtail’s keyboard commands can be customized.

Proposed actions:

  • Document all keyboard commands (SC A.3.1.6 Present Keyboard Commands)
  • 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) Failed

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.
  • Fail: Wagtail’s other traditional "key combinations" keyboard shortcuts are not displayed in the UI. This includes:
    • Commenting
    • Save draft
    • Preview

Proposed actions:

A.3.2.1: Auto-Save (minimum) (Level A) Failed

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) Passed

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

A.3.2.3: Static Input Components (Level A) Passed

There are no moving input components in the CMS.

A.3.2.4: Content Edits Saved (Extended) (Level AAA) Failed

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.1: Static View Option (Level A) Failed

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.
A.3.4.1: Navigate by structure (Level AA) Not applicable

Markup elements aren’t exposed in the CMS.

A.3.4.2: Navigate by Programmatic Relationships (Level AAA) Passed

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

A.3.5.1: Text Search (Level AA) Failed

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:

A.3.6.1: Independence of Display (Level A) Passed

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

A.3.6.2: Save Settings (Level AA) Passed

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

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) Passed

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.1: Preview (Minimum) (Level A) Passed

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) Passed

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.1.1: Content Changes Reversible (Minimum) (Level A) Failed

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.
A.4.1.2: Settings Change Confirmation (Level A) Passed

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) Passed

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.1: Describe Accessibility Features (Level A) Failed

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
A.4.2.2: Document All Features (Level AA) Failed

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

  • For 19 high-level functional areas, 11 are partially documented and one is fully documented.
  • For 141 specific features, 38 are documented.

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

For a full record of documentation status across 160 features divided in 19 functional areas, see A.4.2.2 Document All Features - Wagtail ATAG 2.0 report.

B.1.1.1: Content Auto-Generation After Authoring Sessions (WCAG) (evaluated as Level AAA) Passed

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) (evaluated as Level AA) Failed

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:

Wagtail provides automatic checking for specific accessibility problems but this checking is only performed when authors use thae full-screen live preview, and there is no prompt / suggestion to perform this check (or any other). See Accessibility checker in page editor #10136.

Proposed actions:

B.1.2.1: Restructuring and Recoding Transformations (evaluated as Level AA) Not applicable

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) (evaluated as Level AA) Passed

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) 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) Not applicable

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

B.2.1.1: Ensure that accessible content production is possible. (evaluated as Level AA) Failed

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. Example: Wagtail 5.1 - Editing Blog page Bread and Ciruses.
  • Missing support for table/row headers with TypedTableBlock. This could be worked around by only creating tables with TableBlock, which is possible but unlikely. Example: Wagtail 5.1 - Editing Recipe page Hot Cross Bun.
  • Missing support for setting lang attributes within rich text.

Proposed actions:

B.2.2.1: Accessible Option Prominence (WCAG) (evaluated as Level AA) Passed

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) (evaluated as Level AA) Not applicable

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.1: Alternative Content is Editable (WCAG) (evaluated as Level AA) Failed

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. See RFC 51: Contextual alt text.

B.2.3.2: Automating Repair of Text Alternatives (Level A) Passed

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) Failed

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 RFC 51: Contextual alt text.

B.2.4.1: Accessible Template Options (WCAG) (evaluated as Level AA) Failed

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.

  • For rich text formats:
    • blockquote is missing a cite attribute or a cite element within.
  • For Field block types:
    • BlockQuoteBlock: No support for cite attribute or a <cite> element within.
    • ImageChooserBlock: No support for alt text in context or marking as decorative.
    • TypedTableBlock: No caption support. Header cells hard-coded to first row. No option to set row headers.
  • For Structural block types: all 4 have no issues
  • For form builder field types: all except "Hidden field" have issues with programmatic errors and help text.

Form builder field type issues may be addressed in the future, via improvements in Django. See:

Proposed actions:

For a full tabular view of all template options’ status, see B.2.4. Assist authors with accessible templates - Wagtail ATAG 2.0 report.

B.2.4.2: Identify Template Accessibility (Level AA) Passed

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) Failed

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

B.2.4.4: Accessible Template Options (Enhanced) (Level AAA) Failed

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

B.2.5.1: Accessible Pre-Authored Content Options (Level AA) Not applicable

Wagtail doesn’t provide pre-authored content.

B.2.5.2: Identify Pre-Authored Content Accessibility (Level AA) Not applicable

Wagtail doesn’t provide pre-authored content.

B.3.1.1: Checking Assistance (WCAG) (evaluated as Level AAA) Failed

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

Proposed actions:

B.3.1.2: Help Authors Decide (Level A) 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) 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:

B.3.1.4: Status Report (Level AA) Passed

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:

B.3.1.5: Programmatic Association of Results (Level AA) Failed

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.1: Repair Assistance (WCAG (evaluated as Level AA) Failed

Currently Wagtail’s 8 rules report the presence of a problem but do not suggest specific solutions.

Proposed improvements:

B.4.1.1: Features Active by Default (Level A) Passed

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) Passed

See B.4.1.1 Features Active by Default.

B.4.1.3: Feature Deactivation Warning (Level AA) Passed

See B.4.1.1 Features Active by Default.

B.4.1.4: Feature Prominence (Level AA) Passed

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

B.4.2.1: Model Practice (WCAG) (evaluated as Level AA) Passed

Wagtail’s documentation for content authors does not demonstrate accessible authoring practices. The documentation for developers does: Accessibility considerations.

Proposed actions:

B.4.2.2: Feature Instructions (Level A) Failed

Wagtail’s accessibility checker and alt text setting aren’t documented in the guide for content authors. The documentation for developers does cover this.

Proposed actions:

B.4.2.3: Tutorial (Level AAA) Failed

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) Failed

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

Proposed actions:

Created with ATAG Report Tool version 0.6.0