Automating Accessibility in Health IT – Part 2

The first article in this series, Disabilities and Accessibility in Health IT: The Need Is Constant, introduced the importance of designing web sites and other health care tools for many different types of people. In this article, we’ll look at how far you can go with the automation of web site accessibility.

Automation and the human factor

In most endeavors, computers can provide help while leaving tasks that require human intervention, a role for the computer that user interaction pioneer Doug Engelbart called “augmentation.” In making web sites accessible, we can ask which jobs are for a computer and which are for humans.

Human intervention, in this case, calls for involving people from different disabled communities directly. They might join a focus group to engage in participatory design, or enter a lab to test interfaces.

Caroline Jerome, the designer quoted in the previous article, believes that good design skills are more important than testing. Designing a good interface is not intuitive, but she has found that people who study design can anticipate visitors’ needs. She endorses the WCAG rules, which form the basis of many automated tools we’ll look at.

Brandon Cooper and Jennifer Dunphy Bowers of Get Real Health are responsible for accessibility for a site used by about three million people, with government clients who require compliance with accessibility regulations and standards. Their web site includes a button for submitting feedback, but Cooper and Bowers say that visitors rarely comment on accessibility. But people with disabilities sometimes participate in usability testing, which the company holds every three months.

We’ll review several sophisticated tools in this article that either check web pages for problems or adjust the pages automatically to the needs of the visitor. But they have limitations. The web page for Axe-core claims that “you can find on average 57% of WCAG issues automatically,” with additional elements flagged for manual review.

One continuing problem concerns the “alt text” that every image should bear to provide a verbal description. Automated tools can determine whether alt text is present, but not whether it accurately reflects what the picture is trying to say.

The AI community has developed some tools for identifying and labeling images. UserWay offers one of these. Such tools are great for retail outlets, but often don’t reveal the true significance of an image on more complex sites. For instance, an AI tool can label a picture as “A woman wearing a face mask.” But that probably misses the point. The reason for putting such a picture on a health care site is probably to say: “Make sure your mask tightly covers your mouth and nose.”

Patrick Vice, VP of engineering, product & platform at Fullscript, told me they put their web site through three levels of accessibility testing:

  1. Each time code is checked in, certain automated tests are run. This is a typical quality control procedure known as continuous integration (CI) in the computer field.
  2. A larger automated test, which takes a long time to run, is performed at regular intervals.
  3. They also do manual testing.

The automated tests use Axe-core.

Before wrapping up this section on the human factor, I want to cite a principle emphasized by Dylan Barrell, CTO of Deque Systems, in his Agile Accessibility Handbook (available for free by filling out a form). Technical training and coaching is not enough, he writes: one must constantly connect developers with the people they are coding for, to develop empathy.

Barrell’s book reflects the same interest in continuous integration shown by Fullscript. Many of Barrell’s recommendations are basically trying to integrate accessibility into the same best practices used by companies for software quality in general: bug databases, collection and regular reviews of metrics, and so on.

Axe-core: An open source web accessibility tester

Deque Systems, founded in 1991, faced a skeptical marketplace for many years. A number of companies large and small—including Google, Microsoft, and IBM—had developed rules engines to check web sites for accessibility. But the tools were incomplete and produced very different results, which sometimes even contradicted one another.

A crisis of trust ensued. Many web developers gave up on the whole idea of automated testing.

In Barrell’s view, the companies didn’t take the task of determining accessibility seriously enough. Their projects were all underfunded. Some of them were grassroots efforts that didn’t get enough attention at high managerial levels. Overall, the companies didn’t understand how hard the job was.

Deque took on the task over many years. Axe-core is about the fourth version of a tool first developed more than 20 years before.

Axe-core is essentially a JavaScript library that developers upload to their web servers. If your organization employs a front-end programmer, they likely have enough knowledge to get Axe-core working. The task involves instrumenting the web pages (that is, adding a small piece of JavaScript that monitors what happens on the pages) and specifying what you want the tool to report. The tool determines where you fail to follow the advice in the WCAG specification.

When Deque felt that Axe-core was ready, it released the library as free and open source software (under the Mozilla Public License 2.0). This was a bold move that paid off. In fact, Axe-core’s success illustrates the strengths of free software.

First, developers could examine Axe-core and determine for themselves whether to trust it. The project has also attracted outside contributors, allowing it to evolve organically to meet developer needs.

Second, Deque intensively engaged with the creators of the proprietary testers mentioned earlier in this section. They all agreed to abandon their products, seeing that Axe-core was better. Thus, the web community united around a single platform available to all.

And for Deque’s business, Axe-core delivered on their hopes. They can sell numerous services around it.

Automatic accessibility remediation: User-triggered enhancements

Let’s look now at two companies whose services change web sites on the fly to make them readable for different types of visitors. Do you need to stop animations and popups so they don’t trigger epilectic symptoms? Do you need to enable tabbing from one element to another? Or do you just want larger type?

According to Josh Basile community relations manager at accessiBe, “Epileptic and seizure prone users can browse a website more safely when it is built with a reduction of flashy animations and color combinations. On the other hand, persons impacted by vision impairments or low vision would benefit from eye-catching animations and vibrant colors.” Basile himself is a C4-5 quadriplegic following an accident as a teenager, but has become a lawyer and recently celebrated the birth of his first child.

On sites who contract with accessiBe, each visitor can define a “profile” to enable “superpowers,” as accessiBe calls the service. A visitor can also define different profiles for different web sites.

Web sites that contract with accessiBe or UserWay to provide automated user-triggered enhancements show this support by displaying an accessibility symbol (Figure 1) and provide a related audio indicator that the site is accessible. Both companies promise compliance with WCAG andthe ADA.

Standard accessibility icon
Standard accessibility icon

Figure 1. Standard accessibility icon

A fifteen-minute video (with a text transcription) demonstrates the multiple services offered by UserWay. The company works with the World Health Organization to make sure that the UserWay service works on many sites internationally: It currently supports 45 languages. Among UserWay’s many clients was the Tokyo Olympics.

Another service from UserWay scans web sites and creates tickets for developers to fix accessibility problems, similar to what Axe-core does. accessiBe offers a service called accesscampus to train web developers how to fix problems that can’t be remediated through automation.

That concludes this series’ technical deep dive. The next article wraps up the series with additional considerations and some general principles.

About the author

Andy Oram

Andy is a writer and editor in the computer field. His editorial projects have ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. A correspondent for Healthcare IT Today, Andy also writes often on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM (Brussels), DebConf, and LibrePlanet. Andy participates in the Association for Computing Machinery's policy organization, named USTPC, and is on the editorial board of the Linux Professional Institute.

   

Categories