Most EdTech companies now take accessibility concerns into consideration as they develop new products and services. That’s especially true considering that accessibility standards are codified in the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG 2.1) and the U.S. General Service Administration’s Revised Section 508 standards.
But what about your existing product?
If you’ve never measured and optimized your EdTech product’s accessibility, you almost certainly have gaps to contend with. Your first step is to assess your product and identify your accessibility baseline — or your current level of compliance with accessibility requirements and best practices. Only then can you build an accessibility roadmap that charts a course toward a more inclusive and accessible user experience for all.
At a high level, there are two ways to go about appraising your digital product’s accessibility. The first is to work with an external partner to produce a Voluntary Product Accessibility Template (VPAT). A VPAT is a document demonstrating that your product meets the United States Access Board’s Revised Section 508 Standards for IT accessibility. All government entities, third party partners, and institutions that receive government funding are required to produce a VPAT.
Depending on your unique situation, your EdTech company may be required to complete a VPAT, too.
If a VPAT isn’t required, you’ll need to decide for yourself how to assess and optimize your product’s accessibility. Which leads us to the second option: an informal accessibility audit and remediation plan. Unless you have a particularly compelling reason to go with a VPAT, the latter is probably your best bet. The reason? VPATs are highly structured, which is a good thing. But they are also complex, time-intensive, and costly. Unless you already have experience completing a VPAT, it’s not something you should attempt on your own. In fact, we recommend that an outside party conduct your VPAT so that it cannot be seen as biased.
If you decide to audit your product yourself, your next step is to come up with a game plan. You’ll need to:
Here’s how.
Ready to move forward with an accessibility audit and remediation plan? Take the following steps to begin.
If your EdTech product is small enough and it’s reasonable to do so, plan to test your entire product. However, if your product is larger and more sprawling, then it probably makes better sense to test a representative sample. Select a sampling of pages and workflow states that best represent your product as a whole. Make sure to include any high-traffic areas (such as your sign-in page and onboarding content) and flagship features. Of course, you’ll also want to include any pages or features that you suspect might be harboring exclusive design patterns (such as a visually oriented data dashboard).
The following automated accessibility tools will give you a good understanding of several of the key accessibility issues that may be present within your product.
Automated tests look at a number of accessibility factors, including color contrast, live regions, redundancies in link language that might trip up a screen reader, heading structure (H1s, H2s, and so on), and alt text on images.
Although these tools automatically audit individual pages within your product, you’ll still need to manually run each program on a page-by-page basis. Your engineering team may be able to create a script to further automate this process and reduce your team’s handwork.
Why is it that automated accessibility testing is just one step in the auditing process? Automated accessibility programs aren’t comprehensive. In fact, they only capture about thirty percent of all accessibility issues. This is primarily because of the various workflows and states within your product. Automated programs audit individual pages in their original loading state. They don’t trigger every workflow, state, form field, or button within those pages. For example, if one of your product pages includes a focus state, the automated accessibility tool won’t audit that state unless you manually trigger it and run the program a second time.
Once you’ve completed the automated testing phase, it’s time to round out your accessibility baseline with additional layers of manual testing. This should include:
Once you’ve completed your accessibility audit, it’s time to craft a remediation plan to make your product more accessible. To start, catalogue and categorize your product’s accessibility issues. Plan to use a severity scale to help you prioritize what to fix first. For example, you might rate each accessibility issue according to the following criteria:
Prioritize all issues with a “1” rating first, then move on down the list. You can further prioritize your accessibility to-do’s within each severity rating by fast-tracking issues related to your product’s most critical workflows. For example, if your product sign-in page is inaccessible, then that should be your first priority.
As you frame up your accessibility roadmap, commit to doing more than just the bare minimum required to meet accessibility regulations.
Once your remediation roadmap is complete, communicate your plan to your users. You might even make your roadmap public and allow your users to see exactly what you plan to fix and when. Doing so will build goodwill among users and hold your team accountable to your accessibility remediation plan, as well.
Don’t put your product’s accessibility on the back burner. Start planning your accessibility audit and remediation plan today. Your users (and your legal team) will thank you.