skip navigation
search

This is part of a series of posts about LII’s accessibility compliance initiative. The “accessibility” tag links to the posts in this series-in-progress.

LII’s CFR – why bother re-publishing?

A bit of history: for many years, LII published a finding aid for CFR, which offered tables of contents and facilitated a quick lookup by part and section from the eCFR website. This might not sound like much, but at the time, it was the only practical way to link to or bookmark CFR. In 2010, we undertook a joint study with the Office of the Federal Register, GPO, and the Federal Depository Library Program to convert CFR typesetting code to XML. This project resulted in our publication of an enhanced version of the print-CFR. But there was an enormous demand for the eCFR, which, unlike the print-CFR is updated to within a few days of final-rule publication in the Federal Register, so, in 2015, when the eCFR became available in XML, we started from scratch and re-built our enhanced CFR from that. Nowadays, our CFR reaches about 12 million people each year. If our readers reflect the U.S. population, this would mean more than 300,000 users with visual disabilities are relying on our CFR.

So, what’s the problem?

Simply put, we don’t control the content of CFR. The government publishes it, and we are at their mercy if there’s a problem with the content. And there is a problem with the content, a big one. Or, at last count, about 15,639 big ones. The problem is images. These are not just the kinds of images we’d assume (like diagrams), but images of equations, forms, data tables, even images of whole documents. Usually their captions, if even present, convey next to none of the information the images contain. Sometimes the images are printed sideways. Often they are blurry. Never are they machine-readable.

Now, you might say that remediating this problem should be the responsibility of the publisher. But we don’t have time. Our accessibility compliance target is the end of 2019 (see earlier post), and we can’t realistically expect the government to remediate in time.

Public.Resource.Org to the rescue

While we’ve been working on enhancing CFR for publication, Public.Resource.Org has been testing the limits of free access to law, challenging copyright claims to codes and standards incorporated by reference. Founder and president Carl Malamud is famous for saying “Law is the operating system of our society … So show me the manual!” The “manual” is often a very detailed explanation of what the law requires in practice. Together with Point.B Studio, they have converted innumerable codes and standards into machine-readable formats, including transforming pixel-images to Scalable Vector Graphics.

When we realized that we were going to need to deal with more than 15,000 images, our first step was to ask Carl whether he minded if we used the 1237 CFR images Public.Resource.Org converted in 2016-2017. He very enthusiastically encouraged us to go ahead and, beyond that, offered to support the conversion of more of the images. We provided an inventory of where in the CFR the images appear and how much traffic those pages get. Point.B Studio undertook the monumental task of first sorting the images by category and then converting the most prominent diagrams into SVG and equations into XML. In addition to support from Public Resource, Justia is helping to support this work by Point.B Studio as well.

We’ll be annotating the SVGs with standardized labels and titles. We want to deliver the results of this work to the public as quickly as possible, so we’re releasing the new content as it becomes available.

Step 1: Math is hard, let’s use MathJax

Close to 40% of the images in CFR involve some type of equation. Fortunately, MathML, an XML standard developed in the late 1990s, can be embedded in web pages. The American Mathematical Society (AMS) and the Society for Industrial and Applied Mathematics (SIAM) have teamed up to create MathJax, a Javascript plugin that lets us turn machine-readable MathML into readable, screen-reader accessible web content. Public.Resource.Org and Point.B Studio are converting pictures-of-equations into MathML; our website is using MathJax to provide visual and screen-reader-accessible presentations of the markup. You can see an example at 34 CFR 685.203.

Steps 2 and beyond

In the coming weeks and months, we’ll be remediating accessibility problems and releasing accessible images for eCFR. Stay tuned for updates here and via Twitter.

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 Archive.org)

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 liiaccessibility@cornell.edu.