<jamesn> https://mit.webex.com/mit/j.php?MTID=m71a4dbc9d1dd947b1ad8eecfa8f1d0ff

https://github.com/ncjones/editorconfig-eclipse#readme

<scribe> scribe: MichielBijl

<jemma> https://github.com/w3c/aria/#generating-editors-drafts

<jamesn> rragent, make minutes

Continue review text of section "2.32 Tool Bar" in the keyboard interaction notes http://www.w3.org/TR/wai-aria-practices-1.1/#toolbar

<jemma> "ungraceful shut down." ;-)

<jamesn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29391

MK: Went to the description

<jamesn> Rewrite description to be more inline with spec; remove compact visual form language.

<jamesn> Delete references to menu/menubar.

<jamesn> delete sentence about using role group for a bunch of toolbars.

<jamesn> In keyboard interaction, remove:

<jamesn> "Direction may need to be adjusted for Right to Left languages "

MK: Left off at keyboard interaction
... James do you want to review?
... Any other changes that need to be logged?

JN: You can put any sort of controls in toolbars, correct?

MK: Yes, that does mean you can put in inputs that capture left/right arrows.

JN: Current advice to developers, a) do it, but make it so you can tab in/out of the input. b) make the input its own toolbar
... Possibly a problem for AT switching navigation mode while tabbing between input/toolbar

BG: What is the problem?

MK: Application toolbars that don't allow for keyboard navigation are a real pain to use.

MB: Is this a pattern seen on Windows? Mac doesn't do this for toolbars.

JN/MK: OS X not designed for keyboard use.

MK: we need to word smith this into the description: “some elements in the toolbar may consume left and right arrow keys”
... What do people think of this note:

provide a documented keystroke that allows users to move focus quickly to the tool bar from elsewhere within the web application, placing focus on a tool within the tool bar.

MK: CKEdit uses F10 to move to editor toolbar.

JN: Change to “should consider to provide…”
... If there is a main toolbar, it is good to have a keystroke to move to that, but not if you have a gazillion toolbars.

MK: Or move to context dependent toolbar.

*James typing loudly*

MK: What to do with: There is debate concerning the treatment of disabled toolbar buttons -- should they be focusable or not?

JN: Agree/disagree some of the time; depends.
... Annoying if one button is enabled and 10 are disabled

MK: Agree with James
... What do others think?

BG: I don't think they should be focusable

MK: We should remove the words “there is debate”

MB: Can't we just remove everything except for “Disabled buttons are not focusable until they are enabled.”?

JN: Don't think Ribbons are the right place to look for toolbars.
... Look like menu's on the top level
... Would like to see that our recommendation would be something like: not focusable by default, but there are specific cases where they should be.

MK: Then we should include at least some examples of those specific cases.
... Include the rational

BG: And change buttons to elements?

All: yes.

MK: In general disabled elements are not included in the focus sequence, however there maybe some circumstances where discoverability of a function is crucial.

CP: Does it make sense to make them read only?

<jamesn> "In general disabled elements are not included in the focus sequence but there may be some circumstances where discoverability of a function is crucial and an author may choose to include in the navigation sequence."

MK: No.

JN: You can't have read-only radiobuttons or checkboxes

MK: Delete middle two bullets under states and properties.

AA: Remove line “too few or too many”

*all agree*

MK: Unsure about aria-label

JN: Only if there is more than one.

AA: Could have a visual label that labels something else

MK: I've done that

AA: aria-label if more than one toolbar, and if no visual label
... and could do aria-labelledby if there is a visual label

JN: Is it helpful for toolbars being labelled.

MK: Depends on the buttons/elements inside being labelled
... I find them helpful

JN: So let's leave the recommendation in

MB: You can still label the toolbar if there is only one; I label my nav's like main nav even if there is only one

MK: Yeah

<jamesn> MB: what do we do in other places about labelling

<jamesn> JN: labelling techniques are the same everywhere

<jamesn> AA: I don't think it hurts to call out aria-label or aria-labelledby

<jamesn> MK: I don't think there is a referencable section on that

<jamesn> Birkir: something about labelling widgets would be really useful

<jamesn> Birkir - techically they could use title

<jamesn> JN: yep

<jamesn> MK: wouldn't recommend that

<jamesn> JN: why

JN: Why should I have to label it twice?

<Birkir> title is a source of accessible name (the last fallback admittedly).

MK: That's a worthy issue being addressed

JN: It's like suggesting longdesc in our document
... “warning: this is the last fallback!”

MK: I would never put title as a best practice
... We circle back around to thinking not recommending title
... Should only be done by people totally in the know

CP: Maybe makes sense if you know what you're doing

AA: Title is not part of APG/ARIA, we can leave it out

Birkir: good point

<jemma> I agree with annabbott about title

Review text of section 2.18 listbox https://rawgit.com/w3c/aria/master/practices/aria-practices.html#Listbox

http://w3c.github.io/aria/practices/aria-practices.html#Listbox

MK: Have done some edits
... ARIA doesn't include a definition of “static”
... So I made up wording for it

A listbox widget allows a user to select one or more items from a list of choices or options. A listbox that allows a single option to be chosen is a single-select listbox; one that allows multiple options to be selected is a multi-select listbox.

JN: We have child stuff as the option

MK: Open that in a dialog

JN: No you focus into the child option

MK: You're going to have a screen reader issue
... You can tab around in it, but content in it is invisible

JN: No, if you go in it, you can arrow around in it.

MK: Must not be contained in an option elements

JN: Let me check that

MB: Should we drop “choices” from the first line?

MK: Was an editorial thing

AA: Think we can lose “choices”

JN: Will make a bug

*discussing the weather around the globe*

MK: Conclusion: we will remove choices

MB: Should everything after second sentence be a note?

Birkir: the one that starts with “This is because?”

MB: yes
... Good information, but adds more text

MK: Okay with removing it
... Let's move to the third paragraph

Birkir: explanation should be last

MK: Good point
... Instruction should be before explanantion
... Let's move to last/fourth paragraph

JN: Seems like a general problem
... (not SR specific)

MK: I found it important enough to include

JN: I would argue you don't want repeated start strings for anyone

<jamesn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29469

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/make it/make the input/
Succeeded: s/to toolbar//
Succeeded: s/disabled/focusable/
Succeeded: s/worthy/worthy issue being/
Found Scribe: MichielBijl
Inferring ScribeNick: MichielBijl
Present: AnnAbbott Bryan_Garaventa CharuPandhi JamesNurthen JonGunderson MattKing MichielBijl jemma jongund Birkir

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

Got date from IRC log name: 15 Feb 2016
Guessing minutes URL: http://www.w3.org/2016/02/15-aria-apg-minutes.html
People with action items: 

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