WAI PF Face to Face Day 2 -- 12 Apr 2007

<dpoehlman> scibe: dpoehlman

<aaronlev> Web IRC client works: http://ircproxy.emigrantas.com/

<MichaelC_IAD> scribe: dpoehlman

<aaronlev> hi JRG

<clc4tts> scribe: clc4tts

al: i've always thought that if there were certain things the browser had to do for the content to reach the user, we have to find a way to do that
... what statement is needed for browsers to do the right thing so that developers will take it up
... we can look at ua. we can ghostwrite techniques for ua that say, to make the ua provisions that the way you do aria is the following techniques, best practice
... this is how you meet this requirement
... the normative requirement is the ua requirement - we are just providing a suggestion for how to meet that

rich: i'm concerned that the w3c will say that you need a normative way to map this
... we got to do one for msaa on windows, atk on linux, etc

al: w3c won't lay that on us. what we put is our ambition, what we have the normative statements for
... we have to publish something that publishes the techniques

<JRG> Hello

al: an informative annex this is what we know about good binding would be good

rich: i'm ok with that, but we can't do any platform
... we'll have to choose

jon: problem with uag is that what is rendered and what is in the dom is not the same. sometimes you have invalid html
... we have the requirement for the dom, requirement for the window dressing not through the dom
... in terms of notification, the normative part says that changes to the document styling, only changes to the dom have to be provided
... no requirement to provide notification if dom is not changed

al: we feel that show and hide must be known to at

jon: mappings have to be techniques for extendability

<Zakim> MichaelC_IAD, you wanted to rephrase question as "what does a UA have to do to validly claim it supports ARIA" - validly meaning meeting our requirements, and producing the

michael: maybe we got scared byt he idea of providing all apis, but we need to state what it means to support aria
... do we only ask that they expose aria? that's ok, but we need to say what we are asking for ua to do
... not all useragents are going to claim aria support. we want our definition of support to lead to something meaningful for users
... if something changes (response to jon), we should use spec versioning
... this is aria 1.0 - in aria 1.x, a compliant ua agent would be expected to handle something more

al: we may not invite ua to say if they are conformant or not
... if it is purely a content spec, sites will claim conformance, but user agents can say they support in their vpat that they support the ua, but it is not part of aria conformance
... it's a weaker publicity push if we don't have user agents advertising they support this, but it is not wired into the system that we have to have user agent conformance
... it's a maybe. how normative is it?

michael: we're specifying a content and coding technology. if we don't say what is supposed to be done with content, it could be useless

al: if the author has no idea, they are not likely to follow the model

rich: i think we need content conforming aria and ua conforming aria. we need to bridge this to the at.
... content can be retrieved through the document model - then from a content pserpective we are fine
... then we have the ua part. this show and hide thing concerns me. what we don't have is something tangible other than a technique that says you can support as a best practice by writing this whole section into the dom or using css to show this. but that's a technique and not a standard. how do we make this into a standard for an aria content developer. how do we define something that the...
... browser can support.
... how can we pin something to the content piece.

michael: assistive technology wants to get to the richness of aria and ideally it wants to do it in a way without special customization. if it is only available for the dom, then at will have to add stuff to make it work. whereas if the user agent mapped to the accessibilty api, then ua that arleady support the api wouldn't have to do anything special

rich: i look at the two pieces. like menus, if you were to write those into the dom, then everything that you are putting in has the aria role and states that you need. you just wrote them in. that's fine. but what do we do about css? let's say you have context menus. what can we do to make that work?

aaron: we could add a property and ask people to add something to support aria. so if they want to do it right, they can have it.
... setting a certain attribute that shows or hides it
... you can do it inline
... there is the attribute for the dom and the javascript properties. sometimes there is a map, sometimes not
... you could set the aria state and change the css
... so then the user agent can support the whole thing in the dom

rich: if they expose the dom, you can do your job.

al: the full support should be in the dom, and if you can map it to the api, you should

rich: if we put this aria show property, at least we have compliant content
... then we look at the ua. if the ua can present everything, then you have a compliant ua for the os

michael: i would drop the all. if the api doesn't have everything, then that part can be left in the dom. but at least the accessibilty api is complete

rich: i don't know whre john hrvatin (ie7) is on ui automation, but let's say there wasn't an aria mapping for some of the aria features, then if it is not avaiable throught he api, you could also provide it through the dom. what do you tink?

johnhrv: i always think presenting it in the dom is a back up method. i think only a small set of properties don't map to the msaa. are you really going to go through the dom just to get those few properties?
... should map it as best fit. if something is really incompatible, then go through the dom.

rich: i think for ie, freedom scientific uses a combo of msaa and dom

johnhrv: making everything through the dom is an important fall back. if there are browser differences.

aaron: we still need to support the unofficial method as well just because it is standard practice, but it shouldn't tie down the spec

al: question. it sounds like we convinced ourselves is that only the show and hide changes are missing.
... so we want to put in something in the spec that will be used to drive those changes. and the style rules will trigger off that selector to change visibility or display properties to get these things to show up or disappear

aaron: we should bring back hidden
... have hidden = true (default is hidden=false)

rich: that's part of the solution. we make it available through the dom. we also want this to support the accessibility api.

<Al> RESOLUTION: bring back 'hidden' property

al: this is just one minor point, but it is worth noting

michael: all aria properties must be available in the dom, right?

rich: right
... we have an action item to add hidden property to states and properties

action michael add hidden back in to states and properties

<scribe> ACTION: michael to add hidden to states and properties [recorded in http://www.w3.org/2007/04/12-pf-minutes.html#action01]

<scribe> ACTION: michael to add marquee [recorded in http://www.w3.org/2007/04/12-pf-minutes.html#action02]

<scribe> ACTION: michael to add statement that all aria must be available in dom (hook in ua requirements in that statement) [recorded in http://www.w3.org/2007/04/12-pf-minutes.html#action03]

rich: we should have techniques for the user agents.

al: if we think they should be out there, we need to publish them. if we don't publish, it won't happen

aaron: what level of detail?
... all we do with aria properties is expose them to the accessibility api
... the user experience techniques is something that clc could write up

clc: couldn't at that handle msaa just handle it the same way as standard windows apps?

aaron: no. live region is a new concept.
... there are techniques of how do you map to the api, and then how do you process the aria and handle user experience

jon: if microsoft is implementing this for ie, then it would be nice if ie and ff do it in a compatible way

<Zakim> MichaelC_IAD, you wanted to suggest support for DOM 2 Style module

aaronL they've been using our docs on that

al: anything to wrap up?

rich: do we need to make some statement about user agents?

<MichaelC_IAD> action 2 = michael to add statement that all aria must be available in dom (hook in ua requirements in that statement) and mapping to accessibility API is recommended where possible

al: look at issue 66 when drawing up the techniques

resolution: close issue 27
... close issue 27

<leesa> folks is it Ok if I take a brake for an Hour

<leesa> I have phisotheripy in a half hour so i might as well go now

<leesa> is that OK or are we deeling with the speck when we get back?

<Al> I would suggest that you go ahead and leave for the physiotherapy. We will likely have spec consequences from the 'interim' discussion but there will be action items to develop proposals.

<Stefan> hi

<Stefan> test

<Stefan> cool

<Stefan> anybody else here?

<Stefan> cool

<Stefan> ok .. ready for some text input ..

<Stefan> scribe: stefan

<scribe> scribe: Stefan

interim

reference is http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions#Issues_and_Proposed_Solutions

<Al> ACTION: Al research the status of a possible 'busy' issue in consultation with Aaron [recorded in http://www.w3.org/2007/04/12-pf-minutes.html#action04]

Charles demonstration of interim

interim is not there in live regions, -> sometime no announcements

e.g. in count 5 never announced

anouncements fail if interim is set sometimes, actual speech output falls behind

consequence for stock prices, game logs .. user falls behind considered as serious

Aaron: interim=true means all changes in between are relevant
... now way for AT to manages that
... what is the default? all page changes are always important?
... all of these are just hints .. need to have way for content providers to mark-up pages

<leesa> thanks al

Glen: Last thing in region that changed info may be sufficient for update of Live Regions

Al: are some parts of page garbage? are other needed? how to separate them? -> Markup for critical/deferrable needed

Aaron: iterim is for things that OBLITERATE each other

Jon: screen reader functions used to look explicitly into regions of interest

Glen: example : update of 2 stock prices, one changes frequently, the other not - would they kill each other?

Charles: with his algorithm NOT

<scribe> ACTION: Charles - create real world example or problematic interrupts [recorded in http://www.w3.org/2007/04/12-pf-minutes.html#action05]

Al: back to outstanding issues

outstanding issues of yesterday (#59 etc.), causality issue first http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions#Issues_an, Issue 1d_Proposed_Solutions

http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions#Issues_and_Proposed_Solutions, Issue 1

he AT will need some way to know whether a control is really controlling a live region or if the onChange event for a particular control and an update to a live region that it controls is merely a coincidence (imagine a user tabbing out of the input blank after having typed something but without pressing enter and having some other user send a message at about the same time - both events...

scribe: happened, but the change in the input blank was not the cause for the new message that appeared in the blank).

The browser can trace through the stack of JavaScript function calls that resulted in a change to the page to see if that change was caused by a JavaScript function that was triggered by a user action (such as clicking on a button). This cannot determine causality for every case as it is possible that the user action causes an HTTP request to be made to the server and the response handler...

scribe: for that request then causes the change; such a change would appear to be coming from a world event rather than a user action. However, knowing the source of a change could be helpful in disambiguating the two cases in other scenarios. In addition, for situations where a change can be caused by either user interaction or a world event, the recommendation is to not specify that live region...
... as something that the control is controlling.

Chaals: analogue to popup-blocking issue

Al: web security contexts matter .. there is a group in W3C working on a requirements doc
... different effective politeness needed
... not in the page .. security people might not be happy with it

Chaals: use case is having different politeness instructions
... ..meaning politeness levels ..

Rich: is there anything for content author to do?

still causality issue

<chaals> Web Security Context group -> http://www.w3.org/2006/WSC/

Rich: take becky's tree view example: tree item controls another piece .. what to do for page author?
... to be continued ..

WD #090

WD #90 what to do when activedescendent is not a decendant

Al: go back path to root to know if its really a descendant

Aaron: if it is .. what should User Agent do? Need advice

Rich: example: table / grid is managing descendants, button outside table focused - what to do?

<Zakim> chaals, you wanted to say what is the problem that arises

Aaron: put focus on container that has activedescendant ?!

Rich: who's managing the button?

Al: don#t understand how this is coupled with bubbling lin DOM

Chaals: see not the problem

Al: just question of managing the Active ID, Rich agrees

Rich: leave focus where it is! no Browser change of focus

<leesa> rich can you speek yo?

<leesa> up

Aaron: so ignore activedecendant if it is not a descendant? Is that the solution?

proposed: ignore activedecendant if it is not a descendant (Chaals/Aaron discussion ongoing)
... author must ensure that activedecendant is really a descendant, the user agent should not check this before forwarding focus

<Al> "really a descendant" in includes via 'owns'

objections: none

<Al> lunch until :45

<Al> note -- yesterday's minutes http://www.w3.org/2007/04/11-pf-minutes.html

<JRG> srcibe: jrg

<Al> scribe: JRG

<scribe> scribe: JRG

AL: AL what merit the most FTF time
... I am not sure about Issue 80

AG: Let's do Ramans think about Atomic

AL: I have some proposal

<aaronlev> Case 1: if none of the ancestors have explicitly set atomic, this is the default (aaa:atomic="false") case, and the AT only needs to present the changed node to the user.

<aaronlev> Case 2: if aaa:atomic is explictly set to false, then the AT can stop searching up the ancestor chain, and should present only the changed node to the user.

<aaronlev> Case 3: if aaa:atomic is explicitly set to true, then the AT should present the entire subtree that aaa:atomic="true" was set on.

<aaronlev> The AT may choose to combine several changes and present the entire changed region at once.

<aaronlev> Normally, those rules apply whether the list node was changed or just the text changed.

<aaronlev> However, it's possible to change that default behavior using aaa:relevant. For example, setting aaa:relevant="text" means that only text changes should be presented.

<aaronlev> When a node changes, the AT should look at the current element and then traverse the ancestors to find the first element with aaa:atomic set.

AL: explains his proposal

AG: If you have an atomic on the grandfather and .... then only the child is spoken

AL: You can have sub regions spoken

AG: You stop reading when you see atomic
... It is asserted again, you stop when you hit that

AL: The closest ansestor winds
... Glen are you on?
... I don't think so
... Lisa?

LS: I am on the phone

CC: I agree with AL
... Firefox currently does this

RS: Fine with me if AT vendors are happy

AL: Can someone ask GG?

RS: Let's kepp it, no other good options

AL: AT should combine and log all events should be spoken
... May should be changed to should

CMN: cobine the region

CC: What happens two two regions that change at slightly different times, you need to provide some pausing

AL: I did put may because I didn't define it better, it was not intentiona;

AG: Any value spoken the change has been handled

AL: I'll except the arguement, no change

MC: The instered text is fine?

AG: Yes, use AL proposal

MC: Make a note to insert

RS: Can we close the issue?

AG: Yes, add AL text

RESOLUTION: Accept AL proposal for nested atomic properties

<Al> ACTION: Al close issue WD#83 (atomic nesting) [recorded in http://www.w3.org/2007/04/12-pf-minutes.html#action06]

CC: The closest one wins?

AL: yes

CC: It seems sensible and thats what I am doing

AG: The point is that polietness is herititary

AL: It is a pretty standard concept of inheritance

CC: You may want to be explicit about it

MC: That is what we want to insert right

AL: Relavent is a key word
... Relavent is a liveregion property

MC: I don't see it here

RS: It is a property

MC: Edting document for relevant

RS: Next?

AL: Review busy issue
... An author may change a region, but it may take some time before it is finished loading and then be displayed to the user
... The busy property makes sure the region is not presented until the autor says it is done

LS: I think it is an excellent idea
... When you are making lots of changes, is there nothing that already supports that?

AL: I have not seen anything

JG: What about display: none

AL: It might be visible, just not done

CMN: Is this a progress event

AL: Is this 0 percent complete...
... We have progress meter, but no way to link

AG: We have controls?

AL: Does the region control the progress meter, or visa versa

CMN: The notion of progress events, there is something going on and it spits back prgoress events
... It may say that is on the way, in that notion that you use those events to update the bar

AL: If something is just a few seconds, it may not be worh it

CMN: You say someting is busy and then say if is not busy
... I am writing a draft

LS: -1 may mean it is ...

AL: If you don't know wne it will finish it is undetermined

LS: The value now could be a real value

<chaals> Editor's draft of Progress events -> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html

LS: The value is not in the success, but in the information that something is changing

AL: There is a role progress meter

LS: We have valuenow as a state and maybe we need a progress property
... It is jsut useful information to pass on to the user
... You could go to -1 if there is an error

AL: I don't like magic values, because they cause bugs

CMN: You start event and then anything can listen to progress events
... What the current value is, the final value...
... in an IRC channel you can never know the end, but you might be interested in some measue of how much you have
... When you know the size you can

AL: Length computable in undetermined

CC: I want to address something, the status should be a control to the user
... If you use the AT to list the controls, but the user cannot inteact with it

AL: I think the progress meter spec is a little more complicated, in the busy feature is just wait there is a tansistion
... the change events are artifacts, not complete

AG: IRC comes line by line anyway

AL: ATK has a state called stale
... Don't use it until...

AG: We can get the functional effect by using live=off, interium events don't get spoken

AL: Is there value in telling the user that something is busy
... This not a super long update

CC: I said something similar to what RS said
... This doesn't sound quite as hackey

AL: There is a busy state in the Accessibility API

CC: The advantage is that it looks cleaner

AG: I would tilt in the direction of having it, since it will be more direct for authors to use

AL: When you see busy in the spec...

RS: It is just another property

CC: Using live breaks inheritance rules

AG: True
... Any objection to adding busy

LS: Just waying busy is wasted,I propose progress

DP: The you have 1/4, 1/2, 3/4 done....

LS: CMN proposal is well thought out...
... We can add more values, people using want more information
... If we add a new state, we may need to add more values for future expansion and backward compatibility

AL: I think thta is a good poiint
... We don't want to have progress = 100 on everything
... We can have other values like progress like "error"

AG: Let's take the terms for web API group
... Is there a way to capture the last event?

AL: You listen for them

CMN: If you lifted something from the progress spec, you would just have the last event
... Talked about status values from spec...

AL: Want to propose something

LS: New property called "progress": complete, error, 'not started', ...

AG: Can this be homework

LS: I've got none, value, complete...

AL: How is a sighted person going to know?
... We started this to keep the screen reader from speaking too soon

LS: this is something they can trigger on that from the value of progress, it can be visible
... Seeing something fast or slow, you can make decisions about reading now or later
... It is something that is usually available and authors often make available

AL: I was going to say that we cannot define the values now, we can look at it later

<Zakim> dpoehlman, you wanted to say what about other behaviours such as count down till done? time remaining?

DP: My sentiments are similar, x number of mintes remaining, we need to think about how to measure progress

RS: I am worried about confusing people

LS: People can just put in string, but have recommendations like "busy"

AL: How do developers know that these are strings and not values

AG: I think that you should have a progress control like RS said, different interfaces can show or hide the information from users
... The piint is that is has valuenow attribute
... Maybe we do need a busy property

AL: So it would be an attribute to an IDREF, if it is not there it is ...

AG: That would be one way to do it

LS: I don't know, what started with an easy use case, it is important to the user, but information now needs to create another contro and have references, i don't like it
... The proposal was busy, then we changed it to progress and now we have separate control with references

DP: I am alittle confused
... If we have progress meter, rather than something
... WHy not use the control

JRG: It is more work for authors

AG: Is the proposal is busy?

LS: How about progress?
... We can add more values

AG: What you mean add more values

LS: If we do not have a value "error", "busy" still works

AG: we don't write those rules, there is a lot of heat in the HTML working group
... We have 2 proposals: busy=[true|false] or progress[busy|error|complete???]
... If you have a progress meter you can use it, if you don't we can use one of these two properties
... I don't hear a consensus

LS: Straw pole?

CMN: I like progress with a string

MC: pass

CC: I like busy, with a third value error

JS: I like CC option

SS: I like busy with 'error'

DP: I like progress, but describe them

JRG: I progress with enumeration

DV: Progress with string

AL: I like busy with tristate values

TB: Do we have definitions

RS: Busy with tristate

AG: Consensus is busy[true|false:error]
... Consensus is busy[true|false|error]
... Much I have advocated for short names
... Look at CSS have open ended media types, with a few suggestions
... RESOLVED: Put in the 3 state busy

<scribe> ACTION: cc write up proposal for busy [recorded in http://www.w3.org/2007/04/12-pf-minutes.html#action07]

RS: We can close that

AG: Nose count for hosted dinner tonight?
... 9 people

Issue #86

http://pf-issues:kW9!prCy@cita.disability.uiuc.edu/pf-issues/issues-linear-wd-1.html#86

break

AG: Things around the control relationship

<chaals> scribeNick: chaals

<scribe> scribe: chaals

Issues 86, 59, 60

AL: It is hard for the AT to find the status bar and know whose status it represents (other part of the page, status region isn't visible, ...)
... idea is that the status is controlled by what the user is doing. The region which has a status somewhere should use the controls property to point to the status region.
... Also, what should "controls" be allowed on? Suggest anything - status quo

RS: "controls" isn't the same as statusOf - something else might control the status bar.
... could be live, controlled by something else, ...

AL: Example?

RS: You have 2 or three things that update the status bar

AL: Those would all point to the same status as "controls"

RS: Example, I have a mail client. I select a message, and that updates the status - but the status is for the whole document.

AL: This is already what we are using it for.

AG: This is a status that is part of the scripted application.

SS: Status bar means the browser one, or some internal region? We have a message area that acts as a status for an application.

AL: This is a region in the application

SS: Is this an alert?

AL: Alert only exists sometimes. Status is there all the time.

SS: Example - an alert that is there all the time

AL/RS: Should have been status

AL: Alert is urgent. It may have been chosen because it has more backwards compatibility.
... If status just shows something from the real world, it is just a liveRegion. Status is something that reacts to things on the page. We should come up with some language to clarify this.

CMN: Agree with the idea to use controls, and that we should look at some clearer explanation of when to use status/alert/liveRegion

RS: When we have a status bar, the thing that controls the status is the thing that the status applies to.
... right?

CC: Status and liveregion are not mutually exclusive

AL: Right...
... just need to clarify the relationship

RS draws his mind on a whiteboard.

CC: can you have multiple things controlling status?

AL: Sure

RS: Is there some way we can group things together to make it easier to handle multiple related items?

AL: That's up to the author.

<scribe> ACTION: Aaron to provide text that explains the relationships and how to choose between alert/status/liveRegion/popcorn [recorded in http://www.w3.org/2007/04/12-pf-minutes.html#action08]

AL: If there is nothing controlling the status, it's just a liveRegion

CC: What if there are multiple bits of status?

AL: Will have to make them all available

RESOLUTION: We use controls so anything which has a status, controls its status area.
... Multiple items can share a single status area.

<aaronlev> http://developer.mozilla.org/wiki-images/en/8/83/Moz_ffx_openStandards_264x198.jpg

<aaronlev> 88, 79, 73, 82

Issues 88, 79, 73, 82

AL: Limiting haspopup to certain roles is a bad idea - should be a universal property. All of our other relations are universal...
... hasPopup sounds like a boolean - prefer some other name

AG: Seen the other culture, but...

RS: So we can put this on a section. If you are creating an authoring tool, you might have context menus for poperties...
... do you mean, for *EVERYTHING*?

AL: Effectively - not that you would use it on everything, but we only have limited granularity so that's the way we do that.

RS: Do we need a test case for everything?

AL: Not necessarily

TB: If it is a requirement, then it has to be testable

RS: Do we need a test case for each one?

AL: We can't test every possibility - it is not feasible

RS: We would require it coud be there on anything that has a role

AL: And things that have no role

<Rich> a\q?

<Zakim> Al, you wanted to ask what is the difference among a popup, a flyout, a tooltip, a submenu

CMN: It isn't very hard to generate a large range of combinations (use a script and a list of elements). It is unlikely to introduce regressions on many specific cases, so testing can be done reasonably efficiently and effectively...

AG: What is the difference petween popup, flyout, tooltip, submenu?

[discussion - some people have a concept (which varies from person to person), there are some formal schemata e.g. for Windows platform...]

RS: We take id as a value for hasPopup?

AL: Yep. Would rather a boolean

RS: Me too

AL: It is implemented as a boolean in FF now

AG: So use "owns" to say what the thing is?

AL: Yep.
... so Proposal: Make it universal, boolean, and use "owns" to identify the popup/submenu/foo

AG: Other use case is forward/back button, with a pulldown e.g. for history or more info
... not sure that we want the submenu etc.
... The title attribute was meant to be a stand-alone piece of text. But because it was shown as a tool-tip, it was used as somethng dependent on the content it was a title for, rather than being stand-alone
... rich tooltips are going to take on something of menu functionality - there is a continuum here

AL: Sure. We definitely need "owns" in menu/submenu case. I don't think it is bad to use it in other places, like a tooltip. You don't have to use it if the thing is already a child, of course.

RS: You want to be able to put it on any HTML element.

AL: Yeah - same as we do with a zillion others. We don't have complicated fine-grained control, so we use this approach instead.

RS: Things like this are not showing up in the taxonomy.

AL: Right. There are a bunch of things in that category

RS: OK...

SS: We have elements and popups. Popups are extra stuff you can add to a link - put "hasPopup" and it is good

RS: Would probably want "owns" too

SS: We also have an input - for example to select colours

AL: hasPopup triggers the thing that is owned.
... which could be anything.

AG: to distinguish it from something like a mouseover (which is a tooltip)

AL: We can make sure that hasPopup describes that.

RS: Mouseover is an explicit user action.

<JohnHrv> yep, it's me. thanks, michael

<JohnHrv> ok. thanks, al

<Al> check the log for details (from RRSAgent response above)

CMN: If you are going to talk about mouseover and something as different, you need to build a complete two-level model. At the moment, my understanding is that hasPopup is only based on one level of user action.
... you could do this with focus/activate distinction, if yu like... (modulo mouseover == cfocus debates)

[discussion of this - is there a finite set we can describe, or a messy continuum we need to model?]

AG: I think there should be a smooth transition from moving to something to activating it. What if you get to something and a submenu flies out - what is the next action?

AL: Yeah, but it turns out that it doesn't work like that...

MC: I hear a difference between tooltips, submenus, and some people are using one as the other

AG: I am predicting that the boundaries are blurring and people will do things along the range

JRG: Those things won't have a title attribute.

AL: A TV show pops up a rich title

RS: But you can't navigate around it.

AL: Yes, you can

JRG: There is a difference between a title attribute-derived tooltip, and doing something with scripting. If you are scritping it, you have to make it work.

AG: Sounds like shifting too much of the burden.

AL: We have a role of description - we could use that for tooltip.

[Oh. We don't have that role anymore]

AL: We do need one like that.

RS: Think that is cleaner

AL: Right. then you don't *have* to have it pop up.

RS: How could you navigate a rich description?
... with links, etc.

SS: a tooltip window should not be confused with something that the author makes pop up.

JRG: Seems that you are asking to have the browser make some magic to simulate mouse behaviour to get things

AG: Don't want to ask the author to do it if we can get the user agent to do it.

LS: Can it be the AT providing the access?

AG: Think this is sufficiently basic that this should work at the UA level.

JRG: What about keyboard users without AT?

AG: Exactly: the browser has to provide an activation mechanism

CC: Ditto
... We have haspopup, and that is triggered on activating popup (which is determined by the browser)

AL: WebAPI is trying to make the parallel between hovering, focussing, etc.

<Al> Chaals: WebAPI got as far as making 'click' and 'activate' synonyms

<Al> 'activate' is in players for e.g. SVG

<Al> With voice command, you can say 'next, next, next, ... click'

CMN: The trick is that we are trying to describe something with two interaction levels - mouseover/focus, or some equivalent. There are zillions of examples of this in the wild...
... so we really need to find some way of distinguishing these

AL: Can we do something like rely on the difference between hasPopup and Owns as an activation, with describedBy as the "light touch"

LS: Isn't this just presentational whether it is a mouseover or click?

AG: It is relevant, because the author will make the content according to their perception of how much work it is for the user to activate different kinds of popup, etc.

LS: Not sure. Some people hate mouseover, some love it. Why do I care which method is used on visual rendering?

AG: Because this determines for many authors how they decide which to use

LS: don't think it does.
... think authors base the decision on looking at what they think the users will do.

<JRG> CMN: Most authors don't think about focus groups

<JRG> CMN: Some authors may think about, but most authors think visually and author visually

<JRG> CMN: There are arbitary implementation decisions

<JRG> CMN: The basic paradigm ...

CMN: Agree mostly with Al here. What authors see as visual behaviour determines, in large part, how authors understand user interaction.

AL: If an author is using ARIA we should tell them not to rely on hoverable stuff for interaction.

AG: If you want something different to navigate into, that isn't the default action, you need a different way for them to be triggered.

JRG: Authors have a way of doing something. We are looking for markup patterns that match what auhtors actually do.

AL: If authors want a really interactive tooltip and they are looking at ARIA, we should be saying "don't rely on the light touch thing, because users need access.

JRG: The benefit is that this way they will be less useful for everyone.

<leesa> are you starting again?

<aaronlev> leesa: in a sec

<leesa> ok

<leesa> hello arron!

<Al> http://maps.google.com/maps?f=l&hl=en&q=restaurant&near=Sterling+VA&layer=&sll=39.006112,-77.428894&sspn=0.144332,0.127373&ie=UTF8&latlng=39032540,-77409610,350449784873436566&ei=wZQeRvPfNY7gqwKb1YGTBA

<aaronlev> hi leesa !

<Rich> Al: I still have a heartburn with using described by if it has active elements

<Rich> Al: I understand you want it to be the author's responsibility to get the user there via the keyboard

<Rich> aaron: if it is not a description it is a has popop with owns

<Rich> aaron: it is ok to have previews that are rich

<Rich> michael: we need to be clear

<Rich> al: active elements must be keyboard navigable

<Rich> aaron: if hte describedby has active elements then you need keyboard navigation to get there

<Rich> al: we need owns in stead of describedby in that case

<Rich> aaron: hover may just give you a quick synopsis of the plot

<Rich> michael: a desciption with role would be a violation

<Rich> rich: what have 2 pop-ups with active elements

<Rich> aaron: if activated by a hover should use describedby

<Rich> aaron: if activated by a discrete trigger then should use haspopup and owns

<Rich> aaron: tooltips make things more accessible for some people - low vision

<Rich> aaron: can use describedby for any tooltip even if it has active elements

<leesa> last thing i sa was Q

<Rich> CLC: when you said the light touch you get the title

<Rich> aaron: describedby is used by anything that is pop-up help

<Rich> aaron: haspopup is only for things that are triggered by a key click or eneter

<Rich> s/enenter/enter/

<Rich> chaals: in the fullness of time where ARIA can be used by any case, we are giving you the functionality of title with a richer piece of content

<Zakim> chaals, you wanted to say title will quietly vanish

<Rich> Stefan: if you don't use title how will you do popup?

<Rich> Stefan: are you saying per element, page, or site

<Rich> s/Al: Stefan/

<Rich> aaron: the author will probably want to the minimum markup for what they need

<Rich> CLC: I don't see this as mutually exclusive

<Rich> CLC: you could use title and describedby in some contexts

<Rich> Chaals: If you use a tooltip you can use describedby

<Rich> Chaals: you don't have to use the tooltip if you don't want to

<Rich> Stefan: title (being popped up) is the default behavior of the browser

<clc4tts> http://firevox.clcworld.net/tutorial/tut2.html

<aaronlev> http://www.mozilla.org/access/dhtml/button

<Rich> use haspopup whenever you have something that can be activated

<leesa> ok

<Al> schedule: we will be discussing future F2F schedule tomorrow morning at the beginning of the meeting -- 0900 EDT

<Rich> lisa: I agree to al's coment

<Rich> proposal: use po-up and owns to determine the default action

<Rich> use descirbedby to do something that is passive

<Al> RS: what do you do if there is a popup and a help on the same base element

<Al> CMN: example -- base element is "try me"

<Al> 'help' is HELP

<Al> 'popup' is MENU

<Al> Tryme hooks to HELP with 'describedby'

<Al> Tryme hooks to MENU by 'owns' and also asserts 'haspopup'

<Al> AL: it's up to the author to decide how they afford keyboard navigation to the auxiliary panes.

<Al> It could be by insertion in the tab order, exposing a hidden hyperlink extending Tryme etc.

<Al> CMN: Tryme could even be a hyperlin,

<Al> Tryme has actions:

<Al> onMouseOver bring up MENU

<Al> onHelpKey, bring up HELP

<Al> onClick navigates to href destination

<leesa> lisa is going to sign out now

<leesa> but first

<leesa> good night

<JohnHrv> i've gotta run. any additional updat on tomorrow's agenda?

<Al> no, but we will (including discussing after F2F) try to pack the a.m. with things for you.

<JohnHrv> ok, cool. 9:00 to 10:30 EDT works fairly well, even if it's early

<JohnHrv> talk to you all tomorrow

<Rich> rich: group seems to agree that should not tie in light and heavyweight user actions

<Rich> rich: Proposal is that popup and owns or pop and menu document writes are used to define relationships between an object and a pop-up menu

<Rich> rich: for tooltip overrides we use describedby to refernce the tooltip description and provide a tooltip role for the actual tooltip

<Rich> aaron: the author should be responsible for the keybindings

<Rich> Resolution: haspopup is a boolean which indicates that the object has a popup menu which may be rendered using document writes for the menu as a descendents of the object or through the use of styling in which case the relationship to the pop-up menu is established using owns

<Rich> Resolution: Group agrees to have a tooltip and description role

<Rich> resolution: description means you have a description but it is not used as a tooltip

<Rich> Resolution: a tooltip may be used as a tooltip for the object

<Rich> Resolution: if the tooltip has active elements it must be keyboard navigable

<aaronlev> a pop-up window that displays a description of an element when the user visits that element

<aaronlev> a popup that displays a description of an element when the user visits that element

<aaronlev> or A tooltip is a small box that appears near an object in a graphical user interface (GUI) when a pointer or other cursor controlled by a mouse passes over or rests on that object and which contains a brief text message identifying or explaining the object.

<aaronlev> A popup that displays a description for an element when a user passes over or rests on that object

<aaronlev> A popup that displays a description for an element when a user passes over or rests on that element

- DRAFT -

WAI PF Face to Face Day 2

12 Apr 2007

Attendees

Contents