People who build websites sometimes choose Drupal because of its reputation for accessibility. Technically, features added to Drupal core must conform with the World Wide Web Consortium (W3C) WCAG 2.0 and ATAG 2.0 guidelines. That said, only a small subset of web developers could provide any specifics about those guidelines. People who participate in the Drupal project often trust that Drupal websites, at least "out of the box," will be among the most accessible by people with disabilities. Lullabot, like many other Drupal agencies, regularly shares information about Drupal's accessibility features. We have a generous group of people in Lullabot who call themselves the "Accessibots" who speak at conferences and regularly impart advice about how to prevent inaccessible websites.
While some developers rightly focus on how to make websites accessible, this article focuses on the why. Why does the Drupal community hold accessibility in such high esteem? The Drupal community strives to provide a diverse and inclusive space, so building accessible websites clearly supports those goals. This article explores the stated reasons for Drupal's continued commitment to accessibility beyond the obvious truth that making websites accessible is the right thing to do.
Accessibility is hard work
Much of the Internet is an "inaccessible Internet" that excludes millions of disabled people because making websites accessible requires considerable effort. In the current form of Drupal's Values and Principles — a document intended to "evolve over time" — the last two sentences of the second principle acknowledge this difficulty:
Making security, privacy, accessibility, multilingual capability, and usability top priorities is hard work, but it's worth it. We want to build 'good software.'
Appropriately enough, the second principle offers a value judgment that includes accessibility among the features of "good software." Presumably, nobody wants to build "bad software," but professional web developers know that accessibility, like a robust code test suite, usually falls rather low on the list of priorities. Non-disabled stakeholders commonly, and understandably, prioritize new features.
Building accessible websites requires effort on multiple levels. For instance, those involved in the building process must keep informed about the accessibility guidelines, colors, images, links, buttons, forms, tools for testing the accessibility of a website, and more. Next, they might need to use their knowledge to convince their stakeholders about the value of building accessible websites. Finally, they must know how to make websites accessible using their chosen tools in a way that conforms to the guidelines.
The virtue of accessibility
To counteract the natural human desire to see fancy new features, teams building websites can sometimes provide statistics to make their case for building accessible websites (e.g., "1 in 4 US adults live with a disability"), but frequently they must use value statements like the ones we find on Drupal's Values and Principles page to make a case for prioritizing accessibility. Further, "accessibility" is just one item on a long list of requirements (along with security, privacy, usability, etc.) that we do because of their "inherent worth."
How can we back up the claim, "it's worth it"? What does "worth it" even mean? Grammar books and coaches instruct writers to avoid the word "it" (for instance, in The Writer's Diet, Helen Sword calls "it" a "waste word"). However, the objective here is not to critique word choice, but rather to highlight the intentionally vague nature of this logic. For instance, understand "it's worth it" to indicate that the time or money required to make an accessible website increases the monetary value. More likely, though, we should understand that the idealized version of the Drupal community — the one we want to inhabit, or believe we are inhabiting — values the inherent dignity and worth of all people, with no person excluded.
Put another way; our idealized Drupal community does not build accessible software because of Title III of the Americans with Disabilities Act (in the US), the Accessibility for Ontarians with Disabilities Act (AODA), or some other legal requirement. We build accessible software because we value people. We have opinions about right and wrong, good and bad, etc., and we — ideally — value all people.
We cannot afford to be careless
Further, we understand accessibility requires effort and diligence. The second principle states,
Drupal has such a large impact on the digital landscape that our community cannot afford to be careless.
To make accessible websites requires non-carelessness (or carefulness or conscientiousness). Such a statement indicates a Drupal community that makes careful, calculated decisions about all code considered for Drupal core.
Accessibility is one of five "core gates" — essentially a "checklist" used for evaluating proposed additions to the Drupal codebase. While not every individual patch needs to pass all of the gates, all changes — small and large, front-end and back-end, from routing to rendering, media to menus, forms to fields, and everything else — could inadvertently have negative consequences and therefore must be considered with reference to these "gates" in order to ensure non-carelessness. These core gates do not indicate whether a proposed change is "essential" or not, for example, but they help core maintainers agree on minimum requirements.
To claim that attributes, such as accessibility, are "worth it," also suggests long-term thinking. New features must be accessible both now and for future users. We strive for a continuous flow of inclusive features, accessible to all people. As the web changes, this imagined Drupal community will change with it.
Drupal as a safe haven
The people who create the Drupal software aspire to provide a safe haven for all people. The second principle makes frequent references to safety:
[The Drupal community's] responsibility to ensure that the web is inclusive of every person and accounts for everyone's safety [and that] when software is unsafe, countless people are put at risk of financial, social, and physical harm ... Our community needs to ensure that everyone has access to Drupal and that everyone can use Drupal easily and safely.
Drupal provides safety to organizations such as libraries, governments, universities, and other groups that seek to provide inclusive "digital experiences." Such groups aspire to offer a "safe space" for all people. Drupal does not need to claim that Drupal is safe, and all other software is unsafe. We might compare the consistently safe environment offered by the Drupal software to the "safe space" envisioned by the compassionate people working on Drupal Diversity and Inclusion. Drupal can offer safety to users, safe files, safe HTTP methods, and all other varieties of safety. Further, Drupal offers safety to all people who use the software, disabled or not.
Access by everyone
In 1997, the inventor of the World Wide Web, Tim Berners-Lee, said, "The power of the web is in its universality. Access by everyone, regardless of disability, is an essential aspect." Unfortunately, most people building websites today are not building accessible websites. By some estimates, up to 98 percent of the web does not comply with accessibility standards. People building non-accessible websites might possess the required technical competency, but they get asked to build websites in settings with an ethos that does not prioritize accessibility. The people behind initiatives such as Global Accessibility Awareness Day (GAAD) seek to change the ethos.
Accessibility, we must conclude, is a feature that sets Drupal apart from the majority of the web. Not all Drupal websites are accessible, but Drupal offers a lot to people trying to build accessible websites. Although accessibility requires hard work and diligence, the Drupal community has concluded that proposed technical changes to the Drupal project are necessarily ethical choices and that we must carefully consider their impact on all people.