Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Making Applications Accessible With Open-Source Gauge and AXE

DZone's Guide to

Making Applications Accessible With Open-Source Gauge and AXE

There are a number of open-source tools to address the growing need for developers to integrate accessibility features into their applications.

· Open Source Zone ·
Free Resource

New Report Reveals Open Source Risk Is Still a Mystery to Many. Read more.

It's really exciting to see the growth in awareness of application accessibility in the industry. Nearly one in five people in the US suffers from some form of disability (hearing, vision, etc.). For the proliferation of digitization of brand interaction across all areas of our lives, applications must be accessible for everyone. Whether you're a developer, tester, or team lead, you do not have to be touched personally by this topic to take action and make applications better.

From a development perspective, the current state of accessibility is one of transition. In the past a handful of developers were aware of accessibility requirements and testing was done in a manual fashion. As in every other manual activity taking place post-sprint, it is hard to scale, and many times defects found are ignored because delaying launch carries business implications. If merely creating compliant apps for the benefits of the disabled wasn't sufficient motivation for change, the proliferation of ADA-related litigation activity continues to grow consistently.

Because of this, the DevOps mantra of instilling changes around teams, tools, and processes is now touching this topic. More developers are aware of accessibility requirements, and tools (Apple's Accessibility inspector in Xcode and Google's accessibility framework in Espresso). Similar tools are also available to testers in Appium. For web development, there are nice accessibility scanning tools such as Chrome accessibility audit (part of lighthouse) and interactive browser add-ons (such as WAVE).

The question becomes, what can be automated, and shifted into the regression, smoke or per-commit tests?

For web, there are a couple of open-source tools that offer a nice accessibility scan. One of them is AXE (sponsored by Deque).  It's fairly easy to integrate AXE into any test framework and add a check for accessibility to any existing user flow. It is basically a Javascript inject into the page, that scans object attributes. Therefore it can run on any platform: desktop or mobileGauge is one framework that offers a nice BDD (English-like) scripting, and Java code-behind.

Based on the integration, it's fairly easy to add a new step to a BDD script:

* Open the Gauge homepageGet Started
* Go to Gauge Get Started Page
* I check window for accessibility "Gauge get started page"
* Ensure installation instructions are available


The outcome of this specific implementation (code in GitHub) offers this insight:

Accessibility scan found 3 violations in 5 objects

For each violation, the following is offered:

Error 1
Impact: serious
Rule ID: color-contrast
Summary: Fix any of the following:
Element has insufficient color contrast of 2.82 (foreground color: #777777, background color: #333333, font size: 12.0pt, font weight: normal)
Selector:.container > div.disclamer HTML:<div class="disclamer">Gauge is an open source project, sponsored by ThoughtWorks Inc. under the GPL License, Version 3.0</div>
help: Elements must have sufficient color contrast
helpURL: https://dequeuniversity.com/rules/axe/2.3/color-contrast?application=axeAPI
Tags: [cat.color, wcag2aa, wcag143]


This is really insightful, particularly for developers; it gives you more information about the element ID and the violation, more explanation about them, and how to fix them. But more importantly, it offers a reference to the relevant standards (WCAG).  Also, each element is highlighted:

Image title

Example screenshot for object on page that has an accessibility issue


To summarize, some accessibility defects can become visible to developers almost as soon as they write code. This creates more awareness, collaboration and discussion around accessibility, and eventually better apps for all of us.

To use the sample in this code please visit my GitHub repo


Software composition Analysis for DevSecOps. Start finding vulnerabilities in your open source components today.

Topics:
accessibility ,testing ,test automation ,wcag 2.0 ,ada compliance issues ,open source ,accessibilty

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}