T-shirt. Ironing is optional, accessibility isn’t.
HRTECH and inaccessibility
Over the course of the last decade, I spent a lot of time researching accessibility and in-accessibility as part of my PhD. My basic findings were that most software vendors and the organizations that deploy the software do a dismal job in making their products accessible for people with disabilities. See a conference paper here. I‘ve given a couple of talks too.
Last year, in the US, a major case cleared up some of the debate about whether a website was a place of public accommodation or not. For roughly 20 years, the legislators and the courts in the US seemed unable to figure this out. Dominos Pizza finally resolved the uncertainty, and established more clearly the rights of people with disabilities to be treated fairly and equally by online software. With this judgement, I predicted that it would only be a matter of time until we saw an HRTECH vendor in court, and I strongly advised HRTECH vendors to take accessibility more seriously. I’ve also consistently argued that there is a moral imperative. Many HRTECH vendors talk a good D&I tools story, but then fail to address those very real inequalities they instantiate themselves in their software.
Well, now, it seems, we have that case.
A new case: LightHouse V ADP
I‘ll be watching the progress of LightHouse v ADP very closely. LightHouse is a non for profit organisation based in San Francisco that promotes the independence, equality and self-reliance of people who are blind or have low vision. It is early days in the case, I have learnt to reserve judgement until the courts have had their final say. The specifics of the case revolve around California state law, but it will have broader implications. As the case progresses, we will learn more about what ADP did and didn‘t do to build accessibility into its products. It looks likes part of the case will revolve around overlays. These are tools that purport to provide accessibility by adding a layer on top of an existing application. Several accessibility experts have raised concerns about these sorts of tools. See for instance Sheri Bynre-Haber, the Paciello group and Karl Groves. You might find Grove’s detailed video enlightening.
There are two demands:
The lawsuit’s demands include injunctive relief requiring ADP to make Workforce Now accessible as well as damages to compensate LightHouse for the losses it has incurred from its staff’s inability to use the product it purchased in the manner intended.
Given that so many HRTECH vendors are based in California, this case should make other vendors concerned about inaccessibility liability, especially given the injunctive relief provision in the law ( the court tells you to fix it). There are also shifts in EU law going on, but more on that another day.
So now what?
When you have a moment, unplug your mouse, and try and navigate your application. Switch on the accessibility screen reader, close your eyes, and see if you can fill in your most simple application screen. Now image you have to do that every day (note: visual impairment is not the only relevant disability).
To the start ups: If you build your products with the principles of universal design at the core of what you do, not only will you be well positioned to comply with accessibility legislation, you will actually build more usable and delightful product. It takes a bit of effort, but the long run benefits will be significant. Turn accessibility into part of your product positioning, and make it a basic ethical cornerstone of what you do. Do an audit to figure out where you stand.
To the established vendors: Inaccessible product is not just technical debt, it is moral debt, and a reputation and legal risk. So it is high time you fixed your accessibility backlog. It is time to rethink your definition of done. Review past promises you have made, and deliver on them. Do an audit to figure out where you stand. Work with your customers on this to adjust roadmap commitments.
As with other elements of product quality, such as security, privacy, performance, stability, you are far more likely to be successful if you design for the requirement from the beginning. Consider it to be a non-functional-requirement. (NFR) You need to include accessibility into your design, build and test processes. Accessibility should not be open for a prioritization debate every release, nor is it a layer that you can just paint on afterwards. But it is never too late to make accessibility improvements.
Modern development tooling includes accessibility checking as part of the build, so it is much easier to test for accessibility as you build your software today. At the risk of sounding like a Microsoft sales person, make sure your product, design and engineering team watch the recent Microsoft presentations on accessibility and universal design. There have been significant improvements in operating system browser and mobile OS capabilities, so make sure you take advantage of these. The tools for assessing accessibility have improved significantly too. It has become a lot easier to build accessible solutions, but only if you take the time to learn the methodologies and tooling.
To those buying software: Make accessibility part of your selection criteria, but not just a check-box on page 234 of the RFP. Your wallet will be more powerful than any court in improving accessibility. In the US, October is National Disability Employment Awareness Month. Seems like an ideal moment to challenge your incumbent and prospective vendors to improve product accessibility.
