Skip to
content
Translations
About RSS
Search[Draft] Requirements/Analysis and Changelog for "Involving Users in Web Development"/ Including Users for Better, Easier Accessibility
Latest draft: http://www.w3.org/WAI/EO/Drafts/involving/
Related published document: "Involving Users in Web Accessibility Evaluation"
Draft revision of Involving Users in Web Accessibility Evaluation
This Changelog is an update of "Requirements and Changelog for 'Involving Users in Web Accessibility Evaluation", for the predecessor to this document.
Page Contents
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
Scope
Will:
- be a broad introduction for including users throughout the process (with examples)
- motivate and encourage developers to get some users involved with a few simple steps
- explain why including users is so important (to help developers avoid providing well-meant but wrong solutions
- show that it can be done on a small, informal scale (but that there are professionals who can assist)
- identify where people are likely to mess up and provide some pointers to help them get it right (or examples)
- point to external resources for more details
- encourage adoption of a user-centered design process
Will not:
- cover fine detail on involving users in every aspect of the 'development lifecycle'
- be a step-by-step 'how to' for usability testing nor a comprehensive resource for usability testing with participants with disabilities
Purpose, Goals, Objectives
- Rationale:
- 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
- Ensure that older users are specifically included in the document
Audience
- Primary audience:
-
- Web developers (designers, coders, etc.) who want to create accessible websites
- 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
- Note:
- Usability professionals who want to improve the accessibility of the websites they work on
- leave aside until we have a useful document for developers and other, and then we can see how best to address something to this group
Notes
- Size:
- less than 3?4?5 printed pages
- Incorporate into Implementation Plan for Web Accessibility on completion
- see Archive below for previous wish-list and considerations (may need expanding with respect to older users)
Open issues
- The "How Involving Users Early Helps" section in the latest draft versus 23 Oct draft - note the examples and whether efficiency, effectiveness, and motivation are <h3>s or in a list.
- Revised Involving Users in Web Accessibility Evaluation [Draft Revision] - does this appropriately cut our redundant information, repeat limited vital information, and clearly point to the new document? Note that major additions to this page are out of scope for now.
- use "people with accessibility needs" (rather than people with disabilities) to include older users? or not? or some? where?
- title of the two documents: probably want parrallel titles to show relationship, yet also want them clearly differentiated
- maybe "How to Include Users Throughout the Design Process") - maybe plus a subtitle includes "accessibility"
References
WAI-AGE task force and EOWG Discussions:
- EOWG telecon 23 October 2009
- 23 Oct draft
- AA's 22 Oct draft
- WAI-AGE TF teleconf - 21 October 2009
- WAI-AGE TF teleconf - 1 July 2009
- WAI-AGE TF teleconf - 20 May 2009
- WAI-AGE TF teleconf - 6 May 2009
- EO Meeting 23 October 2008
Related documents:
- Involving Users in Web Accessibility Evaluation - www.w3.org/WAI/eval/users.html
- Implementation Plan for Web Accessibility - www.w3.org/WAI/impl/Overview.html
- WAI-AGE project - www.w3.org/WAI/WAI-AGE/
- WAI-AGE deliverables - www.w3.org/WAI/WAI-AGE/deliverables.html#involve
- Notes on [Usability and] User Centered Design Process - www.w3.org/WAI/redesign/ucd
External references:
- Just Ask: Integrating Accessibility Throughout Design (Henry) - www.uiaccess.com/accessucd/
- @@Bringing Accessibility into the Development Process
- Testing in the Wild, Seizing Opportunity (Chisnell) - www.uie.com/articles/testing_in_wild/share/
- Discount Usability: 20 Years (Jacob Nielsen) - www.useit.com/alertbox/discount-usability.html
- User testing (NCBI/CFIT) - www.cfit.ie/user-testing
- User testing for accessibility (RNIB) - http://tinyurl.com/yz2w5o6
- Conducting user evaluations with people with disabilities (IBM)
- www-03.ibm.com/able/resources/userevaluations.html - User Testing: How to Involve Users in Technical Web Development (ICCHP)
- www.springerlink.com/content/r581r1v71244l62w/ - Focus groups vs. usability testing (Webcredible)
- www.webcredible.co.uk/user-friendly-resources/web-usability/focus-vs-testing.shtml - Getting the Right Participants (HFI) - www.humanfactors.com/downloads/whitepapers.asp#UT
- and thousands more, including those listed at Usable Web, Usability and User Experience Resources, Web Design References: Usability, User Centered Design Resources, etc...
Changelog
Note: See "Previous Changelog" for 2005 meeting minutes and e-mail comments.
26 October Eval Doc
- title "Involving Users in Web Accessibility Evaluation" to Web Accessibility Evaluation with Users
22 October 2009
- Added structure and notes to the draft document in preparation for EO discussion
- Updated Requirements in light of TF (21/Oct/09) discussion
20 October 2009
- Drafting of introduction
- Discussion from TF (20/May/09 & 01/Jul/09) incorporated for discussion
- External references noted above
25 June 2009
- Requirements document (this document) updated to become more structured
- Initial opportunities flagged in DRAFT - Involving Users in Web Development for TF discussion
11 May 2009
- Requirements document (this document) updated to reflect TF discussion at 6 May 2009 teleconf
28 January 2009
- Requirements document (this document) updated to reflect EOWG & TF discussion at October 2008 meeting
- Actions from October 2008 EOWG & TF meeting:
- amend 1st bullet from 'designing for Web accessibility' to more simply 'web design' -- also throughout, e.g., the title [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action02]
- change sub bullet 1 to 'introduce the concept of including users at all stages of your design and development process (from the start to the end)' [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action03]
- under the cautions bullet, mention that users aren't necessarily experts with solutions [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action04]
- consider (at some point) "usability testing" or "user testing" [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action05]
- make sure the requirements title and intro refers to this as an update/evolution of the existing 'involving users' [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action06]
- change 'usability testing professionals' to 'usability professionals' in audience note [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action07]
- consider adding a subsection on "Benefits" which would probably include the current 2nd, 3rd, 4th paragraphs [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action19]
- requirements:
- audience:
- include usability professionals in primary audience and see if we can write for both (but be willing to relegate them if it doesn't work) [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action08]
- include educators along with usability professionals [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action09]
- separate educators as it's own secondary audience (as they are teaching/guiding not doing) [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action10]
- secondary audience - include accessibility professionals [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action11]
- 'encourage' - change sub bullet to be more positive, and mention earlier involvement [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action12]
- 'encourage 2' - drop "in user testing" [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action13]
- 'cautions' bullet - add: try to introduce them in a positive language; subtract "most serious" [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action14]
- consider adding "time of reading" to constrain the length, e.g. 1 hour [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action15]
- ditch "more to encourage ..." [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action16]
- change "move resource from E to I ..." to a note [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action17]
- consider whether this applies to web content developers only, or broader to include authoring tools, browsers, etc. (further discussions on the document may clarify this) [recorded in http://www.w3.org/2008/10/23-eo-minutes.html#action18
- audience:
Archive
Format:
- WAI resource; single Web page
- Structure (draft):
-
- Introduction
- Involving users effectively
- Including diverse users
- Analyzing accessibility problems
- Drawing conclusions
- Related resources - including external resources
- Glossary (limited)
- @@ ethics and consent forms (where to fit in)
- Tasks:
-
- 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
- Seek community review
Title brainstorms:
- Including Users for Better, Easier Accessibility
Involving Users for Better, Easier Accessibility - Involving Users in Web Development
- Involving Users in Web Accessibility Design and Evaluation
- Involving Users in Web Accessibility Development
- ...
Deleted from 2005 version
- a bunch of stuff specifically on evaluation...
- 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 (from 2005)
- [done] Reduce spacing before top of list with previous paragraph
- Add image of green magnifying glass & look for other graphic opportunities
- 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)
- document addressing issues of usability & accessibility & "basic accessibility" and "usable accessibility"
- consider if want to tweak to meet additional "requirements"
- side goal: creating evangelists
- audience: includes tool developers
- scope: including throughout design & development, not just eval [already cover that some...]
Important messages from 2005:
- one user not representative, don't do everything one user says
- distinguish between usability vs. accessibility issues
- distinguish between issues of user agent, website, assistive technology, user knowledge, ...
- more than just people who are blind
- 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
- level of user expertise (depends on target audience) - too advanced might know uncommon work-arounds, not advanced enough may not know thinks like links lists, headings nav, etc.) - people often mis-state their own level
- 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?