Download Separate but Unequal

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
[email protected]
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 webbased 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
(http://www.mta.info/nyct/) 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.