Minutes: User agent teleconference for 10 September, 2009

  http://www.w3.org/2009/09/10-ua-minutes.html 
<http://www.w3.org/2009/09/10-ua-minutes.html>


  User Agent Accessibility Guidelines Working Group Teleconference


    10 Sep 2009

See also: IRC log <http://www.w3.org/2009/09/10-ua-irc>


    Attendees

Present
    +1.425.883.aaaa, Jeanne, AllanJ, +1.617.325.aabb, +1.425.895.aacc, MTH
Regrets
    JanRichards, SimonHarper, DavidTseng
Chair
    Jim_Allan
Scribe
    KimPatch


    Contents

    * Topics <http://www.w3.org/2009/09/10-ua-minutes.html#agenda>
    * Summary of Action Items
      <http://www.w3.org/2009/09/10-ua-minutes.html#ActionSummary>

------------------------------------------------------------------------

 

<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 one
... 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 notifications
... 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

Jim: we talked about JavaScript alerts, aria is part of that to as to 
whether the focus is going to change, that might be another instance of that

<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

<mth> +q

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

<mth> -q

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 [44].

<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
... can't do it undo in the middle of JavaScripted thing
... 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 accessibility
... 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 scoped right
... 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 understanding
... 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


    Summary of Action Items

*[NEW]* *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]
*[NEW]* *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]
*[NEW]* *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]
 
[End of minutes]
<http://www.w3.org/2009/09/10-ua-minutes.html>
-- 
___________________________________________________

Kimberly Patch
President
Redstart Systems, Inc., makers of Utter Command
(617) 325-3966
kim@redstartsystems.com

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

Patch on Speech <http://www.redstartsystems.com/blog/> blog
Redstart Systems <http://twitter.com/RedstartSystems> on Twitter
___________________________________________________