<trackbot> Date: 09 December 2010

<mhakkinen> regrets (on another call)

<mhakkinen> will be on irc

<scribe> Scribe: kford

Dec 23 and 30 meetings

JA: Do we want to meet 12/23 and 12/30?
... We will take those two weeks off.

Accesskey in Opera https://addons.labs.opera.com/addons/extensions/details/excesskey/1.2/?display=en

JA: Has anyone had an opportunity to play with this?

<JAllan> http://my.opera.com/chaals/blog/excesskey

JA: I have tried this a bit.
... It places an icon of a big A in the user interface. It turns a dufferent color when access keys are present. Pressing a hotkey shows you the access keys.
... It keys off the title. If a title is associated you see that and the key. Otherwise just the URL.
... Has more planned.

\JA: For example changing access keys from the default assignments.

JA: Gave assignments for a couple intl cases.
... Developer looking for feedback.
... trick is to find pages with access keys.

Group continues to talk about Opera extension and looking for where access key is in guidelines.

JA: This could be 212.

GL: 4.1.6 too.

<JAllan> latest draft: http://www.w3.org/WAI/UA/2010/ED-UAAG20-20101117/

Group talks about how it relates to speech.

KP: Was surprised about how many users got confused about something that worked sometimes and not all. Was giving example of programs that allow some dictation commands to work some of the time but not in others.

<JAllan> 2.1.6 (former 4.1.6) Present Direct Commands in Rendered Content: The user can have any recognized direct commands (e.g. accesskey) in rendered content be presented with their associated elements (e.g. "[Ctrl+t]" displayed after a link whose accesskey value is "t", or an audio browser reading the value or label of a form control followed by "accesskey control plus t"). (Level A)

<Greg> Our SC require putting accesskey notice next to item it applies to. Chaas' Opera extension takes a different approach altogether, one that might be useful but one we don't address in UAAG20.

KP gives example of Notepad++ and how they do some keyboard items and discovery and changing.

JA: Does Blackbberry do this kind of think.

JL: Not at this time.

KP: The items I'm talking about are not perfect. For example I am not able to share them.

JA: Greg, you've got me thinking, are we too perscriptive?

GL: What we have doesn't prevent someone from doing more but if we think what we have is important it is good.

JR: The screen shot approach is good at times but if the URLs are not bvious for example, having the indications in the contnet would still be better.

<Greg> I feel that it's OK for us to require the implementation we think is most useful (e.g. putting the accesskey next to the element it applies to), which does not prevent someone from going beyond that with additional features (such as providing feedback on whether the page has any accesskeys, or providing a list in a separate window or drop-down menu).

JA: I'll send some comments seeing about getting more toward 2.1.2 and perhaps getting indications in place.

Talk about Principle 2, Operable

JA: This was a carry over but we are not sure why at this point.

Review proposals sent to list

JA Talking about items that benefit accessibility./

<JAllan> "benefit accessibility: Features which benefit accessibility fall into two groups: (1) those features which have been explicitly created to aid accessibility, possibly in an attempt to follow guidelines such as these; or (2) those which assist accessibility but emerge from other functionality not originally created for accessibility purposes. Further, these accessibility benefits may be...

<JAllan> ...explicit such as the ability to control the User Agent from the keyboard; or implicit such as the ability to style a page based on a user supplied style sheet.

<Jan> http://lists.w3.org/Archives/Public/w3c-wai-ua/2010OctDec/0091.html

GL: This is good as a concept but not written in a way to be testable.

JL: In origianl devices we had a lot of shortcuts that ended up being used as accessibility features.
... One of the problems is that by the time we get feedback ona device, we've moved onto a new device.

<JAllan> sh: this should not exclude them from conformance. when features emerge as being an accessibility feature, then they should be documented in the next version.

More talk about device updating frequency and feedback pace.

<JAllan> sh: you can't document things you don't know about.

JA: What do people think about Simon's definition.

Group talking about normative versus informative.

<Jan> A.4.2.1 Document Accessibility Features: All features that must be present to meet Part A of ATAG 2.0 (e.g. keyboard shortcuts, text search, etc.) are documented.

<Jan> A.4.2.1 Document Accessibility Features: All features that must be present to meet Part A of ATAG 2.0 (e.g. keyboard shortcuts, text search, etc.) are documented. (Level A)

<Jan> Note: The accessibility of the documentation is covered by Guideline A.1.1 and Guideline A.1.2.

<Jan> documentation

<Jan> Any information that supports the use of an authoring tool. This information may be provided electronically or otherwise and includes help, manuals, installation instructions, sample work flows, tutorials, etc.

<Greg> Here's UAAG2's current definition of documentation "Any information that supports the use of a user agent. This information may be found, for example, in manuals, installation instructions, the help system, and tutorials. Documentation may be distributed (e.g., as files installed as part of the installation, some parts may be delivered on CD-ROM, others on the Web). See guideline 5.3 for...

<Greg> ...information about documentation."

JA: Should we change 3.2.2 to something similar to ATAG?

<Jan> +1 to using something close to ATAG2

<JAllan> +1

+1

<Greg> +1

All seem to be in agreement.

JA: Simon thanks for this and for sparking the discussion.

<Jan> Sample text from ATAG: B.3.2.3 Instruction Index: The documentation contains an index to the instructions for using the accessible content support features

<JAllan> ACTION: Jallan to rewrite 3.3.2 document accessibility features, to mirror ATAG20, include Simon Definition in the intent [recorded in http://www.w3.org/2010/12/09-ua-minutes.html#action01]

<trackbot> Created ACTION-480 - Rewrite 3.3.2 document accessibility features, to mirror ATAG20, include Simon Definition in the intent [on Jim Allan - due 2010-12-16].

Group now talking about ATAG and a centralized view.

<Jan> Instruction Index: The documentation contains an index to the instructions for using the accessibility features.

<Greg> I'm just a bit concerned that index usually means just a list of links, but it should probably be OK to provide a summary with complete documentation in one page, so perhaps say "index or summary".

JA: I'll take an action on 3.3.4 to summarize what we talked about and come up with a proposal.
... Do we need anything else here.

KF: I think we have covered all of the items from the list on this.

JA: The other item was a blog post with a solution for tooltips.

GL: I sent mail.

<JAllan> ACTION: jallan to rewrite 3.3.4 to remove 'benefit accessibility' [recorded in http://www.w3.org/2010/12/09-ua-minutes.html#action02]

<trackbot> Created ACTION-481 - Rewrite 3.3.4 to remove 'benefit accessibility' [on Jim Allan - due 2010-12-16].

<JAllan> Peter Korn referenced http://library.gnome.org/users/gnome-access-guide/stable/keynav-3.html.en

<JAllan> this should be included in resources for Intent for Guideline 2

Mail discussion on keyboard and tooltips.

http://lists.w3.org/Archives/Public/w3c-wai-ua/2010OctDec/0096.html

KP: For me persoanlly being able to show all tooltips would be best.
... Having to activate on each tooltip would be less benefitial.

GL: In general I think I agree with you but there is the complication of dynamic tooltips.

KP: Show all tooltips is close to what I was talking about in the Notepad++ app.
... Looking under all the rocks at once is often more helpful.

JR: You have to then deal with overlap.

GL: Any invoke mechanism only works if the item can be focussed with the keyboard.
... This would be another place where show all would be helpful.

<Greg> A command to display ALL the tooltips at once would be the only way to see the tooltips for things that don't take keyboard focus.

GL: I can tell you from some Windows XP experience there were issues with keyboard focus activation being annoying.

JA: There doesn't seem to be a good way to change the time that tooltips stay around.

<Greg> That is, having tooltips always pop up when you navigate through Windows Explorer, obscuring the surrounding items, was very annoying.

JA: John does Blackberry do tooltips?

JL: We have the ability but don't do them out of the box.

<JAllan> how do you 'hover' with your finger on a touch screen

<JAllan> ... to see a tooltip

<Greg> In a platform such as Windows, some tooltips are displayed by the platform's facilities (e.g. an application invoking the Win32 tooltip common control) and some are custom, drawn entirely by the application and the platform knows nothing about them. In Windows the app can override default timing of standard tooltip controls, but I know of none that provide UI for that. Similarly one might be...

<Greg> ...able to change their default timings through the Registry, but I know of no UI for doing it.

<JAllan> tooltips are a problem for screen magnification. in order to read the tooltip you must move the mouse off of the item generating the tooltip to read the tooltip with a magnified view...and the tooltip vanishes

Group talks more about tooltips.

GL: Are tooltips worth calling out or are they just examples of full keyboard access, alternative content and such?

<Jan> +1 to not alternative content

<JAllan> kf: tooltips are not alternative content in the traditional sense. they are supplemental content

<JAllan> tooltips are a replacement, not an alternative

<JAllan> gl: expand our alternative content to include 'expanded' content for acronyms, etc. other things with @titles

<JAllan> ... or "extended content" (e.g. tooltips, link information, etc)

<JAllan> kf: danger of combining them, is they might miss the point for tooltips in the alternative content mix.

<JAllan> ...could advocate for separate item

<Greg> "1.1.1 (former 3.1.2) Configurable Default Rendering: The user can specify which types of alternative content to render by default. (Level A)"

<Greg> could be changed to something like

<Greg> "1.1.1 (former 3.1.2) Configurable Default Rendering: The user can specify which types of alternative content (e.g. alt text) and extended content (e.g. tooltip text) to render by default. (Level A)"

<Greg> As Jim brings up, this should probably include the word "recognized" as in:

<Greg> "1.1.1 (former 3.1.2) Configurable Default Rendering: The user can specify which types of recognized alternative content (e.g. alt text) and extended content (e.g. tooltip text) to render by default. (Level A)"

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)

Succeeded: s/frequenccy/frequency/
Succeeded: s/ten/then/
Found Scribe: kford
Inferring ScribeNick: kford
Default Present: kford, jallan, Greg, sharper, shayman, Jan, +1.617.325.aaaa
Present: Jim John Greg Simon John Kelly Mark Kim

WARNING: Replacing previous Regrets list. (Old list: JSpellman, PHLauke)
Use 'Regrets+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Regrets+ Jeanne, Patrick

Regrets: Jeanne Patrick
Found Date: 09 Dec 2010
Guessing minutes URL: http://www.w3.org/2010/12/09-ua-minutes.html
People with action items: jallan

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.