Voluntarily Excellent When It Comes To Accessibility

Next week I will be attending OW2con’24 in Paris-Châtillon.

OW2con is the European conference organized by OW2, the international community of professional open source software (https://www.ow2.org/)

Happening June 11 and 12, the 15th edition of OW2con will bring together developers, IT companies, academics, and non-profit organizations for two information packed days. The conference will include four keynotes, four breakout sessions, and 30 talks from international experts, with presentations ranging from tech topics to business and ethical issues of open source.

I will be there representing Sakai, where I will be giving a talk as part of the Open Source Accessibility breakout session coordinated by the OSAI, Open Source Accessibility Initiative.

My talk is titled “Open Accessibility for Open Source” and will detail Sakai’s multi-year journey to develop and implement a community-sourced approach to accessibility, a long-term strategy that eventually led to us being able to  produce our own VPAT (Voluntary Product Accessibility Template) by utilizing internal partners and resources. Along the way to creating the Sakai 22 VPAT and the soon-to-be-completed Sakai 23 VPAT, we constantly challenged the status quo and searched for ways to improve every part of the VPAT creation process. What ended up emerging is an entirely reimagined, streamlined way of doing VPATs that we plan to use when creating VPATs for all future Sakai releases.

A Journey of (4+ years) Begins With A Single Step

While it’s easy to downplay the significance of such an accomplishment, the Sakai 22 VPAT was 2+ years in the making, probably more like 4 years when you think about the steps we took way back in 2020 to be able to position ourselves to engage in this type of work.

Sakai’s accessibility journey (at least the part of the story that involves me) goes back to 2020, when Chuck Severance, who is Sakai’s Chief Architect and currently serves as the Sakai PMC (Project Management Committee) Chair, first approached me about getting involved with Sakai. Chuck’s approach, which proved to be genius, was to embed me with Sakai’s QA team, where I was to begin evaluating the current state of accessibility for Sakai – not just the accessibility of the Sakai LMS product itself, but accessibility across every facet of the open source Sakai community.

So I started working as a member of the Sakai QA team. I began making recommendations about how to make the different tools and processes we were using more accessible.

I created our first, real substantive accessibility test script, and began performing screen reader/keyboard testing to supplement the efforts of our other QA testers.

Then about 3 months into our little experiment, we established a partnership with Vision-Aid, which provides IT training to blind/low-vision individuals in India, and suddenly tripled the number of blind/low-vision testers working on Sakai.

Around that same time, we started piloting a new initiative called “Accessibility LITE” which involves having some sighted users go through and perform keyboard testing on an adapted version of our accessibility test script.

When the time came for us to create a VPAT for Sakai 21, our expanding Sakai Accessibility Team had plenty to contribute, based on the extensive user testing that we had performed over the prior six months. And while our work was used to supplement (and definitely improve) the VPAT analysis/authoring process, we ultimately decided to utilize an outside contractor to create the Sakai 21 VPAT.

Voluntarily Mediocre

Doing VPATs is nothing new. Like I referenced above, in the past we utilized outside contractors to create VPATs for Sakai 21, and before that, for Sakai 19.

However, for Sakai 22, and moving forward, we decided to take a new approach.

So what changed, or maybe the better question is, what necessitated this change?

First, the VPATs for Sakai 19 and Sakai 21, while allowing us to check off a box to ensure we were in compliance, were in my opinion, woefully inadequate.

That is no disrespect to the contractors that we used. It’s more about the fact that the VPAT template, and the process that is used to complete it, has certain limitations.

In other words, the VPAT is a blunt instrument.

 When you consider that Sakai is a complex application with many moving parts that requires extensive testing, and in-depth analysis to be able to accurately and thoroughly assess the accessibility of the product, I liken it to using a hammer to try and repair some intricate electronic circuitry.

Which brings us to reason #2…

For us in the Sakai community, VPATs are not just paperwork, they are personal.

As LMS’s go, Sakai is un-matched when it comes to its investment in, and commitment to accessibility. You don’t have to look any further than me and my role. It goes without saying that no other LMS has a visually impaired individual serving as the lead for their accessibility team. But as I alluded to in the prior section, I am not the only embedded resource focused on accessibility. In fact, we have an entire team of blind, low-vision testers who are regularly working on Sakai, and have been doing so for several years now thanks to our unique partnership with Vision-Aid.

Well, the “V” in VPAT stands for Voluntary, so when we started talking about how to create the VPAT for Sakai 22, we made the decision to try and use existing resources to accomplish this work, and for the  last couple of years, that’s exactly what we’ve been doing.

MVP (Most Valuable Partner)

It goes without saying that none of this would have been possible without the contributions of Vision-Aid.

While I was responsible for building out our accessibility test script, and performing the initial round of testing on any new tools/features that were added during our Sakai 22 testing, it was the Vision-Aid team who completed the lion’s share of the 2,853 test cases performed across a total of  23 Sakai tools/features.

This was no easy feat, because when we transitioned from Sakai 21 to Sakai 22, we increased the total number of test cases performed by 185%.

Along with all of the user testing, Vision-Aid compiled the detailed WCAG audit findings which became the basis of our VPAT analysis/report. I leaned on them throughout the various phases of the project, many times deferring to their experience and expertise.

If it wasn’t for Vision-Aid serving as my sounding board, going along with some of my far-fetched ideas, and pushing back when necessary, this iterative process never happens, and we’re unable to turn our VPAT from something that is typically transactional, to something that is truly transformative.

It Takes A Community

Along these same lines, we would have struggled to take on a project of this scale, if not for the support of our open source community.

In particular, there’s the students from Marist College who helped out with our “Accessibility LITE” testing. These are sighted individuals serving as part of our regular Sakai QA team who volunteered to perform keyboard testing on an adapted version of our accessibility test script.

And then there’s the developers, UX teams, instructional designers, etc. who are part of our extended accessibility team. A majority of the Sakai community’s full-time developers are employed by our commercial affiliates, companies like Longsight and Entornos de Formación, who are able to deploy technical staff with specific accessibility skills and experience.

The X-Factor

Wanting to be excellent at something, and fully committing to it is one thing, actually achieving said excellence is a little more tricky.

During our initial phase of the Sakai 22 VPAT process, the Vision-Aid team and I constantly pushed the envelope on what we thought was possible, not worrying about how things had been done in the past, or necessarily trying to conform to some prescribed way of doing XYZ.

Conventional wisdom be damned, we were going to brute force the VPAT we wanted into existence, even if it meant that all of the supplemental materials, in-depth explanations, and painfully long narrative report would likely annoy, and potentially alienate our prospective customers.

At one point last fall, I shared (an almost) final version of the Sakai 22 VPAT with a few key decision makers from the Sakai community, sensing that we were approaching the finish line and were close to wrapping everything up.

Boy was I wrong, and in retrospect, I’ve never been happier to be wrong about something.

After having elicited his feedback/input, Chuck had suggested that I share a draft of our Sakai 22 VPAT with one of his colleagues at the University of Michigan, so we held off on finalizing/publishing the VPAT until we could complete this additional round of review.  

Enter the final piece of the puzzle, Gonzalo Silverio.

Gonzalo works for Information and Technology Services at the University of Michigan  where he specializes in Digital Accessibility. 

Gonzalo would prove to be Sakai’s X factor. Through his role as our informal VPAT advisor, he was able to draw on his years of experience supporting accessibility within Learning Management Systems, going back to the formative years of Sakai where he contributed much of the early accessibility work to the original code base as a member of the grant-funded project team, and more recently in his current role at U of M, where he regularly reviews VPATs as part of the university’s purchasing/procurement process.

In my humble opinion, Gonzalo’s single greatest contribution to the redesign/overhaul process, is that he was able to get us to view our reimagined report through the eyes of the VPAT reviewer, who after all, is our target audience.

He helped us understand how your prototypical VPAT reviewer is intent on getting to the bottom quickly and efficiently and leaning on a good VPAT to eliminate surprises and plan for accommodations.

Many of the ideas that Gonzalo contributed were with this notion of the VPAT as an ancillary document, that the essence of the matter needs to be conveyed via external documentation speaking to the culture – past, present, and future – of the product.

It was at Gonzalo’s prompting that I begrudgingly reconsidered my position that our VPAT report should include more substantive information, even if it meant adding several more pages of content to an already lengthy narrative section. Instead, he convinced me to cut out and repurpose, what he assured me was all great information, by moving it over to a new “Sakai Accessibility Strategy” page on the Sakai LMS web site that people will now be redirected to for additional detail.

Gonzalo made his case for reformatting the “Explanation/Remarks” portion of our success criteria table to ensure a consistent look and feel, and helped us come up with a better way to organize/present the Revised Section 508 and EN 301 549 for ICT parts of the report, including straightforward explanations for how these standards crosswalk to the WCAG success criteria.

He emphasized the importance of disclosing any known deficiencies, and suggested including a technical road map to describe any improvements planned for future releases of Sakai.

In essence, Gonzalo described everything he’d like to see in the ideal VPAT, and we redesigned our VPAT to align with the vision he was able to articulate, so we’re cautiously optimistic that our twist on the standard VPAT report will be well received by others out there, who like Gonzalo, have been charged with the thankless job of reviewing multiple VPATs.

See You In Paris

So now this journey has moi going to Paris to speak to the international community of professional open source software, and help other open source communities think through how to replicate this work for their respective projects. 

Without giving away too much of my presentation, you probably already can guess some of the high-level themes for my talk – the underlying strategy is more important than the actual VPAT, it’s more important to get it right than to be the first across the finish line, a community-sourced approach to accessibility is essential and powerful.

But the biggest takeaway is that you too can engage in this type of work. Any organization can begin to develop and implement its own accessibility strategy, you can start small and build from there. Maybe your journey ends up being different than ours, but to the extent you can learn from our experiences, we would like nothing more than to have our project serve as a blueprint for how to create your very own VPAT.

When it’s all said and done, it’s more than just a Voluntary Product Accessibility Template, it’s choosing to voluntarily be excellent when it comes to accessibility.