Proposal: File remediation

[cidilabs]

UDOIT File Remediation

Summary

An important feature of LMS course accessibility management is file remediation. While the hope is that most course content will be within the course as HTML, that is often not the reality. We hope that by providing file remediation we will improve the accessibility coverage of the course content.

Phase I: providing alternate formats
Phase II: student view
Phase III: scanning documents

Why are the phases in this order? Because this seemed like the most accomplishable given the limited resources this project has. Cidi Labs is open to feedback on the best approach to accomplish file remediation.

Phase I: alternate formats

UDOIT will have a "plug-n-play" system for providing alternate file formats. This provides flexibility in how file remediation is handled. Each alternate format will be tied to a service. These services may be open source solutions that may be included, or 3rd party services that provide file remediation through an API.

For example, let's assume we create the following integrations:

• LibreOffice (self-hosted)
• ReadSpeaker
• ABBYY FineReader

An institution may have licenses with all these providers and their configuration may be something like this:

• ABBYY FineReader handles HTML and tagged PDF
• ReadSpeaker handles MP3 and braille

Another institution may not have any licenses with providers and their configuration might be:

• LibreOffice handles HTML and tagged PDF

We will create an entity to store alternate format data created for each file in the LMS.

Once the alternate file has been created by the service the file will be stored in the course files in the LMS. Files will be stored in a directory structure that groups all alternate formats of the same file together, so a student looking for alternate formats will know how to find them.

Alternate File UI

Alternate files will appear on two screens in phase I of file remediation.

• Review Files list - lists the alternate files already created for each file
• Review File modal - Provides a UI to request the alternate file formats for each file

Once the alternate files are created the student will go to the Files section of a course to find the alternate files.

Phase II: student view

A JS script is added to the LMS, and does the following:

• Loads on every page
• Scans the page for course files
• Sends a request to the UDOIT API to see if alternate files exist for each file
• Inserts a small icon to the right of each file link
• On click of the icon a menu appears listing the alternate files that are available
• If file formats have not yet been created, students can request the desired files

Phase III: document scanning

This is likely the most complex of the phases, and in my opinion provides the least amount of value to the end user. Each file in the course would need to be downloaded to the Cidi Labs servers to be tested for a list of accessibility checks. To start, this might be:

• Is a document mostly images (scanned)
• Is a PDF tagged?

We would then flag any files that failed these tests and provide basic instructions on how to remediate.

Mockups

Users will get a list of all file alternates on the "review files" view of UDOIT.

\

When viewing the details of a file a UDOIT user will have the ability to view or request alternate files.

Students will have a non-intrusive option to view alternate formats within the context of the LMS content.

[bagofarms]

I really like where this is going. I have a few questions/comments, though:

1. Will these alternative formats be created automatically, or at the request of the UDOIT user?
2. If they're created automatically, would we have some kind of queue system to allow the user to use UDOIT like normal until the alternative formats are generated?
3. Many faculty like to hide the Files area of their course, so Phase I might not be usable by many students, but it's better to go ahead and release that while we work on Phase II.

[cidilabs]

Great questions. This is what I've been thinking...

1. No, they won't be created automatically. Our thought is to approach this more intentionally, rather than doing a brute force conversion of all files. In the end we're storing all these converted files back in the LMS, so it would be expensive in conversion time, processing power, and file storage to convert everything.
2. We will likely need to handle this with a queue system even when requesting files individually. Some services will process the file in real-time and will need to keep the connection alive to send the converted file in the response. Others will respond with a job ID that can be checked on for a status. Either way, there is some sophistication needed in this part. And one workflow may not work for all integrations.
3. Yes, I'm hoping that phase II will follow very quickly after phase I. It shouldn't be too difficult to build the student UI.

[adrianfish]

I like this logic. Allow the users to distribute the load by requesting the conversion to another format themselves rather than a batch process. There would have to be robust notification mechanisms in place to inform them of progress and the process would obviously have to be reasonably quick. The good thing with this approach, though, is that it would be quick as you're not batch processing huge amounts of file data whenever instructors upload a load of content.

[jmwilson-longsight]

Hi all. Thanks for sharing this. It's a thoughtful approach, and it's super helpful to have this proposal to kick-start discussion. Here are my thoughts.

1. The phases are sequenced in order of feasibility/complexity. I recommend considering user requirements as an input to this sequencing. Has user requirements data been gathered?
2. Re: Phase 1 / alternate formats. For institutions that don't have any of the licensed products listed (or their vended competitors), perhaps committing to providing a default open source solution (LibreOffice?) would make ththise capability most useful out of the box.
3. Re: Phase 2 / student view. What workflows do competitors use to present alternate formats to students? That information would be a useful input to our decisions re: UX for this capability.
4. Re: Phase 3 / document scanning. While I don't doubt that this is the most complex of the three phrases, we should be aware that this phase provides perhaps the greatest value to institutions that adopt UDOIT. The legal risk to institutions is quite substantial, and document scanning allows them to quantify that risk and develop plans to remediate it (using UDOIT / competitor products and/or other means). IMO, it's this risk that would be the primary driver for institutions to adopt UDOIT or a competitor product.

Thanks!

Josh

[adrianfish]

In phase 2, when the alternative format request is made, do you see udoit calling into the LMS for the original, or the LMS calling in to udoit?

[bagofarms]

I think it should work like Phase 1, where the alternative formats are saved to the LMS, and the student view pulls from there. That way, the course still stands on its own, and isn't dependent on UDOIT in the future.

[cidilabs]

Agreed. I imagine the alternative formats would be stored in the LMS course. UDOIT would be the middle man to provide the links to any alternative formats. And UDOIT would not store any of those files, just the links.