Web law

I’m a web developer. I create applications delivered over the World Wide Web. Synonyms include “software engineer”, “programmer”, and “coder”. What’s the connection with law?

The law, as they say, has a long arm. And it does reach into the software that we create and use. Let’s discuss one manifestation of this relationship.

Unelected lawmakers

There’s a myth about the law: The people elect representatives, and the representatives write and adopt the laws.

It’s a myth for multiple reasons. One is that, in most of reality, elected representatives don’t really write laws. Instead, they adopt laws written by others.

By whom?

Well, for the laws that dictate how we build buildings, it’s often the International Code Council, a California nonprofit corporation that has dues-paying voting members.

And for laws of many kinds it’s lobbyists hired by organizations that those laws most directly affect.

Web accessibility

During my 34th week (ending on 5 January 2018) at Learners Guild in Oakland, California, where I’m getting retrained in software development, I’ve been studying “web accessibility”, and that includes web-accessibility law.

Web accessibility is the problem of making websites, and all resources delivered by means of the World Wide Web, “accessible”—or at least more accessible—to everybody, and in particular to people whose access would otherwise be abnormally limited, such as by long-term, temporary, or age-related disabilities.

Suppose, for example, you are designing a website that gives instructions for assembling an item of furniture, and you want people who know various languages to understand it, so you pursue this accessibility by using line drawings with stick figures, arrows, clock icons showing times of day, and a silent video to do most or all of the explanation. Great (if it works); you now have an alingual, and thus panlingual, website. But what about a blind person who wants to assemble that furniture item? All your accessibility efforts will fall flat for that user. If you had written the instructions with text in some language, then the blind user could use a screen reader to convert the instructions from text to speech, and an automated translation service could try to convert it from its original language to the user’s language.

So, accessibility is a tough problem. Making resources overcome some barriers may exacerbate other barriers.

Accessibility law

Governments have become involved with web accessibility. That’s not hard to understand, since anti-discrimination laws and laws requiring disabled-friendly facilities have become familiar. As the web becomes increasingly the interface between businesses and customers, and between governments and citizens, the motivation to mandate an accessible web becomes more obvious.

By now, many governments have adopted laws imposing accessibility requirements on web resources. These include subnational governments, such as California, where Governor Brown just signed a new law in October. In some cases, the laws regulate governments’ own websites. In others, laws require nongovernmental websites, too, to be accessible. And there are hybrids: websites developed by nongovernmental entities for governments, or under government grants.

Given—as I claimed above—that web accessibility is a tough problem, how do governments craft web-accessibility laws?

Well, in line with the above-stated generalization, they typically don’t. In almost all cases, governments simply adopt requirements that others have defined.

By far the most common creator of governmentally adopted web-accessibility requirements is the Accessibility Guidelines Working Group. Currently it has 153 official participants (including “Invited Experts”). Membership is by invitation.

The largest contingent (14) in the AGWG is from Deque Systems, Inc.. That firm sells products and services that evaluate the accessibility of websites and make websites more accessible. Deque also creates and publishes free documentation about web accessibility and a free tool for testing websites for accessibility. Other major participants of this kind are Paciello Group with 9 and Level Access (formerly SSB Bart Group) with 6 persons in the AGWG.

You might then ask, “Isn’t there a conflict of interest when a company that makes money by helping customers satisfy government requirements participates in drafting those very requirements? The tougher the laws, the greater the demand for the company’s services.” Yes, the conflict is natural, and it exists in many domains. In the case of web accessibility, the conflict may work to the advantage of persons with disabilities, by making the laws stricter than they would have been if legislative staffs had actually drafted the laws.

I’m not arguing, however, that the AGWG is consistently biased in favor of draconian legislation. It does include participants from governments, academia, and some information-technology companies (e.g., IBM, Microsoft, Google), and some of those organizations might be burdened by accessibility mandates.

Legislative laziness (if it’s that) has another effect: uniformity. By deferring to a single standardization organization, legislatures tend to make the entire world a single compliance zone. Make your site accessible in Israel, and you’ve made it accessible in Hong Kong. And, some argue, that promotes compliance.

Nuts and bolts

What requirements, then, do laws adopt from the AGWG? Generally they adopt the Group’s Web Content Accessibility Guidelines. WCAG identifies only certain disabilities that it (yes, it’s plural, but I’m treating it like “United States”) is aimed at helping to overcome. These are “blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity, and combinations of these”. But it also argues that measures making web content accessible to users with these disabilities also tend to help “older individuals with changing abilities due to aging” and, more generally, all users.

WCAG assumes that users with disabilities can adopt three main strategies in dealing with web content. First, they can use one ability instead of another. For example, if a video contains subtitles, then somebody who cannot hear can read the subtitles. Second, they can use assistive devices to convert content from one medium to another. For example, if there are no subtitles, a speech-to-text converter can render video dialogues readable. Third, they can do their best.

The WCAG treats text as the universal pivot for conversion. It is easier to convert text to anything else than to convert video, graphics, or voice. So, compliance requires that non-text content be accompanied by text.

For users who do their best with the content that is there, the WCAG limits the skill that the content requires of users. For example, a website is not compliant if it displays medium gray text on a dark gray background: Contrast must exceed a specified threshold. If a page contains a form with buttons to make choices, the buttons must be farther apart than a specified distance, so those with limited pointing control can more easily choose one. And it must be possible to navigate among and press those buttons by using only a keyboard; a mouse must be optional. Speedy fingers must not be demanded; if you press the mouse button and don’t immediately release it, you won’t suffer damage.

The WCAG also regulates site architecture. Moving from item to item with a tab key must follow an appropriate path; sites where the tab key moves the focus quasi-randomly around a page are verboten. Page structure must also be interpretable by a program. Is it divided into sections and subsections? Is part of it required and part optional? If so, then this structure must be one that a program can discern; it must not be evident only to humans who can see it.

Common operations that users perform on web content (such as “undo” and “log in”) must be labeled in a standard fashion, so assistive devices can reliably understand the controls that perform them and operate those controls when instructed by users to do so.

Finally, websites must not make anything flash more than 3 times per second, since that could trigger seizures.

This is only a sample of what the WCAG requires, but it gives the flavor.

What next?

Web accessibility affects us web developers in two ways. First, it defines standards of usability that we either can or must decide to comply with. Second, it creates an automation challenge. We are, after all, software developers. And making web content accessible is a task. So it’s only natural for us to develop software that makes software accessible—automatically.

In studying web accessibility during the week, I tried out 10 programs that assess the accessibility of web pages. The results were unimpressive. Some of them found numerous defects, while others found nothing. Some found one defect, while others found another defect. One of them found defects that didn’t really exist. Each of them overlooked defects that at least one of the others discovered.

One possible response to such disappointing performance is to try to improve it. Perhaps, after more study, I’ll try to create a better assessment tool, contribute improvements to an existing one, or work instead on software that not only assesses content but actually makes it accessible.

After only a week studying this topic, I have far more to learn. This includes getting more familiar with the actual, not only theoretical, consequences of noncompliance. It’s one of those subfields of software development (like network security, encryption, digital banking, and digital privacy) that gives us developers incentives to acquire legal and political knowledge as well as programming skill. And the problem of web accessibility seems likely never to be solved, because the web itself keeps incorporating more immersive, multisensory, and thus probably less inherently accessible interactions, and because consensuses about the classes of persons entitled to accessibility keep changing.

4 thoughts on “Week 34 at an Unbootcamp”

I work at a company whose products are used by government and by business in an industry that is subject to significant government regulation, and we use AGWG guidelines when developing our web-based interfaces. It’s a challenge, and rather than being able to definitively say that our products comply or don’t comply, I would say that we try, as much as we can, within reason, to follow those guidelines. But since our UIs are built on top of UI frameworks developed by others (and this is the common case: who builds UIs from scratch these days?), we cannot always guarantee, for example, that every single capability provided via a mouse-based interface is also available via the keyboard.

In your list of companies heavily involved in AGWG, you didn’t mention The Paciello Group (another commercial provider of accessibility solutions), which has, I think, about 9 AGWG participants.

Thanks for your informative comment. I have corrected my omission of Paciello Group, thanks to your help. In principle, using a framework could help us develop accessible UIs, because the framework could build accessibility in. Have you found this potential benefit unreal?

Most sophisticated UI frameworks try to build accessibility into their component suites, but I am not aware of any frameworks where accessibility is at the top of the list of requirements. An application developer, when evaluating which UI framework(s) to adopt, will have a set of needs that are not always mutually compatible. If a framework has excellent accessibility, but is fairly buggy and is missing some desired components, it is unlikely to be chosen over a more robust and more comprehensive framework that that is OK, but not excellent, with regard to accessibility. The perfect tool doesn’t (yet) exist. (Maybe that’s a project for week 36 at the Learner’s Guild!)

Thanks much. It seems as if the original HTML elements tend to have the best a11y support. So does Captcha, although the Recaptchas that I encounter often expect me to be competitive in U.S. popular culture and have X-ray vision.