W3C logoWeb Accessibility Initiative (WAI)         logo

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

Requirements/Analysis and Changelog for Involving Users in Web Development

Page Contents

Changes Since Publication

Involving Users in Web Projects for Better, Easier Accessibility

Changes on 7 April 2010 version (from December 2009):

Involving Users in Evaluating Web Accessibility

Changes on 3 August 2010 version:

Changes on 7 April 2010 version (from December 2009):

This Changelog is an update of "Requirements and Changelog for 'Involving Users in Web Accessibility Evaluation", for the predecessor to these documents.

About "Involving Users"

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



Will not:

Note: The focus is real live users but should point to references that say more about general consideration of accessibility earlier.

Purpose, Goals, Objectives





Primary audience:

Secondary audience:

A couple of scenarios to keep in mind:



WAI-AGE task force and EOWG Discussions:

Related documents:

External references:

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>

3. Putting back in examples. Previous draft and changelog:

Examples of Benefits<h2>

@@changelog: add short "handle"/heading for each. maybe add "Appendix" to heading. reorder ending sections]]

@@changelog: include other scenarios (e.g., cool new app developers? specs developer!) policy &/or researcher developing ax &/or older user, w/o including both. (how make compelling ?)]]

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


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.


[@@ 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.


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.

[@@ edit above if leave]]

Changelog of Revisions to Drafts

Note: See "Previous Changelog" for 2005 meeting minutes and e-mail comments.

9 March 2010 Edits (based on comments and EOWG teleconference 5 March)

Involving Users in Web Projects for Better, Easier Accessibility 9 March edit

Involving Users in Evaluating Web Accessibility 9 March edit

30 Nov New Doc

12 Nov New Doc

26 October Eval Doc

22 October 2009

20 October 2009

25 June 2009

11 May 2009

28 January 2009



WAI resource;  single Web page

Structure (draft):


Title brainstorms:

  1. Including Users for Better, Easier Accessibility
    Involving Users for Better, Easier Accessibility
  2. Involving Users in Web Development
  3. Involving Users in Web Accessibility Design and Evaluation
  4. Involving Users in Web Accessibility Development
  5. ...

Deleted from 2005 version

Consider for revision or related documents or other

Eval doc from 2009

Eval doc from 2005

Important messages from 2005: