17:55:12 RRSAgent has joined #aria-apg 17:55:12 logging to http://www.w3.org/2016/02/15-aria-apg-irc 17:57:32 jamesn has joined #aria-apg 17:57:45 Zakim has joined #aria-apg 17:57:58 meeting: WAI-PF ARIA Authoring Practices Guide Taskforce 17:58:15 rrsagent, make log world 17:58:47 Agenda+ 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 17:58:47 Agenda+ Review text of section 2.18 listbox https://rawgit.com/w3c/aria/master/practices/aria-practices.html#Listbox 17:58:47 Agenda+ Update pattern work assignments and status https://github.com/w3c/aria/wiki/Aria-Authoring-Practices-Patterns-Status 17:59:01 https://mit.webex.com/mit/j.php?MTID=m71a4dbc9d1dd947b1ad8eecfa8f1d0ff 18:01:51 annabbott has joined #aria-apg 18:03:06 agenda? 18:07:38 jongund has joined #aria-apg 18:08:40 https://github.com/ncjones/editorconfig-eclipse#readme 18:09:18 rrsagent, make minuteas 18:09:18 I'm logging. I don't understand 'make minuteas', jamesn. Try /msg RRSAgent help 18:09:21 rrsagent, make minutes 18:09:21 I have made the request to generate http://www.w3.org/2016/02/15-aria-apg-minutes.html jamesn 18:09:25 present+ jongund 18:09:40 present+ JamesNurthen 18:09:45 scribe: MichielBijl 18:10:09 present+ AnnAbbott 18:10:14 present+ jemma 18:10:21 present+ MattKing 18:10:36 present+ MichielBijl 18:10:40 https://github.com/w3c/aria/#generating-editors-drafts 18:10:57 rragent, make minutes 18:11:03 rrsagent, make minutes 18:11:03 I have made the request to generate http://www.w3.org/2016/02/15-aria-apg-minutes.html jamesn 18:12:14 zakim, next item 18:12:14 agendum 1. "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" taken up [from jamesn] 18:13:53 "ungraceful shut down." ;-) 18:15:18 present+ JonGunderson 18:15:50 cpandhi has joined #aria-apg 18:16:11 present+ CharuPandhi 18:16:46 https://www.w3.org/Bugs/Public/show_bug.cgi?id=29391 18:17:19 MK: Went to the description 18:17:21 Rewrite description to be more inline with spec; remove compact visual form language. 18:17:21 Delete references to menu/menubar. 18:17:21 delete sentence about using role group for a bunch of toolbars. 18:17:21 In keyboard interaction, remove: 18:17:22 "Direction may need to be adjusted for Right to Left languages " 18:17:27 MK: Left off at keyboard interaction 18:17:33 MK: James do you want to review? 18:18:50 MK: Any other changes that need to be logged? 18:18:56 mck has joined #aria-apg 18:19:10 JN: You can put any sort of controls in toolbars, correct? 18:19:34 bgaraventa1979 has joined #aria-apg 18:19:49 present+ BryanGaraventa 18:19:52 present+ Bryan_Garaventa 18:19:59 present- BryanGaraventa 18:20:22 MK: Yes, that does mean you can put in inputs that capture left/right arrows. 18:21:19 JN: Current advice to developers, a) do it, but make it so you can tab in/out of the input. b) make it its own toolbar 18:21:31 s/make it/make the input/ 18:22:41 JN: Possibly a problem for AT switching navigation mode while tabbing between input/toolbar 18:22:59 BG: What is the problem? 18:25:41 MK: Application toolbars that don't allow for keyboard navigation are a real pain to use. 18:28:52 MB: Is this a pattern seen on Windows? Mac doesn't do this for toolbars. 18:29:11 JN/MK: OS X not designed for keyboard use. 18:31:02 MK: we need to word smith this into the description: “some elements in the toolbar may consume left and right arrow keys” 18:32:04 MK: What do people think of this note: 18:32:05 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. 18:32:22 MK: CKEdit uses F10 to move to editor toolbar. 18:33:11 JN: Change to “should consider to provide…” 18:33:54 JN: 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. 18:34:27 MK: Or move to toolbar to context dependent toolbar. 18:34:43 s/to toolbar// 18:34:59 *James typing loudly* 18:36:40 MK: What to do with: There is debate concerning the treatment of disabled toolbar buttons -- should they be focusable or not? 18:36:54 JN: Agree/disagree some of the time; depends. 18:37:22 JN: Annoying if one button is enabled and 10 are disabled 18:37:23 MK: Agree with James 18:37:32 MK: What do others think? 18:38:12 BG: I don't think they should be disabled 18:38:21 s/disabled/focusable/ 18:40:37 MK: We should remove the words “there is debate” 18:42:28 MB: Can't we just remove everything except for “Disabled buttons are not focusable until they are enabled.”? 18:45:08 JN: Don't think Ribbons are the right place to look for toolbars. 18:45:28 JN: Look like menu's on the top level 18:47:13 JN: Would like to see that our recommendation would be something like: not focusable by default, but there are specific cases where they should be. 18:47:30 MK: Then we should include at least some examples of those specific cases. 18:47:55 MK: Include the rational 18:48:03 BG: And change buttons to elements? 18:48:07 All: yes. 18:48:47 Birkir has joined #aria-apg 18:49:02 MK: In general disabled elements are not included in the focus sequence, however there maybe some circumstances where discoverability of a function is crucial. 18:49:16 CP: Does it make sense to make them read only? 18:49:19 "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." 18:49:21 MK: No. 18:50:41 JN: You can't have read-only radiobuttons or checkboxes 18:51:12 present+Birkir 18:53:04 MK: Delete middle two bullets under states and properties. 18:55:12 AA: Remove line “too few or too many” 18:55:17 *all agree* 18:55:41 MK: Unsure about aria-label 18:55:50 JN: Only if there is more than one. 18:56:00 AA: Could have a visual label that labels something else 18:56:06 MK: I've done that 18:56:53 AA: aria-label if more than one toolbar, and if no visual label 18:57:09 AA: and could do aria-labelledby if there is a visual label 18:57:21 JN: Is it helpful for toolbars being labelled. 18:57:36 MK: Depends on the buttons/elements inside being labelled 18:57:44 MK: I find them helpful 18:57:58 JN: So let's leave the recommendation in 18:59:13 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 18:59:16 MK: Yeah 19:01:00 MB: what do we do in other places about labelling 19:01:18 JN: labelling techniques are the same everywhere 19:01:51 AA: I don't think it hurts to call out aria-label or aria-labelledby 19:02:19 MK: I don't think there is a referencable section on that 19:02:47 Birkir: something about labelling widgets would be really useful 19:03:24 Birkir - techically they could use title 19:03:28 JN: yep 19:03:36 MK: wouldn't recommend that 19:03:41 JN: why 19:04:06 JN: Why should I have to label it twice? 19:05:01 title is a source of accessible name (the last fallback admittedly). 19:06:04 MK: That's a worthy addressed 19:06:20 s/worthy/worthy issue being/ 19:06:34 JN: It's like suggesting longdesc in our document 19:07:08 JN: “warning: this is the last fallback!” 19:07:25 MK: I would never put title as a best practice 19:07:42 MK: We circle back around to thinking not recommending title 19:08:06 MK: Should only be done by people totally in the know 19:08:47 CP: Maybe makes sense if you know what you're doing 19:09:01 AA: Title is not part of APG/ARIA, we can leave it out 19:09:13 Birkir: good point 19:09:23 agenda? 19:09:37 I agree with annabbott about title 19:09:55 zakim, next item 19:09:55 agendum 2. "Review text of section 2.18 listbox https://rawgit.com/w3c/aria/master/practices/aria-practices.html#Listbox" taken up [from jamesn] 19:09:56 http://w3c.github.io/aria/practices/aria-practices.html#Listbox 19:11:26 MK: Have done some edits 19:12:14 MK: ARIA doesn't include a definition of “static” 19:12:21 MK: So I made up wording for it 19:12:35 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. 19:14:08 JN: We have child stuff as the option 19:14:16 q+ 19:14:27 MK: Open that in a dialog 19:14:37 JN: No you focus into the child option 19:15:04 MK: You're going to have a screen reader issue 19:15:14 MK: You can tab around in it, but content in it is invisible 19:15:26 JN: No, if you go in it, you can arrow around in it. 19:15:36 MK: Must not be contained in an option elements 19:15:40 JN: Let me check that 19:15:50 ack me 19:17:59 MB: Should we drop “choices” from the first line? 19:18:31 MK: Was an editorial thing 19:18:57 AA: Think we can lose “choices” 19:19:05 JN: Will make a bug 19:20:36 *discussing the weather around the globe* 19:20:58 MK: Conclusion: we will remove choices 19:26:01 MB: Should everything after second sentence be a note? 19:26:16 Birkir: the one that starts with “This is because?” 19:26:18 MB: yes 19:26:38 MB: Good information, but adds more text 19:27:16 MK: Okay with removing it 19:27:48 MK: Let's move to the third paragraph 19:28:27 Birkir: explanation should be last 19:28:31 MK: Good point 19:28:59 MK: Instruction should be before explanantion 19:30:14 MK: Let's move to last/fourth paragraph 19:30:25 JN: Seems like a general problem 19:30:38 JN: (not SR specific) 19:30:47 MK: I found it important enough to include 19:31:18 JN: I would argue you don't want repeated start strings for anyone 19:32:18 https://www.w3.org/Bugs/Public/show_bug.cgi?id=29469 19:32:24 rrsagent, make minutes 19:32:24 I have made the request to generate http://www.w3.org/2016/02/15-aria-apg-minutes.html jamesn 19:35:10 mck has left #aria-apg 19:38:07 rrsagent, bugger off 19:38:07 I'm logging. I don't understand 'bugger off', MichielBijl. Try /msg RRSAgent help 19:38:20 RRSAgent, bye 19:38:20 I see no action items