Bringing Equal Web Access to All Through Empathy and Automation

Filling out tax forms, renewing a driver’s license, applying for state or federal benefits like unemployment or Social Security. Every day, millions of people easily conduct this type of business online.

However, many government and private-sector websites don’t meet the needs of disabled people, leaving them unable to use services.

Accessibility and usability are fundamental to ensuring all citizens have access to the information and resources they need.

But what if you have a sight deficiency and can’t read text because the contrast is poor? What if you use an assistive device to navigate through a page but the links don’t interact with your technology? These are just some of the accessibility issues that people with disabilities face every day. But solving them can be a challenge for web developers and designers.

Ensuring Equitable Access

MITRE researchers Jeff Stanley and Trevor Bostic are addressing the challenges of web accessibility with a capability called Demodocus (Deh-MAH-do-cus), an automated web crawler they created that simulates the online activities of users with disabilities. This is another way we partner with our government sponsors to improve the digital experience for citizens.

Web applications are already required to meet accessibility standards to ensure everyone can receive services. Since Section 508 regulations passed in 1973 (before the creation of the web), the government has committed to better serve the disabled. However, many agencies receive waivers to defer adherence to the standards, which address everything from colors and contrast of type to the need for alt-text that allows screen readers to describe images on the page.

In 2018, the Section 508 Refresh officially took effect. Measurements obtained from metrics associated with requirements help set criteria for the compliance of documents, web content, and some software. With growing elderly and disabled populations—and the recent COVID-19 outbreak causing the transition to web-based delivery for many services—agencies are under increasing pressure to better understand the accessibility issues their users face and then quickly remediate their technology.

Alerting Web Developers to the Inaccessible

Demodocus starts its inspection by automatically identifying all available content on a web page by interacting with elements on the page. It then simulates how a user with a disability is likely to interact with those elements. Currently, it simulates users with disabilities who use only the keyboard—for example, those with ambulatory disabilities—or those with color blindness.

The crawler can then determine, in ways that other currently available tools cannot, what content is unreachable or overly burdensome to access. The tool then reports the elements and actions responsible for content being unreachable. For example, it would report back that a navigation bar dropdown menu only activatable by a mouse click must also have a keyboard equivalent.

“We're starting to see this tidal wave of government sponsors and private industry rushing to catch up with accessibility standards," says Bostic, Demodocus principal investigator (PI). "A lot of our sponsors have potentially hundreds of applications that need to be brought up to accessibility standards.”

Stanley and Bostic are currently testing 30 government websites and 30 non-government websites.

Demodocus’ ability to interact with different pieces of a webpage also allows it to address usability issues by uncovering how easy or friendly a site is for a user trying to accomplish a task.

Stanley, who is the Demodocus co-PI, says there’s also an educational component to the tool. “We’re trying to help developers and testers understand what accessibility is, and what users with disabilities experience as they attempt to access web applications.

"So we built a framework for developers and testers that will familiarize them with this concept. As they continue to work within the government, they can take that experience with them.”

To continue moving forward on accessibility, Stanley says, it must be considered during the planning and architectural phases. “We want developers and designers to think about accessibility when they begin a project. Make it something that’s as important as security testing, so it's always there, and—hopefully—a lot easier to implement.”

Inviting Community Participation—and Honoring a Poet

Bostic notes that often accessibility and usability is a process and education issue. “Most developers and designers just aren't thinking about accessibility when they first develop webpages. Most organizations only have a handful of people that know what accessibility is and are accessibility experts. Even fewer developers are technically comfortable implementing those practices.”

Some government agencies are standing up accessibility program offices for their web developers to help them begin projects in an accessible way. Many agencies also have 508 Program Managers tasked with being the first point of contact for questions about IT accessibility. However, some program offices are small and can especially benefit from a tool like Demodocus.

Demodocus source code is available on the MITRE GitHub. We're inviting comment and contribution to the code base to enable better service delivery to citizens with disabilities.

And what about the application’s unusual name? Stanley and Bostic chose Demodocus in honor of the blind bard in Homer's “Odyssey.” The duo wants to promote the idea that the tool isn’t just inspecting code to determine accessibility violations. They are trying to dig a layer deeper to really understand and empathize with the experiences of users with disabilities.

“Our goal is to get private-industry assistive technology vendors to take this type of a project on and really learn from the algorithms and technology that Demodocus provides—to make the web truly accessible to everyone,” Bostic says.

For more information about Demodocus: ICT Accessibility Testing Symposium

—by Aishia Caryn Freeman