This document will provide an overview of including people with disabilities and older people throughout Web design and development processes. It builds on the existing document “Involving Users in Web Accessibility Evaluation”, available at http://www.w3.org/WAI/eval/users.html

Many Web developers do not involve users in the design process. Even those who do involve users, rarely include people with disabilities or older users.

There are many benefits of including users, especially older users and people with disabilities, in the development process from the beginning of the project.

Bringing users into the process from the early stages helps designers and developers better understand accessibility issues and better implement effective accessibility solutions. It also encourages early incorporation of accessibility solutions, rather than trying to make adjustments at the end of the development process that are often more difficult to implement

Understanding users' needs should also reduce user complaints

Objective:

Provide basic information to help designers and developers get started with including people with disabilities and older users at all stages of Web design and development

Encourage developers to involve users early and often

Encourage developers to do whatever they can - reminding them that informal involvement of users is more useful than no involvement

Notes:

Broaden the scope of the existing document from evaluation only to include/discuss all stages of the development process

Website purchasers/procurers & project managers - want to know "how and when to bring in users"

Standards developers and policy developers [maybe not specifically address, but make the beginning information generic enough that it clearly applies]

Browser and user agents developers

Secondary audience:

Anyone interested in better understanding the basics of involving users with disabilities in Web development - including educators, researchers, decision makers, accessibility professionals, professional evaluators

Users who are interested to participate in the development process (and may want to approach an organization to ask to be involved)

Content authors - understanding how people use their content will help write better, provide better alt-text, better links, etc

Usability professionals who want to improve the accessibility of the websites they work on
[action: leave this one out of consideration until we have a useful document for developers and others, and then we can see how best to address something to this group]

A couple of scenarios to keep in mind:

small local business e.g., takeaway restaurant, developing a first site or first replacement site. Both developer and business owner may be relatively inexperienced at web development. This is a chance to review similar types of sites, to look for examples of good practice, look for different formats and contents. You need to consider what kind of tasks and activities, what information needs, and are there different strategies for providing the same information e.g., a static timetable vs an interactive query system, or different approaches to content management. Review of own site – might include any complaints and observing some real people doing typical tasks in a variety of contexts. Consider alternative use scenarios e.g., using a shared access machine in a library or senior citizen club, a person using zoomed text, a screen reader or non-mouse entry. If using multimedia what would be the experience of a person who is blind or hearing impaired.

medium sized company or service provider – The previous site may have been running 2-3 years and evolved overtime. The IT department is an 'operator' not a developer and engages a professional web developer to upgrade existing system. This is a chance to review existing site, check out any record of complaints. Identify weaknesses in structural design and formats by observing invited users attempting typical tasks and less common tasks. Pay particular attention to issues identified in WCAG 2.0 guidelines that may result in barriers or reduced efficiency related to perception, operation and understanding. Seek out users with different profiles and accessibility needs who can help to specify critical requirements for the new site.

USEM recommendations for involving users (USEM) - good recommendations from a European project which aims to facilitate, enhance and increase qualification and participation of disabled or elderly users and their respective organisations in the European standardisation process - include?

Consider for next revision

1. "You could say that involving users with disabilities in your development project gives you improved usability for free."- add link to supporting studies in the business case appendix when that's done.

2. when it's done, consider adding to the More Info resource list: <a href="http://www.w3.org/WAI/EO/Drafts/access-use/accessibility-n-usability.html">Relationship between Web Accessibility and Usability@@</a>

Including users in the development process helps you more efficiently develop accessible websites that work well for people.

e.g.,

As an example,
consider a developer who does not know what it's like to use a screen reader. To meet the web
accessibility guideline "Provide text alternatives for all non-text content",
the developer might provide alt text such as: "This image is a line art
drawing of a dark green magnifying glass. If you click on it, it will take
you to the Search page." Such alt text is going to be a lot of work for each image. Now, consider another developer who involved users in her project early and has observed people using the web with screen readers. This developer knows that for such images, the only alt needed is "Search". She gets the job done quicker, and better for users.

The first developers' time has been wasted and the result is annoying for users. And, once the problem is discovered (at testing end or after rollout when users complain), it's going to take more time, effort, and money to go back and fix it.

Understanding how people use your website, browser, or other tool, helps you focus your efforts on accessibility solutions that work well for real users in real situations.

e.g.,

[@@ explain better@@] Designers of a financial services website spent quite a bit of effort on a project to determine what was the best way to indicate to users that a large text version of their site was available, that is, what words to use for the link. In the end they learned that most of their target users would not use the alternative version anyway because they were already using screen magnification software or settings.

Understanding users gives you a better perspective on standards and guidelines.

e.g.,

If you only focus on meeting the minimum accessibility standards, you are likely to miss many easy things you can do to improve usability for people with disabilities and older users. For example, some of the WCAG 2.0 Level AAA Success Criteria and Advisory Techniques take just a few minutes to implement.

Rewrote Introduction. Moved first sentence under "How Involving Users Early Helps" to Introduction.

Edited: "Below are the basics that you can do yourself to include users in developing websites and other web products." to "Below are the basics that you can do yourself to include users in your projects."

In Introduction, last paragrpah, first sentence: changed from "different approaches for" to "different aspects of", resulting in: "This page is part of a multi-page Evaluating Web Accessibility resource suite that outlines different aspects of evaluating web accessibility."

Edited first paragraph under "Initial Review'

Edited Note for usability professionals section

Changed "For any accessibility problems
you identify, determine which components are responsible." to "Accessibility problems can be caused by one or more different components."

Added middle sentence under Drawing Conclusions and
Reporting: "Be careful drawing conclusions from limited evaluations or studies. Results from only a couple of people with disabilities cannot be generalized to apply to all people with similar disabilities or people with other disabilities. See the Caution above."

Review the existing document for opportunities to more explicitly include older users, integrating information learned from the WAI-AGE Literature Review, for example, possibly expanding the glossary (Terminology and Notes) section

Expand the existing document to cover including users early and throughout the design and development process (rather than just in evaluation), including older users

Deleted from 2005 version

One of the benefits of including people with disabilities is that Web
developers can learn how people with disabilities interact with the Web and
with assistive technologies.

Consider for revision or related documents or other

Eval doc from 2009

check what would be involved in broadening it to tools, etc. see what did in new companion doc

Note at end of Introduction - maybe soften and integrate briefly earlier

Note at end of Basics - see how might fit in intro

under Drawing Conclusions and reporting, consider including this example: A study looking at the relationship between accessibility and usability of websites used only users who are blind compared with users who are sighted. The study results cannot be applied to all users with disabilities nor used to compare usability and accessibility issues broadly, but that was not made clear in the report.

Eval doc from 2005

consider change:
location: "Introduction" section, second paragraph
current wording: example of screen reader user
suggested revision: example of screen magnification
rationale: screen readers are mentioned elsewhere in the document (for example in "Involving Users Effectively") and often not an obvious AT to
Web developers.

Link to when done:

in For More Info section: [selecting consultants] with the blurb organizations that can help

in For More Info section: How People with Disabilities Use the Web describes how different disabilities affect Web use and accessibility
requirements for people with different kinds of disabilities, and
includes scenarios of people with disabilities using the Web.

in Terminology section: Basic Glossary (formerly known as (fka) Lexicon)

Since this is part of the Evaluation Suite, focus on user involvement
in accessibility testing; however, since ideally users are incorporated throughout the process, mention getting
them involved from the start and throughout

Carefully clarify that usability testing is not a requirement
to ensure comply with WCAG

issues with non-PWDs using AT - false negatives,
'cause don't know how to use screen reader, think it's hard 'cause they
don't know how to use them...

stakeholders - live observation!!! (or at least
highlight tapes), rather than dry report...

issue: terminology. does "usability testing" conjure up formal testing
through complete tasks too much? if so, should we use something else,
such as "user involvement in accessibility testing" or "testing
accessibility features with users" or ?? that is not too awkward?

Document Information

Content last updated: $Date: 2010/08/03 22:14:19 $ by $Author: shawn $
Editors: Andrew Arch and Shawn Lawton Henry, with participation from the WAI-AGE task force and the Education and Outreach
Working Group (EOWG).