Authors: Jonathan Lazar and Brian Wentz

Authors: Jonathan Lazar and Brian Wentz

Pre-print version of

Separate but Unequal: Web Interfaces for People with Disabilities

To be cited as:

Lazar, J., and Wentz, B. (2011). Separate but Unequal: Web Interfaces for People with Disabilities. User Experience Magazine, 10(3), 12-13.

For more information, contact Jonathan Lazar at 410-704-2255 or

Often, web sites state that if you are a user with a disability, then you should use an alternate version of the web site. This is despite the fact that web sites CAN be designed so that the same web site is usable by both people with and without disabilities. We have identified four categories of so-called “separate but equal” interfaces as well as current examples in each category. One category would be an interface that has a separate, mobile version, which is suggested as the accessible version. A second category would be an interface that has older/newer versions, one of which (typically the older version) is recommended as the accessible version. A third category would be a text-only version for an interface. A fourth category would include web-based applications that require specific plug-ins or other proprietary software to fully view the interface content.

The Problem with “Separate but Equal”

In 1954, the U.S. Supreme Court reversed an earlier decision that had allowed for “separate but equal” facilities for Caucasian and African-Americans by ruling that segregation in public education was inherently unequal. Not only did the facilities themselves tend to be unequal, but the core concept of segregation is based on an assumption of inferiority, and the experience of being separated leads to a lifelong feeling of inferiority.

Unfortunately, segregation according to disabilities still exists. When people with disabilities are asked to use a different web site interface based on their disability, often the result is that their interaction experience is unequal. There is often limited functionality, limited content, and content that is out of date. We believe that when people with disabilities are asked to use separate interfaces, this can result in an inferior interaction experience, which is essentially a form of discrimination.

Let’s start with a background on what an accessible web site is. An accessible web site means that people with perceptual or motor disabilities, who often are using alternate means for input or output (such as not using pointing devices, using alternative keyboards, or using speech recognition input or screen reader output), can access the same web content and transactions as someone without an impairment. From a practical, legal, and regulatory point of view, an accessible web site is a web site that follows a series of interface guidelines. The two most commonly-used guidelines are the Web Content Accessibility Guidelines (WCAG) and the Web Guidelines from Section 508 of the U.S. Rehabilitation Act, which are strongly based on the WCAG. In the past, the guidelines have only addressed perceptual and motor impairment, not cognitive impairment. Although WCAG 2.0 does begin to address cognitive impairment, the drafts of the new version of Section 508 do not address cognitive impairment.

Web sites can be designed so that they are accessible for users with perceptual and motor impairment. Adding these accessibility features does not need to change the visual appearance of the web site. The accessibility features occur in the back-end coding, such as meaningful alternative text for images and animation, transcriptions for audio, clear headings for different areas of the web page, and clearly labeling of form fields. The coding techniques that help make a web page accessible are simply good coding standards, and they not only help with documenting code for other programmers, but can also help search engines find and properly categorize a web site. However, some site designers and webmasters have taken the action of either creating a different site for people with disabilities, or directing people with disabilities to only use a certain version of their interface (often the older version). We believe that this leads to an unequal user interaction experience. In the next sections, we will discuss some of the approaches that have been taken for “separate but supposedly equal” web sites, and provide examples of each.

Categories of Separate Interfaces

The first category of separate interfaces that we have identified occurs when a separate, mobile version is suggested as the accessible version for a web site. Web sites designed exclusively for mobile devices are often “slimmed down” and stripped of certain features. To provide functionality for a wide range of mobile devices, the mobile web sites are typically HTML-only and avoid dynamic features that might be problematic on mobile devices. As a result, such an interface may be more likely to be accessible to individuals who are accessing the interface with assistive technology. Realizing this effect, some companies have decided that their separate mobile web sites will be used to also serve as the “accessible” version of their web site, rather than focusing on a single interface that is accessible and usable for the widest range of devices and users. One example of this is Amazon.com which recommends on its Help page under Accessibility Resources that screen reader users should access its mobile web site. Also, Facebook has a page on its “Help Center” that is dedicated to “Accessibility and Assistive Technology,” and this page specifically notes that there is an HTML-only version of the web site. Facebook then further explains that this HTML version is their mobile web site, and provides a link to this version. We have organized usability testing with blind users, and documented that the Facebook mobile version is more usable than the standard version of Facebook for blind users, but it is missing certain features, such as the ability to send an email through Facebook to someone who is not a Facebook “friend.” More importantly, the mobile version of Facebook is not maintained synchronously with the standard version and is often far behind in receiving functionality.

The second category of separate interfaces that we have identified occurs when a web site maintains older/newer versions of the same web site or web-based application, one of which is claimed to be the “accessible” version (typically the older version). Yahoo Mail Classic and Outlook Web Access 2007 Light are two good examples of this. Yahoo recommends that individuals using assistive technology use the Yahoo Mail Classic version of the web-based email interface rather than the current version of the Yahoo Mail interface even though the two web-based interfaces do not have all of the same features. Another example of this category is Microsoft’s Outlook Web Access, which provides web-based access to corporate email. Due to accessibility problems with the standard web-based interface, Microsoft recommends that users who are blind, have low vision, or require screen magnification use a different interface called Outlook Web Access “light.” This version of the web-based email interface is not consistent with the features provided by the standard version of Outlook Web Access.

The third category of separate interfaces occurs when the web site maintains a separate, text-only version. This is often seen as a viable alternative to maintaining a single, accessible interface. The current version of Section 508 as well as the previous version of the Web Content Accessibility Guidelines from the W3C (WCAG 1.0) seem to allow for this. However, a careful read of Section 508 reveals that separate, text-only interfaces are only an alternative as a last resort and must be updated consistently along with the primary web page. Additionally, the newest version of WCAG (2.0) no longer mentions an allowance for separate, text-only interfaces. A few examples of separate, text-only web site versions include the MTA New York City Transit, some government web sites, and some university web sites. The MTA New York City Transit web site ( has a link near the bottom of the page for users to select a “text-only version.” The Inter-American Foundation (iaf.gov) provides a link to the “text only” version of the web site, and the U.S. Consumer Product Safety Commission, has a link to a “text version” at the bottom of the home page. Some universities, such as the University of Virginia, have also attempted to accommodate accessibility through text-only versions of their web sites, relying on products like Usablenet Assistive from the company UsableNet, which attempts to dynamically convert current web site content into text-only format.

In the fourth category of separate interfaces, only limited content is available in HTML format. To get the full content, users must utilize plug-ins that are inaccessible. For instance, the Cumberland News-Times only provides a portion of its content in HTML web pages and requires that you use the Pressreader plug-in for reading the full newspaper content. Pressreader serves more than 1,700 newspapers, and its interface suffers from a number of accessibility challenges that limit its usage by assistive technology products such as screen readers. For example, one news story on its web site starts with a introductory paragraph, and then states that the user should “See our e-Edition for the rest of this story.” Unfortunately, the E-edition using the plug-in suffers from many accessibility problems. The user can’t access the full content on the HTML site, and while the full content is available using the plug-in, the plug-in is not accessible. So by using only the more accessible HTML site, the user can’t access the same level of content.

Implications

Accommodations that require people with disabilities to go through a “separate door” are often problematic. For instance, a U.S. Department of Transportation (DOT) regulation went into effect in 2009, stating that airlines aren’t required to make their web sites accessible for people with disabilities, but that when the airline web sites aren’t accessible, airlines are required to provide the same low prices over the phone as on the web site and to not charge people with disabilities a fee for using the call center. A study by the first author and his research team in 2009 (six months after the regulations had been in effect) found that of 10 major US airlines, four of them had inaccessible web sites, and when making phone calls to those airlines to check on compliance with the DOT policy, two of the airlines refused to honor the regulations, and wound up over-charging people with disabilities at least one-third of the time.

There’s another potential approach for dealing with accessibility that is also problematic. Some organizations state that they do not have the resources to make their web sites accessible, but will make specific pages accessible upon the request of an individual with a disability. For instance, a recent article in the Cornell Daily Sun noted that the Director of Information Technology at Cornell University was hoping to implement improved accessibility standards at the university sometime in the first half of 2011. However, the associate University Counsel of Cornell University made the argument that the law only requires the university to provide materials in an accessible format upon request, and that the web sites themselves do not need to be preemptively accessible. In this situation, individuals with disabilities must place a request for the web page content, which would take time, ensuring that people without any disabilities had an unfair advantage of immediate access to web content, but people with disabilities had a time delay before they had access to web content. In the example given by Cornell University, that delayed access to content would translate into missed opportunities to read class-related materials, to study, and to collaborate with team members. This is similar to the situation with textbooks, where often students with print-related disabilities don’t receive accessible versions of their textbooks until mid-way through the semester, or sometimes at the end of the semester, creating a form of discrimination and an unfair disadvantage.

Going Forward

Any of the approaches in the various categories that we discussed can and do create inequality for people with disabilities. While sometimes the intentions may be good, too often, these approaches are taken because they are seen as an easier way to provide a response to the need for accessibility. Developers and organizations should avoid these “band-aid” approaches to accessibility and instead recognize the value of having one interface for all users that is designed with accessibility and usability for the widest range of users in the widest range of situations. Policymakers also have a responsibility to clearly articulate that having a separate, unequal interface is not an acceptable solution to accessibility. Regardless of intentions, separate is never truly equal.