WD: Have started course on Web architecture. Have started students off designing page with no visual styling, to add it later.
JB: Is early concept draft. To investigate how it addresses needs.
JB: [goes over points in agenda]
SH: [summarises document]
SH: Is not a detailed document.
WL: Are 'users' only people with disabilities?
SH: Roberto says in message that it shouldn't be restrictive.
DS: Wonder how many people are familiar with term users.
DS: Would prefer different term. Too ambiguous.
SH: Could be just people with disabilities. 'Users' may be jargon, but target audience use it.
WL: Can we define 'users' at top of document?
WL: Users doing tests will spread the word beyond specialist groups. Audience could include users doing tests. Also tool designers.
SH: This may interest users, but the rest of the evaluation suite would not.
WL: Important to get these ideas to a wider audience, including beginners.
JB: We did the requirements document last month.
WL: Users doing tests can become emissaries, spreading the [accessibility] message.
JB: Good idea but should go in a different document.
WL: Don't agree. This process is central to group's goals.
JB: Can't do everything in each document. Could point to a document somewhere else.
WL: OK to point to another document.
SH: Reserve editor's discretion.
JB: editor try adding in a point roughly along these lines: involvement of users in eval is a good first step towards establishing ongoing constructive feedback cycle
JB: Can reopen requirements if people really want to but prefer not to.
WD: Looks like a more general document on UCD, rather than one for accessibility.
JB: A clearer focus on accessibility in introduction
HS: document says usability testing not a requirement for WCAG compliance; differentiates them.
HS: so should focus on access or user?
HS: In introduction, need to talk about relationship between access and user testing.
WL: Clarity is confounded by title (usability testing v. accessibility evalaution)
SH: I mean very informally involving users, not rigourous testing.
<shawn> http://www.w3.org/WAI/EO/changelogs/cl-eval-ut.html
HS: Expect clearer distinction between accessibility evaluation and user testing.
JB: Not attempting to tell people how to do usability testing. Document mentions that site must be moderately accessible before trying to test it with users.
WL: Should do preparatory work first.
HS: Need mini-business case up front? reactions?
HS: Need both "when" and "why" explained in intro.
BM: issue is complementing expert evaluation with user testing - form of cross-checking/validation.
SH: Bigger context is not enough attention to even generic usability evaluation; but this issue is *even* more important for PWD.
JB: Contextualise doc with respect to expert accessibility evaluation *and* generic usability testing; and do it concisely!
WD: Consider swopping sections: user involvment, types of user involvement...
HB: agree
Correct: swap user aspect and types of involvement...
HB: Include refs to specific user assistive tech such as braille reading...
JB: Maybe give examples to ensure adequate coverage of disability groups (otherwise may have multiple subjects with same profile?).
SH: Need examples to show potential interaction or conflict between different disability groups?
JB: Danger of feeding myth that
accessibility is logically impossible?
... Maybe provide a summary list of assistive tech?
SH: Point at "How PWD use the Web"...
JB: What (else) is missing from
doc?
... Maybe not clear enough about what to do within a user test
with PWD?
... What to ask the users to do?
WD: This is missing, but might be better in separate, dedicated doc?
JB: Title of this doc implies it should be here?
<shawn> BM: ...there's nothing special from other usability testing...
BMcM: This answer is generic: ask then to do the standard tasks that the site permits?
JB: But some of the audience with need advice or elaboration on that?
<shawn> ??: reference other resources
SH: Agrees with Judy and Barry
(!): How to do this concisely? Requirements say "introduce",
not be comprehensive. Must say *something*...
... write up a little more but then explicitly say that
traditional usability techniques are applicable, with some
mods, and then point at further resources.
JB: under "types of user involvement" add some brief but concrete examples.
HB: Nice to have examples, but danger of being read as one example covers all?
JB: Not in requirements doc, but what about question of "how do I find appropriate test subjects"? There are useful cautions in current doc, but not positive suggestions; such as "contact local disability organisations".
HS: If there was significant take up of this idea, there would not be enough PWD's to go around...
WD: Issue of remuneration? JB: WOuld be good to at least say it is an issue, and there and many different approaches. Standard usability stuff, but maybe our audience doesn't know. SH: So cover by linking to another existing doc.
<Harvey> HB: Concern for compensating participants.
SH: Lots of related issues - too many to deal with?
JB: So can expand "outline structure", name a wider range of issues, but not elaborate, but refer outward to them.
WD: Naming issues and linking to them is good strategy to get people to consider them.
JB: What might we cut out?
HS: Refer to "essential components of web accessibility" doc, and cut out any duplication here.
<shawn> (http://www.w3.org/WAI/intro/components.php)
JB: Not sure that that generic
doc addresses the needs of user testing precisely enough;
particularly the point of distinguishing contributions from
different components within a test context.
... There is some history of mis-attribution of problems to
wrong components.
SH: Understands and will incorporate; all agree to editor discretion.
JB: Anything else we can cut?
(Going, going, Gone...)
JB: Comments on overall structure/flow?
JR: Interplay with title and overall distinction between generic usability and accessibility testing...
(JW->JW)
<Harvey> in Understanding, there you distinguish bewtween usability & accessibility issues;
JB: "user aspects" -> "who to involve"?
SH: Return to discussion of overall title?
JB: Comments on current title?
HB: Got key ideas - "users" + "accessibility"?
WD: Qualification: which should be first?
HS: Before call, wondered about using "usability" in title; but now, in view of discussion, happy with current title.
<shawn> Pasquale: About title, suggestions: "Evaluating Web Accessibility with Users' Help", "Evaluating Web Accessibility with Users' Assistance", "Evaluating Web Accessibility with Users' Support". I tried to translate title into Italian and it seems more comprehensible with "help", "assistance" or "support".
HB: No strong opinion.
Tanguy: Add "with ... users' help/feedback/participation"?
<Harvey> Users Can Help Evaluate Web Accessibility
SH: Similar suggestion from Pasquale
JB: "User involvement in evaluating web accessibility"?
WL: "Involving users in web accessibility evaluation"?
SH: Not sure if will be easily understandable for our target audience (who don't already "get it")?
JW: This title moves (helpfully?)
toward less formal evaluation - if that is what we want?
... Balance is difficult
WL: Actual text already explicitly indicates informality.
WD: Supports title also: if developers are given direction to involve "users", this title will match.
JB: We'll be back to this!
SH: Probably come back to this doc, with new draft, on Sep 16th.
JB: Wrapping up; thanks to all, next meeting on Friday next, 9th September. Encourage all to read docs and comment in advance when possible!
<shawn> Scribe: Alan & Barry
<shawn> Agenda: http://lists.w3.org/Archives/Public/w3c-wai-eo/2005JulSep/0119.html & http://lists.w3.org/Archives/Public/w3c-wai-eo/2005JulSep/0118.html