thibaudcolas/README.md

## README.md

      
    Raw
  

              README.md
            
          
    2023 ATAG 2.0 audit of Wagtail


For the full audit, see wagtail.org/accessibility/atag-audit/.
For the audit’s report history and discussions, see RFC 89 - ATAG 2.0 audit
For the audit as per the W3C ATAG Report Tool, see the JSON export and HTML export. See the rendered Report Tool HTML
For the Authoring Tools List entry, see the submitted data as FormData JSON, multipart/form-data plain-text, submission preview HTML.


## report.html
<!doctype HTML><html><head><title>Accessibility Report</title><meta charset="utf-8"></head><body><style>table,
    td,
    th {
      border-color: #3b3b3b;
    }
    td:not(:last-child),
    th {
      padding: 1em;
      vertical-align: top;
      text-align: left;
    }
    td:not([class]):last-child {
      padding: 0 1em;
    }</style> <h1>Accessibility Report for Wagtail</h1> <div tabindex="-1"><h2>About the Evaluation</h2> <dl><dt>Tool Name</dt><dd>Wagtail</dd><dt>Website</dt><dd>https://wagtail.org/</dd><dt>Conformance Target</dt><dd>AAA </dd><dt>Report Identifier</dt><dd>Tue Oct 31 2023</dd><dt>Evaluator</dt><dd>Thibaud Colas</dd><dt>Organization</dt><dd>Wagtail</dd></dl> </div> <div tabindex="-1"><h2>Executive Summary</h2> <p>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.</p>
<p>High-level results conformance results:</p>
<ul>
<li>Part A: 12 <strong>Pass</strong>, 15 <strong>Fail</strong>, 4 <strong>Not applicable</strong>.</li>
<li>Part B: 10 <strong>Pass</strong>, 13 <strong>Fail</strong>, 8 <strong>Not applicable</strong>.</li>
<li>Total: 22 <strong>Pass</strong>, 28 <strong>Fail</strong>, 12 <strong>Not applicable</strong>.</li>
</ul>
<p>All of the audit was conducted on <a href="https://static-wagtail-v5-1.netlify.app/admin/">Static Wagtail 5.1 demo</a> unless indicated otherwise.</p>
<p>The full audit is available at <a href="https://wagtail.org/accessibility/atag-audit/">wagtail.org/accessibility/atag-audit/</a></p>
<hr>
<p>This audit was conducted as part of Roadmap item <a href="https://github.com/wagtail/roadmap/issues/27">#27: WCAG 2.1 AA for Wagtail admin</a>, to inform upcoming roadmap items:</p>
<ul>
<li><a href="https://github.com/wagtail/roadmap/issues/63">WCAG 2.2 manual audit #63</a></li>
<li><a href="https://github.com/wagtail/roadmap/issues/66">Accessibility checker in page editor #66</a></li>
<li><a href="https://github.com/wagtail/roadmap/issues/69">Accessibility features documentation #69</a></li>
<li><a href="https://github.com/wagtail/roadmap/issues/71">Admin accessibility improvements #71</a></li>
</ul>
 <p></p></div> <h2>Results</h2> <h3>Summary</h3> <p>Reported on
  <strong>63</strong>
  of
  <strong>63</strong>
  Success Criteria.</p> <ul><li>23 Passed</li><li>28 Failed</li><li>0 Cannot tell</li><li>12 Not applicable</li> <li>0 Not Checked</li></ul> <h3>All Results</h3> <table border="1" style="border-collapse: collapse"><thead><tr><th>Success Criterion</th>
      <th>Result</th>
      <th>Observations</th>
      </tr></thead> <tbody><tr><td>A.1.1.1: Web-Based Accessible (WCAG) (evaluated as Level AA)</td> <td> Failed</td> <td> <p>Wagtail <a href="https://wagtail.org/accessibility/">currently targets WCAG 2.1 AA conformance</a> for the administrative interface of the CMS. Though a lot of progress has been made, there are still <a href="https://github.com/orgs/wagtail/projects/9/views/1">known conformance issues</a>.</p>
<p>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 <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/60/edit/">Welcome to the Wagtail bakery!</a>):</p>
<ul>
<li>v5.2: 6 issues</li>
<li>v5.1: 6 issues</li>
<li>v5.0: 7 issues</li>
<li>v4.2: 13 issues</li>
<li>v4.1: 12 issues</li>
<li>v4.0: 7 issues</li>
<li>v3.0: 24 issues</li>
<li>v2.16: 30 issues</li>
</ul>
<p>For a full tabular view of types of issues per release, see <a href="https://wagtail.org/accessibility/atag-audit/#a111-web-based-accessible-wcag">A.1.1.1 Web-Based Accessible (WCAG) - Wagtail ATAG 2.0 report</a></p>
<p>Suggested next steps:</p>
<ul>
<li><a href="https://github.com/wagtail/roadmap/issues/63">WCAG 2.2 manual audit #63</a></li>
<li>Interviews with users of assistive technologies</li>
</ul>
<p>References:</p>
<ul>
<li>Largest outstanding issue: <a href="https://github.com/wagtail/wagtail/issues/4199">Making Wagtail Accessible for users with disabilities #4199</a></li>
<li>Most recent major improvement: <a href="https://docs.wagtail.org/en/stable/releases/4.0.html#windows-high-contrast-mode-support-improvements">Support for WHCM / Contrast themes</a>.</li>
<li><a href="https://docs.google.com/spreadsheets/d/1l7tnpEyJiC5BWE_JX0XCkknyrjxYA5T2aee5JgPnmi4/edit">Living accessibility audit (last update: 2021)</a></li>
</ul>
<p>Full list of 24 currently-documented accessibility issues in GitHub:</p>
<ul>
<li><a href="https://github.com/wagtail/wagtail/issues/10228">Radio inputs do not correctly get associated with their parent (group) label for accessibility #10228</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/10875">Chooser buttons focus colour is too dark in dark mode #10875</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/8056">Replace date &amp; date time picker widget with native browser date pickers #8056</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/10576">Revamp revision comparison diff styles #10576</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/8834">Contrast themes – Info side panel’s button links need a border #8834</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/10300">Missing HTML widget attributes in StreamField widget rendering #10300</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/9666">Barriers for speech recognition users #9666</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/10674">Accessibility regression in userbar #10674</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/7366">Page editing actions dropdown doesn’t support keyboard or screen reader navigation #7366</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/10076">Enhancement to Progress button behaviour #10076</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/8483">Activating a tab based on the URL hash should also set focus to the corresponding tabpanel #8483</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/5408">Page chooser should use buttons instead of links with invalid targets #5408</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/10135">Keyboard support improvements in accessibility checker #10135</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/5989">Feature request: Switch TableBlock’s header controls to a field that requires user input #5989</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/5338">Implement focus management for chooser modals #5338</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/7646">Accessibility and UI issues with typed table block #7646</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/8893">TableBlock is impossible to reach with the keyboard #8893</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/5370">"Unpublished" styles in pages listings are very hard / impossible to see #5370</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/5778">Status tag contrast is too low #5778</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/8507">Add table caption option as part of TypedTableBlock for accessibility #8507</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/5411">Rework the admin UI’s landmark based on established best practices #5411</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/7693">Keyboard navigation breaks with links in paragraph in Chrome on MacOS #7693</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/5325">Datetimepicker UI component is not accessible to screen-reader and keyboard users #5325</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/4199">Making Wagtail Accessible for users with disabilities #4199</a></li>
</ul>
</td> </tr><tr><td>A.1.2.1: Accessibility Guidelines (Level A)</td> <td> Not applicable</td> <td> <p>Wagtail is a web-based CMS.</p>
</td> </tr><tr><td>A.1.2.2: Platform Accessibility Services (Level A)</td> <td> Not applicable</td> <td> <p>Wagtail is a web-based CMS.</p>
</td> </tr><tr><td>A.2.1.1: Text Alternatives for Rendered Non-Text Content (Level A)</td> <td> Failed</td> <td> <p>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:</p>
<ul>
<li>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.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/images/43/">Wagtail 5.1 - Editing image Boston Cream Pie</a></li>
<li>Current: The alt text is permanently set to the contents of the Title field on page load.</li>
<li>Proposed actions:<ul>
<li>The image could be more clearly associated with the live title field with an <code>aria-labelledby</code>.</li>
<li>The title field could have help text to clarify its use as the image’s alt text (at least in the CMS).</li>
<li>Take CMS users into account in <a href="https://github.com/wagtail/rfcs/pull/51">RFC 51: Contextual alt text</a></li>
<li>Research alt text requirements for CMS users with disabilities with ATAG experts.</li>
</ul>
</li>
</ul>
</li>
<li>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.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/77/edit/#panel-child-content-image-section">Wagtail 5.1 - Editing Blog Page: Desserts with Benefits, Image field</a></li>
<li>Current: Alt text set to <code>alt=""</code>, with title displayed after the image.</li>
<li>Proposed actions:<ul>
<li>Associate the visible text with the image with <code>aria-labelledby</code>.</li>
</ul>
</li>
</ul>
</li>
<li>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.<ul>
<li>Example (with Caption field): <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/77/edit/#block-556e76b0-0f5a-42bb-b039-653f3d6b1f0b-section">Wagtail 5.1 - Editing Blog Page: Desserts with Benefits, Image block</a></li>
<li>Alt text set to <code>alt=""</code>, with title displayed after the image, and custom field further down.</li>
<li>Proposed actions:<ul>
<li>Implement this pattern in the bakerydemo website.</li>
<li>Take CMS users into account in <a href="https://github.com/wagtail/rfcs/pull/51">RFC 51: Contextual alt text</a></li>
<li>Associate both the title of the image, and the custom field, with <code>aria-labelledby</code>, or a combination of it and <code>aria-describedby</code>.</li>
<li>Research alt text requirements for CMS users with disabilities with ATAG experts.</li>
</ul>
</li>
</ul>
</li>
<li>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.<ul>
<li>Example: unavailable</li>
<li>Proposed actions:<ul>
<li>Add demo content following this pattern in bakerydemo.</li>
<li>Add a programmatic association between tooltip text and image with <code>aria-labelledby</code>.</li>
<li>Make sure the image has alt text accessible even when the tooltip is closed.</li>
</ul>
</li>
</ul>
</li>
<li>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.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/77/edit/#block-ac48af95-b3be-4602-8c2f-5c43fc080f17-section">Wagtail 5.1 - Editing Blog Page: Desserts with Benefits, Paragraph block</a></li>
<li>Current: Alt text set to <code>alt=""</code>, with no text displayed near the image.</li>
<li>Proposed actions:<ul>
<li>Add a programmatic association between tooltip text and image with <code>aria-labelledby</code>.</li>
<li>Make sure the thumbnail image has alt text accessible even when the tooltip is closed.</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>Outside editing views (possibly not part of ATAG requirements), Wagtail renders images in the following scenarios:</p>
<ul>
<li>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.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/68/revisions/compare/46...108/">Wagtail 5.1 - Comparing Bread and Circuses</a></li>
<li>Current: the image title is used as <code>alt</code> attribute.</li>
<li>Proposed actions:<ul>
<li>Add demo content following this pattern in bakerydemo.</li>
<li>Display the images’ titles in the UI, with programmatic <code>aria-labelledby</code> associations.</li>
</ul>
</li>
</ul>
</li>
<li>Revisions comparison with images or embeds in rich text: currently unimplemented.</li>
<li>Snippets listings. When there is an image column, its alt text is set but invisible in the UI.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/snippets/base/person/">Wagtail 5.1 – Snippets People</a></li>
<li>Current: the image title is used as <code>alt</code> attribute.</li>
<li>Proposed actions:<ul>
<li>Display the images’ titles in the UI, with programmatic <code>aria-labelledby</code> associations.</li>
</ul>
</li>
</ul>
</li>
<li>Image gallery. Here we display the title underneath the image as alt text, in a <code>figcaption</code>.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/images/">Wagtail 5.1 – Images</a></li>
<li>Current: Alt text set to <code>alt=""</code>, but the image is within a <code>figure</code> with the image’s title as <code>figcaption</code>.</li>
<li>Proposed actions:<ul>
<li>Associate the text and the image with <code>aria-labelledby</code>.</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>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 <em>in the CMS</em>, and potentially also in the frontend (with clear options to mark images as decorative or define alt text in context).</p>
<p>Reference: <a href="https://github.com/wagtail/rfcs/pull/51">RFC 51: Contextual alt text</a></p>
</td> </tr><tr><td>A.2.1.2: Alternatives for Rendered Time-Based Media (Level A)</td> <td> Failed</td> <td> <p>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.</p>
</td> </tr><tr><td>A.2.2.1: Editing-View Status Indicators (Level A)</td> <td> Failed</td> <td> <p>Wagtail uses the following status indicators in editing views:</p>
<ul>
<li>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.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/60/edit/">Editing Home Page: Welcome to the Wagtail bakery!</a></li>
<li>Proposed actions:<ul>
<li>Add a programmatic association between fields and their comment presence indicator</li>
<li>Make the comment presence indicator visible at all times.</li>
<li>(WCAG issue) Make the comment addition buttons visible at all times in commenting mode.</li>
</ul>
</li>
</ul>
</li>
<li>Fail: Comments in rich text. Comments are displayed as highlighted text within the rich text field. The association isn’t programmatically exposed.<ul>
<li>Example: none available</li>
<li>Proposed actions:<ul>
<li>Add demo content following this pattern in bakerydemo.</li>
<li>Research how other WYSIWYG interfaces programmatically associate comments with runs of text.</li>
</ul>
</li>
</ul>
</li>
<li>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 <code>aria-describedby</code> ("Character count: 18/120").<ul>
<li>Example <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/82/edit/#panel-child-content-preface-section">Editing Recipe page: Southern Cornbread, Preface field</a></li>
</ul>
</li>
<li>TBC (work in progress): content quality checks within page editor.</li>
</ul>
<p>Outside editing views (possibly not part of ATAG requirements), Wagtail renders status indicators in the following scenarios:</p>
<ul>
<li>Accessibility checks in Wagtail userbar. They are currently not programmatically associated with the content they are for.</li>
</ul>
</td> </tr><tr><td>A.2.2.2: Access to Rendered Text Properties (Level AA)</td> <td> Not applicable</td> <td> <p>Wagtail doesn’t allow editing of any text properties associated with the content.</p>
</td> </tr><tr><td>A.3.1.1: Keyboard Access (Minimum) (Level A)</td> <td> Failed</td> <td> <p>Though the majority of the authoring tool’s functionality is keyboard accessible, there are specific areas that aren’t:</p>
<ul>
<li>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".<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/styleguide/#dropdowns-section">Wagtail 5.1 - Styleguide: Dropdown buttons</a></li>
<li>See <a href="https://github.com/wagtail/wagtail/issues/7366">Page editing actions dropdown doesn’t support keyboard or screen reader navigation #7366</a></li>
<li>Proposed actions:<ul>
<li>Will be fixed as part of <a href="https://github.com/wagtail/wagtail/issues/9030">Re-implement footer actions according to new designs #9030</a></li>
</ul>
</li>
</ul>
</li>
<li>In rich text fields, pin/unpin of the rich text toolbar.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/62/edit/">Wagtail 5.1 - Editing Blog Page: Tracking Wild Yeast</a></li>
<li>Proposed actions:<ul>
<li>Research how other WYSIWYG interfaces allow keyboard interactions with all toolbar controls.</li>
</ul>
</li>
</ul>
</li>
<li>In rich text fields, Edit functionality for links, documents, images, embeds.<ul>
<li>Examples:<ul>
<li>Links: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/76/edit/#panel-child-content-body-section">Wagtail 5.1 - Editing Standard page: About</a></li>
<li>Documents: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/82/edit/#block-910c5024-a47a-45b1-a3a3-8f8bb5a8fa70-section">Wagtail 5.1 - Editing Recipe page: Southern Cornbread</a></li>
<li>Images: no example</li>
<li>Embeds: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/77/edit/">Wagtail 5.1 - Editing Blog page: Desserts with Benefits</a></li>
</ul>
</li>
<li>Proposed actions:<ul>
<li>Research how other WYSIWYG interfaces allow keyboard interactions with all toolbar controls.</li>
<li>Possibly support selection of all those content types and press "Enter" to move focus to their UI.</li>
</ul>
</li>
</ul>
</li>
<li>In image/document/page/task/snippet choosers, the chooser dialog.<ul>
<li>See <a href="https://github.com/wagtail/wagtail/issues/4199">Making Wagtail Accessible for users with disabilities #4199</a></li>
<li>See also <a href="https://github.com/wagtail/wagtail/issues/5338">Implement focus management for chooser modals #5338</a></li>
<li>Examples:<ul>
<li>Images: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/37/edit/#panel-child-content-image-section">Wagtail 5.1 - Editing Bread page: Arepa</a></li>
<li>Snippets: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/37/edit/#panel-child-content-origin-section">Wagtail 5.1 - Editing Bread page: Arepa</a></li>
<li>Documents: no example</li>
<li>Pages: <a href="https://static-wagtail-v5-1.netlify.app/admin/workflows/edit/1/#workflow-pages-section">Wagtail 5.1 - Editing workflow Moderator approval</a></li>
<li>Tasks: <a href="https://static-wagtail-v5-1.netlify.app/admin/workflows/edit/1/#inline_child_workflow_tasks-0-panel-section">Wagtail 5.1 - Editing workflow Moderator approval</a></li>
</ul>
</li>
<li>Proposed actions:<ul>
<li>Complete <a href="https://github.com/wagtail/wagtail/pull/9246">Re-implement chooser modals with new design #9246</a></li>
</ul>
</li>
</ul>
</li>
<li>In page listings, manual sorting of pages.<ul>
<li>Example: not available</li>
<li>Proposed actions:<ul>
<li>Review why the fix to <a href="https://github.com/wagtail/wagtail/issues/5410">Page reordering UI isn’t accessible for keyboard users #5410</a> isn’t working.</li>
</ul>
</li>
</ul>
</li>
<li>In image create/edit forms, creation or editing of a focal area.<ul>
<li>Current: it’s impossible to set a focal area without a mouse.</li>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/images/43/">Wagtail 5.1 - Editing Boston Cream Pie</a></li>
<li>Proposed actions:<ul>
<li>Add keyboard support with a new implementation</li>
<li>Factor in <a href="https://github.com/wagtail/wagtail/issues/10947#issuecomment-1746464044">possible requirements</a> for other types of image manipulation.</li>
</ul>
</li>
</ul>
</li>
<li>In table blocks, editing of the table.<ul>
<li>Example: <a href="https://static-wagtail-v5-1.netlify.app/admin/pages/81/edit/#block-2b9b59cb-4dd7-4ebf-ac66-1ed43471609b-section">Wagtail 5.1 –&nbsp;Editing Recipe page: Hot Cross Bun</a></li>
</ul>
</li>
</ul>
</td> </tr><tr><td>A.3.1.2: No Keyboard Traps (Level A)</td> <td> Passed</td> <td> <p>There are no known keyboard traps in the administrative interface.</p>
</td> </tr><tr><td>A.3.1.3: Efficient Keyboard Access (Level AA)</td> <td> Passed</td> <td> <p>The administrative interface provides the following mechanisms to improve keyboard navigation:</p>
<ul>
<li>A skip link, across all views, to skip the sidebar.</li>
<li>Collapsible sections on long views to avoid having to tab through all of the content.</li>
<li>A mechanism to link to specific collapsible sections, for direct access via bookmarks.</li>
<li>A "Collapse/expand all sections" button on long forms to navigate more easily to a specific section.</li>
<li>The "minimap" skip-menu on long forms to navigate more easily to a specific section.</li>
</ul>
</td> </tr><tr><td>A.3.1.4: Keyboard Access (Enhanced) (Level AAA)</td> <td> Failed</td> <td> <p>See <em>A.3.1.1 Keyboard Access</em>. We would expect addressing all aspects listed in <em>A.3.1.1</em> to also address this criterion.</p>
</td> </tr><tr><td>A.3.1.5: Customize Keyboard Access (Level AAA)</td> <td> Failed</td> <td> <p>None of Wagtail’s keyboard commands can be customized.</p>
<p>Proposed actions:</p>
<ul>
<li>Document all keyboard commands (SC <em>A.3.1.6 Present Keyboard Commands</em>)</li>
<li>Implement a "key map" for Wagtail’s keyboard commands and-or command palette, with a way to upload a new key map as JSON.</li>
</ul>
</td> </tr><tr><td>A.3.1.6: Present Keyboard Commands (Level AAA)</td> <td> Failed</td> <td> <p>Across specific areas:</p>
<ul>
<li>Pass: In rich text fields, Markdown keyboard commands or keyboard shortcuts are displayed within tooltips for specific toolbar buttons.</li>
<li>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.</li>
<li>Fail: Wagtail’s other traditional "key combinations" keyboard shortcuts are not displayed in the UI. This includes:<ul>
<li>Commenting</li>
<li>Save draft</li>
<li>Preview</li>
</ul>
</li>
</ul>
<p>Proposed actions:</p>
<ul>
<li>Implement <a href="https://github.com/wagtail/wagtail/issues/3949">Keyboard shortcut documentation for editor in the Wagtail UI #3949</a></li>
<li>Consider a "Command palette" concept for Wagtail</li>
</ul>
</td> </tr><tr><td>A.3.2.1: Auto-Save (minimum) (Level A)</td> <td> Failed</td> <td> <p>Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the default session time limit is 2 weeks. See <a href="https://github.com/wagtail/roadmap/issues/24">Autosave #24</a> on the Wagtail roadmap.</p>
</td> </tr><tr><td>A.3.2.2: Timing Adjustable (Level A)</td> <td> Passed</td> <td> <p>For Wagtail sites, the default session time limit is 2 weeks.</p>
</td> </tr><tr><td>A.3.2.3: Static Input Components (Level A)</td> <td> Passed</td> <td> <p>There are no moving input components in the CMS.</p>
</td> </tr><tr><td>A.3.2.4: Content Edits Saved (Extended) (Level AAA)</td> <td> Failed</td> <td> <p>Wagtail doesn’t provide auto-save functionality. See <em>A.3.2.1 Auto-Save (Minimum)</em>. We expect the same approach to be followed for both SCs.</p>
</td> </tr><tr><td>A.3.3.1: Static View Option (Level A)</td> <td> Failed</td> <td> <p>Animated GIFs auto-play when rendered, with no option to pause them.</p>
<p>Proposed actions:</p>
<ul>
<li>Research accessibility best practices on animated GIFs</li>
<li>Design a new interface for how CMS users interact with animated GIFs</li>
<li>Implement the new interface according to ATAG, WCAG standards, and accessibility best practices.</li>
</ul>
</td> </tr><tr><td>A.3.4.1: Navigate by structure (Level AA)</td> <td> Not applicable</td> <td> <p>Markup elements aren’t exposed in the CMS.</p>
</td> </tr><tr><td>A.3.4.2: Navigate by Programmatic Relationships (Level AAA)</td> <td> Passed</td> <td> <p>The only editable programmatic relationships are headings and element nesting in rich text fields, which can be navigated via the keyboard.</p>
</td> </tr><tr><td>A.3.5.1: Text Search (Level AA)</td> <td> Failed</td> <td> <p>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.</p>
<p>Proposed actions:</p>
<ul>
<li>Research whether browser searching could/should support finding matches across all tabs.</li>
<li>Research how other content management systems cater for this requirement.</li>
<li>Investigate a possible bespoke CMS search implementation with matches across all CMS views.</li>
<li>Fix <a href="https://github.com/wagtail/wagtail/issues/8483">Activating a tab based on the URL hash should also set focus to the corresponding tabpanel #8483</a></li>
</ul>
</td> </tr><tr><td>A.3.6.1: Independence of Display (Level A)</td> <td> Passed</td> <td> <p>All of Wagtail’s UI settings can be adjusted without modifying the content.</p>
</td> </tr><tr><td>A.3.6.2: Save Settings (Level AA)</td> <td> Passed</td> <td> <p>Specific settings are saved differently. The following settings are persistent for a given user profile, across all sessions of said user:</p>
<ul>
<li>Language</li>
<li>Time zone</li>
<li>Notification settings</li>
<li>Admin interface theme</li>
</ul>
<p>The following settings are persistent for a given browser, across all sessions within said browser:</p>
<ul>
<li>Sidebar expanded/collapsed</li>
<li>Rich text toolbar pinned/unpinned</li>
<li>Minimap opened/closed</li>
<li>Currently-open side panel</li>
</ul>
</td> </tr><tr><td>A.3.6.3: Apply Platform Settings (Level AA)</td> <td> Passed</td> <td> <p>Wagtail’s language, time zone, and theme settings default to respecting platform settings until set to a specific value by the user.</p>
</td> </tr><tr><td>A.3.7.1: Preview (Minimum) (Level A)</td> <td> Passed</td> <td> <p>Wagtail’s live preview for pages and snippets and its draft renders within the user’s browser.</p>
</td> </tr><tr><td>A.3.7.2: Preview (Enhanced) (Level AAA)</td> <td> Passed</td> <td> <p>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.</p>
</td> </tr><tr><td>A.4.1.1: Content Changes Reversible (Minimum) (Level A)</td> <td> Failed</td> <td> <p>Though a large number of authoring actions are reversible, not all are. The following actions are reversible:</p>
<ul>
<li>Plain text and rich text content editing within specific fields, reversible until the user submits the form.</li>
<li>Editing of page or snippets content supporting revisions, reversible for the whole page/snippet at any later point in the site’s history.</li>
</ul>
<p>The following actions are not reversible but do require confirmation to proceed:</p>
<ul>
<li>Permanent deletion of any content which has its own dedicated creation/editing views.</li>
<li>Unpublishing of pages and snippets.</li>
<li>Deletion of comments within page content.</li>
</ul>
<p>The following actions are not reversible and do not require confirmation to proceed:</p>
<ul>
<li>StreamField / InlinePanel block-based content editing, reversible only as part of support for content revisions.<ul>
<li>Consider implementing an in-browser undo-redo stack for those interactions.</li>
</ul>
</li>
<li>Image / Document / Page / Task / Snippet / Embed chooser fields, reversible only as part of support for content revisions.<ul>
<li>Consider implementing an in-browser undo-redo stack for those interactions.</li>
</ul>
</li>
<li>Authoring actions on content that does not support revisions such as images, documents, etc.<ul>
<li>Implement either a confirmation step for those actions, or revisions/versioning support.</li>
</ul>
</li>
</ul>
</td> </tr><tr><td>A.4.1.2: Settings Change Confirmation (Level A)</td> <td> Passed</td> <td> <p>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.</p>
<p>Recommendation for Wagtail:</p>
<ul>
<li>Reset all browser-level settings when users intentionally log out (not on session timeouts)</li>
<li>Add a way to "Reset preferences" – reverse all browser-level and user profile settings to their default value within the user’s profile form.</li>
</ul>
</td> </tr><tr><td>A.4.1.3: Content Changes Reversible (Enhanced) (Level AAA)</td> <td> Passed</td> <td> <p>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.</p>
</td> </tr><tr><td>A.4.2.1: Describe Accessibility Features (Level A)</td> <td> Failed</td> <td> <p>The following functionality would be used to meet Part A and needs to be described either in the documentation or in the user interface:</p>
<ul>
<li>Image title fields’ usage as alt text</li>
<li>Page-level keyboard shortcuts</li>
<li>Skip link</li>
<li>Collapsible sections</li>
<li>Link to specific collapsible sections</li>
<li>Collapse/expand all</li>
<li>Minimap</li>
<li>Session time limit</li>
<li>Editing of headings and elements nesting in rich text fields</li>
<li>Text search</li>
<li>Browser-level UI settings<ul>
<li>Sidebar expanded/collapsed</li>
<li>Rich text toolbar pinned/unpinned</li>
<li>Minimap opened/closed</li>
<li>Currently-open side panel</li>
</ul>
</li>
<li>Profile-level UI settings<ul>
<li>Language</li>
<li>Time zone</li>
<li>Notification settings</li>
<li>Admin interface theme</li>
</ul>
</li>
<li>Live preview</li>
<li>Command palette available commands</li>
</ul>
<p>The following functionality is described in the user interface:</p>
<ul>
<li>Restore revisions</li>
<li>Markdown keyboard commands for rich text</li>
<li>Command palette trigger</li>
</ul>
<p>The following functionality is described in the documentation:</p>
<ul>
<li>Comment shortcut</li>
<li>Rich text keyboard shortcuts</li>
</ul>
<p>The following functionality is provided by the underlying platform:</p>
<ul>
<li>Embeds titles as alt text for embedded content</li>
</ul>
</td> </tr><tr><td>A.4.2.2: Document All Features (Level AA)</td> <td> Failed</td> <td> <p>Here is a high-level record of whether given functionality is documented. As a summary:</p>
<ul>
<li>For 19 high-level functional areas, 11 are partially documented and one is fully documented.</li>
<li>For 141 specific features, 38 are documented.</li>
</ul>
<p>This record does not cover functionality provided by the underlying platform (for example; automated embed creation) or unused by authors.</p>
<p>For a full record of documentation status across 160 features divided in 19 functional areas, see <a href="https://wagtail.org/accessibility/atag-audit/#a422-document-all-features">A.4.2.2 Document All Features - Wagtail ATAG 2.0 report</a>.</p>
</td> </tr><tr><td>B.1.1.1: Content Auto-Generation After Authoring Sessions (WCAG) (evaluated as Level AAA)</td> <td> Passed</td> <td> <p>Wagtail doesn’t automatically generate content after authoring sessions. Processes that operate after authoring sessions and could alter the content are <a href="https://docs.wagtail.org/en/stable/reference/pages/theory.html#id2">scheduled publishing</a> and <a href="https://docs.wagtail.org/en/stable/topics/search/indexing.html#wagtailsearch-indexing-update">search index</a> updates, but in both cases any automatically-generated content would already be present during the session.</p>
</td> </tr><tr><td>B.1.1.2: Content Auto-Generation During Authoring Sessions (WCAG) (evaluated as Level AA)</td> <td> Failed</td> <td> <p>Wagtail automatically generates content in a few scenarios. In the following scenarios, markup is accessible without further work:</p>
<ul>
<li>Pass: Links markup for links to pages, documents, external URLs, email addresses, phone numbers, and internal anchors within rich text fields.</li>
<li>Pass: Embeds for external resources within rich text fields.</li>
<li>Pass: Embeds for external resources in StreamField.</li>
<li>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.</li>
<li>Pass: Table markup from TableBlock.</li>
</ul>
<p>In the following scenarios, markup isn’t accessible out of the box:</p>
<ul>
<li>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. See <a href="https://github.com/wagtail/rfcs/pull/51">RFC 51: Contextual alt text</a>. Example: <a href="https://static-wagtail-v5-1.netlify.app/admin-dark/pages/68/edit/">Wagtail 5.1 - Editing Blog page Bread and Ciruses</a>.</li>
<li>Fail: Table markup from TypedTableBlock. This is lacking the ability to set row or column headers. See <a href="https://github.com/wagtail/wagtail/issues/8507">TypedTableBlock issue #8507</a>. Example: <a href="https://static-wagtail-v5-1.netlify.app/admin-dark/pages/81/edit/">Wagtail 5.1 - Editing Recipe page Hot Cross Bun</a>.</li>
</ul>
<p>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 <a href="https://github.com/wagtail/wagtail/issues/10136">Accessibility checker in page editor #10136</a>.</p>
<p>Proposed actions:</p>
<ul>
<li>Complete alt text improvements as part of <a href="https://github.com/wagtail/rfcs/pull/51">RFC 51: Contextual alt text</a></li>
<li>Implement <a href="https://github.com/wagtail/wagtail/issues/10136">Accessibility checker in page editor #10136</a></li>
<li>Fix <a href="https://github.com/wagtail/wagtail/issues/8507">TypedTableBlock issue #8507</a></li>
</ul>
</td> </tr><tr><td>B.1.2.1: Restructuring and Recoding Transformations (evaluated as Level AA)</td> <td> Not applicable</td> <td> <p>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.</p>
<p>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.</p>
</td> </tr><tr><td>B.1.2.2: Copy-Paste Inside Authoring Tool (WCAG) (evaluated as Level AA)</td> <td> Passed</td> <td> <p>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.</p>
</td> </tr><tr><td>B.1.2.3: Optimizations Preserve Accessibility (Level A)</td> <td> Not applicable</td> <td> <p>Wagtail doesn’t perform any optimizations that would affect accessibility.</p>
</td> </tr><tr><td>B.1.2.4: Text Alternatives for Non-Text Content are Preserved (Level A)</td> <td> Not applicable</td> <td> <p>See <em>B.1.2.1 Restructuring and Recoding Transformations (WCAG)</em>.</p>
</td> </tr><tr><td>B.2.1.1: Ensure that accessible content production is possible.  (evaluated as Level AA)</td> <td> Failed</td> <td> <p>Wagtail places extensive restrictions on the production of web content, which all nonetheless allow for the production of accessible content, with the exception of:</p>
<ul>
<li>Missing support for marking images as decorative / setting alt text in context for image chooser fields. See <em>B.1.1.2 Content Auto-Generation During Authoring Sessions (WCAG)</em>. This could be worked around by only creating images within rich text fields, which is possible but unlikely. Example: <a href="https://static-wagtail-v5-1.netlify.app/admin-dark/pages/68/edit/">Wagtail 5.1 - Editing Blog page Bread and Ciruses</a>.</li>
<li>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: <a href="https://static-wagtail-v5-1.netlify.app/admin-dark/pages/81/edit/">Wagtail 5.1 - Editing Recipe page Hot Cross Bun</a>.</li>
<li>Missing support for setting <code>lang</code> attributes within rich text.</li>
</ul>
<p>Proposed actions:</p>
<ul>
<li>Complete alt text improvements as part of <a href="https://github.com/wagtail/rfcs/pull/51">RFC 51: Contextual alt text</a></li>
<li>Fix <a href="https://github.com/wagtail/wagtail/issues/8507">TypedTableBlock issue #8507</a></li>
<li>Implement <a href="https://github.com/wagtail/wagtail/issues/4694">Feature request: Support for declaring language on elements in rich text. #4694</a></li>
</ul>
</td> </tr><tr><td>B.2.2.1: Accessible Option Prominence (WCAG) (evaluated as Level AA)</td> <td> Passed</td> <td> <p>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.</p>
<p>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.</p>
</td> </tr><tr><td>B.2.2.2: Setting Accessibility Properties (WCAG) (evaluated as Level AA)</td> <td> Not applicable</td> <td> <p>Wagtail doesn’t support setting web content attribute values. This has been discussed extensively for links, as well as an option to set <code>aria-label</code>, but hasn’t been implemented yet.</p>
<p>See:</p>
<ul>
<li><a href="https://github.com/wagtail/wagtail/issues/4694">Feature request: Support for declaring language on elements in rich text. #4694</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/4474">Feature: ability to set links as "nofollow" rel via the WYSIWG editor's link chooser #4474</a></li>
</ul>
</td> </tr><tr><td>B.2.3.1: Alternative Content is Editable (WCAG) (evaluated as Level AA)</td> <td> Failed</td> <td> <p>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 <a href="https://github.com/wagtail/rfcs/pull/51">RFC 51: Contextual alt text</a>.</p>
</td> </tr><tr><td>B.2.3.2: Automating Repair of Text Alternatives (Level A)</td> <td> Passed</td> <td> <p>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.</p>
</td> </tr><tr><td>B.2.3.3: Save for Reuse (Level AAA)</td> <td> Failed</td> <td> <p>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.</p>
<p>Suggested action: incorporate this requirement into <a href="https://github.com/wagtail/rfcs/pull/51">RFC 51: Contextual alt text</a>.</p>
</td> </tr><tr><td>B.2.4.1: Accessible Template Options (WCAG) (evaluated as Level AA)</td> <td> Failed</td> <td> <p>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.</p>
<ul>
<li>For rich text formats:<ul>
<li>blockquote is missing a cite attribute or a cite element within.</li>
</ul>
</li>
<li>For Field block types:<ul>
<li>BlockQuoteBlock: No support for <code>cite</code> attribute or a <code>&lt;cite&gt;</code> element within.</li>
<li>ImageChooserBlock: No support for alt text in context or marking as decorative.</li>
<li>TypedTableBlock: No caption support. Header cells hard-coded to first row. No option to set row headers.</li>
</ul>
</li>
<li>For Structural block types: all 4 have no issues</li>
<li>For form builder field types: all except "Hidden field" have issues with programmatic errors and help text.</li>
</ul>
<p>Form builder field type issues may be addressed in the future, via improvements in Django. See:</p>
<ul>
<li><a href="https://code.djangoproject.com/ticket/32820">Django ticket #32820 – Fields’ errors should be programmatically associated with fields.</a></li>
<li><a href="https://code.djangoproject.com/ticket/32819">Django ticket #32819 - Fields’ help text and errors should be associated with input</a></li>
</ul>
<p>Proposed actions:</p>
<ul>
<li><a href="https://docs.djangoproject.com/en/dev/releases/5.0/">Re-review with Django 5.0 improvements</a></li>
<li>Add cite attribute support to BlockQuote block</li>
</ul>
<p>For a full tabular view of all template options’ status, see <a href="https://wagtail.org/accessibility/atag-audit/#b24-assist-authors-with-accessible-templates">B.2.4. Assist authors with accessible templates - Wagtail ATAG 2.0 report</a>.</p>
</td> </tr><tr><td>B.2.4.2: Identify Template Accessibility (Level AA)</td> <td> Passed</td> <td> <p>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.</p>
</td> </tr><tr><td>B.2.4.3: Author-Created Templates (Level AA)</td> <td> Failed</td> <td> <p>Wagtail doesn’t allow authors to create custom block templates.</p>
</td> </tr><tr><td>B.2.4.4: Accessible Template Options (Enhanced) (Level AAA)</td> <td> Failed</td> <td> <p>Some of Wagtail’s template options aren’t accessible. See <em>B.2.4.1 Accessible Template Options</em>.</p>
</td> </tr><tr><td>B.2.5.1: Accessible Pre-Authored Content Options (Level AA)</td> <td> Not applicable</td> <td> <p>Wagtail doesn’t provide pre-authored content.</p>
</td> </tr><tr><td>B.2.5.2: Identify Pre-Authored Content Accessibility (Level AA)</td> <td> Not applicable</td> <td> <p>Wagtail doesn’t provide pre-authored content.</p>
</td> </tr><tr><td>B.3.1.1: Checking Assistance (WCAG) (evaluated as Level AAA)</td> <td> Failed</td> <td> <p>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:</p>
<ul>
<li><code>button-name</code>: <code>&lt;button&gt;</code> elements must always have a text label.</li>
<li><code>empty-heading</code>: This rule checks for headings with no text content. Empty headings are confusing to screen readers users and should be avoided.</li>
<li><code>empty-table-header</code>: Table header text should not be empty</li>
<li><code>frame-title</code>: <code>&lt;iframe&gt;</code> elements must always have a text label.</li>
<li><code>heading-order</code>: 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.).</li>
<li><code>input-button-name</code>: <code>&lt;input&gt;</code> button elements must always have a text label.</li>
<li><code>link-name</code>: <code>&lt;a&gt;</code> link elements must always have a text label.</li>
<li><code>p-as-heading</code>: 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.</li>
</ul>
<p>There are a number of success criteria that do not have automated checks nor instructions for manual checking:</p>
<ul>
<li>1.1.1 Non-text Content (A) –&nbsp;specifically instructions on correct entry of alt text, and marking images as decorative when appropriate</li>
<li>2.4.4 Link Purpose (In Context) (AA) –&nbsp;instructions and potentially limited automated checks on correct link text (avoid "click here")</li>
<li>1.4.5 Images of Text (AA) –&nbsp;instructions on avoiding images of text except for scenarios where there is no alternative</li>
<li>2.4.9 Link Purpose (Link Only) (AAA) – see above</li>
<li>1.4.9 Images of Text (No Exception) (AAA) – see above</li>
<li>3.1.5 Reading Level (AAA) –&nbsp;instructions for manual checking or automated checks</li>
<li>2.4.10 Section Headings (AAA) – instructions for manual checking or automated checks</li>
<li>3.3.5 Help (AAA) – instructions for manual checking or automated checks for the form builder</li>
</ul>
<p>Proposed actions:</p>
<ul>
<li>Implement more automated checks for WCAG SCs in question. <a href="https://github.com/wagtail/wagtail/discussions/11063">Content quality checkers #11063</a></li>
<li>Implement a manual check process for WCAG SCs in question. <a href="https://github.com/wagtail/wagtail/discussions/11063">Content quality checkers #11063</a></li>
<li>Roadmap: <a href="https://github.com/wagtail/roadmap/issues/50">Readability checks #50</a></li>
<li>Content quality API integrations for text quality and image computer vision</li>
<li>Improve options for organizations to embed their own instructions within the CMS, via HelpBlock and help text.</li>
</ul>
</td> </tr><tr><td>B.3.1.2: Help Authors Decide (Level A)</td> <td> Not applicable</td> <td> <p>Currently all of Wagtail’s automated checks are pass/fail with no author input required. Discussion on further checks: <a href="https://github.com/wagtail/wagtail/discussions/11063">Content quality checkers #11063</a></p>
</td> </tr><tr><td>B.3.1.3: Help Authors Locate (Level A)</td> <td> Not applicable</td> <td> <p>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:</p>
<ul>
<li><a href="https://github.com/wagtail/wagtail/discussions/11063">Content quality checkers #11063</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/10136">Accessibility checker in page editor #10136</a></li>
<li>Correct identification of Wagtail content so errors are only reported on CMS-managed content</li>
</ul>
</td> </tr><tr><td>B.3.1.4: Status Report (Level AA)</td> <td> Passed</td> <td> <p>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.</p>
<p>Possible improvements:</p>
<ul>
<li><a href="https://github.com/wagtail/wagtail/discussions/11063">Content quality checkers #11063</a> – making this data available in more readily accessible reports</li>
<li>Consider making the information easily copy-pasteable</li>
</ul>
</td> </tr><tr><td>B.3.1.5: Programmatic Association of Results (Level AA)</td> <td> Failed</td> <td> <p>Currently the association isn’t programmatic, due to expected compatibility issues.</p>
<p>Possible resolution: Correct identification of Wagtail content so errors are only reported on CMS-managed content.</p>
</td> </tr><tr><td>B.3.2.1: Repair Assistance (WCAG (evaluated as Level AA)</td> <td> Failed</td> <td> <p>Currently Wagtail’s 8 rules report the presence of a problem but do not suggest specific solutions.</p>
<p>Proposed improvements:</p>
<ul>
<li><a href="https://github.com/wagtail/wagtail/discussions/11063">Content quality checkers #11063</a></li>
<li><a href="https://github.com/wagtail/wagtail/issues/10136">Accessibility checker in page editor #10136</a></li>
<li>Correct identification of Wagtail content so errors are only reported on CMS-managed content</li>
</ul>
</td> </tr><tr><td>B.4.1.1: Features Active by Default (Level A)</td> <td> Passed</td> <td> <p>Wagtail’s accessibility checker is on by default and cannot be turned off unless site implementers make CMS customizations in code.</p>
</td> </tr><tr><td>B.4.1.2: Option to Reactivate Features (Level A)</td> <td> Passed</td> <td> <p>See <em>B.4.1.1 Features Active by Default</em>.</p>
</td> </tr><tr><td>B.4.1.3: Feature Deactivation Warning (Level AA)</td> <td> Passed</td> <td> <p>See <em>B.4.1.1 Features Active by Default</em>.</p>
</td> </tr><tr><td>B.4.1.4: Feature Prominence (Level AA)</td> <td> Passed</td> <td> <p>Wagtail currently has no features relating to invalid markup, syntax errors, spelling errors, grammar errors. Possible future changes:</p>
<ul>
<li>Implement more automated checks for WCAG SCs in question. <a href="https://github.com/wagtail/wagtail/discussions/11063">Content quality checkers #11063</a></li>
<li>Implement a manual check process for WCAG SCs in question. <a href="https://github.com/wagtail/wagtail/discussions/11063">Content quality checkers #11063</a></li>
<li>Roadmap: <a href="https://github.com/wagtail/roadmap/issues/50">Readability checks #50</a></li>
</ul>
</td> </tr><tr><td>B.4.2.1: Model Practice (WCAG) (evaluated as Level AA)</td> <td> Passed</td> <td> <p>Wagtail’s documentation for content authors does not demonstrate accessible authoring practices. The documentation for developers does: <a href="https://docs.wagtail.org/en/stable/advanced_topics/accessibility_considerations.html">Accessibility considerations</a>.</p>
<p>Proposed actions:</p>
<ul>
<li><a href="https://github.com/wagtail/roadmap/issues/69">Accessibility features documentation #69</a></li>
<li>Add accessibility criteria to contributor documentation for documentation writing</li>
<li>Review developer documentation for accessibility improvements in examples</li>
</ul>
</td> </tr><tr><td>B.4.2.2: Feature Instructions (Level A)</td> <td> Failed</td> <td> <p>Wagtail’s accessibility checker and alt text setting aren’t documented in the guide for content authors. The documentation for developers does cover this.</p>
<p>Proposed actions:</p>
<ul>
<li>Documentation review to ensure all accessibility features are documented.<ul>
<li>Document all accessibility features in developer documentation.</li>
<li><a href="https://github.com/wagtail/roadmap/issues/69">Accessibility features documentation #69</a></li>
</ul>
</li>
</ul>
</td> </tr><tr><td>B.4.2.3: Tutorial (Level AAA)</td> <td> Failed</td> <td> <p>Wagtail’s accessibility features doesn’t have a tutorial.</p>
<p>Proposed actions:</p>
<ul>
<li>Create a written tutorial in addition to how-to material.</li>
<li>Create a video tutorial in addition to the user guide website.</li>
</ul>
</td> </tr><tr><td>B.4.2.4: Instruction Index (Level AAA)</td> <td> Failed</td> <td> <p>Wagtail’s documentation for content author does not have such an index. The documentation for developers does.</p>
<p>Proposed actions:</p>
<ul>
<li>Add an index of accessibility features to the user guide.</li>
<li><a href="https://wagtail.org/blog/our-outreachy-projects-in-2023/">Outreachy: Accessibility features documentation</a></li>
</ul>
</td> </tr></tbody></table> <p><small>Created with ATAG Report Tool version 0.6.0</small></p></body></html>

## report.json
{"evaluationData":{"web-based-accessible-wcag":{"id":"web-based-accessible-wcag","num":"A.1.1.1","handle":"Web-Based Accessible (WCAG)","result":"Failed","observations":"Wagtail [currently targets WCAG 2.1 AA conformance](https://wagtail.org/accessibility/) for the administrative interface of the CMS. Though a lot of progress has been made, there are still [known conformance issues](https://github.com/orgs/wagtail/projects/9/views/1).\n\nAs 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!](https://static-wagtail-v5-1.netlify.app/admin/pages/60/edit/)):\n\n- v5.2: 6 issues\n- v5.1: 6 issues\n- v5.0: 7 issues\n- v4.2: 13 issues\n- v4.1: 12 issues\n- v4.0: 7 issues\n- v3.0: 24 issues\n- v2.16: 30 issues\n\nFor a full tabular view of types of issues per release, see [A.1.1.1 Web-Based Accessible (WCAG) - Wagtail ATAG 2.0 report](https://wagtail.org/accessibility/atag-audit/#a111-web-based-accessible-wcag)\n\nSuggested next steps:\n\n- [WCAG 2.2 manual audit #63](https://github.com/wagtail/roadmap/issues/63)\n- Interviews with users of assistive technologies\n\nReferences:\n\n- Largest outstanding issue: [Making Wagtail Accessible for users with disabilities #4199](https://github.com/wagtail/wagtail/issues/4199)\n- Most recent major improvement: [Support for WHCM / Contrast themes](https://docs.wagtail.org/en/stable/releases/4.0.html#windows-high-contrast-mode-support-improvements).\n- [Living accessibility audit (last update: 2021)](https://docs.google.com/spreadsheets/d/1l7tnpEyJiC5BWE_JX0XCkknyrjxYA5T2aee5JgPnmi4/edit)\n\nFull list of 24 currently-documented accessibility issues in GitHub:\n\n- [Radio inputs do not correctly get associated with their parent (group) label for accessibility #10228](https://github.com/wagtail/wagtail/issues/10228)\n- [Chooser buttons focus colour is too dark in dark mode #10875](https://github.com/wagtail/wagtail/issues/10875)\n- [Replace date & date time picker widget with native browser date pickers #8056](https://github.com/wagtail/wagtail/issues/8056)\n- [Revamp revision comparison diff styles #10576](https://github.com/wagtail/wagtail/issues/10576)\n- [Contrast themes – Info side panel’s button links need a border #8834](https://github.com/wagtail/wagtail/issues/8834)\n- [Missing HTML widget attributes in StreamField widget rendering #10300](https://github.com/wagtail/wagtail/issues/10300)\n- [Barriers for speech recognition users #9666](https://github.com/wagtail/wagtail/issues/9666)\n- [Accessibility regression in userbar #10674](https://github.com/wagtail/wagtail/issues/10674)\n- [Page editing actions dropdown doesn’t support keyboard or screen reader navigation #7366](https://github.com/wagtail/wagtail/issues/7366)\n- [Enhancement to Progress button behaviour #10076](https://github.com/wagtail/wagtail/issues/10076)\n- [Activating a tab based on the URL hash should also set focus to the corresponding tabpanel #8483](https://github.com/wagtail/wagtail/issues/8483)\n- [Page chooser should use buttons instead of links with invalid targets #5408](https://github.com/wagtail/wagtail/issues/5408)\n- [Keyboard support improvements in accessibility checker #10135](https://github.com/wagtail/wagtail/issues/10135)\n- [Feature request: Switch TableBlock’s header controls to a field that requires user input #5989](https://github.com/wagtail/wagtail/issues/5989)\n- [Implement focus management for chooser modals #5338](https://github.com/wagtail/wagtail/issues/5338)\n- [Accessibility and UI issues with typed table block #7646](https://github.com/wagtail/wagtail/issues/7646)\n- [TableBlock is impossible to reach with the keyboard #8893](https://github.com/wagtail/wagtail/issues/8893)\n- [\"Unpublished\" styles in pages listings are very hard / impossible to see #5370](https://github.com/wagtail/wagtail/issues/5370)\n- [Status tag contrast is too low #5778](https://github.com/wagtail/wagtail/issues/5778)\n- [Add table caption option as part of TypedTableBlock for accessibility #8507](https://github.com/wagtail/wagtail/issues/8507)\n- [Rework the admin UI’s landmark based on established best practices #5411](https://github.com/wagtail/wagtail/issues/5411)\n- [Keyboard navigation breaks with links in paragraph in Chrome on MacOS #7693](https://github.com/wagtail/wagtail/issues/7693)\n- [Datetimepicker UI component is not accessible to screen-reader and keyboard users #5325](https://github.com/wagtail/wagtail/issues/5325)\n- [Making Wagtail Accessible for users with disabilities #4199](https://github.com/wagtail/wagtail/issues/4199)","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"non-web-a11y-guidelines":{"id":"non-web-a11y-guidelines","num":"A.1.2.1","handle":"Accessibility Guidelines","result":"Not applicable","observations":"Wagtail is a web-based CMS.","level":"A","evaluatedLevel":"Level A","evaluated":true},"non-web-platform-a11y-services":{"id":"non-web-platform-a11y-services","num":"A.1.2.2","handle":"Platform Accessibility Services","result":"Not applicable","observations":"Wagtail is a web-based CMS.","level":"A","evaluatedLevel":"Level A","evaluated":true},"alts-for-non-text":{"id":"alts-for-non-text","num":"A.2.1.1","handle":"Text Alternatives for Rendered Non-Text Content","result":"Failed","observations":"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:\n\n- 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.\n  - Example: [Wagtail 5.1 - Editing image Boston Cream Pie](https://static-wagtail-v5-1.netlify.app/admin/images/43/)\n  - Current: The alt text is permanently set to the contents of the Title field on page load.\n  - Proposed actions:\n    - The image could be more clearly associated with the live title field with an `aria-labelledby`.\n    - The title field could have help text to clarify its use as the image’s alt text (at least in the CMS).\n    - Take CMS users into account in [RFC 51: Contextual alt text](https://github.com/wagtail/rfcs/pull/51)\n    - Research alt text requirements for CMS users with disabilities with ATAG experts.\n- 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.\n  - Example: [Wagtail 5.1 - Editing Blog Page: Desserts with Benefits, Image field](https://static-wagtail-v5-1.netlify.app/admin/pages/77/edit/#panel-child-content-image-section)\n  - Current: Alt text set to `alt=\"\"`, with title displayed after the image.\n  - Proposed actions:\n    - Associate the visible text with the image with `aria-labelledby`.\n- 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.\n  - Example (with Caption field): [Wagtail 5.1 - Editing Blog Page: Desserts with Benefits, Image block](https://static-wagtail-v5-1.netlify.app/admin/pages/77/edit/#block-556e76b0-0f5a-42bb-b039-653f3d6b1f0b-section)\n  - Alt text set to `alt=\"\"`, with title displayed after the image, and custom field further down.\n  - Proposed actions:\n    - Implement this pattern in the bakerydemo website.\n    - Take CMS users into account in [RFC 51: Contextual alt text](https://github.com/wagtail/rfcs/pull/51)\n    - Associate both the title of the image, and the custom field, with `aria-labelledby`, or a combination of it and `aria-describedby`.\n    - Research alt text requirements for CMS users with disabilities with ATAG experts.\n- 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.\n  - Example: unavailable\n  - Proposed actions:\n    - Add demo content following this pattern in bakerydemo.\n    - Add a programmatic association between tooltip text and image with `aria-labelledby`.\n    - Make sure the image has alt text accessible even when the tooltip is closed.\n- 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.\n  - Example: [Wagtail 5.1 - Editing Blog Page: Desserts with Benefits, Paragraph block](https://static-wagtail-v5-1.netlify.app/admin/pages/77/edit/#block-ac48af95-b3be-4602-8c2f-5c43fc080f17-section)\n  - Current: Alt text set to `alt=\"\"`, with no text displayed near the image.\n  - Proposed actions:\n    - Add a programmatic association between tooltip text and image with `aria-labelledby`.\n    - Make sure the thumbnail image has alt text accessible even when the tooltip is closed.\n\nOutside editing views (possibly not part of ATAG requirements), Wagtail renders images in the following scenarios:\n\n- 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.\n  - Example: [Wagtail 5.1 - Comparing Bread and Circuses](https://static-wagtail-v5-1.netlify.app/admin/pages/68/revisions/compare/46...108/)\n  - Current: the image title is used as `alt` attribute.\n  - Proposed actions:\n    - Add demo content following this pattern in bakerydemo.\n    - Display the images’ titles in the UI, with programmatic `aria-labelledby` associations.\n- Revisions comparison with images or embeds in rich text: currently unimplemented.\n- Snippets listings. When there is an image column, its alt text is set but invisible in the UI.\n  - Example: [Wagtail 5.1 – Snippets People](https://static-wagtail-v5-1.netlify.app/admin/snippets/base/person/)\n  - Current: the image title is used as `alt` attribute.\n  - Proposed actions:\n    - Display the images’ titles in the UI, with programmatic `aria-labelledby` associations.\n- Image gallery. Here we display the title underneath the image as alt text, in a `figcaption`.\n  - Example: [Wagtail 5.1 – Images](https://static-wagtail-v5-1.netlify.app/admin/images/)\n  - Current: Alt text set to `alt=\"\"`, but the image is within a `figure` with the image’s title as `figcaption`.\n  - Proposed actions:\n    - Associate the text and the image with `aria-labelledby`.\n\nRecommendation 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).\n\nReference: [RFC 51: Contextual alt text](https://github.com/wagtail/rfcs/pull/51)","level":"A","evaluatedLevel":"Level A","evaluated":true},"alts-for-time-based":{"id":"alts-for-time-based","num":"A.2.1.2","handle":"Alternatives for Rendered Time-Based Media","result":"Failed","observations":"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.","level":"A","evaluatedLevel":"Level A","evaluated":true},"editing-view-status-indicators":{"id":"editing-view-status-indicators","num":"A.2.2.1","handle":"Editing-View Status Indicators","result":"Failed","observations":"Wagtail uses the following status indicators in editing views:\n\n- 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.\n  - Example: [Editing Home Page: Welcome to the Wagtail bakery!](https://static-wagtail-v5-1.netlify.app/admin/pages/60/edit/)\n  - Proposed actions:\n    - Add a programmatic association between fields and their comment presence indicator\n    - Make the comment presence indicator visible at all times.\n    - (WCAG issue) Make the comment addition buttons visible at all times in commenting mode.\n- Fail: Comments in rich text. Comments are displayed as highlighted text within the rich text field. The association isn’t programmatically exposed.\n  - Example: none available\n  - Proposed actions:\n    - Add demo content following this pattern in bakerydemo.\n    - Research how other WYSIWYG interfaces programmatically associate comments with runs of text.\n- 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\").\n  - Example [Editing Recipe page: Southern Cornbread, Preface field](https://static-wagtail-v5-1.netlify.app/admin/pages/82/edit/#panel-child-content-preface-section)\n- TBC (work in progress): content quality checks within page editor.\n\nOutside editing views (possibly not part of ATAG requirements), Wagtail renders status indicators in the following scenarios:\n\n- Accessibility checks in Wagtail userbar. They are currently not programmatically associated with the content they are for.","level":"A","evaluatedLevel":"Level A","evaluated":true},"access-rendered-text-props":{"id":"access-rendered-text-props","num":"A.2.2.2","handle":"Access to Rendered Text Properties","result":"Not applicable","observations":"Wagtail doesn’t allow editing of any text properties associated with the content.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"keyboard-access-minimum":{"id":"keyboard-access-minimum","num":"A.3.1.1","handle":"Keyboard Access (Minimum)","result":"Failed","observations":"Though the majority of the authoring tool’s functionality is keyboard accessible, there are specific areas that aren’t:\n\n- 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\".\n  - Example: [Wagtail 5.1 - Styleguide: Dropdown buttons](https://static-wagtail-v5-1.netlify.app/admin/styleguide/#dropdowns-section)\n  - See [Page editing actions dropdown doesn’t support keyboard or screen reader navigation #7366](https://github.com/wagtail/wagtail/issues/7366)\n  - Proposed actions:\n    - Will be fixed as part of [Re-implement footer actions according to new designs #9030](https://github.com/wagtail/wagtail/issues/9030)\n- In rich text fields, pin/unpin of the rich text toolbar.\n  - Example: [Wagtail 5.1 - Editing Blog Page: Tracking Wild Yeast](https://static-wagtail-v5-1.netlify.app/admin/pages/62/edit/)\n  - Proposed actions:\n    - Research how other WYSIWYG interfaces allow keyboard interactions with all toolbar controls.\n- In rich text fields, Edit functionality for links, documents, images, embeds.\n  - Examples:\n    - Links: [Wagtail 5.1 - Editing Standard page: About](https://static-wagtail-v5-1.netlify.app/admin/pages/76/edit/#panel-child-content-body-section)\n    - Documents: [Wagtail 5.1 - Editing Recipe page: Southern Cornbread](https://static-wagtail-v5-1.netlify.app/admin/pages/82/edit/#block-910c5024-a47a-45b1-a3a3-8f8bb5a8fa70-section)\n    - Images: no example\n    - Embeds: [Wagtail 5.1 - Editing Blog page: Desserts with Benefits](https://static-wagtail-v5-1.netlify.app/admin/pages/77/edit/)\n  - Proposed actions:\n    - Research how other WYSIWYG interfaces allow keyboard interactions with all toolbar controls.\n    - Possibly support selection of all those content types and press \"Enter\" to move focus to their UI.\n- In image/document/page/task/snippet choosers, the chooser dialog.\n  - See [Making Wagtail Accessible for users with disabilities #4199](https://github.com/wagtail/wagtail/issues/4199)\n  - See also [Implement focus management for chooser modals #5338](https://github.com/wagtail/wagtail/issues/5338)\n  - Examples:\n    - Images: [Wagtail 5.1 - Editing Bread page: Arepa](https://static-wagtail-v5-1.netlify.app/admin/pages/37/edit/#panel-child-content-image-section)\n    - Snippets: [Wagtail 5.1 - Editing Bread page: Arepa](https://static-wagtail-v5-1.netlify.app/admin/pages/37/edit/#panel-child-content-origin-section)\n    - Documents: no example\n    - Pages: [Wagtail 5.1 - Editing workflow Moderator approval](https://static-wagtail-v5-1.netlify.app/admin/workflows/edit/1/#workflow-pages-section)\n    - Tasks: [Wagtail 5.1 - Editing workflow Moderator approval](https://static-wagtail-v5-1.netlify.app/admin/workflows/edit/1/#inline_child_workflow_tasks-0-panel-section)\n  - Proposed actions:\n    - Complete [Re-implement chooser modals with new design #9246](https://github.com/wagtail/wagtail/pull/9246)\n- In page listings, manual sorting of pages.\n  - Example: not available\n  - Proposed actions:\n    - Review why the fix to [Page reordering UI isn’t accessible for keyboard users #5410](https://github.com/wagtail/wagtail/issues/5410) isn’t working.\n- In image create/edit forms, creation or editing of a focal area.\n  - Current: it’s impossible to set a focal area without a mouse.\n  - Example: [Wagtail 5.1 - Editing Boston Cream Pie](https://static-wagtail-v5-1.netlify.app/admin/images/43/)\n  - Proposed actions:\n    - Add keyboard support with a new implementation\n    - Factor in [possible requirements](https://github.com/wagtail/wagtail/issues/10947#issuecomment-1746464044) for other types of image manipulation.\n- In table blocks, editing of the table.\n  - Example: [Wagtail 5.1 – Editing Recipe page: Hot Cross Bun](https://static-wagtail-v5-1.netlify.app/admin/pages/81/edit/#block-2b9b59cb-4dd7-4ebf-ac66-1ed43471609b-section)","level":"A","evaluatedLevel":"Level A","evaluated":true},"no-keyboard-traps":{"id":"no-keyboard-traps","num":"A.3.1.2","handle":"No Keyboard Traps","result":"Passed","observations":"There are no known keyboard traps in the administrative interface.","level":"A","evaluatedLevel":"Level A","evaluated":true},"efficient-keyboard-access":{"id":"efficient-keyboard-access","num":"A.3.1.3","handle":"Efficient Keyboard Access","result":"Passed","observations":"The administrative interface provides the following mechanisms to improve keyboard navigation:\n\n- A skip link, across all views, to skip the sidebar.\n- Collapsible sections on long views to avoid having to tab through all of the content.\n- A mechanism to link to specific collapsible sections, for direct access via bookmarks.\n- A \"Collapse/expand all sections\" button on long forms to navigate more easily to a specific section.\n- The \"minimap\" skip-menu on long forms to navigate more easily to a specific section.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"keyboard-access-enhanced":{"id":"keyboard-access-enhanced","num":"A.3.1.4","handle":"Keyboard Access (Enhanced)","result":"Failed","observations":"See _A.3.1.1 Keyboard Access_. We would expect addressing all aspects listed in _A.3.1.1_ to also address this criterion.","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"customise-keyboard-access":{"id":"customise-keyboard-access","num":"A.3.1.5","handle":"Customize Keyboard Access","result":"Failed","observations":"None of Wagtail’s keyboard commands can be customized.\n\nProposed actions:\n\n- Document all keyboard commands (SC _A.3.1.6 Present Keyboard Commands_)\n- Implement a \"key map\" for Wagtail’s keyboard commands and-or command palette, with a way to upload a new key map as JSON.","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"present-keyboard-commands":{"id":"present-keyboard-commands","num":"A.3.1.6","handle":"Present Keyboard Commands","result":"Failed","observations":"Across specific areas:\n\n- Pass: In rich text fields, Markdown keyboard commands or keyboard shortcuts are displayed within tooltips for specific toolbar buttons.\n- 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.\n- Fail: Wagtail’s other traditional \"key combinations\" keyboard shortcuts are not displayed in the UI. This includes:\n  - Commenting\n  - Save draft\n  - Preview\n\nProposed actions:\n\n- Implement [Keyboard shortcut documentation for editor in the Wagtail UI #3949](https://github.com/wagtail/wagtail/issues/3949)\n- Consider a \"Command palette\" concept for Wagtail","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"auto-save-minimum":{"id":"auto-save-minimum","num":"A.3.2.1","handle":"Auto-Save (minimum)","result":"Failed","observations":"Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the default session time limit is 2 weeks. See [Autosave #24](https://github.com/wagtail/roadmap/issues/24) on the Wagtail roadmap.","level":"A","evaluatedLevel":"Level A","evaluated":true},"timing-adjustable":{"id":"timing-adjustable","num":"A.3.2.2","handle":"Timing Adjustable","result":"Passed","observations":"For Wagtail sites, the default session time limit is 2 weeks.","level":"A","evaluatedLevel":"Level A","evaluated":true},"static-input-components":{"id":"static-input-components","num":"A.3.2.3","handle":"Static Input Components","result":"Passed","observations":"There are no moving input components in the CMS.","level":"A","evaluatedLevel":"Level A","evaluated":true},"content-edits-saved":{"id":"content-edits-saved","num":"A.3.2.4","handle":"Content Edits Saved (Extended)","result":"Failed","observations":"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.","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"static-view-option":{"id":"static-view-option","num":"A.3.3.1","handle":"Static View Option","result":"Failed","observations":"Animated GIFs auto-play when rendered, with no option to pause them.\n\nProposed actions:\n\n- Research accessibility best practices on animated GIFs\n- Design a new interface for how CMS users interact with animated GIFs\n- Implement the new interface according to ATAG, WCAG standards, and accessibility best practices.","level":"A","evaluatedLevel":"Level A","evaluated":true},"navigate-by-structure":{"id":"navigate-by-structure","num":"A.3.4.1","handle":"Navigate by structure","result":"Not applicable","observations":"Markup elements aren’t exposed in the CMS.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"navigate-by-relationships":{"id":"navigate-by-relationships","num":"A.3.4.2","handle":"Navigate by Programmatic Relationships","result":"Passed","observations":"The only editable programmatic relationships are headings and element nesting in rich text fields, which can be navigated via the keyboard.","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"text-search":{"id":"text-search","num":"A.3.5.1","handle":"Text Search","result":"Failed","observations":"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.\n\nProposed actions:\n\n- Research whether browser searching could/should support finding matches across all tabs.\n- Research how other content management systems cater for this requirement.\n- Investigate a possible bespoke CMS search implementation with matches across all CMS views.\n- Fix [Activating a tab based on the URL hash should also set focus to the corresponding tabpanel #8483](https://github.com/wagtail/wagtail/issues/8483)","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"independence-of-display":{"id":"independence-of-display","num":"A.3.6.1","handle":"Independence of Display","result":"Passed","observations":"All of Wagtail’s UI settings can be adjusted without modifying the content.","level":"A","evaluatedLevel":"Level A","evaluated":true},"save-settings":{"id":"save-settings","num":"A.3.6.2","handle":"Save Settings","result":"Passed","observations":"Specific settings are saved differently. The following settings are persistent for a given user profile, across all sessions of said user:\n\n- Language\n- Time zone\n- Notification settings\n- Admin interface theme\n\nThe following settings are persistent for a given browser, across all sessions within said browser:\n\n- Sidebar expanded/collapsed\n- Rich text toolbar pinned/unpinned\n- Minimap opened/closed\n- Currently-open side panel","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"apply-platform-settings":{"id":"apply-platform-settings","num":"A.3.6.3","handle":"Apply Platform Settings","result":"Passed","observations":"Wagtail’s language, time zone, and theme settings default to respecting platform settings until set to a specific value by the user.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"preview-minimum":{"id":"preview-minimum","num":"A.3.7.1","handle":"Preview (Minimum)","result":"Passed","observations":"Wagtail’s live preview for pages and snippets and its draft renders within the user’s browser.","level":"A","evaluatedLevel":"Level A","evaluated":true},"preview-enhanced":{"id":"preview-enhanced","num":"A.3.7.2","handle":"Preview (Enhanced)","result":"Passed","observations":"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.","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"content-changes-reversible":{"id":"content-changes-reversible","num":"A.4.1.1","handle":"Content Changes Reversible (Minimum)","result":"Failed","observations":"Though a large number of authoring actions are reversible, not all are. The following actions are reversible:\n\n- Plain text and rich text content editing within specific fields, reversible until the user submits the form.\n- Editing of page or snippets content supporting revisions, reversible for the whole page/snippet at any later point in the site’s history.\n\nThe following actions are not reversible but do require confirmation to proceed:\n\n- Permanent deletion of any content which has its own dedicated creation/editing views.\n- Unpublishing of pages and snippets.\n- Deletion of comments within page content.\n\nThe following actions are not reversible and do not require confirmation to proceed:\n\n- StreamField / InlinePanel block-based content editing, reversible only as part of support for content revisions.\n  - Consider implementing an in-browser undo-redo stack for those interactions.\n- Image / Document / Page / Task / Snippet / Embed chooser fields, reversible only as part of support for content revisions.\n  - Consider implementing an in-browser undo-redo stack for those interactions.\n- Authoring actions on content that does not support revisions such as images, documents, etc.\n  - Implement either a confirmation step for those actions, or revisions/versioning support.","level":"A","evaluatedLevel":"Level A","evaluated":true},"settings-change-confirm":{"id":"settings-change-confirm","num":"A.4.1.2","handle":"Settings Change Confirmation","result":"Passed","observations":"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.\n\nRecommendation for Wagtail:\n\n- Reset all browser-level settings when users intentionally log out (not on session timeouts)\n- Add a way to \"Reset preferences\" – reverse all browser-level and user profile settings to their default value within the user’s profile form.","level":"A","evaluatedLevel":"Level A","evaluated":true},"content-changes-reversible-enhanced":{"id":"content-changes-reversible-enhanced","num":"A.4.1.3","handle":"Content Changes Reversible (Enhanced)","result":"Passed","observations":"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.","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"describe-features":{"id":"describe-features","num":"A.4.2.1","handle":"Describe Accessibility Features","result":"Failed","observations":"The following functionality would be used to meet Part A and needs to be described either in the documentation or in the user interface:\n\n- Image title fields’ usage as alt text\n- Page-level keyboard shortcuts\n- Skip link\n- Collapsible sections\n- Link to specific collapsible sections\n- Collapse/expand all\n- Minimap\n- Session time limit\n- Editing of headings and elements nesting in rich text fields\n- Text search\n- Browser-level UI settings\n  - Sidebar expanded/collapsed\n  - Rich text toolbar pinned/unpinned\n  - Minimap opened/closed\n  - Currently-open side panel\n- Profile-level UI settings\n  - Language\n  - Time zone\n  - Notification settings\n  - Admin interface theme\n- Live preview\n- Command palette available commands\n\nThe following functionality is described in the user interface:\n\n- Restore revisions\n- Markdown keyboard commands for rich text\n- Command palette trigger\n\nThe following functionality is described in the documentation:\n\n- Comment shortcut\n- Rich text keyboard shortcuts\n\nThe following functionality is provided by the underlying platform:\n\n- Embeds titles as alt text for embedded content","level":"A","evaluatedLevel":"Level A","evaluated":true},"document-all-features":{"id":"document-all-features","num":"A.4.2.2","handle":"Document All Features","result":"Failed","observations":"Here is a high-level record of whether given functionality is documented. As a summary:\n\n- For 19 high-level functional areas, 11 are partially documented and one is fully documented.\n- For 141 specific features, 38 are documented.\n\nThis record does not cover functionality provided by the underlying platform (for example; automated embed creation) or unused by authors.\n\nFor 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](https://wagtail.org/accessibility/atag-audit/#a422-document-all-features).","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"content-after-authoring-session":{"id":"content-after-authoring-session","num":"B.1.1.1","handle":"Content Auto-Generation After Authoring Sessions (WCAG)","result":"Passed","observations":"Wagtail doesn’t automatically generate content after authoring sessions. Processes that operate after authoring sessions and could alter the content are [scheduled publishing](https://docs.wagtail.org/en/stable/reference/pages/theory.html#id2) and [search index](https://docs.wagtail.org/en/stable/topics/search/indexing.html#wagtailsearch-indexing-update) updates, but in both cases any automatically-generated content would already be present during the session.","level":"A, AA, AAA","evaluatedLevel":"Level AAA","evaluated":true},"content-during-authoring-session":{"id":"content-during-authoring-session","num":"B.1.1.2","handle":"Content Auto-Generation During Authoring Sessions (WCAG)","result":"Failed","observations":"Wagtail automatically generates content in a few scenarios. In the following scenarios, markup is accessible without further work:\n\n- Pass: Links markup for links to pages, documents, external URLs, email addresses, phone numbers, and internal anchors within rich text fields.\n- Pass: Embeds for external resources within rich text fields.\n- Pass: Embeds for external resources in StreamField.\n- 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.\n- Pass: Table markup from TableBlock.\n\nIn the following scenarios, markup isn’t accessible out of the box:\n\n- 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. See [RFC 51: Contextual alt text](https://github.com/wagtail/rfcs/pull/51). Example: [Wagtail 5.1 - Editing Blog page Bread and Ciruses](https://static-wagtail-v5-1.netlify.app/admin-dark/pages/68/edit/).\n- Fail: Table markup from TypedTableBlock. This is lacking the ability to set row or column headers. See [TypedTableBlock issue #8507](https://github.com/wagtail/wagtail/issues/8507). Example: [Wagtail 5.1 - Editing Recipe page Hot Cross Bun](https://static-wagtail-v5-1.netlify.app/admin-dark/pages/81/edit/).\n\nWagtail 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](https://github.com/wagtail/wagtail/issues/10136).\n\nProposed actions:\n\n- Complete alt text improvements as part of [RFC 51: Contextual alt text](https://github.com/wagtail/rfcs/pull/51)\n- Implement [Accessibility checker in page editor #10136](https://github.com/wagtail/wagtail/issues/10136)\n- Fix [TypedTableBlock issue #8507](https://github.com/wagtail/wagtail/issues/8507)","level":"A, AA, AAA","evaluatedLevel":"Level AA"},"restructuring-recording-transformations":{"id":"restructuring-recording-transformations","num":"B.1.2.1","handle":"Restructuring and Recoding Transformations","result":"Not applicable","observations":"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.\n\nIf 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.","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"copy-paste-in-authoring-tool":{"id":"copy-paste-in-authoring-tool","num":"B.1.2.2","handle":"Copy-Paste Inside Authoring Tool (WCAG)","result":"Passed","observations":"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.","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"optimizations-preserve-accessibility":{"id":"optimizations-preserve-accessibility","num":"B.1.2.3","handle":"Optimizations Preserve Accessibility","result":"Not applicable","observations":"Wagtail doesn’t perform any optimizations that would affect accessibility.","level":"A","evaluatedLevel":"Level A","evaluated":true},"text-alts-for-non-text-preserved":{"id":"text-alts-for-non-text-preserved","num":"B.1.2.4","handle":"Text Alternatives for Non-Text Content are Preserved","result":"Not applicable","observations":"See _B.1.2.1 Restructuring and Recoding Transformations (WCAG)_.","level":"A","evaluatedLevel":"Level A","evaluated":true},"accessible-content-possible":{"id":"accessible-content-possible","num":"B.2.1.1","handle":"Ensure that accessible content production is possible. ","result":"Failed","observations":"Wagtail places extensive restrictions on the production of web content, which all nonetheless allow for the production of accessible content, with the exception of:\n\n- 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](https://static-wagtail-v5-1.netlify.app/admin-dark/pages/68/edit/).\n- 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](https://static-wagtail-v5-1.netlify.app/admin-dark/pages/81/edit/).\n- Missing support for setting `lang` attributes within rich text.\n\nProposed actions:\n\n- Complete alt text improvements as part of [RFC 51: Contextual alt text](https://github.com/wagtail/rfcs/pull/51)\n- Fix [TypedTableBlock issue #8507](https://github.com/wagtail/wagtail/issues/8507)\n- Implement [Feature request: Support for declaring language on elements in rich text. #4694](https://github.com/wagtail/wagtail/issues/4694)","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"accessible-option-prominence":{"id":"accessible-option-prominence","num":"B.2.2.1","handle":"Accessible Option Prominence (WCAG)","result":"Passed","observations":"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.\n\nFor StreamField block formats, the order is up to each site implementer to decide on. There are no built-in formats that are automatically included.","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"setting-accessibility-props":{"id":"setting-accessibility-props","num":"B.2.2.2","handle":"Setting Accessibility Properties (WCAG)","result":"Not applicable","observations":"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.\n\nSee:\n\n- [Feature request: Support for declaring language on elements in rich text. #4694](https://github.com/wagtail/wagtail/issues/4694)\n- [Feature: ability to set links as \"nofollow\" rel via the WYSIWG editor's link chooser #4474](https://github.com/wagtail/wagtail/issues/4474)","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"alternative-content-editable":{"id":"alternative-content-editable","num":"B.2.3.1","handle":"Alternative Content is Editable (WCAG)","result":"Failed","observations":"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](https://github.com/wagtail/rfcs/pull/51).","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"automatic-repair-of-text-alts":{"id":"automatic-repair-of-text-alts","num":"B.2.3.2","handle":"Automating Repair of Text Alternatives","result":"Passed","observations":"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.","level":"A","evaluatedLevel":"Level A","evaluated":true},"save-for-reuse":{"id":"save-for-reuse","num":"B.2.3.3","handle":"Save for Reuse","result":"Failed","observations":"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.\n\nSuggested action: incorporate this requirement into [RFC 51: Contextual alt text](https://github.com/wagtail/rfcs/pull/51).","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"accessible-template-options":{"id":"accessible-template-options","num":"B.2.4.1","handle":"Accessible Template Options (WCAG)","result":"Failed","observations":"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.\n\n- For rich text formats:\n  - blockquote is missing a cite attribute or a cite element within.\n- For Field block types:\n  - BlockQuoteBlock: No support for `cite` attribute or a `<cite>` element within.\n  - ImageChooserBlock: No support for alt text in context or marking as decorative.\n  - TypedTableBlock: No caption support. Header cells hard-coded to first row. No option to set row headers.\n- For Structural block types: all 4 have no issues\n- For form builder field types: all except \"Hidden field\" have issues with programmatic errors and help text.\n\nForm builder field type issues may be addressed in the future, via improvements in Django. See:\n\n- [Django ticket #32820 – Fields’ errors should be programmatically associated with fields.](https://code.djangoproject.com/ticket/32820)\n- [Django ticket #32819 - Fields’ help text and errors should be associated with input](https://code.djangoproject.com/ticket/32819)\n\nProposed actions:\n\n- [Re-review with Django 5.0 improvements](https://docs.djangoproject.com/en/dev/releases/5.0/)\n- Add cite attribute support to BlockQuote block\n\nFor a full tabular view of all template options’ status, see [B.2.4. Assist authors with accessible templates - Wagtail ATAG 2.0 report](https://wagtail.org/accessibility/atag-audit/#b24-assist-authors-with-accessible-templates).","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"identify-template-accessibility":{"id":"identify-template-accessibility","num":"B.2.4.2","handle":"Identify Template Accessibility","result":"Passed","observations":"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.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"author-created-templates":{"id":"author-created-templates","num":"B.2.4.3","handle":"Author-Created Templates","result":"Failed","observations":"Wagtail doesn’t allow authors to create custom block templates.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"accessible-template-options-enhanced":{"id":"accessible-template-options-enhanced","num":"B.2.4.4","handle":"Accessible Template Options (Enhanced)","result":"Failed","observations":"Some of Wagtail’s template options aren’t accessible. See _B.2.4.1 Accessible Template Options_.","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"accessible-pre-authored-content-options":{"id":"accessible-pre-authored-content-options","num":"B.2.5.1","handle":"Accessible Pre-Authored Content Options","result":"Not applicable","observations":"Wagtail doesn’t provide pre-authored content.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"identify-pre-authored-content-accessibility":{"id":"identify-pre-authored-content-accessibility","num":"B.2.5.2","handle":"Identify Pre-Authored Content Accessibility","result":"Not applicable","observations":"Wagtail doesn’t provide pre-authored content.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"checking-assistance":{"id":"checking-assistance","num":"B.3.1.1","handle":"Checking Assistance (WCAG)","result":"Failed","observations":"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:\n\n- `button-name`: `<button>` elements must always have a text label.\n- `empty-heading`: This rule checks for headings with no text content. Empty headings are confusing to screen readers users and should be avoided.\n- `empty-table-header`: Table header text should not be empty\n- `frame-title`: `<iframe>` elements must always have a text label.\n- `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.).\n- `input-button-name`: `<input>` button elements must always have a text label.\n- `link-name`: `<a>` link elements must always have a text label.\n- `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.\n\nThere are a number of success criteria that do not have automated checks nor instructions for manual checking:\n\n- 1.1.1 Non-text Content (A) – specifically instructions on correct entry of alt text, and marking images as decorative when appropriate\n- 2.4.4 Link Purpose (In Context) (AA) – instructions and potentially limited automated checks on correct link text (avoid \"click here\")\n- 1.4.5 Images of Text (AA) – instructions on avoiding images of text except for scenarios where there is no alternative\n- 2.4.9 Link Purpose (Link Only) (AAA) – see above\n- 1.4.9 Images of Text (No Exception) (AAA) – see above\n- 3.1.5 Reading Level (AAA) – instructions for manual checking or automated checks\n- 2.4.10 Section Headings (AAA) – instructions for manual checking or automated checks\n- 3.3.5 Help (AAA) – instructions for manual checking or automated checks for the form builder\n\nProposed actions:\n\n- Implement more automated checks for WCAG SCs in question. [Content quality checkers #11063](https://github.com/wagtail/wagtail/discussions/11063)\n- Implement a manual check process for WCAG SCs in question. [Content quality checkers #11063](https://github.com/wagtail/wagtail/discussions/11063)\n- Roadmap: [Readability checks #50](https://github.com/wagtail/roadmap/issues/50)\n- Content quality API integrations for text quality and image computer vision\n- Improve options for organizations to embed their own instructions within the CMS, via HelpBlock and help text.","level":"A, AA, AAA","evaluatedLevel":"Level AAA","evaluated":true},"help-authors-decide":{"id":"help-authors-decide","num":"B.3.1.2","handle":"Help Authors Decide","result":"Not applicable","observations":"Currently all of Wagtail’s automated checks are pass/fail with no author input required. Discussion on further checks: [Content quality checkers #11063](https://github.com/wagtail/wagtail/discussions/11063)","level":"A","evaluatedLevel":"Level A","evaluated":true},"help-authors-locate":{"id":"help-authors-locate","num":"B.3.1.3","handle":"Help Authors Locate","result":"Not applicable","observations":"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:\n\n- [Content quality checkers #11063](https://github.com/wagtail/wagtail/discussions/11063)\n- [Accessibility checker in page editor #10136](https://github.com/wagtail/wagtail/issues/10136)\n- Correct identification of Wagtail content so errors are only reported on CMS-managed content","level":"A","evaluatedLevel":"Level A","evaluated":true},"status-report":{"id":"status-report","num":"B.3.1.4","handle":"Status Report","result":"Passed","observations":"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.\n\nPossible improvements:\n\n- [Content quality checkers #11063](https://github.com/wagtail/wagtail/discussions/11063) – making this data available in more readily accessible reports\n- Consider making the information easily copy-pasteable","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"programmatic-association-of-rules":{"id":"programmatic-association-of-rules","num":"B.3.1.5","handle":"Programmatic Association of Results","result":"Failed","observations":"Currently the association isn’t programmatic, due to expected compatibility issues.\n\nPossible resolution: Correct identification of Wagtail content so errors are only reported on CMS-managed content.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"repair-assistance":{"id":"repair-assistance","num":"B.3.2.1","handle":"Repair Assistance (WCAG","result":"Failed","observations":"Currently Wagtail’s 8 rules report the presence of a problem but do not suggest specific solutions.\n\nProposed improvements:\n\n- [Content quality checkers #11063](https://github.com/wagtail/wagtail/discussions/11063)\n- [Accessibility checker in page editor #10136](https://github.com/wagtail/wagtail/issues/10136)\n- Correct identification of Wagtail content so errors are only reported on CMS-managed content","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"features-active-by-default":{"id":"features-active-by-default","num":"B.4.1.1","handle":"Features Active by Default","result":"Passed","observations":"Wagtail’s accessibility checker is on by default and cannot be turned off unless site implementers make CMS customizations in code.","level":"A","evaluatedLevel":"Level A","evaluated":true},"option-to-reactivate-features":{"id":"option-to-reactivate-features","num":"B.4.1.2","handle":"Option to Reactivate Features","result":"Passed","observations":"See _B.4.1.1 Features Active by Default_.","level":"A","evaluatedLevel":"Level A","evaluated":true},"feature-deactivation-warning":{"id":"feature-deactivation-warning","num":"B.4.1.3","handle":"Feature Deactivation Warning","result":"Passed","observations":"See _B.4.1.1 Features Active by Default_.","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"feature-prominence":{"id":"feature-prominence","num":"B.4.1.4","handle":"Feature Prominence","result":"Passed","observations":"Wagtail currently has no features relating to invalid markup, syntax errors, spelling errors, grammar errors. Possible future changes:\n\n- Implement more automated checks for WCAG SCs in question. [Content quality checkers #11063](https://github.com/wagtail/wagtail/discussions/11063)\n- Implement a manual check process for WCAG SCs in question. [Content quality checkers #11063](https://github.com/wagtail/wagtail/discussions/11063)\n- Roadmap: [Readability checks #50](https://github.com/wagtail/roadmap/issues/50)","level":"AA","evaluatedLevel":"Level AA","evaluated":true},"model-practice":{"id":"model-practice","num":"B.4.2.1","handle":"Model Practice (WCAG)","result":"Passed","observations":"Wagtail’s documentation for content authors does not demonstrate accessible authoring practices. The documentation for developers does: [Accessibility considerations](https://docs.wagtail.org/en/stable/advanced_topics/accessibility_considerations.html).\n\nProposed actions:\n\n- [Accessibility features documentation #69](https://github.com/wagtail/roadmap/issues/69)\n- Add accessibility criteria to contributor documentation for documentation writing\n- Review developer documentation for accessibility improvements in examples","level":"A, AA, AAA","evaluatedLevel":"Level AA","evaluated":true},"feature-instructions":{"id":"feature-instructions","num":"B.4.2.2","handle":"Feature Instructions","result":"Failed","observations":"Wagtail’s accessibility checker and alt text setting aren’t documented in the guide for content authors. The documentation for developers does cover this.\n\nProposed actions:\n\n- Documentation review to ensure all accessibility features are documented.\n  - Document all accessibility features in developer documentation.\n  - [Accessibility features documentation #69](https://github.com/wagtail/roadmap/issues/69)","level":"A","evaluatedLevel":"Level A","evaluated":true},"tutorial":{"id":"tutorial","num":"B.4.2.3","handle":"Tutorial","result":"Failed","observations":"Wagtail’s accessibility features doesn’t have a tutorial.\n\nProposed actions:\n\n- Create a written tutorial in addition to how-to material.\n- Create a video tutorial in addition to the user guide website.","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true},"instruction-index":{"id":"instruction-index","num":"B.4.2.4","handle":"Instruction Index","result":"Failed","observations":"Wagtail’s documentation for content author does not have such an index. The documentation for developers does.\n\nProposed actions:\n\n- Add an index of accessibility features to the user guide.\n- [Outreachy: Accessibility features documentation](https://wagtail.org/blog/our-outreachy-projects-in-2023/)","level":"AAA","evaluatedLevel":"Level AAA","evaluated":true}},"meta":{"name":{"id":"name","value":"Wagtail"},"website":{"id":"website","value":"https://wagtail.org/"},"executiveSummary":{"id":"executiveSummary","value":"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.\n\nHigh-level results conformance results at the success criteria level as per the [W3C ATAG report tool](https://www.w3.org/WAI/atag/report-tool/), pass/fail:\n\n- Total: 22 **Pass**, 28 **Fail**, 12 **Not applicable**.\n- Part A: 12 **Pass**, 15 **Fail**, 4 **Not applicable**.\n- Part B: 10 **Pass**, 13 **Fail**, 8 **Not applicable**.\n\nAt the guidelines level as per the [W3C Authoring Tools list](https://www.w3.org/WAI/tools-list/authoring/), with partial support:\n\n- Part A: 2 **Pass**, 9 **Partially**, 1 **Fail**, 1 **Not applicable**.\n- Part B: 3 **Pass**, 6 **Partially**, 1 **Fail**, 1 **Not applicable**\n\nAll of the audit was conducted on Wagtail 5.1.1 released on 2023-08-14, on the demo site [Static Wagtail 5.1 demo](https://static-wagtail-v5-1.netlify.app/admin/) unless indicated otherwise.\n\nThe full audit is available at [wagtail.org/accessibility/atag-audit/](https://wagtail.org/accessibility/atag-audit/)\n\n---\n\nThis audit was conducted as part of Roadmap item [#27: WCAG 2.1 AA for Wagtail admin](https://github.com/wagtail/roadmap/issues/27), to inform upcoming roadmap items:\n\n- [WCAG 2.2 manual audit #63](https://github.com/wagtail/roadmap/issues/63)\n- [Accessibility checker in page editor #66](https://github.com/wagtail/roadmap/issues/66)\n- [Accessibility features documentation #69](https://github.com/wagtail/roadmap/issues/69)\n- [Admin accessibility improvements #71](https://github.com/wagtail/roadmap/issues/71)"},"evaluatorName":{"id":"evaluatorName","value":"Thibaud Colas"},"evaluatorOrg":{"id":"evaluatorOrg","value":"Wagtail"},"evaluationId":{"id":"evaluationId","value":"Tue Oct 31 2023"},"conformanceTarget":{"id":"conformanceTarget","value":"AAA"},"createdWith":{"id":"createdWith","value":"0.6.0"}}}

## wai-authoring-tools-list-formdata.json
[
  "submission",
  "1",
  "/WAI/tools-list/authoring/submit-a-tool/success.html",
  "/WAI/tools-list/authoring/submit-a-tool/failure.html",
  "wai-authoring-tools-list",
  "Thibaud Colas",
  "thibaudcolas@gmail.com",
  "Wagtail",
  "https://wagtail.org/",
  "Wagtail",
  "A Django content management system focused on flexibility and user experience",
  "https://wagtail.org/accessibility/",
  "free",
  "v5.1.1",
  "2023-08-14",
  "partially",
  "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.",
  "not applicable",
  "",
  "partially",
  "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.\n\nSee https://wagtail.org/accessibility/atag-audit/#a211-text-alternatives-for-rendered-non-text-content for specific occurrences where we are aware improvement is needed.",
  "partially",
  "Wagtail uses the following status indicators in editing views:\n\n- 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.\n- Fail: Comments in rich text. Comments are displayed as highlighted text within the rich text field. The association isn’t programmatically exposed.\n- 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\").",
  "partially",
  "Though the majority of the authoring tool’s functionality is keyboard accessible, there are seven specific areas that aren’t:\n\n- 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\".\n- In rich text fields, pin/unpin of the rich text toolbar.\n- In rich text fields, Edit functionality for links, documents, images, embeds.\n- In image/document/page/task/snippet choosers, the chooser dialog.\n- In page listings, manual sorting of pages.\n- In image create/edit forms, creation or editing of a focal area.\n- In table blocks, editing of the table.\n\nSee https://wagtail.org/accessibility/atag-audit/#a311-keyboard-access-minimum for the full status and proposed changes.",
  "partially",
  "Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the default session time limit is 2 weeks.",
  "no",
  "",
  "partially",
  "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.",
  "partially",
  "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.",
  "yes",
  "",
  "yes",
  "",
  "partially",
  "Though a large number of authoring actions are reversible, not all are. The following actions are reversible:\n\n- Plain text and rich text content editing within specific fields, reversible until the user submits the form.\n- Editing of page or snippets content supporting revisions, reversible for the whole page/snippet at any later point in the site’s history.\n\nThe following actions are not reversible but do require confirmation to proceed:\n\n- Permanent deletion of any content which has its own dedicated creation/editing views.\n- Unpublishing of pages and snippets.\n- Deletion of comments within page content.\n\nThe following actions are not reversible and do not require confirmation to proceed:\n\n- StreamField / InlinePanel block-based content editing, reversible only as part of support for content revisions.\n  - Consider implementing an in-browser undo-redo stack for those interactions.\n- Image / Document / Page / Task / Snippet / Embed chooser fields, reversible only as part of support for content revisions.\n  - Consider implementing an in-browser undo-redo stack for those interactions.\n- Authoring actions on content that does not support revisions such as images, documents, etc.\n  - Implement either a confirmation step for those actions, or revisions/versioning support.",
  "partially",
  "The following functionality would be used to meet Part A and needs to be described either in the documentation or in the user interface:\n\n- Image title fields’ usage as alt text\n- Page-level keyboard shortcuts\n- Skip link\n- Collapsible sections\n- Link to specific collapsible sections\n- Collapse/expand all\n- Minimap\n- Session time limit\n- Editing of headings and elements nesting in rich text fields\n- Text search\n- Browser-level UI settings\n  - Sidebar expanded/collapsed\n  - Rich text toolbar pinned/unpinned\n  - Minimap opened/closed\n  - Currently-open side panel\n- Profile-level UI settings\n  - Language\n  - Time zone\n  - Notification settings\n  - Admin interface theme\n- Live preview\n- Command palette available commands\n\nThe following functionality is described in the user interface:\n\n- Restore revisions\n- Markdown keyboard commands for rich text\n- Command palette trigger\n\nThe following functionality is described in the documentation:\n\n- Comment shortcut\n- Rich text keyboard shortcuts\n\nThe following functionality is provided by the underlying platform:\n\n- Embeds titles as alt text for embedded content\n\nSee https://wagtail.org/accessibility/atag-audit/#a422-document-all-features for a full record of which features are and aren’t documented.",
  "partially",
  "Wagtail automatically generates content in a few scenarios. In the following scenarios, markup is accessible without further work:\n\n- Pass: Links markup for links to pages, documents, external URLs, email addresses, phone numbers, and internal anchors within rich text fields.\n- Pass: Embeds for external resources within rich text fields.\n- Pass: Embeds for external resources in StreamField.\n- 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.\n- Pass: Table markup from TableBlock.\n\nIn the following scenarios, markup isn’t accessible out of the box:\n\n- 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.\n- Fail: Table markup from TypedTableBlock. This is lacking the ability to set row or column headers. \n\nWagtail 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).",
  "yes",
  "",
  "partially",
  "Wagtail places extensive restrictions on the production of web content, which all nonetheless allow for the production of accessible content, with the exception of:\n\n- 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.\n- Missing support for table/row headers with TypedTableBlock. This could be worked around by only creating tables with TableBlock, which is possible but unlikely. \n- 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.",
  "yes",
  "",
  "partially",
  "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.",
  "partially",
  "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.\n\nFor form fields in the form builder, a wide range of fields have accessibility issues with no alternatives available.\n\nThere are known issues with:\n\n- Blockquotes in rich text (no cite field)\n- Blockquotes in StreamField (no cite field)\n- Images in StreamField (no alt text field)\n- TypedTableBlock in StreamField (no caption, no column header or row header support)\n\nSee https://wagtail.org/accessibility/atag-audit/#b241-accessible-template-options-wcag for a full record of accessibility issues in content templates",
  "not applicable",
  "",
  "partially",
  "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:\n\n- `button-name`: `<button>` elements must always have a text label.\n- `empty-heading`: This rule checks for headings with no text content. Empty headings are confusing to screen readers users and should be avoided.\n- `empty-table-header`: Table header text should not be empty\n- `frame-title`: `<iframe>` elements must always have a text label.\n- `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.).\n- `input-button-name`: `<input>` button elements must always have a text label.\n- `link-name`: `<a>` link elements must always have a text label.\n- `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.\n\nThere are a number of success criteria that do not have automated checks nor instructions for manual checking:\n\n- 1.1.1 Non-text Content (A) – specifically instructions on correct entry of alt text, and marking images as decorative when appropriate\n- 2.4.4 Link Purpose (In Context) (AA) – instructions and potentially limited automated checks on correct link text (avoid \"click here\")\n- 1.4.5 Images of Text (AA) – instructions on avoiding images of text except for scenarios where there is no alternative\n- 2.4.9 Link Purpose (Link Only) (AAA) – see above\n- 1.4.9 Images of Text (No Exception) (AAA) – see above\n- 3.1.5 Reading Level (AAA) – instructions for manual checking or automated checks\n- 2.4.10 Section Headings (AAA) – instructions for manual checking or automated checks\n- 3.3.5 Help (AAA) – instructions for manual checking or automated checks for the form builder\n\nAll 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.",
  "no",
  "",
  "yes",
  "",
  "partially",
  "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.",
  "Thank you to the Wagtail accessibility team for the foundational work that made this audit and report possible. Thank you to Torchbox for sponsoring this audit and associated reporting.\n\nAdditional thanks to Albina Starykova, Joshua Munn, Sage Abdullah, Thibaud Colas, and Nick Lee for their work on Wagtail’s first ever accessibility checker (https://wagtail.org/blog/introducing-wagtails-new-accessibility-checker/), which was essential for us to partly meet B.3. and B.4. guidelines.\n\n---\n\nOur full report in Markdown/HTML is available at https://wagtail.org/accessibility/atag-audit/\n\nOur full report in the ATAG Report Tool format is available at https://gist.github.com/thibaudcolas/c48b0b4cf8e7966cd09d22677ab63173."
]

## wai-authoring-tools-list-formdata.txt
form_name: submission
form_version: 1
success: /WAI/tools-list/authoring/submit-a-tool/success.html
failure: /WAI/tools-list/authoring/submit-a-tool/failure.html
repository: wai-authoring-tools-list
submitter-name: Thibaud Colas
submitter-email: thibaudcolas@gmail.com
tool-name: Wagtail
tool-link: https://wagtail.org/
tool-vendor: Wagtail
tool-description: A Django content management system focused on flexibility and user experience.
tool-statement: https://wagtail.org/accessibility/
tool-license: free
tool-version: v5.1.1
tool-release-date: 2023-08-14
question-web-based-accessible: partially
web-based-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.
question-non-web-based-accessible: not applicable
non-web-based-accessible-partially-description:
question-alt-available: partially
alt-available-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").
question-works-with-keyboard: 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.
question-enough-time: partially
enough-time-partially-description: Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the default session time limit is 2 weeks.
question-flashing-optional: no
flashing-optional-partially-description:
question-navigate-by-structure: partially
navigate-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.
question-content-searchable: partially
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.
question-supports-display-prefs: yes
supports-display-prefs-partially-description:
question-previews-accessible: yes
previews-accessible-partially-description:
question-prevent-mistakes: partially
prevent-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.
question-features-documented: partially
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.
question-auto-content-accessible: partially
auto-content-accessible-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).
question-accessibility-information-preserved: yes
accessibility-information-preserved-partially-description:
question-accessible-content-production-possible: partially
accessible-content-production-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.
question-editors-guided: yes
editors-guided-partially-description:
question-alternatives-manageable: partially
alternatives-manageable-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.
question-accessible-templates-available: partially
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
question-accessible-components-available: not applicable
accessible-components-available-partially-description:
question-automatically-checks: partially
automatically-checks-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.
question-helps-fix-problems: no
helps-fix-problems-partially-description:
question-features-promote-accessibility: yes
features-promote-accessibility-partially-description:
question-documentation-promotes-accessibility: partially
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.
comments: Thank you to the Wagtail accessibility team for the foundational work that made this audit and report possible. Thank you to Torchbox for sponsoring this audit and associated reporting.

Additional thanks to Albina Starykova, Joshua Munn, Sage Abdullah, Thibaud Colas, and Nick Lee for their work on Wagtail’s first ever accessibility checker (https://wagtail.org/blog/introducing-wagtails-new-accessibility-checker/), which was essential for us to partly meet B.3. and B.4. guidelines.

---

Our full report in Markdown/HTML is available at https://wagtail.org/accessibility/atag-audit/

Our full report in the ATAG Report Tool format is available at https://gist.github.com/thibaudcolas/c48b0b4cf8e7966cd09d22677ab63173.

## wai-authoring-tools-list-preview.html
<dl>
  <dt>Your name</dt>
  <dd>Thibaud Colas</dd>
  <dt>Email</dt>
  <dd>thibaudcolas@gmail.com</dd>
  <dt>Tool name</dt>
  <dd>Wagtail</dd>
  <dt>Link to tool main page</dt>
  <dd>https://wagtail.org/</dd>
  <dt>Vendor</dt>
  <dd>Wagtail</dd>
  <dt>Description</dt>
  <dd>
    A Django content management system focused on flexibility and user
    experience
  </dd>
  <dt>Link to accessibility information</dt>
  <dd>https://wagtail.org/accessibility/</dd>
  <dt>License (required)</dt>
  <dd>Free</dd>
  <dt>Version</dt>
  <dd>v5.1.1</dd>
  <dt>Release date (of this version)</dt>
  <dd>14 August 2023</dd>
  <dt>Web-based functionality is accessible</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    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.
  </dd>
  <dt>Non-web-based functionality is accessible</dt>
  <dd>Not applicable</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Alternative content available to editors</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    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.<br /><br />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.
  </dd>
  <dt>Editing-view presentation can be programmatically determined</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    Wagtail uses the following status indicators in editing views:<br /><br />-
    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.<br />- Fail:
    Comments in rich text. Comments are displayed as highlighted text within
    the rich text field. The association isn’t programmatically exposed.<br />-
    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").
  </dd>
  <dt>Works with keyboard</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    Though the majority of the authoring tool’s functionality is keyboard
    accessible, there are seven specific areas that aren’t:<br /><br />- 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".<br />- In rich text fields, pin/unpin of the
    rich text toolbar.<br />- In rich text fields, Edit functionality for
    links, documents, images, embeds.<br />- In
    image/document/page/task/snippet choosers, the chooser dialog.<br />- In
    page listings, manual sorting of pages.<br />- In image create/edit forms,
    creation or editing of a focal area.<br />- In table blocks, editing of
    the table.<br /><br />See
    https://wagtail.org/accessibility/atag-audit/#a311-keyboard-access-minimum
    for the full status and proposed changes.
  </dd>
  <dt>Enough time</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the
    default session time limit is 2 weeks.
  </dd>
  <dt>Flashing content optional</dt>
  <dd>No</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Content can be navigated by structure</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    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.
  </dd>
  <dt>Content searchable</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    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.
  </dd>
  <dt>Supports display preferences</dt>
  <dd>Yes</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Previews are accessible</dt>
  <dd>Yes</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Helps editor prevent and correct mistakes</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    Though a large number of authoring actions are reversible, not all are.
    The following actions are reversible:<br /><br />- Plain text and rich
    text content editing within specific fields, reversible until the user
    submits the form.<br />- Editing of page or snippets content supporting
    revisions, reversible for the whole page/snippet at any later point in the
    site’s history.<br /><br />The following actions are not reversible but do
    require confirmation to proceed:<br /><br />- Permanent deletion of any
    content which has its own dedicated creation/editing views.<br />-
    Unpublishing of pages and snippets.<br />- Deletion of comments within
    page content.<br /><br />The following actions are not reversible and do
    not require confirmation to proceed:<br /><br />- StreamField /
    InlinePanel block-based content editing, reversible only as part of
    support for content revisions.<br />
    - Consider implementing an in-browser undo-redo stack for those
    interactions.<br />- Image / Document / Page / Task / Snippet / Embed
    chooser fields, reversible only as part of support for content
    revisions.<br />
    - Consider implementing an in-browser undo-redo stack for those
    interactions.<br />- Authoring actions on content that does not support
    revisions such as images, documents, etc.<br />
    - Implement either a confirmation step for those actions, or
    revisions/versioning support.
  </dd>
  <dt>(Accessibility) features documented</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    The following functionality would be used to meet Part A and needs to be
    described either in the documentation or in the user interface:<br /><br />-
    Image title fields’ usage as alt text<br />- Page-level keyboard
    shortcuts<br />- Skip link<br />- Collapsible sections<br />- Link to
    specific collapsible sections<br />- Collapse/expand all<br />- Minimap<br />-
    Session time limit<br />- Editing of headings and elements nesting in rich
    text fields<br />- Text search<br />- Browser-level UI settings<br />
    - Sidebar expanded/collapsed<br />
    - Rich text toolbar pinned/unpinned<br />
    - Minimap opened/closed<br />
    - Currently-open side panel<br />- Profile-level UI settings<br />
    - Language<br />
    - Time zone<br />
    - Notification settings<br />
    - Admin interface theme<br />- Live preview<br />- Command palette
    available commands<br /><br />The following functionality is described in
    the user interface:<br /><br />- Restore revisions<br />- Markdown
    keyboard commands for rich text<br />- Command palette trigger<br /><br />The
    following functionality is described in the documentation:<br /><br />-
    Comment shortcut<br />- Rich text keyboard shortcuts<br /><br />The
    following functionality is provided by the underlying platform:<br /><br />-
    Embeds titles as alt text for embedded content<br /><br />See
    https://wagtail.org/accessibility/atag-audit/#a422-document-all-features
    for a full record of which features are and aren’t documented.
  </dd>
  <dt>Generates accessible markup</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    Wagtail automatically generates content in a few scenarios. In the
    following scenarios, markup is accessible without further work:<br /><br />-
    Pass: Links markup for links to pages, documents, external URLs, email
    addresses, phone numbers, and internal anchors within rich text fields.<br />-
    Pass: Embeds for external resources within rich text fields.<br />- Pass:
    Embeds for external resources in StreamField.<br />- 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.<br />-
    Pass: Table markup from TableBlock.<br /><br />In the following scenarios,
    markup isn’t accessible out of the box:<br /><br />- 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.<br />- Fail: Table markup from TypedTableBlock.
    This is lacking the ability to set row or column headers.
    <br /><br />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).
  </dd>
  <dt>Preserves accessibility information</dt>
  <dd>Yes</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Accessible content production is possible</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    Wagtail places extensive restrictions on the production of web content,
    which all nonetheless allow for the production of accessible content, with
    the exception of:<br /><br />- 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.<br />- Missing support for table/row
    headers with TypedTableBlock. This could be worked around by only creating
    tables with TableBlock, which is possible but unlikely. <br />- 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.
  </dd>
  <dt>Editors guided</dt>
  <dd>Yes</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Text alternatives can be managed</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    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.
  </dd>
  <dt>Accessible templates available</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    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.<br /><br />For form fields in the form builder, a
    wide range of fields have accessibility issues with no alternatives
    available.<br /><br />There are known issues with:<br /><br />-
    Blockquotes in rich text (no cite field)<br />- Blockquotes in StreamField
    (no cite field)<br />- Images in StreamField (no alt text field)<br />-
    TypedTableBlock in StreamField (no caption, no column header or row header
    support)<br /><br />See
    https://wagtail.org/accessibility/atag-audit/#b241-accessible-template-options-wcag
    for a full record of accessibility issues in content templates
  </dd>
  <dt>Accessible components/plug-ins available</dt>
  <dd>Not applicable</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Checks accessibility automatically</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    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:<br /><br />- `button-name`: `&lt;button&gt;`
    elements must always have a text label.<br />- `empty-heading`: This rule
    checks for headings with no text content. Empty headings are confusing to
    screen readers users and should be avoided.<br />- `empty-table-header`:
    Table header text should not be empty<br />- `frame-title`:
    `&lt;iframe&gt;` elements must always have a text label.<br />-
    `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.).<br />-
    `input-button-name`: `&lt;input&gt;` button elements must always have a
    text label.<br />- `link-name`: `&lt;a&gt;` link elements must always have
    a text label.<br />- `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.<br /><br />There
    are a number of success criteria that do not have automated checks nor
    instructions for manual checking:<br /><br />- 1.1.1 Non-text Content (A)
    –&nbsp;specifically instructions on correct entry of alt text, and marking
    images as decorative when appropriate<br />- 2.4.4 Link Purpose (In
    Context) (AA) –&nbsp;instructions and potentially limited automated checks
    on correct link text (avoid "click here")<br />- 1.4.5 Images of Text (AA)
    –&nbsp;instructions on avoiding images of text except for scenarios where
    there is no alternative<br />- 2.4.9 Link Purpose (Link Only) (AAA) – see
    above<br />- 1.4.9 Images of Text (No Exception) (AAA) – see above<br />-
    3.1.5 Reading Level (AAA) –&nbsp;instructions for manual checking or
    automated checks<br />- 2.4.10 Section Headings (AAA) – instructions for
    manual checking or automated checks<br />- 3.3.5 Help (AAA) – instructions
    for manual checking or automated checks for the form builder<br /><br />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.
  </dd>
  <dt>Helps content editors fix problems</dt>
  <dd>No</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Accessibility features prominent</dt>
  <dd>Yes</dd>
  <dt>Description</dt>
  <dd>Not provided</dd>
  <dt>Documentation promotes accessibility</dt>
  <dd>Partially</dd>
  <dt>Description</dt>
  <dd>
    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.
  </dd>
  <dt>Comments</dt>
  <dd>
    Thank you to the Wagtail accessibility team for the foundational work that
    made this audit and report possible. Thank you to Torchbox for sponsoring
    this audit and associated reporting.<br /><br />Additional thanks to
    Albina Starykova, Joshua Munn, Sage Abdullah, Thibaud Colas, and Nick Lee
    for their work on Wagtail’s first ever accessibility checker
    (https://wagtail.org/blog/introducing-wagtails-new-accessibility-checker/),
    which was essential for us to partly meet B.3. and B.4. guidelines.<br /><br />---<br /><br />Our
    full report in Markdown/HTML is available at
    https://wagtail.org/accessibility/atag-audit/<br /><br />Our full report
    in the ATAG Report Tool format is available at
    https://gist.github.com/thibaudcolas/c48b0b4cf8e7966cd09d22677ab63173.
  </dd>
</dl>
	[
	"submission",
	"1",
	"/WAI/tools-list/authoring/submit-a-tool/success.html",
	"/WAI/tools-list/authoring/submit-a-tool/failure.html",
	"wai-authoring-tools-list",
	"Thibaud Colas",
	"thibaudcolas@gmail.com",
	"Wagtail",
	"https://wagtail.org/",
	"Wagtail",
	"A Django content management system focused on flexibility and user experience",
	"https://wagtail.org/accessibility/",
	"free",
	"v5.1.1",
	"2023-08-14",
	"partially",
	"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.",
	"not applicable",
	"",
	"partially",
	"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.\n\nSee https://wagtail.org/accessibility/atag-audit/#a211-text-alternatives-for-rendered-non-text-content for specific occurrences where we are aware improvement is needed.",
	"partially",
	"Wagtail uses the following status indicators in editing views:\n\n- 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.\n- Fail: Comments in rich text. Comments are displayed as highlighted text within the rich text field. The association isn’t programmatically exposed.\n- 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\").",
	"partially",
	"Though the majority of the authoring tool’s functionality is keyboard accessible, there are seven specific areas that aren’t:\n\n- 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\".\n- In rich text fields, pin/unpin of the rich text toolbar.\n- In rich text fields, Edit functionality for links, documents, images, embeds.\n- In image/document/page/task/snippet choosers, the chooser dialog.\n- In page listings, manual sorting of pages.\n- In image create/edit forms, creation or editing of a focal area.\n- In table blocks, editing of the table.\n\nSee https://wagtail.org/accessibility/atag-audit/#a311-keyboard-access-minimum for the full status and proposed changes.",
	"partially",
	"Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the default session time limit is 2 weeks.",
	"no",
	"",
	"partially",
	"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.",
	"partially",
	"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.",
	"yes",
	"",
	"yes",
	"",
	"partially",
	"Though a large number of authoring actions are reversible, not all are. The following actions are reversible:\n\n- Plain text and rich text content editing within specific fields, reversible until the user submits the form.\n- Editing of page or snippets content supporting revisions, reversible for the whole page/snippet at any later point in the site’s history.\n\nThe following actions are not reversible but do require confirmation to proceed:\n\n- Permanent deletion of any content which has its own dedicated creation/editing views.\n- Unpublishing of pages and snippets.\n- Deletion of comments within page content.\n\nThe following actions are not reversible and do not require confirmation to proceed:\n\n- StreamField / InlinePanel block-based content editing, reversible only as part of support for content revisions.\n - Consider implementing an in-browser undo-redo stack for those interactions.\n- Image / Document / Page / Task / Snippet / Embed chooser fields, reversible only as part of support for content revisions.\n - Consider implementing an in-browser undo-redo stack for those interactions.\n- Authoring actions on content that does not support revisions such as images, documents, etc.\n - Implement either a confirmation step for those actions, or revisions/versioning support.",
	"partially",
	"The following functionality would be used to meet Part A and needs to be described either in the documentation or in the user interface:\n\n- Image title fields’ usage as alt text\n- Page-level keyboard shortcuts\n- Skip link\n- Collapsible sections\n- Link to specific collapsible sections\n- Collapse/expand all\n- Minimap\n- Session time limit\n- Editing of headings and elements nesting in rich text fields\n- Text search\n- Browser-level UI settings\n - Sidebar expanded/collapsed\n - Rich text toolbar pinned/unpinned\n - Minimap opened/closed\n - Currently-open side panel\n- Profile-level UI settings\n - Language\n - Time zone\n - Notification settings\n - Admin interface theme\n- Live preview\n- Command palette available commands\n\nThe following functionality is described in the user interface:\n\n- Restore revisions\n- Markdown keyboard commands for rich text\n- Command palette trigger\n\nThe following functionality is described in the documentation:\n\n- Comment shortcut\n- Rich text keyboard shortcuts\n\nThe following functionality is provided by the underlying platform:\n\n- Embeds titles as alt text for embedded content\n\nSee https://wagtail.org/accessibility/atag-audit/#a422-document-all-features for a full record of which features are and aren’t documented.",
	"partially",
	"Wagtail automatically generates content in a few scenarios. In the following scenarios, markup is accessible without further work:\n\n- Pass: Links markup for links to pages, documents, external URLs, email addresses, phone numbers, and internal anchors within rich text fields.\n- Pass: Embeds for external resources within rich text fields.\n- Pass: Embeds for external resources in StreamField.\n- 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.\n- Pass: Table markup from TableBlock.\n\nIn the following scenarios, markup isn’t accessible out of the box:\n\n- 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.\n- Fail: Table markup from TypedTableBlock. This is lacking the ability to set row or column headers. \n\nWagtail 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).",
	"yes",
	"",
	"partially",
	"Wagtail places extensive restrictions on the production of web content, which all nonetheless allow for the production of accessible content, with the exception of:\n\n- 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.\n- Missing support for table/row headers with TypedTableBlock. This could be worked around by only creating tables with TableBlock, which is possible but unlikely. \n- 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.",
	"yes",
	"",
	"partially",
	"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.",
	"partially",
	"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.\n\nFor form fields in the form builder, a wide range of fields have accessibility issues with no alternatives available.\n\nThere are known issues with:\n\n- Blockquotes in rich text (no cite field)\n- Blockquotes in StreamField (no cite field)\n- Images in StreamField (no alt text field)\n- TypedTableBlock in StreamField (no caption, no column header or row header support)\n\nSee https://wagtail.org/accessibility/atag-audit/#b241-accessible-template-options-wcag for a full record of accessibility issues in content templates",
	"not applicable",
	"",
	"partially",
	"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:\n\n- `button-name`: `<button>` elements must always have a text label.\n- `empty-heading`: This rule checks for headings with no text content. Empty headings are confusing to screen readers users and should be avoided.\n- `empty-table-header`: Table header text should not be empty\n- `frame-title`: `<iframe>` elements must always have a text label.\n- `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.).\n- `input-button-name`: `<input>` button elements must always have a text label.\n- `link-name`: `<a>` link elements must always have a text label.\n- `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.\n\nThere are a number of success criteria that do not have automated checks nor instructions for manual checking:\n\n- 1.1.1 Non-text Content (A) – specifically instructions on correct entry of alt text, and marking images as decorative when appropriate\n- 2.4.4 Link Purpose (In Context) (AA) – instructions and potentially limited automated checks on correct link text (avoid \"click here\")\n- 1.4.5 Images of Text (AA) – instructions on avoiding images of text except for scenarios where there is no alternative\n- 2.4.9 Link Purpose (Link Only) (AAA) – see above\n- 1.4.9 Images of Text (No Exception) (AAA) – see above\n- 3.1.5 Reading Level (AAA) – instructions for manual checking or automated checks\n- 2.4.10 Section Headings (AAA) – instructions for manual checking or automated checks\n- 3.3.5 Help (AAA) – instructions for manual checking or automated checks for the form builder\n\nAll 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.",
	"no",
	"",
	"yes",
	"",
	"partially",
	"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.",
	"Thank you to the Wagtail accessibility team for the foundational work that made this audit and report possible. Thank you to Torchbox for sponsoring this audit and associated reporting.\n\nAdditional thanks to Albina Starykova, Joshua Munn, Sage Abdullah, Thibaud Colas, and Nick Lee for their work on Wagtail’s first ever accessibility checker (https://wagtail.org/blog/introducing-wagtails-new-accessibility-checker/), which was essential for us to partly meet B.3. and B.4. guidelines.\n\n---\n\nOur full report in Markdown/HTML is available at https://wagtail.org/accessibility/atag-audit/\n\nOur full report in the ATAG Report Tool format is available at https://gist.github.com/thibaudcolas/c48b0b4cf8e7966cd09d22677ab63173."
	]
	form_name: submission
	form_version: 1
	success: /WAI/tools-list/authoring/submit-a-tool/success.html
	failure: /WAI/tools-list/authoring/submit-a-tool/failure.html
	repository: wai-authoring-tools-list
	submitter-name: Thibaud Colas
	submitter-email: thibaudcolas@gmail.com
	tool-name: Wagtail
	tool-link: https://wagtail.org/
	tool-vendor: Wagtail
	tool-description: A Django content management system focused on flexibility and user experience.
	tool-statement: https://wagtail.org/accessibility/
	tool-license: free
	tool-version: v5.1.1
	tool-release-date: 2023-08-14
	question-web-based-accessible: partially
	web-based-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.
	question-non-web-based-accessible: not applicable
	non-web-based-accessible-partially-description:
	question-alt-available: partially
	alt-available-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").
	question-works-with-keyboard: 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.
	question-enough-time: partially
	enough-time-partially-description: Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the default session time limit is 2 weeks.
	question-flashing-optional: no
	flashing-optional-partially-description:
	question-navigate-by-structure: partially
	navigate-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.
	question-content-searchable: partially
	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.
	question-supports-display-prefs: yes
	supports-display-prefs-partially-description:
	question-previews-accessible: yes
	previews-accessible-partially-description:
	question-prevent-mistakes: partially
	prevent-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.
	question-features-documented: partially
	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.
	question-auto-content-accessible: partially
	auto-content-accessible-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).
	question-accessibility-information-preserved: yes
	accessibility-information-preserved-partially-description:
	question-accessible-content-production-possible: partially
	accessible-content-production-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.
	question-editors-guided: yes
	editors-guided-partially-description:
	question-alternatives-manageable: partially
	alternatives-manageable-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.
	question-accessible-templates-available: partially
	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
	question-accessible-components-available: not applicable
	accessible-components-available-partially-description:
	question-automatically-checks: partially
	automatically-checks-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.
	question-helps-fix-problems: no
	helps-fix-problems-partially-description:
	question-features-promote-accessibility: yes
	features-promote-accessibility-partially-description:
	question-documentation-promotes-accessibility: partially
	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.
	comments: Thank you to the Wagtail accessibility team for the foundational work that made this audit and report possible. Thank you to Torchbox for sponsoring this audit and associated reporting.

	Additional thanks to Albina Starykova, Joshua Munn, Sage Abdullah, Thibaud Colas, and Nick Lee for their work on Wagtail’s first ever accessibility checker (https://wagtail.org/blog/introducing-wagtails-new-accessibility-checker/), which was essential for us to partly meet B.3. and B.4. guidelines.

	---

	Our full report in Markdown/HTML is available at https://wagtail.org/accessibility/atag-audit/

	Our full report in the ATAG Report Tool format is available at https://gist.github.com/thibaudcolas/c48b0b4cf8e7966cd09d22677ab63173.
	<dl>
	<dt>Your name</dt>
	<dd>Thibaud Colas</dd>
	<dt>Email</dt>
	<dd>thibaudcolas@gmail.com</dd>
	<dt>Tool name</dt>
	<dd>Wagtail</dd>
	<dt>Link to tool main page</dt>
	<dd>https://wagtail.org/</dd>
	<dt>Vendor</dt>
	<dd>Wagtail</dd>
	<dt>Description</dt>
	<dd>
	A Django content management system focused on flexibility and user
	experience
	</dd>
	<dt>Link to accessibility information</dt>
	<dd>https://wagtail.org/accessibility/</dd>
	<dt>License (required)</dt>
	<dd>Free</dd>
	<dt>Version</dt>
	<dd>v5.1.1</dd>
	<dt>Release date (of this version)</dt>
	<dd>14 August 2023</dd>
	<dt>Web-based functionality is accessible</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	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.
	</dd>
	<dt>Non-web-based functionality is accessible</dt>
	<dd>Not applicable</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Alternative content available to editors</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	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.<br /><br />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.
	</dd>
	<dt>Editing-view presentation can be programmatically determined</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	Wagtail uses the following status indicators in editing views:<br /><br />-
	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.<br />- Fail:
	Comments in rich text. Comments are displayed as highlighted text within
	the rich text field. The association isn’t programmatically exposed.<br />-
	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").
	</dd>
	<dt>Works with keyboard</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	Though the majority of the authoring tool’s functionality is keyboard
	accessible, there are seven specific areas that aren’t:<br /><br />- 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".<br />- In rich text fields, pin/unpin of the
	rich text toolbar.<br />- In rich text fields, Edit functionality for
	links, documents, images, embeds.<br />- In
	image/document/page/task/snippet choosers, the chooser dialog.<br />- In
	page listings, manual sorting of pages.<br />- In image create/edit forms,
	creation or editing of a focal area.<br />- In table blocks, editing of
	the table.<br /><br />See
	https://wagtail.org/accessibility/atag-audit/#a311-keyboard-access-minimum
	for the full status and proposed changes.
	</dd>
	<dt>Enough time</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	Wagtail doesn’t provide auto-save functionality. For Wagtail sites, the
	default session time limit is 2 weeks.
	</dd>
	<dt>Flashing content optional</dt>
	<dd>No</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Content can be navigated by structure</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	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.
	</dd>
	<dt>Content searchable</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	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.
	</dd>
	<dt>Supports display preferences</dt>
	<dd>Yes</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Previews are accessible</dt>
	<dd>Yes</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Helps editor prevent and correct mistakes</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	Though a large number of authoring actions are reversible, not all are.
	The following actions are reversible:<br /><br />- Plain text and rich
	text content editing within specific fields, reversible until the user
	submits the form.<br />- Editing of page or snippets content supporting
	revisions, reversible for the whole page/snippet at any later point in the
	site’s history.<br /><br />The following actions are not reversible but do
	require confirmation to proceed:<br /><br />- Permanent deletion of any
	content which has its own dedicated creation/editing views.<br />-
	Unpublishing of pages and snippets.<br />- Deletion of comments within
	page content.<br /><br />The following actions are not reversible and do
	not require confirmation to proceed:<br /><br />- StreamField /
	InlinePanel block-based content editing, reversible only as part of
	support for content revisions.<br />
	- Consider implementing an in-browser undo-redo stack for those
	interactions.<br />- Image / Document / Page / Task / Snippet / Embed
	chooser fields, reversible only as part of support for content
	revisions.<br />
	- Consider implementing an in-browser undo-redo stack for those
	interactions.<br />- Authoring actions on content that does not support
	revisions such as images, documents, etc.<br />
	- Implement either a confirmation step for those actions, or
	revisions/versioning support.
	</dd>
	<dt>(Accessibility) features documented</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	The following functionality would be used to meet Part A and needs to be
	described either in the documentation or in the user interface:<br /><br />-
	Image title fields’ usage as alt text<br />- Page-level keyboard
	shortcuts<br />- Skip link<br />- Collapsible sections<br />- Link to
	specific collapsible sections<br />- Collapse/expand all<br />- Minimap<br />-
	Session time limit<br />- Editing of headings and elements nesting in rich
	text fields<br />- Text search<br />- Browser-level UI settings<br />
	- Sidebar expanded/collapsed<br />
	- Rich text toolbar pinned/unpinned<br />
	- Minimap opened/closed<br />
	- Currently-open side panel<br />- Profile-level UI settings<br />
	- Language<br />
	- Time zone<br />
	- Notification settings<br />
	- Admin interface theme<br />- Live preview<br />- Command palette
	available commands<br /><br />The following functionality is described in
	the user interface:<br /><br />- Restore revisions<br />- Markdown
	keyboard commands for rich text<br />- Command palette trigger<br /><br />The
	following functionality is described in the documentation:<br /><br />-
	Comment shortcut<br />- Rich text keyboard shortcuts<br /><br />The
	following functionality is provided by the underlying platform:<br /><br />-
	Embeds titles as alt text for embedded content<br /><br />See
	https://wagtail.org/accessibility/atag-audit/#a422-document-all-features
	for a full record of which features are and aren’t documented.
	</dd>
	<dt>Generates accessible markup</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	Wagtail automatically generates content in a few scenarios. In the
	following scenarios, markup is accessible without further work:<br /><br />-
	Pass: Links markup for links to pages, documents, external URLs, email
	addresses, phone numbers, and internal anchors within rich text fields.<br />-
	Pass: Embeds for external resources within rich text fields.<br />- Pass:
	Embeds for external resources in StreamField.<br />- 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.<br />-
	Pass: Table markup from TableBlock.<br /><br />In the following scenarios,
	markup isn’t accessible out of the box:<br /><br />- 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.<br />- Fail: Table markup from TypedTableBlock.
	This is lacking the ability to set row or column headers.
	<br /><br />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).
	</dd>
	<dt>Preserves accessibility information</dt>
	<dd>Yes</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Accessible content production is possible</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	Wagtail places extensive restrictions on the production of web content,
	which all nonetheless allow for the production of accessible content, with
	the exception of:<br /><br />- 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.<br />- Missing support for table/row
	headers with TypedTableBlock. This could be worked around by only creating
	tables with TableBlock, which is possible but unlikely. <br />- 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.
	</dd>
	<dt>Editors guided</dt>
	<dd>Yes</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Text alternatives can be managed</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	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.
	</dd>
	<dt>Accessible templates available</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	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.<br /><br />For form fields in the form builder, a
	wide range of fields have accessibility issues with no alternatives
	available.<br /><br />There are known issues with:<br /><br />-
	Blockquotes in rich text (no cite field)<br />- Blockquotes in StreamField
	(no cite field)<br />- Images in StreamField (no alt text field)<br />-
	TypedTableBlock in StreamField (no caption, no column header or row header
	support)<br /><br />See
	https://wagtail.org/accessibility/atag-audit/#b241-accessible-template-options-wcag
	for a full record of accessibility issues in content templates
	</dd>
	<dt>Accessible components/plug-ins available</dt>
	<dd>Not applicable</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Checks accessibility automatically</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	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:<br /><br />- `button-name`: `<button>`
	elements must always have a text label.<br />- `empty-heading`: This rule
	checks for headings with no text content. Empty headings are confusing to
	screen readers users and should be avoided.<br />- `empty-table-header`:
	Table header text should not be empty<br />- `frame-title`:
	`<iframe>` elements must always have a text label.<br />-
	`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.).<br />-
	`input-button-name`: `<input>` button elements must always have a
	text label.<br />- `link-name`: `<a>` link elements must always have
	a text label.<br />- `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.<br /><br />There
	are a number of success criteria that do not have automated checks nor
	instructions for manual checking:<br /><br />- 1.1.1 Non-text Content (A)
	– specifically instructions on correct entry of alt text, and marking
	images as decorative when appropriate<br />- 2.4.4 Link Purpose (In
	Context) (AA) – instructions and potentially limited automated checks
	on correct link text (avoid "click here")<br />- 1.4.5 Images of Text (AA)
	– instructions on avoiding images of text except for scenarios where
	there is no alternative<br />- 2.4.9 Link Purpose (Link Only) (AAA) – see
	above<br />- 1.4.9 Images of Text (No Exception) (AAA) – see above<br />-
	3.1.5 Reading Level (AAA) – instructions for manual checking or
	automated checks<br />- 2.4.10 Section Headings (AAA) – instructions for
	manual checking or automated checks<br />- 3.3.5 Help (AAA) – instructions
	for manual checking or automated checks for the form builder<br /><br />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.
	</dd>
	<dt>Helps content editors fix problems</dt>
	<dd>No</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Accessibility features prominent</dt>
	<dd>Yes</dd>
	<dt>Description</dt>
	<dd>Not provided</dd>
	<dt>Documentation promotes accessibility</dt>
	<dd>Partially</dd>
	<dt>Description</dt>
	<dd>
	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.
	</dd>
	<dt>Comments</dt>
	<dd>
	Thank you to the Wagtail accessibility team for the foundational work that
	made this audit and report possible. Thank you to Torchbox for sponsoring
	this audit and associated reporting.<br /><br />Additional thanks to
	Albina Starykova, Joshua Munn, Sage Abdullah, Thibaud Colas, and Nick Lee
	for their work on Wagtail’s first ever accessibility checker
	(https://wagtail.org/blog/introducing-wagtails-new-accessibility-checker/),
	which was essential for us to partly meet B.3. and B.4. guidelines.<br /><br />---<br /><br />Our
	full report in Markdown/HTML is available at
	https://wagtail.org/accessibility/atag-audit/<br /><br />Our full report
	in the ATAG Report Tool format is available at
	https://gist.github.com/thibaudcolas/c48b0b4cf8e7966cd09d22677ab63173.
	</dd>
	</dl>