Meeting Legal Accessibility Standards: Open Source Software

This post adapted from the article, “Meeting Legal Accessibility Standards: Open Source Software—‘Actively Maintained, Highly Rated’ Does Not Equal ‘Highly Accessible,’” originally published in the May 2016 issue of Mealey’s™ Litigation Report: Cyber Tech & E-Commerce. Mealey’s is a subscription-based information provider and a division of LexisNexis.

Download this article as an accessible PDF.

Copyright © 2016 by Hiram Kuykendall. Any commentary or opinions do not reflect the opinions of Microassist or LexisNexis, Mealey’s. 

“Actively Maintained, Highly Rated” Does Not Equal “Highly Accessible”

Litigation and threats of litigation relating to accessibility for people with disabilities have become increasingly common, as noted in our previous article, but the standard for meeting accessibility requirements remains elusive to many in the legal, business, and information technology communities. We will deal with some of those standards and requirements in a subsequent article, but the general principle is that when a product is intended for internal or public use, an organization is responsible for ensuring that the final user experience is perceivable and usable by people who have vision, hearing, mobility, and cognitive challenges—that it is accessible.

While there may be some dispute regarding whether and to what extent various laws may apply, it is the organization’s responsibility to produce a product that is in compliance with legal and contractual obligations. Those responsibilities may include accessibility requirements for employees, job applicants, and external customers of the organization. In addition, many companies may be subject to accessibility requirements by virtue of the contracts they sign, either because those contracts are explicit in their terms, or because the provisions are included by reference. While some debate the applicability of some of these laws to web-based customer experiences, the number of accessibility-based suits and demand letters continue to climb.

The delay of new guidelines exacerbate this quandary. The Department of Justice (DOJ) has withdrawn its Notice of Proposed Rulemaking on website accessibility for state and local government entities originally published for comment in 2010, and it has issued a new Supplemental Advanced Notice of Proposed Rulemaking. The DOJ is moving forward with rulemaking under Title II of the Americans with Disabilities Act (governing state and local government) separately from its rulemaking under Title III (regarding website access for public accommodations using internet websites).* So far, the courts and plaintiffs have not been receptive to the argument that in the absence of clear DOJ website accessibility standards, there is no obligation to maintain accessible websites. The lack of clear standards and guidance virtually guarantees the Wild West of accessibility-based litigation, and demands will continue to be an active part of the landscape for years to come.

Since this writing, the DOJ has pulled the plug on website accessibility rulemaking, and courts continue to be the battleground for web accessibility requirement decisions.  

Assuming, as we do, that website accessibility is a requirement for federal, state, and local governments and for many, if not all, businesses by virtue of contract, state and federal law, or business necessity, what can such entities rely upon to ensure that their websites and web applications are accessible to disabled persons? The answer, unfortunately, is that the entity cannot rely solely upon the representation of the vendor or product creator that the product or service is accessible. Due diligence performed by the organization in reviewing Voluntary Product Accessibility Templates (VPATS) and pages of accessibility compliance information delivered by tool providers can still lead to the inclusion of non-conformant packages. Nowhere is this more apparent than in the area of open source products and components.

There is no group so singularly surprised by the inaccessibility of their endeavors as those who implement open source-based solutions.

Inevitably, as part of the initial risk assessment once an issue arises, the technical owners are asked to what degree they evaluated the accessibility of the open source product and components. The most common answer I encounter is, “It is open source and they say they are accessible.”

Open Source Product

First, a very abbreviated definition of open-source software (OSS) is any source code released to the public where the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose, but retains the license. Individuals, communities, and commercial organizations have released a multitude of software packages and components under one of several types of open source licenses. There are many advantages to an organization using open source software, including:

• No user or hardware licensing (free for most usages)
• Community-contributed extensions
• Substantial package features
• Scalability from the one-person blog to a tool serving thousands of people
• Good community support

Starting with an open source solution provides a substantial savings in terms of development time and product acquisition costs as long as the organization’s usage is consistent with the license. What is not readily apparent is the organization’s accessibility obligations.

Open Source Commitment to Accessibility

There are many categories of open source tools. One of the most frequently encountered types of software requiring remediation falls into the content management system (CMS) category. We will use this category of software to illustrate open source accessibility challenges.

A CMS can be used to create anything from a simple website to a blog to very advanced, workflow-based system. The low cost and highly scalable nature of these packages make them attractive, and they are a favorite platform for novice users, colleges, and universities, as well as the private sector. The two major players we will talk about are:

• WordPress
• Drupal

Note there are many other types of open source software that the following discussion can equally apply to. Learning management systems (LMS) are a prime example of widely used open source software and have the same accessibility challenges as their CMS counterparts. Examples of these tools include Moodle, Sakai, and Canvas.

The majority of quality open source solutions have a very public commitment to accessibility and work hard to ensure that the core packages developed are perceivable and usable. WordPress and Drupal are both examples of highly respected, open source release, accessible themes and core modules also known as plugins. While an initial out-of-the-box installation may be quite accessible, they are limited to base functionalities such as user management, security, and infrastructure components that are intended to be built upon. As such, the initial install is generic and unattractive.

The real value and power of open source software is its abundance of both community and commercially available add-on themes and modules. These additions range from minor free extensions to full-blown commercial-grade packages. A developer will attempt to select a theme or module for evaluation based on the following criteria:

Due to the large number of community contributions, this filtering exercise is an effective method for narrowing the potential community provided solutions, but gauging accessibility is problematic. For example, Drupal uses an in informal pledge that states:

“#D8AX – I pledge to make this [module or theme] as accessible as it can be. If you find any flaws, please submit an issue [link to issue queue]. Help me fix them if you can.”

Developers must know to include key word “#D8AX” for version 8 or “#D7AX” for version 7 to help limit the filter search for accessible projects.

Similarly, WordPress has a theme “Accessibility Ready” feature that helps narrow the search for accessible themes and extensive pages and forums on accessibility.

Below are some statistics that give an indication of the daunting task of identifying candidate themes and modules that are accessible.

Drupal:

• Over 11,000 actively maintained themes.
• Over 10,400 actively maintained modules.
• Only 1,597 have a #D8AX or #D7AX accessibility indicator.

WordPress

• Over 2,126 themes not including commercial variations.
• 103 themes have been identified as accessible.
• Over 44,000 plug-ins (modules)

While there have been substantial efforts by the Drupal, WordPress, and other open source communities, the onus to ensure selected themes and modules are accessible still falls to the integrator or developer to ensure it meets the applicable laws and contract stipulations. Furthering the issue is the large number of highly rated, actively used and highly used modules that are simply not accessible.

Compounding Issues for Open Source Product Accessibility

Testing — It is unfortunately difficult to assess the accessibility of a website or web application. There are automated tools that can easily detect failures to comply with accessibility coding standards. These semantic failures unfortunately only account for about 30 percent of known failures. The remaining 70 percent have to be manually tested for by people who understand and are able to test for compliance failures.

Training — Gaining the understanding of creating an accessible experience is also hard to obtain. While the internet is full of information addressing accessibility, it is not well organized and in many cases solutions are subjective and prone to limitations. Limitations range from standards not being fully implemented by assistive technologies (AT), such as screen readers, to differing coding solutions based on the underlying technologies.

Technical Competency — The brilliance of the open source movement is the ease of installation and configuration. Due to the free nature of open source CMS packages, almost all hosting providers provide one click deployment, making access and configuration of these tools seamless and achievable for first-time novice users and advanced developers alike. As such, there is a new breed of application integrators who have mastered selecting and combining themes and modules into robust applications, but who are not versed in coding. This new style of integrators relies on the originating module developer to provide the core functionality to include accessibility. The integrator will limit his or her role to modifying the styling of the theme or module but will often lack the technical prowess to test and remediate accessibility shortcomings.

Remediation — The good news is that the full source code of the core and all modules are available. The bad news is changing the code creates challenges. Modern open source solutions provide mechanisms that easily apply updates that are essential to ensure that security patches and other desirable time sensitive updates apply quickly. It is therefore common practice for hosting providers to automatically apply installation updates with minimal or no notice to the site owner. In addition, many open source packages themselves are patch aware and will alert — and in some cases update — the code base depending on the configuration. The implication of this is that a code owner cannot directly change the underlying code without taking on a substantial manual maintenance obligation to preserve the changes throughout each new patch. Various open source communities have adopted three methods for applying changes. The first method is to simply modify the underlying code and resubmit it back to the community. While this is certainly in line with the spirit of the open source philosophy, many developers do not take on the challenge. The underlying code is complex and developers may not want to invest the time to modify the code and submit it to the community. The next technique takes advantage of theme and module extension functionality that allow application developers to modify the code in a way that augments the main module without having to take on ownership responsibilities and that allows modification to persist even after updates. This is done through a series of “hooks” that allow the insertion or modification of certain pieces of functionality through documented application programming interfaces (API). The third method is by using a JavaScript overlay to change the code at runtime. This is the most prevalent solution in the accessibility remediation world due to the speed and platform independence. In this scenario, the developer would write supplemental code to add, remove, or modify the page in real time. Since this overlay is independent of the underlying code, JavaScript developers knowledgeable in accessibility can create fixes for WordPress, Drupal, or any web-based platform without having to dig deeply into the complex underlying code. Unfortunately, both developing JavaScript overlays and creating appendage code can be subject to breakage if a module creator makes a substantial change. For example, if the module creator addresses the accessibility issues, then both modification types would apply, duplicating accessibility instructions and likely breaking overall accessibility.

Project Management — In the world of time, scope, and budget trade-offs, accessibility considerations are seldom planned for. As a result, the awareness of accessibility remediation often comes in well after a product release. In complex systems, open source or not, the cost of remediation can match or exceed the cost of original development. If the organization is not under pressure from litigation, contract issues or social pressure, accessibility will likely be deferred. Depending on the nature of the application, the accessibility issues can be an organizational risk waiting to pounce. This is especially true when sales are to entities like federal and state government that have strong accessibility contract language.

Conclusion

While open source software offers amazing features for little to no cost, the organization is not absolved of its contractual and legal obligations. The accessibility diligence of a core open source community do not necessarily extend to the packages contributed by individual and other organizations and should be independently verified. Finally, while there are effective remediation techniques that can be applied to bring a open source product into accessibility compliance, there are challenges in ramping up individuals in accessibility remediation techniques. The solutions can vary considerably in speed of remediation delivery and also have long-term maintenance considerations.

Microassist Digital Accessibility Services

Have you received an accessibility demand letter because of your open source website or application? Please contact us for any questions you have about our accessibility services and how we might support your organization.

Services include:

• Accessible Website and Application Development— We rely heavily on accessibility best practices and using HTML5 and ARIA (Accessible Rich Internet Applications) standards to build WCAG-compliant and human-tested accessible environments. Our teams are proficient in open source technologies such as WordPress, Drupal and Moodle, as well as custom frameworks in .NET, PHP, AngularJS, and other frameworks. Our Learning and Development team can also help you create accessible custom training.
• Accessible Document Services—  Whether you’re dealing with a few or a warehouse of Microsoft Office documents, PDFs, or other files, there are several ways Microassist can enable your team to offer documents and materials that meet stringent accessibility standards.
• Accessibility Remediation— Our accessibility remediation services help you fix existing materials so that they conform to WCAG, Section 504 and 508, Department of Education OCR, and ADA Title II/III requirements. We remediate websites, applications, documents, and elearning, recommending re-creation when that is more efficient and economical. Especially for website and applications, to find out what is in need of remediation, we’ll start with an Accessibility Audit.
• Accessibility Training— With several courses available for developers, testers, and content creators, your team can become equipped to consistently and expertly produce accessible digital products and online environments.
• VPAT^®Evaluation Services — Primarily used by government purchasers and government vendors during the procurement and sale of ICT products and services under Section 508, a Voluntary Product Accessibility Template^® (VPAT) attests to the accessibility of a given product or service. Contact us to make sure the VPAT you write or review is accurate and meaningful.

Learn More about Digital Accessibility

Our Digital Accessibility Digest blog covers our Accessibility in the News archives as well as expert commentaries on digital accessibility issues.

Our most popular commentaries include:

• The WCAG 2.1 Update: A Brief Look at What’s Changed
• Introducing VPAT^® 2.0, the More Stringent Accessibility Reporting Tool Required for Government IT Procurement
• Accessibility in the News, Legal Edition: Updates on ADA Title III News and More
• What Lawyers Need to Know: A Primer on Digital Accessibility Terms and Today’s Legal Landscape