See also: IRC log
<jamesn> scribe: jamesn
MK: what state is this in - you sent an email
AA: not done yet but can take a look
JG: think it is greatly
simplified
... added 2.1 and 2.2 sections
Sections 2.1 and 2.2 are "done" 2.3 is not
MK: perhaps folks should read it offline
https://rawgit.com/jongund/aria/master/practices/aria-practices.html#aria_landmark"
https://rawgit.com/jongund/aria/master/practices/aria-practices.html#aria_landmark
MK: one of things we talked about was rolling the content into example pages which demo the use of landmarks
AA: haven't started that yet
JG: interested in working on but nothing to show at this point
MK: since it is a WIP reviewing during the call may not be the most frutiful thing
JG: one question. The forms
landmark. Put into APG that this is not a commonly used
Landmark
... we were afraid that people might put a form landmark in
MK: I have never understood why we have it. Kind of like a cousin to application
AA: think it goes back to b4 ATs made big progress
MK: HPR revelaed form elements as they thought it was useful to the reader but no one does that any more
JN: potentially see the use in SVG or something
<mck> scribe: matt_king
<mck> IP: not sure we should discourage or promote use of form
<mck> aa: have to define it
<boerst> need to drop, due to conflict
<mck> jg: people see them; see form landmark, so use it because I have a form
<mck> iP: that's why we need to explain when to use it
<mck> jg: for search, we want people to use search landmark
<mck> jg: we need to show cases where it is useful
IP: same situation as navigation role. there are definate use cases where might want to naviagte
<mck> ip: I think it is similar to navigation; don't put on all linkks, but do so when it is significant
<mck> aa: consider login
<mck> jn: maybe a portal page where there is a small bit of the page for login, may be useful there
JN: some places forms may be ok.
Charu: are there any advantages?
<mck> cp: is there advantage of using it? we could list that?
<mck> aa: maybe the login example
<mck> jn: no disadvantage, we shouldn't steer people away
<mck> aa: concern people may use it for every form
<scribe> scribe: jamesn
MK: if the purpose of the form
role was to have a mapping for the form element
... then I think we should make it a structure rather than a
role
... dont think it is mapped by any browser
... another possibility to avoid that is that only forms with
labels are mapped - like regions
... could use region from an AT perspective
JN: that goes for all landmarks
really
... i disagree that form is less important
IP: making decisions about UI - i agree
MK: rare that there is a part of
a web page which is not part of main which has a form
... even if it was a common practice the benefit is low. get
the real info from the label not the type
... others get info with type
IP: can put form inside
navigation
... no point in making structural
... dont make it structural
JN: is there any evidence this is
a problem
... aria in HTML says <form> maps to role=form
JG: sometimes have empty forms in pages
so i think that is a bug
MK: any time there is an implicit role it puts it in the tree. If has role form will be regarded as a landmark
<jongund> https://www.w3.org/TR/html51/semantics.html#the-form-element
MK: exposing it is a decision of the screen reader.
JN: search is now allowed on form elements
MK: form is a landmark. unless we make a spec change need authoring guidance
JG: would a login form be an appropriate use of form
CP: looking at html spec. the form element had default saemantic as role=form. search and presentation are allowed
<jongund> https://www.w3.org/TR/html51/semantics.html#the-form-element
<cpandhi> https://www.w3.org/TR/html-aria/#index-aria-search
<cpandhi> https://www.w3.org/TR/html-aria/#docconformance
JG: primary content of authentication page is username and password
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.
JN: is a rec track document
... very confusing documents
MK: wish we could fold "using
aria in HTML" into the APG
... we should request a change.
JG: seemed to agree that was a good idea at the time
MK: from a perspective of
minimizing role bloat - don't see a lot of value in the form
role. Less to write abotu etc.
... wondering if should propose deprecating it in aria 1.1
JN: epub wants to get more specific on things
IP: for screen readers has no
value unless used for navigation
... however, there could be future cases where it is useful
JN: what harm does it do if someone puts it in?
JG: perhaps describe as a
specifialized region
... agree that the label on the form is more important than
that there is a form there
MK: harm is overuse
... if used judiciously then it is not worth having region and
form in my mind
... for 1 thing - in addition to dont use role form where there
is an html form
... if a child of another region and the majority of the region
is the form then don't use it
JN: should state that form
elements do NOT have to be children of form role
... good uses bank sites have login regions etc.
example here - https://www.bankofamerica.com/
ARIA in HTML - https://www.w3.org/TR/html-aria/
<mck> https://www.w3.org/TR/html-aria/#docconformance
JG: will have menu bar update next week
<jemma> https://rawgit.com/jongund/oaa-examples/master/examples/menu-button/menu-button-1.html
JG: Is a menu button that links to other pages ok?
JN: a favourites menu would navigate to them
MK: if the links are persistant
on the page - would not turn them into menu items.
... no one would be aware that could do other stuff. lose all
the other semantics if you put it in a menu
just a set of links - dont put them in a menu bar
rather see them just in a navigation structure
JG: grid - was that for mega menus
MK: the element which opens the mega menu would move focus within it'
JG: would you constarin within megamenu until you close it
MK; yes or select something
JK: it opens the menu
JN: but focus doesnt move to the
menu items
... you mean focus should move to the first item
... yes
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
... good use of menu button Jon
JG: when you open a menu button focus should move to the 1st menu item?
MK: yes
AA: and esc should close
JK: it does
JG: should break the keyboard
stuff up - for the menu and for the button
... also have someone working on combo box
... was close last week
MK: can add both to next weeks
agenda
... probably a few more weeks on landmarks?
AA: probably
MK: combobox is 1 of the roles
i'm working on for the spec
... 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.
http://w3c.github.io/aria/practices/aria-practices.html#toolbar
MK: in 1st para makes assumptions
that there is a menu bar and it is a subset
... not sure that is true any more
... the assumption it manages focus is more of a practice
... not consistent
VO collapses toolbars and have to interact with them
Spec: "Authors may manage focus of descendants for all instances of this role, as described in Managing Focus."
"A collection of commonly used function buttons or controls represented in compact visual form."
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.
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.
like here http://www.oracle.com/webfolder/technetwork/jet/uiComponents-toolbar-toolbarPattern.html
JK: what is the distinction between menu button and toolbar?
JN: can have a menu button in a toolbar
MK: will reduce description to 2
sentences from 3 paragraphs :)
... group info seems useless
JN: would agree with removing that
MK: RTL stuff? do we remove?
JN: I think we should have something general abotu all patterns which include left and right arrows
THE HOUR
OR 90 MINS
will pick up with the toolbars
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: jamesn Inferring ScribeNick: jamesn Found Scribe: matt_king Found Scribe: jamesn Inferring ScribeNick: jamesn Scribes: jamesn, matt_king Present: IanPouncey jongund JamesNurthen MattKing AnnAbbott CPandhi TeresaBoers JaEunJemmaku Regrets: Jemma Michiel Bryan WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 25 Jan 2016 Guessing minutes URL: http://www.w3.org/2016/01/25-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]