W3C logoWeb Accessibility Initiative (WAI)         logo

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

Analysis/Requirements and Changelog for "Involving Users in Web Accessibility Evaluation"

Page Contents

About Involving Users in Web Accessibility Evaluation

Purpose, Goals, Objectives





Note: See "References" section above for meeting minutes and e-mail comments.

24 Oct - 1 Nov 2005

14 Oct 2005

For EOWG discussion 14 Oct

  1. [done] review of content changes since last version: listed under 12-13 Oct 2005
  2. [done] heading "Optimizing User Involvement": some suggestions (from Wayne) and comments (from Shawn):
    • Involving Users Effectively
      [one reaction: There are *many* more considerations for involving users more effectively, this section just touches on part -- so I'm a little uncomfortable with that broad section title. (although throughout the whole document we are just touching on little bits...) Also, we use "effectively" elsewhere in talking about implementing accessibility solutions]
    • Getting the Most from Users
      [one reaction: Yes, I guess that's what this section is about; however, I wonder if this can be misconstrued (or translated) negatively?]
  3. [done] clarifying benefit of involving PWDs: "I think the document needs to highlight that the developers get a realistic feel of how content is rendered to PWD and how the AT devices most likely being used in the target-population render the content." [from Sailesh]
    Question: is this implicitly covered already (see current wording below), or should we add more about this (probably to an already long Introduction)?
    • current wording: "... involve people with disabilities helps better understand accessibility issues and implement more effective accessibility solutions.
      For example, take a Web developer who does not know what it is like to use a screen reader... observing a person use the site with a screen reader will clearly show the developer that...
      When Web developers, managers, and other project stakeholders see people with disabilities use their Web site, most are highly motivated by a new understanding of accessibility issues. Collaborating with people with disabilities who are target "users" of a Web site early in a project helps Web developers be more efficient in addressing accessibility, thus maximizing the results from investment in accessibility."
  4. [done] minor formatting:
    • bold: Bolding helps online skimming for most people (particularly helps emphasize important points). However, it adds visual complexity and might slow some careful reading. Which way do we want to err? How is the bolding in the current version (e.g., places we can cut it out)?
    • alt <code> markup resulting in different font for most configurations: Does the different font face increase readability by differentiating the example alt text from the rest of the text, or decrease readability by complicating the visual presentation with another font face?
      • with code markup see the: previous version, 2nd paragraph starting with "For example, take a Web developer who..."
      • without code markup: see the current version, 2nd paragraph starting with "For example, take a Web developer who..."
  5. [done] adding user "needs" (or "requirements") to "Including Diverse Users" section [Shawn will provide summary for previous teleconference discussion and e-mails. notes from 30 Sept minutes: "need to stop people thinking of PWD as "needy" - prefer not to reference "needs. stressing the diversity of users is what we are trying to do. concern is that there is a myth that PWD have an incredibly wide range of "requirements" that can never be met. happy to leave as is."]
  6. [done] minor style guide question: contractions would make it easier reading for this native English speaker (-ed.). what is the trade off in understandability for native speakers of other languages, translators, and formality of the document?
    • example without contractions: For example, take a Web developer who does not know what it is like to use a screen reader.
    • example with contractions: For example, take a Web developer who doesn't know what it's like to use a screen reader.

12-13 Oct 2005

5 Oct 2005

30 Sept 2005 Teleconference

from action items in minutes:

28 Sept 2005 Revision Notes

16 Sept 2005 Teleconference

from action item list in minutes:

[done, added to agenda planning] for EOWG discussion: referencing other documents (instead of how is in the For More Informatino section)

[done, for now - will re-address] from e-mail: for discussion: "About title, please consider also: "User involvement in evaluating web accessibility" or "Involving users in web accessibility evaluation". I like concept of "involving" more than "including"."

14 Sept 2005 Revision Notes

notes about things that were in the previous version or the comments that are not in this version:

2 Sept 2005 Teleconference