Accessibility is a fast-growing concern for all EdTech companies. If your EdTech product doesn’t effectively serve all of its users (including those with disabilities) then you have a problem. You aren’t just excluding whole categories of users. You’re shortchanging your overall user experience — and setting yourself up for possible lawsuits to boot.
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.
Voluntary Product Accessibility Template vs. an Informal Accessibility Audit: Which is Right for Your EdTech Company?
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:
- Familiarize yourself with the guidelines in Revised Section 508. Alternatively, you could choose to use the World Wide Web Consortium’s Web Content Accessibility Guidelines (WCAG 2.1).
- Audit your product (or a representative portion of it) to determine your accessibility baseline with respect to current accessibility guidelines
- Build an actionable accessibility roadmap that prioritizes fixes to remediate your product
Here’s how.
How to Audit Your EdTech Product’s Accessibility — and Craft an Actionable Remediation Plan
Ready to move forward with an accessibility audit and remediation plan? Take the following steps to begin.
Determine which parts of your product to audit
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).
Run a first round of tests using automated tools
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.
Follow up with a second round of manual testing
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:
- Keyboard-only testing. Interact with key areas of your product using only a keyboard. Check to make sure keyboard-only users can access the interactive elements on the screen, such as buttons, links, and images. Be sure each of these elements includes a focus state that passes color contrast ratios. Finally, make sure that keyboard-only users don’t get stuck in “keyboard traps” (for example, if they enter a menu, make sure they can also backtrack out of it.)
- Color-contrast testing. If you don’t know how to use dev tools to check your product’s contrast, you’ll have to do it manually using an online color-contrast checker.
- Screen reader testing. Screen readers can be difficult to use for the uninitiated. For that reason, all UX designers should develop a baseline understanding of the various screen readers and how they work. Different screen readers interact differently with different browsers. You don’t necessarily need to test every screen reader in every browser, but you should be aware of some of the key differences. NVDA and JAWS are the most widely used screen readers. However, both of these programs are built for PCs, not Mac computers. VoiceOver for Mac is included in all Apple products, but it’s generally considered less effective and is therefore much less popular among visually impaired users. As you consider whether your product is optimized for screen readers, ask yourself:
- Do your headlines make sense?
- Are your table headers marked up correctly?
- Do images have descriptive alt text?
- Are you properly communicating the status of various components (such as whether a menu is open or closed)?
- User testing that includes people with disabilities. Be sure to have users with disabilities test your product, including those who rely on screen readers or keyboard-only interactions. Their feedback will yield the most meaningful accessibility insights of all. In addition, these users can help point out usability and ease-of-use issues. While those issues may not be mandated by compliance rules, addressing them will make your product more inclusive — and better for everyone in the long run.
Create a remediation plan
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:
- User cannot access critical information
- User cannot access critical information but there is a known workaround
- User cannot access non-critical information
- The issue doesn’t prevent user access but does impact the product’s usability
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.
