W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, and resources to make the Web accessible to people with disabilities

This is an outdated draft and should not be referenced or quoted.
The latest version is at: www.w3.org/WAI/intro/usable

[Early Rough Concept Draft] Relationship Between Web Accessibility and Usability

Page Contents

Introduction

This page explores the relationship between web accessibility and usability in the context of standards, guidelines, and conformance. It highlights the overlapping benefits and addresses some questions about making websites, browsers, assistive technologies, and other web tools accessible and usable by people with disabilities.

Understanding Usability and Accessibility

There is significant overlap between usability and accessibility, and not a clear distinction between them. In most situations there is no need to differentiate between usability and accessibility, because they are complimentary and you want to do both well. There are a few cases when the distinction is important, such as when looking at discrimination against people with disabilities and when defining specific accessibility standards.

Usability Benefits Accessibility

Usability means designing your products and services to be effective, efficient, and satisfying. User-centered design (UCD) focuses on usability goals, user characteristics, environment, tasks, and workflow in the design of an interface. UCD is an iterative process with well-defined methods and techniques for analysis, design, and evaluation from the first stage of projects, through implementation.

International Organization for Standardization (ISO) 9241-11 defines usability as the "extent to which a product can be used by specified users to achieve specified goals effectively, efficiency and with satisfaction in a specified context of use." [ISO 9241-11] Accessibility focuses on including people with disabilities as the "specified users" and a wide range of situations, including assistive technologies, as the "specified context of use".[x]

Accessibility Benefits Usability

Accessibility is about ensuring an equivalent user experience for people with disabilities. For the web, it means that people with disabilities can perceive, understand, navigate, and interact with websites and tools, and that they can contribute equally without barriers. Whereas usability can be seen as optional, accessibility is not an option, it is a human right, as recognized in the UN Convention on the Rights of Persons with Disabilities.

Some accessibility requirements are specific to people with disabilities. For example, they ensure that websites work well with assistive technologies such as screen readers that read aloud web pages, [[browser settings to ]]screen magnifiers that enlarge web pages, and specialized keyboards that are used to input text. [[ what's an examples of the latter?]]

Most accessibility requirements benefit people with and without disabilities. While they are general usability principles, they are included in accessibility standards/guidelines because they can be significant barriers to people with disabilities. For example, being able to use a website without a mouse is good usability, and it an accessibility requirement because people with some physical and visual disabilities cannot use a mouse at all. Thus products designed to meet accessibility requirements are more usable for everyone.

Usability testing with participants with disabilities is particularly beneficial because many general usability issues are more apparent to users with disabilities. For example, a large number of links poorly organized on a web page will be more of a problem for people with some types of cognitive, physical, or visual disabilities. General usability issues are often easier to identify because participants with disabilities are more sensitive to usability problems.

Usable Web Accessibility

Usable web accessibility combines usability and accessibility to ensure that websites and web tools are usable by people with disabilities. [[user experience]]

Real People

Usable web accessibility means meeting the needs of real people using the Web. An effective way to meet the needs of real people is to involve users early and throughout the design process. This helps developers understand essential basics of how people with disabilities use the Web. For example, observing people with disabilities complete complex tasks on an accessible website and then struggle with the same tasks on an inaccessible website helps developers better understand accessibility barriers and solutions.

UCD methods and techniques can be used to involve users with disabilities in design projects.

While including users with disabilities is key to making your accessibility efforts more effective and more efficient, that alone cannot address all issues. Even large projects cannot cover the diversity of disabilities, adaptive strategies, and assistive technologies. That is the role of accessibility standards.

Technical Standards

The W3C Web Accessibility Initiative (WAI) develops a set of guidelines that are internationally recognized as the standard for web accessibility.

The WAI guidelines address the broad needs of people with auditory, cognitive, neurological, physical, speech, and visual disabilities, including people with age-related impairments. They also include considerations for different types of websites, browsers, and other web technologies and tools. The WAI guidelines combine these considerations in unified requirements that address different people and situations

@@in practice

@@usability approaches provide a good tool to assess trade-offs between one design/implementation and another.

@@adaptability is part of accessibility

Sometimes developers want to optimize the design for particular audiences or situations. For example, to improve the usability of an online learning system for students with hearing disabilities or such. This could mean emphasizing particular requirements that are more relevant to those users or situations, such as using simple language and sign language videos to better accommodate people with hearing disabilities.

Fortunately the Web is highly adaptable and allows the same content to be presented to users in different ways according to their needs and preferences. For example, websites can provide content in different colors, layouts, or presentation formats to meet the needs of a particular user. In some cases websites could even provide different content that serves the same purpose. For example, different versions of a course, to help students with different learning styles to complete the same curriculum.

Website that are optimized to better meet the accessibility needs of particular audiences can still meet the technical standards. Even if individual presentations of the content are not accessible to all users, websites as a whole could provide default presentations that meet the technical standards to remain accessible for other users with disabilities.

[Editor note: the flow of this is not right -- maybe split into a section on "optimizations" and another on "multiple versions/presentations of the same content" (aka adaptation)?

Usability Beyond Accessibility

@@optimizing a design to specifically increase the *usability* for people with disabilities

Interdependency of Technologies

@@web developers may need to compensate for lack of accessibility support in browsers, markup languages, etc

Harmonized Technical Standards

@@competing standards rather than building on each-others work, especially in the field of usable web accessibility

@@questions check-list

[Editor note: This section is for internal purposes only and will be removed in later drafts.]

Question: Can a website meet accessibility standards and be technically accessible, but not be really usable by people with disabilities?
Answer: implicitly answered in Usable Web Accessibility, in particular in section Real People, by eliminating the concept of "technically accessible" -- there is only accessible or not.
Question: Can a website be usable by people with disabilities, but not meet accessibility standards (not be "technically accessible")?
Answer: attempted in @@adaptability is part of accessibility but not really clear. Maybe works better if a section on "optimization" is broken out (see note at the end of the section)
Question: When does such poor usability make a website not practically accessible by people with disabilities (even if "technically accessible")?
Answer: implicitly answered in Scope of Accessibility and Benefits of Accessibility for Usability but maybe needs more emphasis?
Question: How do general usability issues impact people with disabilities more than people without disabilities?
Answer: implicitly answered in Scope of Accessibility and Benefits of Accessibility for Usability -- does this need to be differentiated from the previous question?
Question: Does designing a site for optimum "usable accessibility" compromise usability for people without disabilities?
Answer: a bit already in Usable Web Accessibility, some more about trade-offs should come in the intro-section of @@in practice, some more discussion of this particular question should come in Usability Beyond Accessibility
Question: Do "usable accessibility" requirements conflict for people with different disabilities? (for example, website developer: "some people say my site has too many links/ too much information, but then they don't want me using javascript to create expanding menus for progressive disclosure") ("I used used XYZ fancy feature to put my 100s of links in a nice widget, but then people complained it's not accessible to screen readers. But then I put all the links in nested lists and people complained it's too much for people with cognitive disabilities.) Issue: The problem is not inherently accessibility, here, it's usability - you have too many links not well organized.
Answer: implicitly answered in Benefits of Accessibility for Usability -- dies this need more clarification?
Question: What aspects of website accessibility and usability are web developers responsible for, versus browsers and assistive technologies. (for example, website developer: "If the browsers and AT don't do their job well, I shouldn't have to compensate for it, should I?") (for example: should websites have a text resize widget?)
[I think when we talk about accessibility/usability then we also need to briefly mention the context such as browsers and Web technologies. For instance, that HTML does not (yet) provide sections markup, so that the header elements have to be (mis-)used for that purpose. That is getting technical but messaging that "designers may need to compensate for the lack of usability in the browsers and technologies" is important.]
[@@it is about browsers not being usable and therefore website developers sometimes need to compensate for it. This is quite apparent for older people and others who are new to computer but not really an accessibility issue per se. If you are writing guidelines for developers making websites accessible, should they include compensations for browser and AT inadequacy?]
[Another complication when defining accessibility standards and guidelines is the responsibilities of the browsers and other components of web accessbilty.]
Answer: should be addressed in Interdependency of Technologies
Question: What if a feature that will improve usability for some users cannot be made accessible (e.g., an Ajax widget)?
Answer: not addressed -- wondering about adding something along the lines of "accessibility is not option, it is a human right" (and point to the UN Convention) in Scope of Accessibility

References and Resources

[X] ISO 9241-11: Ergonomic Requirements for Office Work with Visual Display Terminals, Part 11: Guidance on Usability

[X] Introduction to Web Accessibility

[X] Understanding Web Accessibility

[X] "Distinguishing Between Accessibility and Usability Issues"

Resources for More Information

[maybe list some, e.g., those in the Analysis page list, "yes, list them, this shows the history of the issue and gives it credibility"+1+1]

[x] FOCUS Project [Editor note: moved to "additional resources" because it is still very drafty]