Automated Accessibility Checking

[ajkiessl]

From the epic (#1589):

If feasible, the first step in this process would be an automated check of each document that is uploaded to ScholarSphere during the workflow for depositing a work. This check would use a third-party tool to analyze and evaluate each document in terms of accepted accessibility standards. We've begun to describe this step in #1580. We would want this automated check to be triggered by each document upload and to run asynchronously in the background. The result of the check should be a pass/fail evaluation of each document along with a list of any detected accessibility issues (and suggested remediations) for each document.

We have decided to use Adobe's PDF Services API to do our accessibility checking. Refer to #1580 (comment) for some links to documentation. We will need to build our own wrapper that returns a pass/fail analysis and parses out any issues and remediations given to us by the API. Accessibility checking should kick off in an async Sidekiq job for each uploaded PDF after the file upload step in the submission workflow.

There may be a way to pass signed URLs from ScholarSphere's AWS S3 bucket to Adobe for checking, so let's investigate that before considering other options. Here's the documentation for passing signed URLs: https://developer.adobe.com/document-services/docs/overview/pdf-services-api/howtos/pdf-external-storage-sol/ .

We'll also need to keep in mind that we only get 500 document checks a month on the free version. (#1580 (comment))

[ajkiessl]

Part of #1589

[ajkiessl]

Look into how Adobe handles our PDFs when we send them. For security/privacy concerns, we may need to mention to users that an external entity will have temporary access to their work.

We could hold off on accessibility checking for embargoed works.