If you’re designing for the web, you may have applications or public-facing integrations that should be vetted for Accessibility. This includes the platform itself. In the early days of drag-and-drop CMS platforms like Squarespace or Wix, it was hard to ensure the visual interface followed proper hierarchy, or avoided navigational issues like keyboard traps.
The process outlined below can help you evaluate software or web services to ensure Accessibility for your, or your client’s users.
Depending on your particular use case, different products will pose different levels of risk. While it is not a perfect system, we can mitigate risk via the number of users:
<aside> 💡
Note: You can define levels of risk for yourself, but all public-facing content, including web apps and digital marketing platforms are assumed to reach over 100 users and identified as "High Risk."
</aside>
For High Risk assessments ACRs should be evaluated before the procurement process can proceed. In cases where products prove to be partially or fully noncompliant, an EEAAP could be developed, signed and documented.
For Medium Risk assessments, ACRs must be evaluated before the procurement process can proceed. In cases where products prove to be partially or fully noncompliant, EEAAPs or simple workarounds may be required on a case-by-case basis.
For Low Risk or No Risk assessments, ACRs should still be collected and reviewed, however a full evaluation may not be necessary for the particular use case, unless they are known to directly affect a population of Dis/abled users.