Accessibility analysis/remediation workflow

[EricDurante]

Background

In order to better serve users who have disabilities and in order to comply with new regulations regarding the accessibility of publicly-funded research outputs, ScholarSphere curators want to make a good faith effort to ensure the accessibility of all of the documents that are being submitted by depositors for publication. While the responsibility for making documents accessible ultimately lies with the creators/depositors, the ScholarSphere curators are already in a good position to review the accessibility of each deposit and to provide guidance to the depositors and help with remediation if needed. However, the curators' capacity to handle this workload is limited, so we would like to build a workflow to facilitate this process that is as automated and streamlined as possible.

Importantly, this workflow should not introduce more friction to the process of depositing a work. In other words, it shouldn't discourage anyone from depositing their work in ScholarSphere. Generally this means that we'll want to provide resources and opportunities to improve accessibility to users as they're beginning the deposit process, but we shouldn't introduce any new restrictions or requirements for making deposits or publishing. It will be best to encourage depositors to be proactive about accessibility, but then allow them to deposit/publish regardless and then retroactively review/remediate deposited works in a systematic way.

Workflow

Automated Accessibility Checking

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.

Storage and Notification of Accessibility Check Results

For each file that can be automatically accessibility checked, we'll want to cache the results of the check for later use. When a depositor is viewing/editing one of their work versions and viewing the list of uploaded files associated with that work version they should see a visual indicator of the accessibility check status of each file that can be automatically checked. The status may be pending if the check hasn't yet completed or cannot be completed for some reason, or it may be pass or fail depending on the results of the check. We may also want to indicate some "not-checked" or "N/A" status for files where an accessibility check isn't applicable or the file type isn't supported. For checks that have completed, there should be a link for the depositor to view the results of the check within the ScholarSphere web app. Additionally, the depositor should receive an email notification for each failed check/file that lists the issues with the file and/or includes a link to the check results in the web app.

Ability for Depositor to Save Work Draft and Request Accessibility Remediation Assistance

Similar to how depositors can currently request curation assistance for datasets prior to publication, we may want depositors of articles and other work types to have the ability to do the same thing in order to request manual review/assistance from a ScholarSphere curator regarding document accessibility prior to publishing their work. If a depositor selected this option, their work would be saved as a draft, and the work would enter a queue for review by a curator.

Open questions:

1. Does this apply to all non-data/code work types?
2. Should this always be an option for the applicable work types, or should it only be an option if one or more files doesn't pass automated accessibility checking? (The latter would require us to make the depositor wait for feedback before moving on..)
3. Do we want the list of these curation requests to live in AirTable along with all of the other curation tasks? If so, how should they be identified or distinguished from other tasks?

Ability for Curators to Review/Track Each Deposited Work

An automated check may be the best way to provide quick feedback to depositors about easily detected/correctable accessibility issues. However, we know that we likely won't be able to run an automated accessibility check on every type of file that is uploaded to ScholarSphere (in fact, we may only be able to do so with PDF files). We also know that a passing automated check does not at all guarantee that a file is actually accessible by all WCAG standards. The only way to guarantee that any given file meets the standards is for a human reviewer to carefully inspect it and remediate any issues.

To ensure that all works deposited in ScholarSphere are actually accessible, we would need each work (regardless of whether it was automatically checked) to enter into a queue for manual review by a ScholarSphere curator. After a curator has inspected each file that's attached to the current work version and worked with the depositor to remediate any issues, they would need a way to manually indicate that the work had been reviewed for accessibility and thus remove it from the queue. If a new version of the work is created in the process of remediating accessibility issues, then the work should not re-enter the queue, but if a new version of the work is created for any other reason, then it should re-enter the queue for another manual accessibility review.

This queue for manual review would be separate from the queue for works where the depositor actively requested an accessibility review from a curator prior to publication and should exclude works where curation was requested so that the curation of works in these two queues can be prioritized separately. The mechanism for resolving/removing works from both queues could probably be the same.

Open questions:

1. Again, could/should this list be tracked in AirTable?
2. Is this actually a reasonable thing to do? In other words, will there be enough curators to handle this work? Or will the to-do list just get hopelessly long?

Automated Remediation

This may be a nice-to-have feature if we're able to get to it, but we'd need to give a lot more thought to how/where this would fit into the workflow, how it would be triggered and by whom (curator, depositor, or either?), and whether or not the result could be used without passing some kind of manual review first.

[EricDurante]

@bdezray Here's my first attempt at an epic describing the whole accessibility curation workflow. There are some open questions (and certainly others that haven't occurred to me yet), but this is also just a straw-man to some extent. Please add anything that you think is missing and/or push back on anything that you think that I didn't get right.

Once we're satisfied that we've captured what we really intend to do, I think that we can break this down in to smaller issues, or even smaller epics along the lines of the headings under "Workflow".