User Agent Accessibility Guidelines Working Group Teleconference -- 10 Sep 2009

<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

- DRAFT -

User Agent Accessibility Guidelines Working Group Teleconference

10 Sep 2009

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output