See also: IRC log
<trackbot> Date: 12 January 2015
<jamesn> Meeting: ARIA APG Working Group
<jemma> me jemma
<jemma> 1217244AAAA
<jamesn> 1. Menu: http://www.w3.org/WAI/PF/aria-practices/#menu
<jamesn> Are there additional authoring limitations imposed by menu event requirements?
<jamesn> In particular, should persistent menus work or do they need to be discouraged?
<jamesn> UAIG section 5.8.4. Special Events for Menus
<jamesn> http://www.w3.org/TR/wai-aria-implementation/#mapping_events_menus
scribe LJWatson
<jamesn> http://www.w3.org/2012/webcrypto/wiki/Efficient_IRC
<jemma> JaEun Jemma Ku
<annabbott> Leonie: my email = aabbott@us.ibm.com
<jemma> Ku is my last name
MK: A couple of the bug summaries
need cleaning up.
... 27526 and 27527.
... 27526 updated.
... 27527 need to review the keyboard interaction?
BG: The pattern assumes it will
be a vertical menu, but that's not always the case.
... Need to be careful the pattern doesn't assume an
orientation.
<Birkir> Yeap, sorry guys, traffic
JN: Did we file an issue against the ARIA spec for menu orientation?
BG: Yes.
JN: Need to make sure keyboard interaction works for all orientations, or constrain the pattern to a vertical convention.
MK: Think the first option. Would still want people to use this pattern for horizontal menus.
JN: We could have two separate patterns and/or sub-patterns for the different orientation/keyboard interactions?
MK: We could add to the table.
AA: How does the user know which orientation is being used?
JN: When support for aria-orientation is introduced, but for now through experience.
<Birkir> We leave the most efficient way to communicate orientation to the individual screen reader vendors.
BG: The pattern mentions aria-orientation on separator, which is confusing.
MK: It's required on the separator role, so has to be in the menu pattern.
BG: It's still confusing.
MK: Correction aria-orientation isn't required for separator.
<Birkir> e
MK: Need a bug about separating horizontal and vertical orientation.
<Birkir> need to look into why aria-setsize and aria-posinset are not supported properties for elements with role menuitem
BG: In the attribute list it doesn't mention aria-disabled for disabled menu items.
MK: Do we need to separate menu and menubar?
JN: Don't think so.
MK: A menubar is just a
horizontal menu, right?
... Also what is the difference between a persistently visible
menu and a menubar.
BG: I think possibly event firing.
AA: Menubars have buttons on them?
JN: Toolbars have buttons, menubars have menuitems.
MK: With Jaws once in menu mode,
don't know it makes any difference?
... Don't see there should be any difference in the way an AT
treats them.
BG: If you tab to a container with either menu or menubar there is a difference, but not if you tab to a menuitem within one of those constructs.
BirkirG: Menu is persistent, menubar isn't.
<Birkir> Oh, I got it backwards then ;) not the first time.
BG: The APG doesn't differentiate between the two.
MK: Doesn't describe menubar, or
how/when to choose between the two.
... Actually not clear to me that we need the menubar role at
all.
BirkirG: Agree. It confuses things.
MK: As a minimum we should explain when a menubar isn't a menu.
BG: Should either explain the differences or separate into different patterns, either is fine.
MK: Suggest we change the opening paragraph, and also add a definition of menubar.
JG: There is a platform API difference between the menu and menubar roles.
MK: Think a persistently visible menu should be supported.
BG: Supported, but not best
practice. If we promote persistent menus, there's a risk
developers will apply the ARIA even when the menu interaction
isn't client-side.
... There are instances where it would be ok, but my worry is
with generalising it.
MK: So a menu with a sub-menu must be able to manage focus in such a way that you can return focus to the parent menu, and navigate to a different child menu.
<Birkir> LJ: wow, that level of transcription accuracy is crazy. *grin* Just had to point it out.
MK: Don't think we should
discourage persistent menus as best practice.
... Think we need to think about this more.
JN: Not sure the pattern encourages persistent menus?
JN: Will there be a meeting next week?
<jongund> I will be on holiday next monday
MK: Think enough of us can make it, so we'll go ahead and plan to meet.
<jamesn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26377
JN: Not sure why the menu is part
of the menu button pattern. Can we remove it?
... Seems to duplicate menu behaviour description.
... Suggest we change keyboard interaction information to refer
back to the menu design pattern.
<jamesn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27811
Jn: Drop "when presenting the menu ensure it's completely visible on screen"?
BG: Yes.
JN: Will add that to the menu bug so we do it in both places at the same time.
<jamesn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27810
JN: Last bullet under k'board interaction... seems understandable but incorrect.
BirkirG: Usually a menu isn't more than 6/7 items.
JN: Plus it's already in menu, doesn't need to be in menubutton too.
BG: Yes.
JN: Has anyone come across a
hybrid menu/menubutton widget? A button section of buttons, and
a menu section of buttons.
... So a menu with menuitems and a default button action.
BG: Yes. We need a pattern to
handle this.
... There is a labelling issue for one thing.
JN: Not sure what the right
solution is - better descriptions/interaction help, or two tab
stops (one for the button and one for the menu).
... Will log a placeholder bug so we don't lose this.
BG: Call it a split button?
LW: Split button menu pattern?
<jamesn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27812
BirkirG: Will need aria-expanded on it for example.
JN: Depends on how it's implemented - we might need multiple pattern variations.
BirkirG: Essentially replacingbrowser context menu with custom menu.
BG: How does it work in Jaws with Shift f10?
JN: It isn't going to work.
... This is usually used when there is already native
focus.
LW: Should we mention this in the pattern?
JN: Yes think so.
JG: So Shift f10 opens the context menu?
JN: Yes.
... Windows touch also has a way to hold down and invoke things
like this.
... There does need to be a gesture and/or an alternative for
touch devices though.
JG: Does it always replace the browser context menu?
JN: Don't think you can support
both on a single element/object.
... No way to access/choose between different context
menus.
... If entire application had same custom context menu, the
context of the thing you're on would have no impact. That
doesn't make e it a good idea though.
BG: A user in the virtual buffer of a screen reader wouldn't have access to it.
<jongund> i need to leave a little early for another meeting
JN: What about advising that context menus should be focusable in order to provide the nescessary context to make them useful?
BG: We might want to include the alternative of adding it through the body tag too?
JN: What confuses me is that this seems to be targeted at clicking on whitespace, so where there is no focus.
BG: Apart from the triggering mechanism, the resulting menu interaction should be the same.
JN: So we can refer people back to the menu instead of replicating that guidance?
BG: Yes.
<jamesn> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27813
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) Succeeded: s/cople/couple/ Succeeded: s/COrrection/Correction/ No ScribeNick specified. Guessing ScribeNick: LJWatson Inferring Scribes: LJWatson Default Present: +1.217.244.aaaa, Jon_Gunderson, James_Nurthen, Bryan_Garaventa, Matt_King, LJWatson, +1.512.459.aabb, jemma, Ann_Abbott, +1.919.607.aacc, Birkir Present: James_Nurthen Matt_King Léonie_Watson Bryan_Garaventa Jemma_Ku Jon_Gunderson Birkir Ann_Abbot Found Date: 12 Jan 2015 Guessing minutes URL: http://www.w3.org/2015/01/12-aria-apg-minutes.html People with action items:[End of scribe.perl diagnostic output]