See also: IRC log
<jamesn> Updates resolve bugs:
<jamesn> 28085 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28085
<jamesn> 29469 https://www.w3.org/Bugs/Public/show_bug.cgi?id=29469
<jamesn> https://rawgit.com/w3c/aria-practices/master/aria-practices.html#tabpanel
<jamesn> Updates resolve bug 29303 https://www.w3.org/Bugs/Public/show_bug.cgi?id=29303#c0
<jongund> what is our host room ID?
<jamesn> 646 444 732
<jongund> what is the password
<scribe> scribe: Birkir
JN: Never put our sacred password in a comment, us /me space to do it via a comment.
<jamesn> Updates resolve bugs:
<jamesn> 28085 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28085
<jamesn> 29469 https://www.w3.org/Bugs/Public/show_bug.cgi?id=29469
MK: A lot of changes were made, we need to go through this top to bottom.
MK *grumbles about Jaws*
MK: Looking at the second
paragraph, need to look at whether children presentational is
still in ARIA 1.1 draft.
... We aim for simpler language in this paragraph.
JN: How are paragraphs 2 and 3 different?
MK: 2nd paragraph talks about
loss of structure, the third talks about not having long text
in options (we may apply this best practice to other widgets
e.g. menu).
... We might want to create a separate general best practices
section that we could link to, for future.
AA: How does the browser treat images in options, since it treats the option as flat text.
MK: Treats image text alternative as part of the option string, without announcing the role.
JN: Should we remove the first sentence from paragraph 2 (we don't need the term "static" introduced).
MK: The concept "static" is not dfined in the spec.
MK/JN: start paragraph with "the contents of option elements..."
AA: Mention the things with images in options?
JN: Generally I find taht if you have more than two children of an element like optoin, you might as well put an aria-label on it to control how it is read.
BG: Should we change the language of paragraphs 3 and 4 to 'authors should" rather than "should not".
MK: Dificult to phrase it in an
'authors should" way.
... Perhaps change it in paragraph 4.
Joint decision to leave paragraphs 3 and 4 as is.
MK: Deleted bullet about tab key in keybord interaction, we should avoid talking about the tab key unless it does something inside the widget.
AA: Changet he sub tbllet of list one "optionally an option" ? REmvoe the word "optionally"?
JN: The (optional) keyword may be confusing e.g. the "home and end" key section (are both optional, or just the end key)?
MK: Changed sentence to "author may choose to have the first option selected".
JN: Who is the mystery call-in user.
BG2: It is Bryan.
<bgaraventa1979> incognito
MK: Discuss combining the
multiple selection models. Hard to write it in a way that came
across clerly.
... Changed the headings to "recommended model" and
"alterantive model".
... Tried to order keyboard shortcuts from most important to
less important.
JN: "unselect all" keystroke missing for multiple select mode.
MK: WAs told to remove it, we may want to provie a link or button to achieve that purpose.
AA: Under recommended selection model, the o in "optional" should be capitalized.
<jamesn> http://www.oracle.com/webfolder/technetwork/jet/uiComponents-select-multi.html
After checking other entries we collective decide to capitalize the "o" in "Optional".
MK: Should we add a note at the end?
Consensus, yes.
Birkir: Why do we have the alterantive select model.
MK: Firefox implements this
keybaord behavior automatically for a multi-select
listbox.
... Item for self, make a note about difference between focus
and selection. Ditto about active descandants.
... Add a note to the end of this section saying something
along the lines of: "Authors should provide a control that
allows user to de-select all options in a multi-select
listbox).
AA: Make ti a third bullet, after alterantive selection model.
Birkir: Should we add a note about only doing this for large listboxes, (clutters up the UI by adding two focusble controls, select and de-select, for each listbox element).
<jemma_> is this the link? https://www.w3.org/TR/wai-aria-practices-1.1/#Listbox
<jemma_> refreshed doc
sakim, next item
<jamesn> https://rawgit.com/w3c/aria-practices/listbox/aria-practices.html#Listbox
MK: Changed first sentence to
inclue a link. Used the word "boundry" to avoid
repetition.
... Editorial item, include a sentence that explains what a
window splitter does.
JN: Jaws/NVDA do not switch modes when tabbing to a separator.
MK: What does a separator map to,
horizontal rule?
... Does anything in html map to the separator role? <hr>
maps to separator.
... So what do we do with a window splitter?
JG: Is it a slider?
MK: What we could do (do not puke) is to use the application role ....
'JN: A popular way around this is a splitter with a child button.
MK: Button does not trigger interactive mode.
<jemma_> +q
JN: Do screen readers need window splitter?
MK: In some cases yes, e.g. when maximizing a window.
Bryan: I have never seen display none applied to content.this type of collapsed
JN: Looks like we don't have a good role for this, separator is static.
MK: Use combination of application and role description role. Would be a sensible use of the application role (note from scribe, the first?)
Bryan: It is not going to work on touch-screen devices.
Birkir: Isn't touch-screen APG primarily an ARIA 2.0 item?
MK: It kind of is, e.g. hard to describe touch-screen interaction for listboxes and trees.
JG: Do we really need this section?
MK: We could, but if we are going to reserve it, we need to come up with a solution.
<jemma_> +q
MK: Important for sighted screen
reader users.
... Need to be able to press arrow key until content is
expanded or collapsed. Screen reader only users may not need to
know this at all.
<jemma_> vote for drop
<jamesn> http://jdevadf.oracle.com/adf-richclient-demo/faces/index.jspx
JN: Goes looking for an example.
<jongund> https://jsfiddle.net/
JG: Fiddle.net has it (code in one payne, results in another).
<jemma_> https://rawgit.com/jongund/oaa-examples/master/examples/treeview/treeview-1.html
MK: The fact we quickly found a few examples shows us this is used. This is a prime candidate for a creating a custom widget using ARIA.
Jemma: Want to ask a question about trees.
MK/JN: Work on a better window splitter example, take it back to the group.
AA: Spec discusses a visible separator, e.g. between groups of menu items or as a movable separator between two regions in a split payne. This indicates a spec problem. A static element should not be an operable element.
rsagent, make minutes
rrsagent make minutes
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: Birkir Inferring ScribeNick: Birkir Present: jaeunjemmaku JamesNurthen Michiel_Bijl jongund Bryan_Garaventa JaEunKu Regrets: Leonie WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 02 May 2016 Guessing minutes URL: http://www.w3.org/2016/05/02-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]