This is post #23 in the ADA Compliance Series, which aims to outline a structure for validating and justifying a claim of “ADA compliance” for a website or other digital system (a few notes and disclaimers on that).
As a metaphor, sure, as a practical matter of legal and regulatory obligations we’d say no. That doesn’t mean you don’t have to make the site accessible, but does chip away at the scope of the laws and regulations that are relevant. Two reasons we don’t view “removing barriers” as a requirement of the website:
- The barriers defined in the ADA are physical barriers—they don’t apply to communication mediums like websites. Those are meant to be thought of as auxiliary aids and services under the ADA.
- Even if the removal of barrier language did apply (it doesn’t) it’s required only when “readily achievable.” As a practical matter, only a small set of digital accessibility requirements can be implemented in a fashion that would meet the definition of readily achievable. The majority, in the context of enterprise production systems, are difficult and expensive to fix.
First a little background. There’s a pretty extensive concept of barriers and their removal under the ADA. We often see this cited (erroneously in our view) in digital accessibility cases. It comes up in a few different ways but, basically, most of the lawsuits will claim that there are barriers on the website and it’s the duty of the plaintiff to remove those barriers. These barriers are typically a set of usability issues that the user ran into while interacting with the website.
The removal of barriers concept finds its genesis in one of specific prohibitions of the ADA 42 U.S.C. § 12182 (b) (2) (A) (iv) – (v). For reference, that language is:
“(iv)a failure to remove architectural barriers, and communication barriers that are structural in nature, in existing facilities, and transportation barriers in existing vehicles and rail passenger cars used by an establishment for transporting individuals (not including barriers that can only be removed through the retrofitting of vehicles or rail passenger cars by the installation of a hydraulic or other lift), where such removal is readily achievable;”
The regulatory guidance implementing that is in 28 CFR 36.304 “Removal of Barriers.” For your reference, that language is:
“A public accommodation shall remove architectural barriers in existing facilities, including communication barriers that are structural in nature, where such removal is readily achievable, i.e., easily accomplishable and able to be carried out without much difficulty or expense.”
The regulation then goes on to cite a list of examples 100% of which relate to changes to the physical nature of the building. This aligns with the Department of Justice’s view on the matter which is provided in the 1991 Preamble and Section by Section Analysis – Section 36.304 Barrier Removal which pretty concisely sums up the matter:
“The requirement to remove architectural barriers includes the removal of physical barriers of any kind.”
But wait, what about communication barriers?
Communication barriers are specific to the barriers that are also structural in nature. Also from the preamble:
“The statute, however, as read by the Department, limits the application of the phrase “communications barriers that are structural in nature” to those barriers that are an integral part of the physical structure of a facility.”
“Given that Sec.36.304’s proper focus is on the removal of physical barriers, the Department believes that the obligation to provide communications equipment and devices such as TDD’s, telephone handset amplifiers, assistive listening devices, and digital check-out displays is more appropriately determined by the requirements for auxiliary aids and services under Sec.36.303 (see Education and Labor report at 107 – 108). The obligation to remove communications barriers that are structural in nature under Sec.36.304, of course, is independent of any obligation to provide auxiliary aids and services under Sec.36.303.”
“In response to comments that the priorities failed to address communications issues, the Department wishes to emphasize that the priorities encompass the removal of communications barriers that are structural in nature. It would be counter to the ADA’s carefully wrought statutory scheme to include in this provision the wide range of communication devices that are required by the ADA’s provisions on auxiliary aids and services.”
So, this would provide further evidence that communication media—notably websites—would best be served under the auxiliary aids and services requirements and not under the removal of barrier requirements.
Still not convinced?
Well than take note that the removal of barriers is required when “readily achievable.” Readily achievable is defined as “easily accomplishable and able to be carried out without much difficulty or expense.” You’ll see it in a variety of other standards and laws relating to accessibility.
“In striking a balance between guaranteeing access to individuals with disabilities and recognizing the legitimate cost concerns of businesses and other private entities, the ADA establishes different standards for existing facilities and new construction. In existing facilities, which are the subject of Sec.36.304, where retrofitting may prove costly, a less rigorous degree of accessibility is required than in the case of new construction and alterations (see Sec. 36.401 – 36.406) where accessibility can be more conveniently and economically incorporated in the initial stages of design and construction.” (source: https://www.corada.com/documents/2010-ada-title-iii-regulations-1991-preamble/36-304)
Some of the accessibility barriers in websites do, likely, meet the definition of readily achievable and can readily be remedied. The problem is those items are the distinct minority of issues. The majority of issues—and those that impact accessibility—require much difficulty and expense to remove. Production websites are not things that can be easily changed. It takes a huge amount of effort to design, develop, test, and deploy them. Additionally, accessibility issues are often deep seated in the code of the system and their remediation is, as a general rule, not “easily accomplishable.”