Comment of Public.Resource.Org on the Notice of Proposed Rulemaking on Oil and Gas and Sulphur Operations in the Outer Continental Shelf-Update of Incorporated Cranes Standard

1. Introduction

Public.Resource.Org submits this comment to object to one aspect of the proposed Bureau of Safety and Environmental Enforcement (“the Bureau”) regulation entitled, “Oil and Gas and Sulphur Operations in the Outer Continental Shelf-Update of Incorporated Cranes Standard”: It proposes to incorporate by reference a public safety standard that is not reasonably available to people affected by the rule, as required by law.[1]

Public.Resource.Org has previously submitted an extensive comment on the Bureau’s Notice of Proposed Rulemaking (NPRM) entitled “Oil and Gas and Sulphur Operations in the Outer Continental Shelf-Blowout Preventer Systems and Well Control.” [2] We hereby incorporate by reference the full text of that submission, Docket Number BSEE-2015-0002-0062, into the present comment. [3] In particular, the present NPRM raises the exact same issues of availability of the lack of availability and accessibility of critical public safety standards incorporated into law.

In this NRPM, the Bureau proposes to upgrade one standard to a later edition. That standard is the American Petroleum Institute’s Specification 2C. API 2C-2004 (March 2004, Sixth Edition), Offshore Pedestal-mounted Cranes, incorporated into law by the Minerals Management Service (MMS), the predecessor agency to the Bureau at 30 CFR 250.198(h)(69). The Bureau proposes to update the Code of Federal Regulations to require the use of the Seventh Edition of this specification, dated March 2012.

The Bureau cites as justification for this revision of the CFR the fact that the Seventh Edition of API 2C “extended the standard to more types of cranes and made significant improvements to the standard for design, manufacture and testing of cranes in areas such as gross overload (e.g., from supply boat entanglement), consideration of duty cycles (including intensity and frequency of crane use), structural design, and wire rope design.” The Bureau maintains that this action “would improve safety and help prevent injury as well as damage to property.”

We note that the period allowed for comments from the public for this period is absurdly short, with the NPRM being published on June 15, 2015 and comments due on July 16, 2015. The Bureau cites as justification:

“This proposed rule provides 30-days for public comment because the Seventh Edition of API Spec. 2C (which was extensively reviewed and discussed during the API standard-setting consensus process) has been in effect for well over two years; thus, the relevant industries are already familiar with both the Seventh Edition and the existing BSEE regulations incorporating the prior edition of that standard.”

BSEE has worked hand-in-glove with API for over two years on this upgrade to the Code of Federal Regulations. In addition, BSEE participated extensively for several years in the process that led to the 2012 publication of the Seventh Edition. It is unreasonable for the Bureau to give the public 30 days to comment on such an important change.

We note also that on June 8, 2015, Public.Resource.Org submitted a FOIA request to the Bureau, asking for all communications between the Bureau and API on the subject of “making API standards available for public viewing during either the NPRM period or after a rule is promulgated.” [4] On June 9, 2015, the Bureau acknowledged our request and assigned it control number BSEE-2015-00199. [5] We are now well past the 20 business days required by law for a response, a response that would be highly relevant to our preparation of the present comment.

Because of the short period allowed for public feedback, this comment will focus on a demonstration of why it is important to make the law available to not only be read but spoken. We have taken the 2004 edition of API Specification 2C and transformed it into HTML as a demonstration of how much more accessible and usable the law can be made.

2. The Public Inspection Version of API 2C-2004

API has, in a manner of speaking, made API 2C-2004 available for public inspection during the comment period. However, the user interface and restrictions make the copy made available virtually unusable.

We have provided screen dumps of several pages of the user interface provided to the public as an attachment to this comment. [6] As noted in our previous comment, incorporated by reference here, just getting to the standard involves an onerous process of registration, acceptance of stringent terms of use, and a hit-or-miss process of navigation to find the standard, at each step of which the user is bombarded by a sales pitch to “Purchase Your API Standards Today!” and “BUY NOW!”

Once the user reaches the standard, it is wrapped in a user interface, made by a Dutch company called UniFlip that wraps the document in a Flash interface so that printing, searching, copying, and other normal browser functions are disabled. The first thing the user sees is the title page of the document, which is displayed at a maximum of 650 by 485 pixels, absurdly small for a page of text. At that size, a line of type is only 13 pixels high, and because the type is bitmaps instead of a computer font, the pixelation makes the type very hard to read.

The small viewport for a page of text of 650 by 485 pixels is only for those people who have large monitors on their desk. If a user has a laptop or a tablet, the page shrinks to fit the available size.

In “page mode”, the user may only flip through the document forwards and backwards. There is an “index” mode which puts thumbnails of each page of the document up on the screen, with type so small that it is literally unreadable.

The only alternative to “page mode” and “index mode” is for the user to click on a page, which provides a magnified version of a small portion of the page. The window for viewing is prominently watermarked (making the text very hard to read) and the reader must scroll down the page at least 3 times in order to read the full text. In the case of key diagrams, one can only see a portion of the diagram at a time.

This public inspection version is not usable. Reading a 70-page technical specification, discussing that specification with colleagues, and then preparing a detailed comment about crane safety cannot be accomplished with the interface API has provided.

3. The Public Purchase Version of API 2C-2004

The alternative to using the public inspection facility provided by API is to purchase a copy of API 2C-2004 for $129.00 as either a printed copy or a Secure PDF. The Secure PDF document uses the File Open plugin, which means it only works with Adobe Acrobat Reader, does not work on tablets or other modern devices, and provides API with the exact date and time each time the reader opens the document.

The Secure PDF version of API 2C-2004 has disabled almost all key functions necessary to work with the document. In particular copying has been disabled, meaning that a user cannot highlight a paragraph of text and copy it into a word processor to quote the standard, nor could the reader extract a few pages to send them to a colleague for comment.

The version of API 2C-2004 which we purchased does allow accessibility, in this case through the use of the Adobe Acrobat Reader “Read Aloud” function. However, many standards that are secured with the File Open plugin have this function disabled.

BSEE has made an assertion that this standard is “reasonably available,” but it has left all the details of what that means up to a private party that can change at will or simply by a whim the functions permitted by the user (including government workers who are required to use these standards).

Because API 2C-2004 is incorporated by reference into law, and because the law has no copyright in the United States, we have posted a low-resolution copy of this document. [7]

4. Creating an HTML Version of API 2C-2004

In order to demonstrate how much more usable and accessible key provisions of the law can be made, I personally processed this standard to create a modern HTML transformation of API 2C-2004. This was an extremely laborious process.

• First, the document was scanned.
• Second, the document was processed with Optical Character Recognition (OCR), using the open source tesseract toolkit. [8] Tesseract works quite well on high-quality scans, and is particularly adept at recognizing text in columns. We believe even higher-quality results can be achieved using a package called OCRopus, also available as open source. [9] The advantage of OCRopus is the ability to train the software using actual samples from text, thus improving recognition accuracy.
• Third, I spent several days going through the OCR text to remove hyphenation and to correct OCR errors. While I believe the present text has removed most OCR errors, it is still possible that there are a few left and the short comment period precluded being able to ask for help from Internet volunteers to do a more detailed proof of the document.
• Fourth, the document was set in HTML. All four levels of headers in the specification were tagged as such, paragraphs were identified, numbered and numbered lists were marked, and italics and bold text was identified.
• Fifth, all the mathematical formulas were recoded using the MathML markup language. [10]
• Sixth, all of the graphics were recoded using the SVG markup language. [11]
• Seventh, all tables were set.
• Eighth, the form in Appendix C was set as a properly accessible form.
• Ninth, a style sheet was applied to all elements in the text.
• Tenth, any external links to standards incorporated by reference that were available on our site were marked as hyperlinks and any other references to external resources, such as the CFR, were tagged.
• Eleventh, any internal references within the document to a section, figure, table, or equation were made into hyperlinks.
• Twelfth, a table of contents was generated and “ARIA” tags were added in key locations to improve accessibility. [12]

During this process, we made extensive use of the W3C HTML5 validator [13] and the tenon.io accessibility validator [14] to make sure the code was valid.

The result is a single file containing all formulas and graphics inline and coded using the modern HTML5 standard. The entire document is standalone, but there are 3 links to Internet resources in the head section. First, there are links to Google fonts, [15] which improve readability, however the document would look fine even if those fonts are not loaded. Second, there is a call to the Mathjax javascript library, which makes the mathematics display properly on older browsers without proper MathML support.

The resulting file has been submitted as an attachment to this comment and is available on our site for viewing by the public. [16]

5. Accessibility of the Transformed API 2C-2004

One of the key goals of this exercise was to demonstrate how much more accessible this key standard required by law can be made for people who are visually impaired. We note that it is a requirement of federal law under Section 508 that materials such as this, which are used on a daily basis by federal workers and the public, be made accessible. [17]

There are several features in this transformed API 2C-2004 that make it easier for a screen reader to work with, and thus make it more accessible to people who are visually impaired:

• First, the entire text is readable, and readable with structure. This means that there is a table of contents, and it a screen reader can allow the user to quickly navigate between the table of contents and go to a particular section, then flip through the subsections to find relevant text.
• Second, references to footnotes are tagged with the aria-describedby attribute. That means instead of just hearing “17” for a footnote and then having to go hear the whole footnote to know what it contains, we have tagged the title or some other short description of what is in the footnote. The user could thus hear that “17” is a footnote, then hear that this footnote is “Section 508 Accessibility” and then choose whether or not to hear the entire footnote.
• Third, because all the math is in MathML, a screen reader can provide a much better rendition of mathematical formulas, reading the math instead of simply spelling out a bunch of symbols. A use would hear “the square root of two plus variable A” instead of “S Q R T 2 plus sign A.”
• Fourth, accessibility of images is a key challenge. For each graphic in the SVG format, we have added a title and a description. This is like the “alt” tag that can be put on an image, the difference is that titles and descriptions can be added to sub-components of a diagram in SVG, allowing a screen reader to walk the user through descriptions of different parts.
• Fifth, we have made an attempt at making the form in Appendix C accessible, through the use of tags that identify each input field. We were somewhat constrained in this exercise because the form was so poorly designed and we don’t change the text of a standard incorporated into law.

We note that our work on accessibility is a work in progress. In particular, we are continuing to move from "presentation MathML," which has a strict focus on replication of that exact look of a mathematical equation from the printed version of the standard, to "content MathML," which has a focus on making sure the semantics of the equation are properly encoded so that a screen reader can properly speak an equation. Likewise, we are continuing to develop expertise in the use of accessible SVG markup, a particularly difficult area.

6. Usability and Reusability of the Transformed API 2C-2004

The transformed API 2C-2004 has a number of features that make it more usable:

• First, we moved from the 2-column format to a single column of text with inline graphics. This means the document is much more scalable. If you make your browser wide, you will the text expands to fill the screen. Likewise, graphics are not fixed size and will shrink or grow to fit the available space.
• Second, because the graphics are coded in SVG, somebody working on a new document, such as a training manual or a public comment about crane safety, can make a copy of the images and put them into an illustration program. The diagrams can be colored or improved. Subcomponents can be broken out, such as one of the 5 types of cranes that are illustrated in Figure 1 of the specification.
• Third, the mathematical formulas and tables can be pulled out of the specification and reused.
• Fourth, because the document is built using CSS style specifications, a designer could easily change the look and feel of the document, changing the font size or even the entire layout of the document (for example, it would be trivial to move back to a two-column layout).
• Fifth, not only can the HTML look-and-feel of the document be changed because of CSS, it is easy to use a tool such as Prince XML [18] to generate a PDF document. Because we coded in the original page numbers, one could even generate a PDF document that maintains the original pagination.

7. Why It Is Important To Encourage This Transformation of the Law

Making the regulations that BSEE promulgates and enforces is vitally important to the proper functioning of the Bureau. It is important that Bureau employees have access to the law in a usable fashion, and it is equally important that those who are regulated have ready access to the law.

Imagine, if you will, that the entire text of 30 CFR Chapter II, the regulations promulgated by the Bureau, has been set into the same HTML format that we have demonstrated with API 2C-2004. And, at the same time, imagine that all the standards that are incorporated by reference into 30 CFR Chapter II are also set into the same HTML format.

This would be a dramatic improvement of the federal regulations that the Bureau administers, something that would be especially useful to field personnel, both those working for the Bureau and those working for regulated parties. It would also be much more useful to those that oversee the Bureau, including those charged with oversight within the Executive Branch (such as your inspector general) and the Legislative Branch (such as oversight committees).

Now, continue this thought experiment and imagine how useful it would be for Bureau personnel have ready access to the rules (and standard incorporated into those rules) in agencies with which you interact, such as other agencies inside of the Department of Interior, numerous organizations within the Departments of Homeland Security (such as the Coast Guard), Transportation (such as PHMSA), Labor (such as OSHA), as well as numerous independent agencies, such as the Chemical Safety Board. Indeed, imagine a “grand unified Code of Federal Regulations,” available in bulk with all the incorporated standards included, the entire Code being marked up using the technologies we have used for the present submission.

Making the Code of Federal Regulations more usable is an activity that should be applauded and encouraged, but the present posture of the Bureau actively discourages this type of innovation. The Bureau is certainly free to delegate standards-making to other organizations, but that cannot result in citizens being prohibited from reading and speaking the law without a license. Doing so hurts the operational efficiency of the Bureau, it violates the law, and it discourages innovation.

Putting the decision of who can read and speak the law in the hands of a private party is wrong, and the Bureau should change the proposed rule to make it clear that in America, the law belongs to the people. Anything less is illegal and arbitrary and flies in the face of long-held constitutional principles and the requirements of federal law.

Sincerely yours,

Carl Malamud,
President and Founder
Public.Resource.Org

8. Notes