The more important question is, why would you want to do that?
I get asked the question, “Can I go to beta without being accessible?” frequently. This question usually comes outside of my employment situation, most often from companies that either sell software or use websites to provide software, services, or information.
Typically, the question gets asked happens because the project owners did not take the proactive steps to make something accessible out of the gate.
- they either forgot about accessibility altogether, either intentionally, through ignorance, or through benign indifference or;
- they are thinking about accessibility as a feature that is easy to add to the end of the product development cycle just before release.
I have three different answers for this question that vary depending on my mood and my previous interactions with the individual asking the question.
Answer 1: Yes, but …
You might be surprised that someone as rabid of a disability advocate as I am would ever answer yes to this question. Well, it isn’t an unqualified yes. It is a “sure, do whatever the heck you want, you are the business owner, you assume the risk” yes, with a list of all the things that could very quickly go sideways.
Most accessibility managers don’t have the ability to block releases.
Sometimes, “success” is figuring out the best that can be accomplished for your users with disabilities in an extremely sub-optimal situation.
The “buts” are:
- For websites/products that are employee-facing only, you might hear from your HR department or your government labor department if you exclude employees with disabilities from your Beta solely because of their status as a disabled person, where their non-disabled peers are included.
- For websites/products that are public-facing only, your users/customers could experience the same issues as highlighted in #1 — they could hear from disgruntled employees or the government because the user/customer installed something that discriminates against their employees with disabilities. The organization that produced the inaccessible website/product could also get named in complaints and litigation. These suits get bad publicity that destroys any credibility an organization has behind its disability inclusion and diversity efforts.
- Making the product accessible after the Beta could involve changes to the code ranging from minor to a complete overhaul. Let’s say hypothetically your website/product includes parallax, lots of motion, or drag and drop. Making that type of website/product accessible would require significant redesign and recoding. These changes would completely invalidate the results of your Beta testing with participants without disabilities. Even the code changes necessary for minor accessibility updates can invalidate your beta testing. Effectively, by releasing an inaccessible product to a broad Beta, you are begging to have to do it twice, at double the cost, with schedule delays to make the accessible version of the product generally available.
- Accessibility bolted on at the end is never as good as accessibility integrated from the beginning. It is always more expensive because you are looking at accessibility from the perspective of “find the bugs, fix the bugs.” Preventing the bugs from happening in the first place is always a better, faster, and cheaper approach. If you get to Beta without having thought about accessibility, chances are there are bucketloads of bugs, which means vast quantities of remediation.
My best recommendation when an accessibility manager is faced with an inaccessible Beta that they are being told must go out “as is” is to require the product team releasing the Beta to develop an accommodations plan.
- Use this opportunity as a “stealth” education exercise.
- The teams who want to release inaccessible Betas frequently don’t realize the problems they are creating or the impact of the discrimination those problems are causing.
- Requiring the product team to create an accommodations plan brings that message home, because they must set up all the processes and procedures to provide equal access because they didn’t make the Beta accessible.
- Hopefully, they think twice before repeating that mistake. If not, move on to answers two and three the next time this situation comes up.
Answers 2 and 3: “No” and “Absolutely Not”
Accessibility managers need to pick their battles.
If an accessibility manager becomes known for saying no to every single request, that by itself becomes a problem. People will end run the accessibility manager, and ask for forgiveness rather than permission if they know the answer to the permissions request will always be “no.” This results in accessibility managers not finding out about inaccessible releases until the first customer complaint comes in.
Starting with “Yes, but…” can lead product teams to come to the conclusion that they need to be accessible without forcing it on them.
When the same battle occurs more than twice with the same product team, then they are deliberately ignoring accessibility, not just forgetting about it or being uninformed. That is when I think it is acceptable to change the “Yes, but” answer to some variation of “No.”
That *is* a battle a good accessibility leader wants to fight, because having someone repeatedly getting away with breaking the rules sends a message that the rules don’t matter. There are two situations where I will escalate my answer from “no” to “absolutely not.”
- When the inaccessible release will impact areas where there have already been complaints about accessibility from users.
- Where the inaccessibility will be very easily seen, attracting the attention of serial plaintiffs.
- People with disabilities have the right not to be excluded from Betas. If the entire point of a Beta is to get user feedback, your Beta will be invalidated entirely if the UI code must be modified after the Beta to support accessibility.
- Calling your inaccessible release a Beta does not eliminate your legal risk. The ADA doesn’t have a clause somewhere saying “Betas are exempt.”
- The more times a product owner tries to release inaccessible code, the harder accessibility managers need to push. By protecting your disabled customers, you *are* protecting the organization.