How to Test Your Software’s Accessibility

Accessibility is not only a concern for physical spaces but virtual ones as well. Whether your organization has a software-based product or just a website, it’s important to consider software’s accessibility.

1.      Consider Legal Requirements

Not only can inaccessible software make it difficult or impossible for certain groups of people to use software, it can also be illegal. Software accessibility laws are in a state of flux, but more lawsuits relating to software accessibility emerge each year.

According to the law firm Seyfarth Shaw LLP, 2017 saw a 16 percent rise in lawsuits related to the Americans with Disabilities Act’s (ADA) Title III primarily because of website accessibility lawsuits. ADA Title III helps ensure people with disabilities can access public accommodations. As the ADA was passed before widespread internet access, how this regulation applies to websites is hazy. This type of lawsuit often requires websites to have connections to physical locations. But, that does not mean companies with products that do not relate to physical locations have nothing to worry about in terms of accessibility regulations.

Section 508 of the Rehabilitation Act requires the US federal government to use accessible information and communication technologies (ITC). This means that if your company wants to sell ITC to the US federal government, your product needs to adhere to Section 508’s standards. Software accessibility laws aren’t limited to the US either, the European Union’s EN 301 549 requires ITC used by the EU’s public sector to adhere to certain accessibility requirements. Companies that sell products to the US federal government and/or EU public sector should consider completing a voluntary product accessibility template (VPAT®) to make it easier to determine your product’s accessibility. Please consult a lawyer for legal advice.

2.      Consider All Types of Disability

While doing accessibility testing, it is important to account for the various forms disabilities take. From blindness to hearing loss to cerebral palsy to epilepsy and beyond, different disabilities require different accommodations.

For this reason, many accessibility standards cover diverse sets of concerns. Section 508, for example, has functional performance criteria that requires ITC to still be usable with limited or no ability to do such things as speak, manipulate objects, and perceive color. This usability is achieved through specific requirements like requiring values associated with an object to be able for programs to change (502.3.4) and list of actions on objects to be determined with assistive technology (502.3.11).

3.      Consider How Accessible to Make your Software

The guidelines outlined by legal requirements are a good place to start as these often take into account a variety of disabilities, but it is also important to consider whether you will accommodate disabilities beyond the legal requirements/recommendations and the extent to which you plan to accommodate people with these disabilities.

A website aimed at elderly consumers, for example, might go beyond the legal recommendations for catering to disabilities that often emerge with age. As a result, the website might go beyond WCAG 2.0’s level AAA requirement that text can be resized to up to 200 percent without users having to scroll horizontally to read a line of text, by already using a large font size and making the text resizable to greater than 200 percent (1.4.8 item 5).

Even within the legal requirements themselves, there are choices to make. WCAG 2.0’s requirements are a good example. It features levels A, AA, and AAA compliance. Level A is the lowest level of compliance and level AAA is the highest. Each higher compliance level must also adhere to the level(s) below it.

Compliance with the Revised Section 508 Standards requires many of the guidelines from WCAG 2.0’s levels A and AA. It is, therefore, advisable to meet at least levels A and AA requirements’, but the decision to meet AAA requirements is a more complicated one. It will likely come down to how much money and time your company is able to invest and how important accessibility is to your business model.

4.      Choose Your Assessment Method

Just as there is no definite answer for how accessible to make your software, there is no single best way to evaluate software accessibility. Two primary methods involve using accessibility evaluation tools and outsourcing to a company that specializes in accessibility tests.

Which you decide will, again, probably be determined by your budget and how important accessibility is to your customer base as outsourcing tends to be more expensive. As for accessibility evaluation tools, the World Wide Web Consortium (W3C) has compiled a list of possible tools.

5.      Implement Your Assessment Method

While implementing your assessment method, it is important to decide what specifically will be assessed for accessibility. For example, will you only assess what end users’ access? Will you also assess the elements of your user interface only accessible at the administrative level? Will you only assess the versions of the product you sell to the organizations that require these regulations or all of them? These questions may influence who is able to use and purchase your product.

What Accessibility Options Impulse Offers

Impulse strives for SafeConnect to adhere to Section 508 and levels A and AA of WCAG 2.0 for our end users. Impulse conducted its accessibility testing using JAWS (Job Access with Speech), a screen reading tool, to help ensure SafeConnect is accessible with assistive technology.

To request a demo of SafeConnect or learn more, visit our demo page.

Comments are closed.