See also: IRC log
<AllanJ> trackbot, start meeting
<trackbot> Date: 10 September 2009
<kford> zakim 1.425.883.aaaa is kford
<kford> trackbot, start meeting
<trackbot> Meeting: User Agent Accessibility Guidelines Working Group Teleconference
<trackbot> Date: 10 September 2009
<kford> Chair: Jim_allan
<AllanJ> WCAG20 Techniques http://www.w3.org/TR/WCAG20-TECHS/
<AllanJ> ATAG Techniques http://www.w3.org/WAI/AU/2009/ED-ATAG20-TECHS-20090814/#gl-Web-based-accessible
<AllanJ> UAAG10 Techniques http://www.w3.org/TR/2002/NOTE-UAAG10-TECHS-20021217/
Jean: when WCAG did their techniques they went with a different-- understanding, examples, testing procedures, resources, I'd like to propose that we also looked at restructuring our techniques document for information in it
Greg: it makes it easier when someone is trying to understand a piece to have everything in one place -- a restatement of guidelines, what's the benefit, techniques for testing, not sure about the different formats
Jim: at least we would have a different model to go by
Jean: the content for the working group is a big deal and hard to do
Henny: good idea
Jim: face-to-face agenda
Kelly: two, three, four will take the longest
Jim: write comments to the list,
will finalize the agenda and get it out
... we've never quite got to principal five, which is ensure that the user interface is understandable, goal for today is to review that and see if we have any immediate issues
... 5.1 help users avoid unnecessary messages
<Greg> While it’s important, I don’t see “avoiding unnecessary messages” as making the UI “understandable”.
Jim: let the user change -- override what the author set
Kelly: good idea in one sense but
the whole aria thing is more of a technique-- aria has the
concept of politeness
... is this already covered -- you're supposed to respect all the politeness levels shouldn't that come in from aria?
... does the user agent have to support aria to comply with our guidelines?
... let's say a year from now there's another great accessibility thing -- a technique might but a guideline can't reference a specific technology like this
Henny: In WCAG, you don't reference specific technologies
Kelly: should we 86 this
... how do I know what I've satisfied this criteria?
Greg: there's the issue of text
messages as opposed to a more general form of alerts or
... it's not clear whether were talking about only notifications that will take the focus, include notifications that will appear in a separate window but do not change the focus
Mark: I think we updated that in the definition
<Zakim> jeanne, you wanted to say that it appears to be more of a usability issue than an accessibility issue.
Kelly: one of the things that's
happening in user agent development -- on one hand you could
argue this is supposed to help you avoid things that interrupt
you, but in some ways it's actually hurting accessibility
... Internet Explorer the information bar -- the whole point is to stop making alerts be modal, but for accessibility it's better to take the focus
... I don't want to single out IE. we needed different guidelines, I think this guideline is almost missing the actual serious problem that's starting to happen
... the subtle notifications that are being presented have a greater opportunity to be missed for accessibility purposes
Jim: change this so not to ignore but to modify
Jim: the user has the option to change the way these things are rendered -- could be low priority thing turn those off, don't bother me, or high-priority jump up and down
Kelly: hard to quantify, but maybe at a priority two it's OK
Jim: cell phone use -- these sort of alerts and warnings are these issues on cell phones also
usually just yes no prompts
<AllanJ> action kford to rewrite 5.1.1 to be user has option to change rendering of messages from UA and content
<trackbot> Sorry, couldn't find user - kford
Kelly: usually very limited -- different experience
<AllanJ> action kellyford to rewrite 5.1.1 to be user has option to change rendering of messages from UA and content
<trackbot> Sorry, couldn't find user - kellyford
Jim: 5.2 helped the users avoid mistakes -- usually involves form submission
Kelly: interesting concept and not a bad idea but I think we should lower it to a P3
Greg: context -- if object is to help user avoid mistakes a number of other things that would fit into this category-- that may change the way we think about this
<Greg> Here's from ISO 9241-171:
<Greg> 8.4.3 Provide “Undo” and/or “Confirm” functionality
<Greg> Software should provide a mechanism that enables users to undo at least the most recent user action and/or cancel the action during a confirmation step .
<Greg> NOTE 1 Although this is a general ergonomic principle, “Undo” mechanisms are particularly important for users who
<Greg> have disabilities that significantly increase the likelihood of an unintentional action. These users can require significant time and effort to recover from such unintentional actions.
<Greg> NOTE 2 A macro is considered to be one user action.
<Greg> NOTE 3 Generally, the more consecutive actions the user can undo, the better.
<Greg> NOTE 4 It is preferable that undo operations themselves can be undone.
<Greg> NOTE 5 However, this might not be possible for such interactions as operations causing fundamental transformation of
<Greg> logical or physical devices, or could involve a data exchange with third parties that are out of the software’s control, etc.
<Greg> NOTE 6 The default configuration can provide a confirmation step for any action that the user cannot undo with a
<Greg> single “Undo” command.
<Greg> NOTE 7 Software could allow the user to disable the confirmation for specific actions.
<Greg> EXAMPLE 1 A user with Parkinson’s disease might inadvertently input a sequence of keystrokes that activates several
<Greg> dialogues that then need to be undone. The use of several steps of the undo function permits the user to go back to the original state.
<Greg> EXAMPLE 2 A user is about to format a hard disk. As this is an operation that cannot be undone, the software shows
<Greg> a confirmation dialog before the formatting begins.
Greg: anytime you press a hotkey
that moves the focus to another object or invokes another
window or invokes some user interface element -- need
notification or don't need notification, that's where the
examples come in
... entire category of things which user might accidentally invoke or might be invoked for them without their knowledge
Jim: in a form, no way to unpush a radio button
Greg: another issue with people using in unintended way, but not be able to change is bad
Mark: from the UA point of view the only thing reliably undo are things within the UA interface
Greg: in some cases implemented in such a way that is using real controls, in other cases custom controls
Jim: Web 2.0 Web applications
there's not a lot of undo that the user has control over
... I think the form submission thing is really focused for success criteria, but then what Mark was talking about when things are heavily scripted in the UA doesn't have a lot to do
Greg: a lot would fit in there, things like spellchecking helps users avoid mistakes -- hoping to look through whole iso-2.1
<Greg> (ISO 9241-171 "Ergonomics of human-system interaction — Part 171: Guidance on
Jim: example of Firefox red squiggly underlined this spelled word -- does that get revealed, that's up there in guideline to
<Greg> software accessibility:)
Kelly: as written right now this
seems like another one that should be axed. has nothing to do
with making the user interface understandable
... too narrowly focused
Jim: Greg, see if there's a generic success criteria?
Craig: I'm still hoping that everything like that that's not specifically Web related will be taken out of our document before too long
<AllanJ> issue: review UAAG20 and ISO 9241-171 remove duplicate items
<trackbot> Created ISSUE-43 - Review UAAG20 and ISO 9241-171 remove duplicate items ; please complete additional details at http://www.w3.org/WAI/UA/tracker/issues/43/edit .
Jim: important what you said about removing all the little bits that are already in generic software accessibility and only include the things that are specific to user agents
Greg: still waiting on at what point we can reference other documents
Jeanne: complaints about referencing a document people have to pay for
Greg: it would reduce the chance that guidelines would conflict with each other
<AllanJ> ACTION: Greg recast Guideline 5.2 to be more generic (spell check, etc.) [recorded in http://www.w3.org/2009/09/10-ua-minutes.html#action01]
<trackbot> Created ACTION-224 - Recast Guideline 5.2 to be more generic (spell check, etc.) [on Greg Lowney - due 2009-09-17].
Jim: 5.3 -- are these in iso
Greg: section 11 online documentation help and support services
Kelly: if the point of this
guidelines is making user agent understandable, missing the
boat, only talk about the things that are related to
... either its only talking about accessibility or we are being too narrow
... office ribbon as an example -- if I don't think that benefits accessibility all I have to do is make sure that it's documented, but it's really a new action paradigm for me to understand what's going on and how to interact with it I should make sure that the ribbon is explained.
Jim: I agree -- it's not really
... we may be missing a lot about making the user interface understandable -- I'm not sure where we need to go with it
... the ribbon was a whole metaphor for how they were going to do things and change the excepted standard of drop-down menus that everybody had used -- does that mean that if a browser comes out with a new user interface do they have to provide documentation that explains -- chicken and egg thing -- ribbon is a huge leap.
Kelly: p1 document accessibility, getting people to explain, level 3
Mark: something new -- has to be self documented or self explaining
Henny: we have a documentation
department -- each new release they go back through and update
-- it's a massive job
... original features touch browsing, in which case written from scratch
Jim: do you do a how-to, or here it is, does this
Henny: one document -- difficult for users to gather information they need when it's spread all over the documentation
<kford> ACTION: kford to draft guideline on how to document the user interface [recorded in http://www.w3.org/2009/09/10-ua-minutes.html#action02]
<trackbot> Sorry, couldn't find user - kford
<AllanJ> KP: Word Ribbon, much worse for speech users, increased number of steps, amount of space taken up by ribbon affected some users.
<AllanJ> ...metric of counting steps, made it much worse. instructions are very different for speech users.
<Greg> 5.3.3 "Changes Between Versions" should require documentation of "changes to features that AFFECT accessibility" rather than only those that "BENEFIT" accessibility.
<AllanJ> ...instructions are different for different populatiohs
<jeanne> ACTION: JS to update document to change 5.3.3 from BENEFIT to AFFECT [recorded in http://www.w3.org/2009/09/10-ua-minutes.html#action03]
<trackbot> Created ACTION-225 - Update document to change 5.3.3 from BENEFIT to AFFECT [on Jeanne Spellman - due 2009-09-17].
Jim: Kelly's comment on principal 5 overall
Greg: principles don't refer to understandable
<Greg> Suggest retitling the Principle to better reflect what we put into it.
Greg: one or more additional principles to replace five to contain what doesn't fit in anywhere else
Jim: crux of understandable in
WCAG says documentation can't be beyond the users
... put it under operable, also put confirmation under operable?
Greg: if we want to have an understandable principle because of the paralleling, principle used in other documents, things that would fit under that principle include providing documentation, level language used, consistency of terminology used within the product and its documentation
<Greg> An example from ISO of something that would fit under an "Understandable" princple is: 8.1.2 Provide meaningful names Names of user-interface elements should be comprised of natural language words that are meaningful to the intended users.
Greg: dealing with input, output, sound -- interesting choice that WAI creating documents that aren't structured for developer -- problematic determining where to put things
<Greg> That is, ISO 9241-171 and ANSI 200.2 are both organized by functional areas (e.g. input, labeling, etc.) rather than by principles; the former is more oriented towards software designers/implementers.
<AllanJ> scribe: KimPatch
<AllanJ> KP: if using natural language, commands have 3 word phrase, with only last word different, make commands very long
<AllanJ> ...object should be first, then action, "page bookmark" vs "bookmark page"
<AllanJ> ...front loading information
<AllanJ> ...dialog box title should be same name as menu item that opens it
Jim: operable or design technique
rrs agent, make minutes
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: KimPatch Inferring ScribeNick: KimPatch WARNING: No "Topic:" lines found. Default Present: +1.425.883.aaaa, Jeanne, AllanJ, +1.617.325.aabb, +1.425.895.aacc, MTH Present: +1.425.883.aaaa Jeanne AllanJ +1.617.325.aabb +1.425.895.aacc MTH Regrets: JanRichards SimonHarper DavidTseng Found Date: 10 Sep 2009 Guessing minutes URL: http://www.w3.org/2009/09/10-ua-minutes.html People with action items: 5.2 greg guideline js kford recast WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]