Open DannyLancaster opened 1 year ago
Hi @DannyLancaster, I have created an Umbraco package that relates to this issue called Accessibility Reporter, which enables Umbraco content editors to test the accessibility of their content directly within Umbraco. The tests are run using axe-core and and the results are displayed within a tab on content pages. Users are able to see why tests failed and are provided with help on how to fix any issues. They can also export the test results to a spreadsheet.
The screenshot below shows a view of what the package looks like in Umbraco.
I have lots of ideas on how to make it as best as it can be and would love help with it.
Here are a few links with more information.
Umbraco Marketplace - https://marketplace.umbraco.com/package/umbraco.community.accessibilityreporter Github - https://github.com/mattbegent/umbraco-accessibility-reporter Website - https://umbraco.accessibilityreporter.com/
When creating content, the web author usually combines text and images with lists, blocks, objects and functionalities to compile a full page. By allowing the web author to test the page before publishing, many unnecessary accessibility problems can be avoided. In this feature, there is also a built-in auto-repair functionality that suggests fixes to the identified accessibility issues and the results do not require programming skills.
There are many automatic accessibility testing tools on the market; open source as well as commercial. They vary in quality and complexity, but more importantly, they focus on different target audiences. Many of the tools are made specifically for developers, to support their work while creating a website. Others help designers to choose the right combination of colours and the like. Some tools are made to support web authors to publish in an accessible way.
There are also many other kinds of tools that may help the authors, like spell checks and crawlers that look for broken links etc.
CivicActions maintains a list of available open source tools for evaluating page-level accessibility. https://accessibility.civicactions.com/guide/tools#page-level-evaluation
As with all automatic accessibility testing, these tools can only test parts of the requirements, and some point to issues that need to be checked manually.
By building an API-based service using an automatic accessibility testing tool core service, the page specific content can be checked for certain accessibility issues. This way, only web author-relevant failures would be presented, so that the author can concentrate on remediating these.
The main goal of this feature is to help the web author make sure different objects or parts of the web page are checked separately and that the end result is accessible-before publishing the page.
Web author view
Possible built-in success criteria conformance tests to be done:
<h1>-<h6>
to identify headings.<ol>, <ul> and <dl>
for lists or groups of links.<th> and <td>
.Tools like Sa11y and Editoria11y allow web authors to focus on what they can control. Most accessibility errors are introduced in the editor’s body field, so it is possible to target the WYSIWYG to that field and generate accessibility errors that target that section of the page specifically.
Sa11y - https://ryersondmp.github.io/sa11y/#install Editorially - https://itmaybejj.github.io/editoria11y/
Editoria11y needs to have JavaScript added to the HTML headers for the page:
Video documentation
https://youtu.be/rNfmErOgDIk
Recommendations for implementation
To make sure the implementation of the features is not causing accessibility problems for web authors with disabilities: