<trackbot> Date: 16 February 2015

<jamesn> Meeting: ARIA Authoring Practices TF

<jamesn> scribe: annabbott

tooltip http://www.w3.org/WAI/PF/aria-practices/#tooltip

Matt: 3 places in guide address tooltip

<mattking> 3.2.6.1. Supporting Tooltips with the Keyboard

<mattking> http://www.w3.org/WAI/PF/aria-practices/#kbd_tooltips

<mattking> 4.1.2.2. Using a tooltip as a description

<mattking> http://www.w3.org/WAI/PF/aria-practices/#Descriptions_tooltip

Matt: above two are outside design patterns, useful but doesn't see why it isn't all incorporated into design pattern
... 4.1 is about Labeling & Describing so understand why it is there
... longer term would like to see shorter text and refer to examples.

James: examples have to include supporting stuff for kbd and describedby

Ann & Leonie: developers need 1 place to find info

James: kbd interaction is important and not relegate that to examples

Matt: agrees however structure now seems awkward

<jamesn> this keyboard example is also way more complex than necessary - http://www.w3.org/WAI/PF/aria-practices/#kbd_tooltips

Matt: other sections in doc should support design patterns
... explain at a broader level
... look at design pattern for tooltips first

<mattking> design pattern http://www.w3.org/WAI/PF/aria-practices/#tooltip

Leonie: do they work on mobile?

James: not without doing something special
... accessible name HTML5 accessibility API mappings - if no accessible name, default to Title.

Matt: are those mappings condisered normative?

James: don't think so

Leonie: gets mapped to accessible description

James: if not used as accessible name
... different on per item basis

Matt: for tooltips, are we talking strictly about elements that use the tooltip role?

Bryan: assumes so

Matt: says it is a supplement

<mattking> Popup that displays a description for an element when a user passes over or rests on that element. Supplement to the normal tooltip processing of the user agent. It should popup automatically when the user gives input focus to the widget or element with which it is associated. The tooltip widget can be dismissed by pressing the Escape key or by other methods noted below. The tooltip widget...

<mattking> ...differs from the

<mattking> Dialog (Tooltip)

<mattking> in that it does not receive focus at any time.  

Matt: doesn't give any idea why it exists

James: doesn't like the description
... kbd users don't get access

Matt: no way to force browser to display

James: can't force Title to come up
... drop 'supplement to tooltip"

Group agrees

Matt: need to give idea purpose of tooltip role

Jon: can control placement
... authors want to control style, not browser
... would need to script to control tooltips

Matt: should start out with explanation on use
... authors should use tooltips whenever the title attribute doesn't provide adequate control

Jon: cautions against tying to specific browsers

Matt: have role that does what browser does

James: tooltip doesn't receive focus vs dialog tooltip
... not really a dialog because it acts like a tooltip

Bryan: acts like popup

James: like popup help - what's the difference?
... F6 moves between panes

Matt: not in favor of special keystrokes

James: maybe tooltip should never have focusable content
... if focusable content, use dialog tooltip

Matt: not fond of "resting" or "pass over"
... use "place focus" instead of "resting"
... use "hover" instead of "pass over"
... no mention of delay
... users don't want lots of tips appearing - makes them dizzy

James: doesn't think it needs to be specified

Matt: language seems to make it "have to"

James: doesn't say it has to appear immediately

Matt: optionally with delay

Bryan: not just when you mouse over, could be for error handling
... doesn't agree with making delay required

James: doesn't think we need to address

Jon: can work on examples from OAA into githum and explain delay there

Matt: maybe that's why "rest" was included

James: not talking about modalities, but immediacy of feedback
... thinks it is usability and usability folks should choose

Matt: thinks including in examples is important

James: add Note about may/may not have a delay
... added to existing bug

Matt: another note about ESCAPE key but says nothing about tooltip - maybe just copied/pasted in

James: re: about last in/first out
... doesn't want to worksmith note when in multiple places

wordsmith = wordsmith

Matt: if more than one widget uses the same keys - note is about nested widgets
... if a widget nested within another widget uses the same key as its parent

James: only place this note appears

Matt: funny - it was written for grid

James: maybe move to kbd section
... nested widgets like on a toolbar

Matt: radios in a toolbar wouldn't wrap

James: thinks text is useful but maybe wrong for tooltip

Matt: doesn't like "if more than one widget"
... likes "if nested widgets"

James: will add to bug

Matt: anything else on tooltips that should be rolled into design pattern

James: describing section seems a bit bizarre

Matt: 3.6.1.2 is about kbd?

James: that's about focus

Matt: needs code snippet

James: example is way to complex
... strip out nonrelevant stuff

alert http://www.w3.org/WAI/PF/aria-practices/#alert

<mattking> http://www.w3.org/WAI/PF/aria-practices/#alert

<mattking> A message with important information 

<mattking> that is all that is in the description

Ann: developers are prone to misuse alerts

Matt: do get over-used and crazy verbose

Bryan: JAWS 16/IE 11 has broken alerts

Ann: JAWS hasn't supported polite vs assertive for a while

Bryan: how alerts are triggered would be useful
... if positioned off screen then moved on screen, alert won't function

Matt: add info re live regions

James: section 5 or 6 Managing live

Matt: one sentence has caused lots of problems

<mattking> Live regions are parts of a Web page that the author expects to change. Examples of live regions include tables with dynamically updated content (sports stats, stock information), logs where new information is being added (chat transcript logs), notification areas (status, alerts), etc.

James: add what are not live regions

Bryan: devs don't realize that ATs announce all info sounds same.
... carousel pages are coded as live

James: any change not triggered by a user (background or asyncronous unexpected)

Bryan: alerts are live regions

James: found another section that's better

<jamesn> alert - You must use the alert role for a one-time notification which shows for a period of time and goes away and is intended to alert the user that something has happened. The assistive technology should be notified by the user agent that an alert has occurred, if your operating system supports this type of event notification. When choosing to use alert you should use the alertdialog role instead if something inside the alert is to receive focus. Both

<jamesn> alert and alertdialog appear to pop-up to the user to get their attention.

Bryan: tied into OS

Matt: do you (Bryan) have an example?

<jamesn> http://whatsock.com/training/

Jon: are alert examples from OAA site examples we want to keep?
... : couple different examples there

James: guessing one isn't a dialog

Jon: there are two

Matt: thinks it is appropriate use of role

James: not really coming up as an alert to sighted users

Matt: appears dynamically but not an overlay

Bryan: purpose to convey something that is important

Matt: timeout is better as dialog
... is the difference just styling

James: doesn't think guessing game is appropriate use

Matt: input error or save message is appropriate

Bryan: same as aria-live=rude (assertive)
... when focus is moved, alert causes confusion

Matt: general pattern for usage for input errors?

Bryan: hopefully more broad
... as it interrupts what is being announced

Matt: screen reader use case needed?

Bryan: prefer it to be broad enough
... in-line error handling where error only appears when Submit is selected

Leonie: when using this pattern it is applicable to only one application at a time
... it can be a distraction to all users

Matt: so when you need to intentionally distract a user
... without taking control of focus
... state what they are intended for
... bug needed to develop proposal for description

James: in favor of copy/pasting stuff - not sure can satisfy everyone

Bryan: helpful to have link to general live region section and call out differences
... dev needs to code to spec and not AT behavior

<jamesn> +1000

Bryan: and bugs need to be filed against AT

<jamesn> Meeting: ARIA Authoring Practices TF

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/worksmith/wordsmith/
Succeeded: s/Protocols and Formats Working Group Teleconference/ARIA Practices TF/
Found Scribe: annabbott
Inferring ScribeNick: annabbott
Default Present: Matt_King, Jon_Gunderson, James_Nurthen, Ann_Abbott, Leonie_Watson, Bryan_Garaventa
Present: Matt_King Jon_Gunderson James_Nurthen Ann_Abbott Leonie_Watson Bryan_Garaventa
Regrets: Birkir

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 16 Feb 2015
Guessing minutes URL: http://www.w3.org/2015/02/16-aria-apg-minutes.html
People with action items: 

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