18:06:24 <RRSAgent> RRSAgent has joined #aria-apg
18:06:24 <RRSAgent> logging to http://www.w3.org/2016/01/25-aria-apg-irc
18:06:33 <jamesn> rrsagent, make log world
18:06:34 <MichielBijl> MichielBijl has joined #aria-apg
18:07:40 <jamesn> regrets+ Jemma Michiel Bryan
18:07:55 <IanPouncey> present+ IanPouncey
18:08:03 <jongund> present+ jongund
18:08:15 <jamesn> present+ JamesNurthen
18:08:24 <jamesn> present+ MattKing
18:08:31 <jamesn> present+ AnnAbbott
18:08:55 <jamesn> present+ CPandhi
18:09:09 <jamesn> scribe: jamesn
18:09:21 <jamesn> Meeting: ARIA APG TF
18:09:29 <jamesn> agenda?
18:09:37 <jamesn> zakim, next item
18:09:37 <Zakim> agendum 1. "Update on draft of landmark design pattern (John/Ann) https://rawgit.com/jongund/aria/master/practices/aria-practices.html#aria_landmark" taken up [from jamesn]
18:09:38 <annabbott> present+ TeresaBoers
18:09:51 <jamesn> MK: what state is this in - you sent an email
18:09:58 <jamesn> AA: not done yet but can take a look
18:10:10 <jamesn> JG: think it is greatly simplified
18:10:17 <jamesn> JG: added 2.1 and 2.2 sections
18:11:01 <jamesn> Sections 2.1 and 2.2 are "done" 2.3 is not
18:11:12 <jamesn> MK: perhaps folks should read it offline
18:11:14 <jamesn> https://rawgit.com/jongund/aria/master/practices/aria-practices.html#aria_landmark"
18:11:17 <jamesn> https://rawgit.com/jongund/aria/master/practices/aria-practices.html#aria_landmark
18:11:38 <jamesn> MK: one of things we talked about was rolling the content into example pages which demo the use of landmarks
18:11:47 <jamesn> AA: haven't started that yet
18:12:00 <jamesn> JG: interested in working on but nothing to show at this point
18:12:24 <jamesn> MK: since it is a WIP reviewing during the call may not be the most frutiful thing
18:12:45 <jamesn> JG: one question. The forms landmark. Put into APG that this is not a commonly used Landmark
18:13:11 <jamesn> JG: we were afraid that people might put a form landmark in
18:13:35 <jamesn> MK: I have never understood why we have it. Kind of like a cousin to application
18:13:49 <jamesn> AA: think it goes back to b4 ATs made big progress
18:13:53 <jamesn> q?
18:13:56 <jamesn> q+
18:14:22 <jamesn> MK: HPR revelaed form elements as they thought it was useful to the reader but no one does that any more
18:15:32 <jamesn> JN: potentially see the use in SVG or something
18:17:21 <mck> scribe: matt_king
18:17:36 <mck> IP: not sure we should discourage or promote use of form
18:17:43 <mck> aa: have to define it
18:18:09 <boerst> need to drop, due to conflict
18:18:13 <mck> jg: people see them; see form landmark, so use it because I have a form
18:18:23 <mck> iP: that's why we need to explain when to use it
18:18:41 <mck> jg: for search, we want people to use search landmark
18:18:53 <mck> jg: we need to show cases where it is useful
18:19:58 <jamesn> IP: same situation as navigation role. there are definate use cases where might want to naviagte
18:20:02 <mck> ip: I think it is similar to navigation; don't put on all linkks, but do so when it is significant
18:20:36 <mck> aa: consider login
18:21:02 <mck> jn: maybe a portal page where there is a small bit of the page for login, may be useful there
18:21:09 <jamesn> JN: some places forms may be ok.
18:21:17 <jamesn> Charu: are there any advantages?
18:21:22 <mck> cp: is there advantage of using it? we could list that?
18:22:05 <mck> aa: maybe the login example
18:22:18 <mck> jn: no disadvantage, we shouldn't steer people away
18:22:26 <mck> aa: concern people may use it for every form
18:22:40 <jamesn> scribe: jamesn
18:23:01 <jamesn> MK: if the purpose of the form role was to have a mapping for the form element
18:23:20 <jamesn> MK: then I think we should make it a structure rather than a role
18:23:31 <jamesn> MK: dont think it is mapped by any browser
18:23:58 <jamesn> MK: another possibility to avoid that is that only forms with labels are mapped - like regions
18:24:34 <jamesn> MK: could use region from an AT perspective
18:24:46 <jamesn> JN: that goes for all landmarks really
18:25:15 <jamesn> JN: i disagree that form is less important
18:25:27 <jamesn> IP: making decisions about UI - i agree
18:25:47 <jamesn> MK: rare that there is a part of a web page which is not part of main which has a form
18:26:26 <jamesn> MK: even if it was a common practice the benefit is low. get the real info from the label not the type
18:26:34 <jamesn> MK: others get info with type
18:26:48 <jamesn> IP: can put form inside navigation
18:26:56 <jamesn> IP: no point in making structural
18:27:04 <jamesn> q+
18:27:36 <jamesn> IP: dont make it structural
18:27:44 <jamesn> q-
18:29:44 <jamesn> JN: is there any evidence this is a problem
18:29:58 <jamesn> JN: aria in HTML says <form> maps to role=form
18:30:16 <jamesn> JG: sometimes have empty forms in pages
18:30:22 <jamesn> so i think that is a bug
18:31:32 <jamesn> MK: any time there is an implicit role it puts it in the tree. If has role form will be regarded as a landmark
18:31:36 <jongund> https://www.w3.org/TR/html51/semantics.html#the-form-element
18:31:44 <jamesn> MK: exposing it is a decision of the screen reader.
18:32:40 <jamesn> JN: search is now allowed on form elements
18:34:20 <jamesn> MK: form is a landmark. unless we make a spec change need authoring guidance
18:34:51 <jamesn> JG: would a login form be an appropriate use of form
18:35:28 <jamesn> CP: looking at html spec. the form element had default saemantic as role=form. search and presentation are allowed
18:35:55 <jongund> 	https://www.w3.org/TR/html51/semantics.html#the-form-element
18:36:49 <cpandhi> https://www.w3.org/TR/html-aria/#index-aria-search
18:37:43 <jamesn> q+
18:37:52 <cpandhi> https://www.w3.org/TR/html-aria/#docconformance
18:38:11 <jamesn> JG: primary content of authentication page is username and password
18:40:19 <jamesn> ARIA in HTML is a [HTML51] specification module. Any HTML features, conformance requirements, or terms that this specification module makes reference to, but does not explicitly define, are defined in the [HTML51] specification.
18:40:56 <jamesn> JN: is a rec track document
18:41:53 <jamesn> JN: very confusing documents
18:42:07 <jemma> jemma has joined #aria-apg
18:42:13 <jamesn> MK: wish we could fold "using aria in HTML" into the APG
18:42:46 <jemma> present+ JaEunJemmaku
18:44:08 <jamesn> MK: we should request a change.
18:44:17 <jamesn> JG: seemed to agree that was a good idea at the time
18:45:07 <jamesn> MK: from a perspective of minimizing role bloat - don't see a lot of value in the form role. Less to write abotu etc.
18:45:23 <jamesn> MK: wondering if should propose deprecating it in aria 1.1
18:45:56 <jamesn> JN: epub wants to get more specific on things
18:46:09 <jamesn> IP: for screen readers has no value unless used for navigation
18:46:21 <jamesn> IP: however, there could be future cases where it is useful
18:46:52 <jamesn> JN: what harm does it do if someone puts it in?
18:47:08 <jamesn> JG: perhaps describe as a specifialized region
18:47:27 <jamesn> JG: agree that the label on the form is more important than that there is a form there
18:47:34 <jamesn> MK: harm is overuse
18:47:56 <jamesn> MK: if used judiciously then it is not worth having region and form in my mind
18:48:18 <jamesn> MK: for 1 thing - in addition to dont use role form where there is an html form
18:48:49 <jamesn> MK: if a child of another region and the majority of the region is the form then don't use it
18:49:05 <jamesn> q+
18:50:08 <jamesn> JN: should state that form elements do NOT have to be children of form role
18:50:09 <jamesn> q-
18:51:56 <jamesn> JN: good uses bank sites have login regions etc.
18:52:25 <jamesn> example here - https://www.bankofamerica.com/
18:52:53 <jamesn> ARIA in HTML - https://www.w3.org/TR/html-aria/
18:52:55 <mck> https://www.w3.org/TR/html-aria/#docconformance
18:53:24 <jamesn> zakim, next item
18:53:24 <Zakim> agendum 3. "Update pattern work assignments and status https://github.com/w3c/aria/wiki/Aria-Authoring-Practices-Patterns-Status" taken up [from jamesn]
18:53:57 <jamesn> zakim, take up item 2
18:53:57 <Zakim> agendum 2. "Discuss example development work in progress" taken up [from jamesn]
18:54:36 <jamesn> JG: will have menu bar update next week
18:55:38 <jemma> https://rawgit.com/jongund/oaa-examples/master/examples/menu-button/menu-button-1.html
18:56:15 <jamesn> JG: Is a menu button that links to other pages ok?
18:56:54 <jamesn> JN: a favourites menu would navigate to them
18:57:17 <jamesn> MK: if the links are persistant on the page - would not turn them into menu items.
18:57:44 <jamesn> MK: no one would be aware that could do other stuff. lose all the other semantics if you put it in a menu
18:57:58 <jamesn> just a set of links - dont put them in a menu bar
18:58:14 <jamesn> rather see them just in a navigation structure
19:00:24 <jamesn> JG: grid - was that for mega menus
19:00:43 <jamesn> MK: the element which opens the mega menu would move focus within it'
19:01:15 <jamesn> JG: would you constarin within megamenu until you close it
19:01:26 <jamesn> MK; yes or select something
19:02:40 <jamesn> JK: it opens the menu
19:02:52 <jamesn> JN: but focus doesnt move to the menu items
19:03:25 <jamesn> JN: you mean focus should move to the first item
19:03:30 <jamesn> JN: yes
19:04:05 <jamesn> MK: if tab to it and force jaws into forms mode then will track it - but if just press enter then it is as if the button did nothing as the focus didnt move
19:04:15 <jamesn> MK: good use of menu button Jon
19:04:31 <jamesn> JG: when you open a menu button focus should move to the 1st menu item?
19:04:33 <jamesn> MK: yes
19:04:51 <jamesn> AA: and esc should close
19:04:54 <jamesn> JK: it does
19:05:17 <jamesn> JG: should break the keyboard stuff up - for the menu and for the button
19:05:27 <jamesn> JG: also have someone working on combo box
19:05:35 <jamesn> JG: was close last week
19:05:47 <jamesn> MK: can add both to next weeks agenda
19:05:58 <jamesn> MK: probably a few more weeks on landmarks?
19:06:00 <jamesn> AA: probably
19:08:34 <jamesn> MK: combobox is 1 of the roles i'm working on for the spec
19:09:15 <jamesn> MK: there may be some things that dont quite work well yet. not going to disallow aria-owns. going to recommend aria-controls instead of owns.
19:10:47 <jamesn> zakim, next item
19:10:47 <Zakim> agendum 3. "Update pattern work assignments and status https://github.com/w3c/aria/wiki/Aria-Authoring-Practices-Patterns-Status" taken up [from jamesn]
19:10:54 <jamesn> zakim, take up item 4
19:10:54 <Zakim> agendum 4. "Review text of section 2.32 Tool Bar http://www.w3.org/TR/wai-aria-practices-1.1/#toolbar" taken up [from jamesn]
19:11:01 <jamesn> zakim, close item 3
19:11:01 <Zakim> agendum 3, Update pattern work assignments and status https://github.com/w3c/aria/wiki/Aria-Authoring-Practices-Patterns-Status, closed
19:11:03 <Zakim> I see 1 item remaining on the agenda:
19:11:03 <Zakim> 4. Review text of section 2.32 Tool Bar http://www.w3.org/TR/wai-aria-practices-1.1/#toolbar [from jamesn]
19:11:12 <jamesn> zakim, take up item 4
19:11:12 <Zakim> agendum 4. "Review text of section 2.32 Tool Bar http://www.w3.org/TR/wai-aria-practices-1.1/#toolbar" taken up [from jamesn]
19:12:29 <jamesn> http://w3c.github.io/aria/practices/aria-practices.html#toolbar
19:12:56 <jamesn> MK: in 1st para makes assumptions that there is a menu bar and it is a subset
19:13:04 <jamesn> MK: not sure that is true any more
19:14:12 <jamesn> MK: the assumption it manages focus is more of a practice
19:14:47 <jamesn> MK: not consistent
19:15:11 <jamesn> VO collapses toolbars and have to interact with them
19:16:01 <jamesn> Spec: "Authors may manage focus of descendants for all instances of this role, as described in Managing Focus."
19:16:52 <jamesn> "A collection of commonly used function buttons or controls represented in compact visual form."
19:19:58 <jamesn> Apple Definition (from OSX) - A toolbar (which is often combined with a title bar) gives users convenient access to the most frequently used commands and features in an app.
19:20:45 <jamesn> Oracle (ADF rich client) - Toolbars group iconic and textual commands which act on objects on a page or within a component (Tables, TreeTables and Trees). Toolbars contain at least one button along with optional separators, standard web widgets and overflow lists.
19:25:23 <jamesn> like here http://www.oracle.com/webfolder/technetwork/jet/uiComponents-toolbar-toolbarPattern.html
19:25:48 <jamesn> JK: what is the distinction between menu button and toolbar?
19:25:57 <jamesn> JN: can have a menu button in a toolbar
19:26:13 <jamesn> MK: will reduce description to 2 sentences from 3 paragraphs :)
19:27:23 <jamesn> MK: group info seems useless
19:27:33 <jamesn> JN: would agree with removing that
19:30:38 <jamesn> MK: RTL stuff? do we remove?
19:30:57 <jamesn> JN: I think we should have something general abotu all patterns which include left and right arrows
19:31:02 <jamesn> THE HOUR
19:31:11 <jamesn> OR 90 MINS
19:35:29 <jamesn> will pick up with the toolbars
19:35:46 <jamesn> rrsagent, make minutes
19:35:46 <RRSAgent> I have made the request to generate http://www.w3.org/2016/01/25-aria-apg-minutes.html jamesn
19:37:15 <mck> 29391 – Pattern-toolbar
19:37:16 <mck> https://www.w3.org/Bugs/Public/show_bug.cgi?id=29391
20:03:55 <trackbot> trackbot has joined #aria-apg
21:04:50 <jongund> jongund has joined #aria-apg
21:55:06 <jongund> jongund has joined #aria-apg
23:19:43 <MichielBijl> I have added EditorConfig support to the Guide