Open Accessibility For Open Source

Last week at this time, I was taking in the early morning ambiance of Châtillon, a quaint little suburb on the southwestern outskirts of Paris.

As I meandered through the idyllic neighborhoods, classical French architecture and beautifully manicured gardens in full bloom seamlessly blended together, as if created by the master strokes of an impressionist painter.

Unusually narrow walkways abutted cobblestone streets barely wide enough to accommodate automobile traffic, their well-worn, scarred surfaces gripping the ancient ground beneath, every twist and turn serving as a literal means of tracing their lineage back to their distant cart path ancestors.

The aroma of freshly baked pastries and brewing coffee wafted through the air, while the subdued chatter of song birds was the only perceivable noise, say for the repeated thumping of one’s own shoes against the sidewalk, or the occasional “bonjour” when exchanging pleasantries with a local passerby.

While I realize this account makes it sound like I was in full-on tourist mode, the above technically describes my morning commute to work, as I was on my way to OW2con, the European conference organized by OW2, the international community of professional open source software.

Orange, a French multi-national telecommunications company, hosted this year’s event at its research and innovation eco-campus in Châtillon.

Situated in a uniquely intimate technology park setting, The Orange Gardens Innovation Center is a handsomely appointed venue with a large, state-of-the-art amphitheater, spacious meeting rooms, and plenty of cozy indoor and outdoor spaces for networking with other conference attendees during breaks in the schedule, usually while enjoying some decadent dessert, or sipping on one of the region’s signature wines.

The 15th edition of OW2con brought together hundreds of developers, IT companies, academics, and non-profit organizations for two information packed days. The conference included 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 was attending OW2con’24 as a representative of Sakai, where I had been invited to do a presentation on day two of the conference as part of an Open Source Accessibility breakout session coordinated by the Open Source Accessibility Initiative.

Photo of Chris presenting to the Open Source Accessibility Initiative group during the Open Source Accessibility breakout session at OW2con’24.

My talk, which I titled “Open Accessibility for Open Source” detailed Sakai’s multi-year journey to develop and implement a community-sourced accessibility strategy, that eventually led to us being able to produce our own VPAT, or Voluntary Product Accessibility Template.

My goal with this particular talk was to share some high-level concepts with the other attendees, lessons learned from our experiences reimagining and overhauling our VPAT creation process, that they could apply to their own open source projects, if their organizations were interested in trying to replicate our approach to this work.

What follows is a sampling of some of the key themes that I touched on during my presentation, which I’ve taken the liberty of expounding upon here, for this long-form blog version.

Note: For additional background and some historical context, you may want to read my “Voluntarily Excellent When It Comes To Accessibility” blog and/or check out the supplemental materials available at: https://www.sakailms.org/accessibility/accessibility-strategy

The underlying strategy is more important than the actual VPAT

While the goal was always to be able to produce our own VPAT, at the end of the day, some 30 or so pages of paper are not as important as the underlying strategy that is helping to drive all of this work.

If you don’t retain anything else from this blog, at least remember to go to that page on the Sakai LMS web site and read about the Sakai Accessibility Strategy, because that is absolutely key to everything.

Starting with a robust accessibility strategy is like having a well-stocked kitchen. It’s likely that you will already have all of the ingredients you will need to create a VPAT. On the other hand, creating a VPAT without an accessibility strategy is like running to the store to get ingredients for a specific recipe. You can do it, but you might waste a lot of time and energy tracking down everything you need, and your overall breadth and quality of work may suffer from being one-dimensional.

If we stick with this baking analogy, you’ll only be able to make that one dessert, and each time you go to make it, you’ll be starting over again from scratch.

So, maybe you’re able to whip up that batch of savory éclairs on a special occasion, but no apple pie, no New York style cheese cake, no chocolate chip cookies. None, ever. (I don’t know about you, but I don’t want to live in a world where there aren’t any chocolate chip cookies!)

Even after going through the hassle of creating one of these detailed reports, a VPAT is only a point in time, your accessibility strategy is ultimately what has staying power.

Reconciling these two competing interests is something that we had struggled with, since we knew we needed a VPAT, but we instinctively wanted to lead with our broader accessibility strategy, but the templated VPAT report has certain limitations, and it’s just not able to accommodate the amount/type of qualitative information we felt was warranted.

I always believed we were on the right path in terms of how our community was approaching accessibility, but the real “a ha”, epiphany moment for me came when Gonzalo Silverio (our informal VPAT advisor) introduced me to a companion resource he uses when reviewing VPATs. As I started familiarizing myself with this “Compliance Documentation Calculator” it became apparent to me that we were doing all of the things included on the checklist, meaning that we had already done most of the heavy lifting, and the VPAT was going to be more or less a formality, the final exclamation point for summarizing and presenting this entire body of work.

That being said, we still needed some way to articulate our broader accessibility strategy, and with the templated VPAT report only providing so much real estate to work with, our solution was to create a dedicated page on the Sakai LMS web site to house this other supplemental information.

Regardless of what variation of this approach you decide to use, or wherever you’re at in the process, being able to substantiate that you’re taking the necessary steps to maintain/improve the accessibility of your product, can provide you with much needed air cover – before, during, and after your VPAT project.

It’s more important to get it right than to be the first across the finish line

Yes, we actually have a Sakai racing team which competes on the “Tour de Lemons” racing circuit, which fittingly, is an endurance race.

For us in the Sakai community, this has been a multiyear journey to get to this point, and that’s okay – it’s a marathon, not a sprint.

Admittedly, this has been a drawn-out process, but it was because we were refining our strategy, and aligning it to the VPAT process, and working on the Sakai 22 and Sakai 23 VPATs, all at the same time.

A lot of the delay had to do with us evolving through several different iterations of our preferred VPAT format. The early draft of our Sakai 22 VPAT doesn’t look anything like the version Vision-Aid and I created last summer, and that’s drastically different then the final version that Gonzalo had worked with us on.

At times the process was frustrating, and redesigning and reworking entire sections of the VPAT was painful, but eventually we got it right, and hopefully the hard part is behind us now.

Even absent having a VPAT to work on, it’s not like you can stop doing everything else – if you are part of an open source software project, there are always new things being worked on in the master branch that need to be tested, occasional regressions that cause some feature to break, bug fixes that need to be retested/verified, etc.

Instead of dwelling on how long the VPAT process was taking us, we tried to focus on the positives. Something that could be perceived as a negative, for instance, it taking more than a year to create the Sakai 22 VPAT, we turned into a positive, by including that extra perspective/context in our supplemental materials, for example, by emphasizing that the high volume of user testing equates to us being more thorough, which it absolutely does.

And that’s something that we can quantify and actually attach a number to – of the 2853 test cases performed, only 91 had to initially be failed.

Eventually, everything you do related to accessibility supports your strategy, and it all becomes part of your accessibility story.

Now in full disclosure, we were hoping to have the Sakai 23 VPAT completed by the time of the OW2 conference. Sakai 23 was released almost a year ago now, and we just came out with 23.2.

There’s always going to be a certain amount of lag-time built into any accessibility assessment, but that’s not necessarily a bad thing. Testing a version that has been in production for a little while means that its probably more stable, which is a good thing when you are evaluating the sheer number of tools/features that we are testing.

That being said, the Sakai 23 VPAT is 90% complete, there is still some user testing that we need to wrap up before we can do our final analysis, but we are very close to being able to put the finishing touches on the report.

Authenticity matters and promotes credibility

As you can tell by this photo, I don’t mind poking fun at myself – I believe I have a great sense of humor, and this is just another example of me being my authentic self.

Now, when you talk about authenticity as it relates to your accessibility strategy and VPAT, this can mean a few different things.

First, to the extent you are able, you should try to incorporate individuals with disabilities into your user testing/community. Individuals with disabilities, for example blind/low-vision users who rely on screen readers and other assistive technology, are able to provide for an authentic accessibility experience.

Also, when putting together your VPAT, don’t be afraid to give an honest assessment of your product, warts and all. No software is perfect – if you are portraying your project as flawless either you’re being disingenuous or you haven’t tested enough.

You don’t have to match your big commercial competitors dollar-for-dollar, but your commitment to, and investment in accessibility must be long-term

Well, nothing says long-term commitment better than an image of a couple tying the knot in front of an iconic Paris landmark. I hope this guy is in it for the long haul, especially for the sake of the bride’s father who probably forked out a small fortune for this little shindig.

The message here is that when it comes to your investment in accessibility, you don’t have to keep up with your commercial competitors. Chances are that you won’t be able to compete with them anyways, at least not from a strictly dollars and cents standpoint.

For example, when I look at Sakai’s competitors in the LMS space, there’s no way that we can match them in terms of their accessibility spend. They have the resources to employ entire teams of developers who exclusively focus on accessibility. They have armies of analysts and lawyers that craft these elaborate VPAT reports that look like they belong on a coffee table.

So, instead of trying to be something that we’re not, we focus on being the best version of who we actually are. As an open source community, our model provides for direct input from users, which often translates into us being more responsive to our customers.

Having a visually impaired person serve as the Lead of our Accessibility Team demonstrates that we not only care about accessibility, but that we value the contributions of individuals with disabilities to the point that we recruit them into our community as full-fledged members.

Remember, VPATS aren’t just for the affluent corporations with access to the almighty dollar, they’re also free marketing tools for those resourceful organizations who can figure out creative ways to tell their stories, and in doing so, lean into their unique attributes to separate themselves from the crowd.

A community-sourced approach to accessibility is essential and powerful

Open source projects already value the concept of community, and understand its importance in terms of specialization, and diversity, and where different contributions are coming from.

Well, it’s no different when you are talking about a community-sourced approach to accessibility.

Using Sakai as an example…

We have blind/low-vision testers.

We have sighted users who are performing keyboard testing on an adapted version of our accessibility test script.

We have developers who are well versed in accessibility and accessible design.

We have commercial affiliates who are willing to invest staff resources/funding to advance our accessibility goals.

Everybody has something to contribute, and it all starts to add up, and before you know it, you have a mature accessibility strategy which is key to being able to do your own VPAT.