Open DannyLancaster opened 1 year ago
Hey @DannyLancaster, do you know if there is a cost associated with the Adobe Accessibility Checker API? If so I wonder if there is another similar service that can offer the same or similar functionality
Hi @MMasey, unfortunately, I think it is as it is part of the Adobe Acrobat DC package
Can't remember exactly how the We4Authors cluster left this one. Let me do some digging.
A feature testing documents before publishing them makes it easier for the web author to handle documents.
Automatic testing of document accessibility already exists on the market, both as external commercial products and built into the PDF-making software Adobe Acrobat DC. As with any automatic accessibility testing, they are not able to find all accessibility issues, but the automated tests do cover the key issues that may for example exclude screen reader users from the content.
The Adobe accessibility checker could potentially be included in the authoring tool by creating an API-based service that can be used to test the document before publishing it. This way, the author would be made aware about is sues that can be automatically tested, such as tagging of the document, which is important for assistive technology to navigate the content. The automatic checker can also point to potential issues that have to be controlled manually, like colour contrast and reading order.
Web author view
Guide for implementation
When a PDF file is uploaded it is asynchronously checked for accessibility issues. The system returns an accessibility status and a list of accessibility issues. This could happen via a separate REST response or with the REST response that uploaded the file.
The client/browser sends a POST request to upload a file to the CMS:
The actual request might differ depending on the authoring tool used. Most traditional authoring tools would most likely send a post request with x-www-form-urlencoded and not base64 encode it.
The authoring tool would reply to the file upload with a response that not only contains the regular response code (e.g. HTTP “201 Created” for a successful upload) but also a list of possible accessibility issues:
Reference to an example of a library that could be used to implement such a backend: https://gitlab.tingtun.no/eiii_source/pdfwam/-/blob/master/pdfwcag.py
Reference to a discussion on possible implementation options in Plone: https://github.com/plone/volto/issues/1506
Video documentation
https://youtu.be/tMaMPLWepaQ
Recommendations for implementation
To make sure the implementation of the features is not causing accessibility problems for web authors with disabilities: