skip navigation

LII’s overarching mission is to help people find and understand the law, and if free access to law means anything at all, it includes accessibility by definition. Over the years, we’ve worked to make the law more discoverable, more usable, and more accessible. But we’ve not done everything. Now we’re doing a lot more.

What is Web Accessibility?

At its simplest, web accessibility means making web content and services usable by everyone. That “everyone” includes, among others, people with vision impairments, including blindness; people who are deaf or hard-of-hearing; and people with mobility and fine-motor impairments. These days, the acronym “POUR” summarizes the operating principles of web accessibility; content must be:

  • Perceivable (e.g., audio must be transcribed and text must be machine-readable);
  • Operable (e.g., users must be able to navigate using only the keyboard);
  • Understandable (e.g., navigation must be consistent); and
  • Robust (e.g., the website must behave in the same way across a variety of browsers and assistive technologies, including potential future ones).

More complicatedly, web accessibility means conforming to the standards developed by accessibility experts and adopted by government. These standards change over time. In 1998, the federal government and the World Wide Web Consortium (W3C) disagreed about the standards, so government web developers had to conform to what were then the Section 508 Standards, while others might be free to conform to the W3C standard. The standards keep developing (in fact, between the time the federal government finalized the rule adopting the current standard and the time that implementation was required a year later, the W3C issued an additional set of guidelines).

What’s the history?

The last time we undertook a dedicated effort to bring our website into accessibility conformance (in the mid-2000s), we used the government’s Section 508 standards. At the time, these required that:

(a) A text equivalent for every non-text element shall be provided (e.g., via “alt”, “longdesc”, or in element content).

(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.

(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.

(d) Documents shall be organized so they are readable without requiring an associated style sheet.

(e) Redundant text links shall be provided for each active region of a server-side image map.

(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

(g) Row and column headers shall be identified for data tables.

(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.

(i) Frames shall be titled with text that facilitates frame identification and navigation.

(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

(k) A text-only page, with equivalent information or functionality, shall be provided to make a web site comply with the provisions of this part, when compliance cannot be accomplished in any other way.  The content of the text-only page shall be updated whenever the primary page changes.

(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with §1194.21(a) through (l).

(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

(o) A method shall be provided that permits users to skip repetitive navigation links.

(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.

Source: Access Board (2009, via

At that time, most of our content problems were with marking up data tables. We were extremely fortunate to be aided in this effort by then-student, now Cornell University Associate Vice President for Inclusion and Workforce Diversity, Angela Winfield, who made accessibility conformance part of her editorial work for us. And semantic markup made everything more discoverable.

And then our attention was diverted elsewhere. From time to time, we’d receive fan mail from a blind law student, thanking us for providing an accessible version of the Federal Rules that they could use in class. We thought we were doing pretty well. But we were not keeping up.

Several things had changed. Just as we were wrapping up our accessibility conformance project, the Web Accessibility Initiative of the W3C standards body promulgated new Web Content Accessibility Guidelines (WCAG 2.0). Whereas in the past, federal regulations diverged from WCAG standards, within the past few years, WCAG 2.0 level AA has become the standard for new government websites in both the United States and the European Union. The WCAG 2.0 standards are far more extensive than the former Section 508 regulations, so modern accessibility compliance initiatives are far broader in scope.

Another major change after our last push on accessibility was that we became re-publishers of the Code of Federal Regulations. This project introduced a panoply of accessibility challenges, most of which we believed the federal government publishers could – and should – remediate, but which we endeavored to ameliorate ourselves. The results were mixed. We added indentation to make the text more readable, but because the text is not consistent in its enumeration, the markup is sometimes flawed. We added links to defined terms and acronyms to improve understandability, but this resulted in semi-duplicated links that were difficult for screen readers to distinguish. Most frustratingly, the CFR contains more that fifteen thousand images, many of which could not be fully remediated by adding “alt” or “longdesc” text (our next blog post will cover that).

What now?

TL;DR: our parent institution, Cornell University, has committed to achieving WCAG 2.0 conformance by the end of 2019, so our timetable is tight. Most saliently, we will not be able to wait for the federal government to publish underlying data that fully supports web accessibility.

Over the next several months, you’ll probably notice some changes to the LII website. We’re releasing accessibility-enhanced content and features as soon as they are complete, and we will plan to update you as we progress through this project. If you need assistance in the meantime, you can reach us at

Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>