October 22, 2019

“Open for Whom?” – Accessibility and Open Access

At UW we’ve been thinking about OA Week’s theme of “Open for Whom?” in the context of our efforts to increase the accessibility of our resources and services. We’re pleased that the latest version release of the Manifold digital book publishing platform included substantial accessibility improvements, largely due to a partnership between Cast Iron Coding, the web development firm building Manifold, and UW’s Accessible Technology Services (ATS) Office. 

We spoke with Ava Cole, a Student Accessibility Assistant in ATS, about their experience working on this project.

What is your role in ATS?

I support Hadi Rangin [Information Technology Accessibility Specialist] in his endeavors to evaluate, advocate, and ensure the accessibility of software used on campus. Ideally we’d have five Hadis, but since we only have one he has a number of students as his henchmen. I’m a full-time student, and I work part time. Right now there are two students, but we’re hoping to add more.

How does an ATS evaluation typically play out?

Usually it starts when the manager / owner of a new, software-related service at the university comes to us and says “we want to adopt this new software, but we want to make sure it’s accessible.” Spoiler: it’s never accessible.

We collaborate with that person to do a full evaluation, testing the functional tasks the software is designed to perform, and the workflows that people will typically use it for. We use different techniques, including a static review of the code, testing the software with different evaluation tools, and also using assistive technologies to try to complete each of the tasks. We compile a big list of issues, put them in a spreadsheet, and write an accompanying report describing the overall status of accessibility. When we are done we hand off our findings to the service owner / manager who then uses it to advocate for accessibility in the purchasing process. Usually UW-IT is surprised but supportive, and the company is defensive.

Ideally this is then the start of a collaboration with the company. With good projects they will assign us a liaison, and we’ll work with them to fix the accessibility issues. Sometimes it’s great, and they’re strong advocates within the company for the changes to be made. But sometimes we spend a lot of time “talking to the hand.” In every collaboration it’s a process of educating them and doing our best to help them help themselves, but it can be hard.

What was it like working on the Manifold evaluation?

It was the same process of Elliott Stevens [English Studies & Research Commons Librarian], who is, by the way, a fantastic collaborator and leader, approaching us about Manifold. The Libraries had already begun using the software, which isn’t unusual. So we looked at the platform, and immediately saw that it had a lot of issues. 

What was really different with this project was that after the initial evaluation, instead of handing it off to execs and having it trickle down to the developers, we met with Matt Gold and Terence Smyre [two of the principal investigators on the Manifold grant project]. They were immediately receptive, saying they hadn’t realized there were so many holes. And because Manifold is open source software, hosted on GitHub, instead of waiting for the spreadsheet to get in the right hands, we started filing issues directly into their GitHub. 

Within five minutes of filing the first issue, Zach Davis [Cast Iron’s Principal and Chief Technologist] replied and said “thank you, I’m putting it in the workflow.” This is exponentially faster than how it usually happens. So as we continued to put the findings on GitHub, we were getting fixes back really fast. That cycle of us doing the testing and them doing the fixes has been totally different than other projects we’ve worked on. 

Another change, and this is something I think about a lot, is the way this project is letting us share our own work. We put all this publicly funded time into researching how to fix software accessibility issues, and some of it is really bleeding edge. Like for one project, the software had these interactive data grids that were really functional and powerful, and looked great visually, but were horribly inaccessible. It took a month of ruminating and talking and brainstorming and research, including bringing it up in Hadi’s monthly Explore with Hadi meetup, to come up with a suggested design pattern for the company and provide them with the solution. However, that application is proprietary – so all the work is now hidden. The knowledge created from that discourse is effectively gone.

But with Manifold, it’s all open. We’ve been doing the same kind of discussion and research around Manifold’s highlighting and annotation functions. And the good news is that the findings are now available in GitHub – it’s public knowledge. It’s cool when it’s publicly funded work, and the work is actually public. 

So, it’s been a good collaboration?

It’s definitely stood out, people-wise. In some collaborations it feels like we have to convince people of why accessibility is important – having to hold their hand. Sometimes the only reason the company incorporates our feedback is because it’s a selling point; we tell them “making it accessible will increase your market share.” With the Manifold team, as soon as we mentioned it they were really excited. They were really open to the feedback and motivated on their own to make accessibility a priority.

What’s the current status of the project?

Right now we meet with Terence and Matt on a regular basis, continuing to test new features as they put them out. We’re starting a new push on the authoring side; the way content is managed in Manifold doesn’t make sure that the content itself is accessible. Manifold isn’t an authoring tool – it ingests existing content. So if the ingested content isn’t accessible, it doesn’t matter if the application is accessible. We’re encouraging them to add an accessibility checker for uploading content. It would be great if it actually enforced accessibility of the content, but that would be very ambitious.

What lessons can the Open Access and Accessibility communities share? 

We live in a world that isn’t set up to be open or accessible; our position as advocates are similar, in that we’re the underdogs. Accessibility, privacy, security, and equity are always neglected until someone tells people they have to pay attention. Usually it has to happen using policy or law; without the ADA our office wouldn’t exist. 

They also all have to be part of the development process from start to finish, otherwise it won’t be a good outcome. Hadi always says accessibility can’t be an afterthought – something you tack on to the end of the software development process. If you do it that way it’s never going to be functionally accessible, letting people use it in a meaningful way without a lot of pain.

Higher education is a great launching pad for this work, but I want to emphasize that these have to be community efforts. With accessibility, it can’t just be our office who’s worried about it – we do a lot of work but we can’t cover everything. Any institution that has buying power needs to consider the agency they have to advocate for access, privacy, and accessibility. This means UW as a whole, or divisions like the Libraries and UW Medicine. Often people think they don’t have power, but they really do. People look up to the Libraries; how can that power be leveraged?