SaaS & Web App Accessibility Compliance Requirements
More and more often today, software is accessed via a browser rather than your computer’s hard drive. And today such providers must consider the accessibility of their software or lose competitiveness or worse, face lawsuits.
To answer the question”do SaaS and web apps need to be accessible” the answer is yes.
Just like websites, SaaS and web app providers must conform to the Web Content Accessibility Guidelines (WCAG) in order to comply with the Americans with Disabilities Act (commercial & public) or Section 508 of the Rehabilitation Act (Federal agencies).
While most of the legal pressure is currently on website operators, SaaS providers are feeling pressure from the market. Procurement managers in government agencies as well as private corporations are requiring WCAG compliance.
That pressure is different in different markets. Your average B2C consumer may not be aware of accessibility when shopping for home bookkeeping solutions, for example. However in a B2B scenario, depending on the intended use for the software, WCAG compliance may be a strict requirement - especially for those competing in healthcare, finance, or education in particular. And for anyone selling to the government, the requirement is very straightforward.
SaaS Accessibility Requirements for US Federal Procurement
Digital accessibility procurement requirements for US government agencies or entities that receive federal funds are explicit. In 2017, Section 508 of the Rehabilitation Act was updated to specify requirements for information and communication technology. The updates, which went into effect in January 2018, incorporated the Web Content Accessibility Guidelines (WCAG) 2.0, and clarified its applicability to websites, electronic documents and software.
Therefore any SaaS provider that wishes to sell their web-based applications and software to the government must be able to demonstrate that their product conforms to the WCAG 2.0. The method for such is the authoring of a Voluntary Product Accessibility Template (VPAT), which once completed is referred to as a Accessibility Conformance Report (ACR).
VPAT and ACR for Demonstrating Accessibility Compliance Saas and Web Applications
The VPAT and ACR were developed by the government for the purpose of establishing a standardized format for assessment and reporting of digital accessibility and WCAG conformity. It is now becoming increasingly adopted in the commercial space.
Many providers choose not to author their own VPATS. There are two good reasons to outsource this to external accredited VPAT and ACR consultants. The first is credibility. The second is that it takes a high degree of both technical understanding of the code and the application, along with depth of experience in accessibility and the WCAG.
Digital Accessibility for Corporate and State and Municipal SaaS Procurement
Corporations under ADA Title iii, as well as states and municipalities under ADA Title ii must ensure that all information technology be accessible to people with disabilities.
While most of the headlines focus on website accessibility lawsuits, this does not mean that web-based software is excluded. It's simply a case that websites are incredibly exposed to click-by attorneys looking to make easy money with a few clicks of the mouse. Testing web apps and software requires more complex and expensive. Going after websites is simply easier, but inevitably web-based software will become the target.
Today savvy IT and procurement teams understand the law and the risk. And this is why WCAG conformance demonstrated via a VPAT / ACR is becoming a standard requirement for all IT procurement.
What is the standard for SaaS 508 and ADA accessibility compliance?
While the requirements and what Section 508 covered became crystal clear in 2017, the ADA lags behind. The DOJ has thus far abdicated its role in establishing what exactly is the scope of the ADA and the standards for digital accessibility. This has left the courts to make these decisions. Unfortunately, this has created a patchwork of nuances as you move from district to district. With all that said, regardless of state or ADA vs 508, the WCAG is the de facto standard universally accepted in the US and most countries.
Process for Saas and online software ADA and 508 compliance
Reaching WCAG compliance depends on where you’re starting from. The most cost effective path is to simply start with a clean slate and make accessibility a priority from the very beginning. If product owners, designers, and developers prioritize accessibility at every step of the project, then without surprise, this path is the least expensive and most effective. Here, testing is done throughout design and development stages, and once the software is stable and loaded with data and content, a final deep audit is conducted.
Compliance of existing apps requires an audit and remediate approach. This can lead to required changes to the design of the user interface and recoding of templates and components. It can be very time consuming and expensive.
In either case, it’s essential to recognize the limitations of automated testing tools. Even the best are 30% effective and cannot even detect 70% of WCAG issues. Therefore the process must include manual testing by qualified and accredited auditors. Further, the more experienced auditors will not only understand all of the many user scenarios, but they should also understand the code. This is what separates the JV from Varsity (and us from our competitors).
Wrap up
The pressure from an unending flow of web-related ADA lawsuits is forcing website owners to make their websites WCAG compliant. But while SaaS providers can easily read that writing on the wall, their immediate pressure is coming from their customers who themselves face legal risk if the IT they buy is not accessible. Therefore for SaaS providers to avoid their own litigation, and successfully compete in markets that increasingly require WCAG compliance, well... you get the idea.