<jamesn> ls

<Birkir> Hey guys .. did not get an agenda for today so wasn't sure if meeting would go ahead .. can join call in a few minutes.

<annabbott> Birkir: no agenda was sent out for today's call

<jamesn> http://w3c.github.io/aria/practices/aria-practices.html#TreeView

JN: I will file bugs as we go along
... The tree node should be a an example of a tree
... Can I just make editorial changes, I think this issue is purely editorial

JG: Must a tree view "must" have a visual indicator?

MK: We don't use "must", but we do use "should"

JN: Is the APG for writing a widget or determiing what widget I should use

AA: If they have a sub itme then it is open

MK: Can you still see the parent menu

JN: Depends on the implementation, but mobile it may not be

MK: On a desktop it is cascding menus,....

JN: Depends on the size of the display

MK: In trees you always see the pattern

JN: It could be scrolled off the screen

MK: But you could scroll back up

JN: yes

MK: In the description, most of this is mostly in the KB section

JN: Yes

MK: This could be some work

JN: It could be just copying and pasting

MK: I don't think it is straight copy and past, with the focus...

JN: We would have a separate path, focusing stuff, maybe not, we will see, I will load a bug
... "There must be visual distinction between focused and selected nodes"
... This is part of the description
... talking about mouse and keyboard behavior

MK: That is unual

JN: Maybe we should drop it

MK: Yes
... We have some similar things in listbox
... Can we go back and look at the patterns we have already done
... We are still establishing our pattern....
... Reviewing other roles with selection.....

<jamesn> this is the bug I am logging so far

<jamesn> Move the applicable general behaviour bullets to the keyboard section.

<jamesn> 4th bullet (Nodes can be focused and/or selected. There must be visual distinction between focused and selected nodes.) should remain a note in the general section.

<jamesn> 5th bullet (Arrowing to an item with the keyboard or clicking on an item with the mouse will focus and select the node. Any previous selections are cleared) should potentially be dropped.

MK: Listbox and treeview are the first ones with selection
... We have only talked about the keyboard....

JG: Do mouse interactions help inform which widget is appropriate?

MK: What kind of can of worms would that open up
... I don't think we talk about mouse, it might add alot of information and may not be relavent

JN: Me too
... If someone is using a different mouse interaction, we shouldn't advise people or limit innovation

MK: There could be a place in the support section, we could link to WCAG 2.0 keyboard operation

JG: I feel we should remove mouse interaction information

JN: Drop fifth bullet or keep the non-mouse part

MK: The selection part is covered by other statements

AA: It will be in the KB section

MK: That bullet makes an assumption about single select
... Quite often we .., last week we talked about single and multi-select
... We do not want to encourage modifier keys for single and multi-select due to problems with mobile
... For example using the space bar for selecting
... If is a single select...

JN: I have not seen them that way, I would love to see an example

MK: In install programs, there is a checkbox

JN: It is still not a checkbox, but the visual indication will indicated it is selected, ... modifier key...
... Going off for 5-10 minutes...

MK: Reading the kB section
... Shift+PageDn should be Shift+End, creating bug
... There are two different kinds of multi-select
... I will separate them out

JG: "*" expands all nodes

AA: In windows the "*" expands just the nodes on the current level, not all nodes

MK: You tried numpad "*"?
... I don't think it is a standard, I would like to see it deleted
... I have seen control "+" or control "-"
... AA: "*" does expand on the current level, in windows explorer

J: I think it could be recommended if people provide the function

AA: Just add expand all nodes at the current level?

MK: All siblings at that level
... We typically use the windows as the basis for the style guide, I have seen control "+" and "-"

JN: Just at that level

AA: I am not seeing them work in WIndows Explorer

JN: mouse user can not expand all nodes, so we are describing behavior that is not there for others

MK: I am trying to thin of a specific example

JG: I think it should be an optional behaviors, but if you provide it use these keys

<Matt> In Windows, it expands all siblings at the same level, not all nodes.

<Matt> A key to do this is optional.

MK: I am changing keypad to numeric keypad
... I just tested a open source tree that uses control "+", it is multi-plateform, it is just what they choose
... Enter usually performs a default action

JN: If there is no default action then it could expand or contract a node

MK: reviewing today's bugs

JN: I think these are mostly editorial....

MK: I was going to create a bug on listbox and mention both types of selection models
... I think that is a visual styling decision, both need to be described

JN: that is fair enough
... I think we need to define optional keyboard shortcuts
... I am going to add the optional one in one bug
... How about Home and End

MK: I do not consider them optional

JN: Depends on the size of the tree
... expand all contract all are optional
... There are times when moving use letteres is alot of work

MK: There are alot of tree that do not support that feature
... It there are more than 5 node at any level...

JN: Probably all trees, but maybe not

AA: I went to the guidelines for KB windows guidelines, "+" on numpad ......

JN: It does expand all the children

MK: You are not seeing anything like control "+" or "-"

AA: I don't see anything like that

JN: Provide a link to Windows Guidelines

AA: Page goes on and on

MK: I added a bug for multi-selection...

<annabbott> Guidelines for Keyboard User Interface Design (Microsoft): https://msdn.microsoft.com/en-us/library/ms971323.aspx

<annabbott> Search for Tree View

MK: I need to read the properties and states
... Our roles and states and properties is usually a list, here it is a sentence

JN: That is an editorial fix
... I don't want to get into aria-owns

MK: That is probably a good idea
... psoinset and setsize

JG: These are needed when the DOM does not present the position and the setsize

JN: These are things that people need to be thinking of using

AA: So why don't we need aria-owns

JN: This is used when the DOM does not represent what you want in the accessibility tree

MK: A tree contain, poorly written needs to be rewritten...
... We need to says something about the DOM structure

JN: There needs to be ....

<Matt> scribe: matt_king

<Matt> AA: we at least need a reference to aria-owns

<Matt> mk: we need to state that treeitems are dom children or owned by the tree element.

<annabbott> Bug: tree view - posinset and setsize

<annabbott> MK: at a reasonable stopping point

<annabbott> MK: do we need to talk about aria-selected in States & Properties

<annabbott> MK: also need to cover multi-select

<annabbott> James: Let's see if we can grab from somewhere else

<annabbott> MK: maybe from Listbox

<annabbott> MK: not available for call next week

<annabbott> James: may not be able to make next week

<annabbott> MK: for next two weeks

<annabbott> MK: June 29 and July 6

<annabbott> James: out first three weeks of August

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)

No ScribeNick specified.  Guessing ScribeNick: jongund
Found Scribe: matt_king

WARNING: No "Topic:" lines found.

Present: AnnAbbott JonGund JamesNurthen matt_king

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

Got date from IRC log name: 22 Jun 2015
Guessing minutes URL: http://www.w3.org/2015/06/22-aria-apg-minutes.html
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report