See also: IRC log
<scribe> scribe: AnnAbbott
<jamesn> scribe: annabbott
<jamesn> "Normally the newly focussed tab will automatically activate, but in some instances this will not happen and space or enter will be needed to activate the tab."
JN: did everything in the bug, plus arrow nav plus Space/Enter
<jamesn> Space or Enter - with focus on a tab, space or enter will activate the tab if the tab does not activate automatically.
MK: if Space or Enter are required, selected state should not follow focus
Bryan: selected state is implicit with focus
MK: no, not implicit
... if not displayed, isn't selected - just focused
... Selected and expanded are redundant
Bryan: jQuery allows selection of multiple tabs - like for deletion
MK: sort of unusual, would need to shift-select
Ian: not this pattern
MK: thought aria-expanded was global
Bryan: was changed
MK: selected is suppose to indicate expanded
JN: multi-selectable is actually part of accordion pattern
MK: should we include both selected AND expanded?
Bryan: useful to include both, just in separate design patterns
MK: aria-current is better all
the way around
... differences are too suble for end user to discern
meaning
JN: need to decide if this goes to publication on 11th
MK: tabpanel is weird name for this section
JN: would required a bunch of editing
<MichielBijl> Doesn't sound like something we can edit that before the next publish
MK: thinks it should be tabbed interface instead of tabpanel
<jamesn> Tabs?
MK: tabpanel only refers to a part of the widget
<MichielBijl> +1
<MichielBijl> +2
<jamesn> https://www.google.com/design/spec/components/tabs.html#
JN: let's address after thtis draft
thtis=this
<MichielBijl> +1
JN: should we pull this draft in?
MK: agrees
... need language to differentiate difference between active
and selected
<MichielBijl> Tab panel rename issue on github: https://github.com/w3c/aria/issues/286
JG: should examples follow the spec or APG?
<bgaraventa1979> important to keep in mind that the spec is normative, and APG is not
MK: need an example that follows 1.0 spec
MK: did everything in bug, except
delete, which includes discussions
... MK: rewrote second paragraph re: reason for use
(grouping)
... kbd seems more part of design and left it in
... use toolbar only if three controls exist
JG: fine with me
<jemma> https://rawgit.com/w3c/aria/jn-tab-pattern-changes/practices/aria-practices.html#toolbar
<Birkir> It eturns a beautiful 404 error indeed.
JN: merged and deleted that
branch just now
... what about vertical toolbars?
MK: nothing in bug about orientation
JG: should both arrow keys (left & up) be supported
MK: anytime there is orientation, should add a Note
<jamesn> "If the items in a menu or menubar are arranged horizontally:
<jamesn> Right Arrow performs as Down Arrow is described above and vice versa.
<jamesn> Left Arrow performs as Up Arrow is described above and vice versa."
Group: agrees
... should change in tabpanel also
MK: inexperienced screen reader
users just press keys
... add bullet for aria-orientation
JN: no mention in tabpanel either
MK: add to bug or log an issue in case can't get to it immediately
<Birkir> What is better, swarms or superbugs?
MK: will merge this one in
... would like to get listbox in this week - will make edits
with a note that it has been updated and not reviewed
JN: or send to list for review
MK: only remaining is tree
JN: will try to get done
MK: lot of bugs, but not
discussed by group
... and not related to patterns
... next is accordion
Ian: creating two examples - one follows current pattern and other a series of disclosure widgets
MK: for second, have you considered heading with a button?
Ian: yes
MK: likes button inside heading
JN: Ian is writing
implementation, not the design pattern
... maybe include design pattern as part of that effort?
MK: Do we want to log any bugs against current accordion text in APG?
Jemma: kbd interaction pattern isn't clear
<mck> Accordian bug from bryan
<mck> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26254
<mck> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26254
MK: believes it is bug Bryan raised
JN: should look at spec
<Birkir> This proposed accordion pattern (based on tabs) is near impossible for a mobile device user to interact with (easy to lose tabs after a tabpanel). Themore simplified version is much more workable on all devices.
MK: use Bryan's bug as starting point.
JN: but won't happen before next publish
MK: modal dialog isn't done
... mark toolbar and tab done
JN: will indicate pending issues
MK: menu/menubutton ready for review?
<jemma> https://rawgit.com/jongund/oaa-examples/master/examples/menu-button/menu-button-2.html
<jemma> https://rawgit.com/jongund/oaa-examples/master/examples/menu-button/menu-button-1.html
MK: are examples merged in?
JG: no merged in
MK: make pull request once group reaches concensus
JN: can always be rejected
MK: look at menu-button1
first
... works with JAWS
... what's the difference?
JG: second example uses native semantics
MK: second example does not work with JAWS
Jemma: only include example 1?
JG: second example is lacking onclick event
MK: one should have a submenu - can merge that in later
<jongund> go to go we will work on and fix menu-2 and add sub menu to an example
Jemma: will work with Jon
... fix title and get merged in
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) Found Scribe: AnnAbbott Found Scribe: annabbott Inferring ScribeNick: annabbott Present: AnnAbbott JaEunJemmaKu MichielBijl JamesNurthen MattKing Charu JonGunderson Bryan IanPouncey Bryan_Garaventa Birkir Got date from IRC log name: 07 Mar 2016 Guessing minutes URL: http://www.w3.org/2016/03/07-aria-apg-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]