Content author: Office of Accessibility

Like most states and other large organizations, the State of Minnesota buys a lot of its technology. We depend on a wide range of vendors to provide us with digital applications and services. They range from highly specialized apps, such as a laboratory tool, to Software as a Service (SaaS) tools (cloud-based model for delivering software applications over the internet) used by every state employee. 

By state law, every one of these digital tools must be accessible – whether it is for use by a single state employee or by the general public. Our State's Digital Accessibility Standard uses the Web Content Accessibility Guidelines (WCAG) 2.1 and the amended Section 508 of the Rehabilitation Act to measure accessibility.

When a technology doesn’t meet our accessibility standard, agencies must file an Accessibility Exception.  

Identifying inaccessible technology

When an agency needs to buy technology for a particular purpose, they need to find out whether it presents any barriers to users with disabilities. The quality of information depends on a variety of factors. For example:

• The vendor may or may not have clear, credible, accessibility documentation, like an Accessibility Conformance Report (ACR), which is the completed version of a Voluntary Product Accessibility Template (VPAT).
• The vendor may or may not provide a road map to address known/reported accessibility issues. 
• State employees may or may not get a demonstration from the vendor.
• State employees may or may not be able to test the technology in advance of the purchase.

If an agency gets all the above information, it should have a good idea of whether the technology is accessible. If an agency gets no information, it may have to assume it isn’t accessible until they have an opportunity to use it.

It’s important to note that “accessible” doesn’t mean the technology must pass every single WCAG criteria with flying colors. Rather, there are two general, intertwined questions to ask:

• Does the application enable people with disabilities to have an experience that is functionally equivalent to those experienced by people without disabilities?
• Does the application present any barriers to users with disabilities? Examples of such barriers can include:
  • Key elements (such as a Submit button) are not accessible by keyboard.
  • Text or operable elements fail color contrast requirements.
  • Form labels or other user interface components lack accessible names.

The agency can declare the application accessible if one of the following apply:

• The vendor provides a credible, thorough, ACR that shows there are no significant barriers.
• The vendor’s ACR does identify some barriers, but 
  • They include a roadmap to fixing the barriers.
  • They have a demonstrated commitment to fixing barriers.
• The agency has tested the application and found it accessible.

In some cases, even with a credible ACR and a roadmap to fix known issues, the agency may still file a short-term exception with a plan to close it once the fixes are implemented.

In all other cases, the agency must file an exception to purchase the application. 

Exceptions

The purpose of an exception is to help the agency:

• Acknowledge that they are buying technology that may present barriers or great challenges to some users with disabilities.
• Accept the risk associated with the purchase.
• Use the information to make plans to mitigate that risk.

For example, the agency must:

• Take steps to ensure that any users will be able to accomplish the relevant task, whether through alternative means or equivalent facilitation.
• Ensure that no employee’s job status will be negatively impacted by the application.

Ideally, the agency should also work with the vendor to improve the product’s accessibility. 

All exceptions have a time limit based on the level of risk it represents. The higher the risk, the shorter the exception period. Prior to expiration, the agency reviews the exception and determines whether to:

• Renew the exception at the same risk level.
• Document a reduction in risk and renew for a longer period.
• Document elimination of barriers and close the exception.
• Discontinue the app.

Future articles 

In part 2 of this ‘Accessibility Exceptions at the State’ series, we will examine how the state assigns the level of risk to exceptions.