Having a VPAT is not the same thing as being accessible
How I see myself / How others see me (cat looking into mirror, tiger looking back)
I try to write thoughtful, sometimes geeky articles about the esoteric and subtle nature of accessibility. But sometimes, you gotta start at the beginning
I’m sure every accessibility manager has had this type of conversation at least once in their life (and if you are lucky, only once. But nobody’s that lucky).
Chat author (whom typically the Accessibility Manager doesn’t know):
Hi Accessibility Manager! I hear you are in charge of this thing called accessibility for our organization. Glad I found you !!! Great Big Widgets wants to buy Product JKL, and they want us to commit in the contract that we are accessible. They said to start by asking for something called a VPAT.
Accessibility Manager: Here’s the URL to where our VPATs are stored, but the VPAT for Product JKL is really out of date.
Chat Author: Product JKL has a VPAT, great!
Accessibility Manager: Product JKL isn’t actually accessible, which is what the customer is asking for. It is full of things called “exceptions” which is code for “Places where Product JKL isn’t accessible.” Also, we are selling JKL version 96.59.4, but the VPAT is for version 2 so the VPAT is no longer valid.
(This is part of the conversation where I frequently quote Jessica Rabbit and say VPATs don’t intend to be misleading, they’re just drawn that way.)
Chat author: OK, I’ll just send Great Big Widgets the VPAT file and let them figure it out.
Accessibility Manager: Finds wall, bangs head, occasionally augmented by searching for alcohol or cursing or whatever their typical stress relief activity is.
Occasionally the chat author will inquire why the exceptions haven’t been addressed. Those are the authors that are more concerned about “Does the product actually work for people with disabilities” rather than “I need to get these people a piece of paperwork so the sale will close and then they will leave me alone.”
Then the Accessibility Manager gets to relay all the excuses they have heard from the product teams each time the manager has asked them to update the VPAT. And yes, I’ve heard them all. More than once. (Disclaimer: collection below from 15 years of experience)
The process was broken, and Product JKL didn’t close the loop to get the fixes to the exceptions into the product.
Product JKL had more urgent business needs to execute.
Product JKL was planning a UI rewrite and wanted to wait until that was done before they wrote a new VPAT.
Team JKL had a lot of turnovers, and just never got to it.
Product JKL’s division didn’t have the funds to pay for the retesting / new VPAT.
Product JKL was supposed to be EOLed but then made an amazing recovery from its product deathbed.
We inherited Product JKL when Corporation A1B2C3 was acquired, and Section 508/the ADA didn’t apply to Corporation A1B2C3. Pick your favorite sub-excuse here: they were too small, they didn’t sell to the US government, it did apply but they didn’t care and got away with it, or they aren’t based in the US.
No one ever uses VPATs, so why waste resources on them? It’s not like we have any disabled customers anyways, right?
#8 is a lie, it’s just like any good support system, you only notice a VPAT when you need one, and it *isn’t* there. And with 18% of the general population having a disability, the chances of you having 100 % perfectly able-bodied customers, or people who want to be customers, is vanishingly close to zero.
None of the other seven excuses I identified above are legitimate either. Here is where you can imagine me rolling up my ramp to the closest soap box.
Being a “little bit inaccessible” is like being “a little bit pregnant”
If you are inaccessible, YOU ARE INACCESSIBLE. Full stop.
a) If the VPAT contains an A-level exception, then by definition, an entire group of people with disabilities will be completely blocked from using the section of your product where the exception is located.
b) That inaccessibility can result in you losing a sale, or getting sued.
3. VPATs *cannot* be pulled out of thin air. They require the following steps:
a) if it’s been a while or you’ve never done one you need to figure out what you are testing and how. That’s a whole article by itself.
b) Estimating costs and getting approved for outside vendors, or scheduling resources internally.
c) Getting a round of testing done and finding out how many bugs have to be fixed and triaging them. Even for companies with robust accessibility processes, there are almost always bugs to be fixed.
d) Fixing the bugs.
e) Confirming that the bug fixes are correct, and didn’t introduce or uncover new bugs. This part of the process is not unique to accessibility, it is just like any other QA cycle.
f) Authoring the VPAT. The INT version of the VPAT template is up to 27 pages when empty I think. This is no longer a back-of-the-envelope exercise.
g) Publishing the VPAT.
It does not get any simpler than the seven steps I’ve outlined above. And it can get much much more complicated, depending on a number of things such as:
budgeting and expenditure processes within your organization
the number of bugs that need to be fixed (and then confirmed)
the number of test/retest cycles the product requires
whether or not the resources to fix the bugs are working on other things
who you have to bribe to get internal resources juggled, etc., etc.
The fastest I’ve ever seen this accomplish from beginning to end is four months. Typically it’s more like a year, and for super complicated products it can be more like 18 to 24 months.
Troubl;e is companioes use a VPAt as a substitute for an accessible product. If you write them honestly they should be a clear indiocation of where you are in the journey. The ones I write for the company I work at from time to time are just a case of reviewing the bugs we closed since the last rewrite and adding things that have been raised since. Update every 6 months and takes a couple of days at most. Not hard."
And they will tell you the impact of the non-compliance (e.g. it's in a certain workflow)