Make sure that the promises you are making about your accessibility are realistic. You want to guarantee that particular pages will be reviewed against particular sets of criteria with consideration of the client’s budget, actual demands, and the time frame you are offering.
- When promising web accessibility, be specific, measurable, achievable, relevant, and time-bound.
- Only promise to pass specific tests with measurable pass/fail criteria.
- Be clear about which pages are included and excluded from accessibility testing.
- Work with people who have extensive web accessibility experience to test larger scoped builds.
- Ensure that testers are different from builders to avoid biased testing.
- Provide training and instructions to your team on how to populate and check content.
Transcript
Welcome back to the Easy A11y Guide channel. I’m Gen Herres, and in this video, I’m going to talk to you about what you can and can’t promise when you go to deliver web accessibility.
In previous videos, I talked about how web agencies can sell accessibility to their maintenance clients and with their new builds. If you miss those videos, I’ll have them linked in the video description below.
Promise to pass a specific test
Now that you’ve sold accessibility to your client, you want to get into the specifics of what you are going to promise to deliver. The first thing you want to look at is how much web accessibility you sold. Was it a lower level or a higher level? And the appropriate price point for those levels.
You can only promise passing a specific test with your web accessibility. You cannot deliver a 100% accessible website for everyone because you just don’t know what everyone’s individual challenges and technical setup are. It’s just not possible. But you can pass specific test that have specific pass/fail criteria. When working with lower-budget clients, like I do when I do a one-day build, very little time is allotted for testing or remediation.
So I only include passing of the Lighthouse test for the one-day build. As I scale to higher price points, I add in more testing and more accessibility. When I write out the promise of what I’m going to deliver, I make sure that the goals here and the promises are smart or specific, measurable, achievable, relevant, and time-bound.
In my one-day build example, here’s how that would play out. I’d promise that on the day of the build, the pages that I built for that day would achieve a score of 100 on the accessibility test of Google Lighthouse, unless the client specifically asked for something which would prevent that score from being achieved in the allotted build time of the day. This goal is specific.
Only promise things that are specific and measurable
It’s very clear what I’m promising, only these specific pages that I built. The goal is measurable since it refers to a specific score on a specific set of tests. The goal is achievable because I have processes in place that allow me to build these pages, so I almost never have anything to correct. Rework is very expensive, and you want to make sure that your processes are really dialed in to prevent rework from being needed.
The goal is relevant. Passing the Lighthouse test does do something for web accessibility. Not everything, but this is a limited-budget client. The goal is time-bound because I’m only promising on that specific day that it’s going to pass. If the client goes in there and does additional work in the future and messes things up, that’s outside the scope of my promise.
For some client reassurance, I like to talk about previous experiences that I’ve had with this one-day build. For example, some of the websites that I’ve built on a one-day build have been tested by accessibility specialists as well as by users with real disabilities using screen readers. The websites have done very, very well with very few requests for any changes.
As project scopes and budgets increase, I will offer more comprehensive testing and more pages. I still won’t make any promises that it will be 100% accessible because, again, I can’t measure that. I always want to be promising things that are measurable. It’s also important to note that I always specify which pages will and won’t be covered with the accessibility testing. For example, if a client has hundreds of old blog posts, you’ll likely want to exclude the bulk of them from what is tested so that you can save time and money.
I also make it clear that the definition of pass means that there were no issues found. This could be that the criteria just didn’t have anything that was applicable, or it could be that the tester didn’t find any issues when they test it. That doesn’t necessarily guarantee that it will pass in every single situation for every single user. Because again, I can’t promise for unknowns.
Work with people who have extensive web accessibility experience
To test these larger scoped builds, you’ll need to have people with extensive web accessibility experience. You also need to make sure that the person who does the testing is different from the person who does the building. The reason is, just like editors go over what a writer wrote, you need testers who go over what a builder built. You can’t test your own work well. If you don’t have in-house developers and testers with the accessibility experience, then you’ll need to bring in accessibility professionals.
Prices can vary a lot on this and depend on how much training they will be providing your team and how much doing of the work they will do. In many cases, it is less expensive to have them do the initial building work and then provide your team with training and instructions on how to populate and check the content that needs to be added. Then have their testers do the final testing. For more information on how to deliver an accessible website, check out my video on that topic, linked in the description.
Recap
To wrap up what we’ve talked about, you want to make sure that you are making smart promises with your accessibility. That means specific, measurable, achievable, relevant, and time-bound. You want to promise specific sets of criteria to be checked on specific pages. Measurable, pass/fail tests for that criteria, achievable within the budget provided, relevant in scope to what the client actually needs, and that you are only promising it on a specific time period.
Thanks for watching. I’m Gen Herres from the Easy A11y Guide, where we try to make accessibility easier to implement through done-for-you services, tools, and processes. If you enjoyed this video, please give it a thumbs up. It really helps our channel.
You can subscribe to our channel for more accessibility tips and to be notified when new videos are released. For more, tutorials, and more, please visit easya11yguide.com. Thank you so much again for watching, and I look forward to seeing you in the next video.