- From: Michiel Bijl <michiel@agosto.nl>
- Date: Mon, 15 Feb 2016 20:34:56 +0100
- To: ARIA Working Group <public-aria@w3.org>
- Message-Id: <65DC2302-76D4-401B-836D-5BFE222712CD@agosto.nl>
Today’s minutes can be found as text in this e-mail and at this URL: https://www.w3.org/2016/02/15-aria-apg-minutes.html <https://www.w3.org/2016/02/15-aria-apg-minutes.html>
—Michiel
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WAI-PF ARIA Authoring Practices Guide Taskforce
15 Feb 2016
See also: [2]IRC log
[2] http://www.w3.org/2016/02/15-aria-apg-irc
Attendees
Present
AnnAbbott, Bryan_Garaventa, CharuPandhi, JamesNurthen,
JonGunderson, MattKing, MichielBijl, jemma, jongund,
Birkir
Regrets
Chair
SV_MEETING_CHAIR
Scribe
MichielBijl
Contents
* [3]Topics
1. [4]Continue review text of section "2.32 Tool Bar" in
the keyboard interaction notes
http://www.w3.org/TR/wai-aria-practices-1.1/#toolbar
2. [5]Review text of section 2.18 listbox
https://rawgit.com/w3c/aria/master/practices/aria-prac
tices.html#Listbox
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<jamesn>
[8]https://mit.webex.com/mit/j.php?MTID=m71a4dbc9d1dd947b1ad8ee
cfa8f1d0ff
[8] https://mit.webex.com/mit/j.php?MTID=m71a4dbc9d1dd947b1ad8eecfa8f1d0ff
[9]https://github.com/ncjones/editorconfig-eclipse#readme
[9] https://github.com/ncjones/editorconfig-eclipse#readme
<scribe> scribe: MichielBijl
<jemma>
[10]https://github.com/w3c/aria/#generating-editors-drafts
[10] https://github.com/w3c/aria/#generating-editors-drafts
<jamesn> rragent, make minutes
Continue review text of section "2.32 Tool Bar" in the keyboard
interaction notes
[11]http://www.w3.org/TR/wai-aria-practices-1.1/#toolbar
[11] http://www.w3.org/TR/wai-aria-practices-1.1/#toolbar
<jemma> "ungraceful shut down." ;-)
<jamesn>
[12]https://www.w3.org/Bugs/Public/show_bug.cgi?id=29391
[12] https://www.w3.org/Bugs/Public/show_bug.cgi?id=29391
MK: Went to the description
<jamesn> Rewrite description to be more inline with spec;
remove compact visual form language.
<jamesn> Delete references to menu/menubar.
<jamesn> delete sentence about using role group for a bunch of
toolbars.
<jamesn> In keyboard interaction, remove:
<jamesn> "Direction may need to be adjusted for Right to Left
languages "
MK: Left off at keyboard interaction
... James do you want to review?
... Any other changes that need to be logged?
JN: You can put any sort of controls in toolbars, correct?
MK: Yes, that does mean you can put in inputs that capture
left/right arrows.
JN: Current advice to developers, a) do it, but make it so you
can tab in/out of the input. b) make the input its own toolbar
... Possibly a problem for AT switching navigation mode while
tabbing between input/toolbar
BG: What is the problem?
MK: Application toolbars that don't allow for keyboard
navigation are a real pain to use.
MB: Is this a pattern seen on Windows? Mac doesn't do this for
toolbars.
JN/MK: OS X not designed for keyboard use.
MK: we need to word smith this into the description: “some
elements in the toolbar may consume left and right arrow keys”
... What do people think of this note:
provide a documented keystroke that allows users to move focus
quickly to the tool bar from elsewhere within the web
application, placing focus on a tool within the tool bar.
MK: CKEdit uses F10 to move to editor toolbar.
JN: Change to “should consider to provide…”
... If there is a main toolbar, it is good to have a keystroke
to move to that, but not if you have a gazillion toolbars.
MK: Or move to context dependent toolbar.
*James typing loudly*
MK: What to do with: There is debate concerning the treatment
of disabled toolbar buttons -- should they be focusable or not?
JN: Agree/disagree some of the time; depends.
... Annoying if one button is enabled and 10 are disabled
MK: Agree with James
... What do others think?
BG: I don't think they should be focusable
MK: We should remove the words “there is debate”
MB: Can't we just remove everything except for “Disabled
buttons are not focusable until they are enabled.”?
JN: Don't think Ribbons are the right place to look for
toolbars.
... Look like menu's on the top level
... Would like to see that our recommendation would be
something like: not focusable by default, but there are
specific cases where they should be.
MK: Then we should include at least some examples of those
specific cases.
... Include the rational
BG: And change buttons to elements?
All: yes.
MK: In general disabled elements are not included in the focus
sequence, however there maybe some circumstances where
discoverability of a function is crucial.
CP: Does it make sense to make them read only?
<jamesn> "In general disabled elements are not included in the
focus sequence but there may be some circumstances where
discoverability of a function is crucial and an author may
choose to include in the navigation sequence."
MK: No.
JN: You can't have read-only radiobuttons or checkboxes
MK: Delete middle two bullets under states and properties.
AA: Remove line “too few or too many”
*all agree*
MK: Unsure about aria-label
JN: Only if there is more than one.
AA: Could have a visual label that labels something else
MK: I've done that
AA: aria-label if more than one toolbar, and if no visual label
... and could do aria-labelledby if there is a visual label
JN: Is it helpful for toolbars being labelled.
MK: Depends on the buttons/elements inside being labelled
... I find them helpful
JN: So let's leave the recommendation in
MB: You can still label the toolbar if there is only one; I
label my nav's like main nav even if there is only one
MK: Yeah
<jamesn> MB: what do we do in other places about labelling
<jamesn> JN: labelling techniques are the same everywhere
<jamesn> AA: I don't think it hurts to call out aria-label or
aria-labelledby
<jamesn> MK: I don't think there is a referencable section on
that
<jamesn> Birkir: something about labelling widgets would be
really useful
<jamesn> Birkir - techically they could use title
<jamesn> JN: yep
<jamesn> MK: wouldn't recommend that
<jamesn> JN: why
JN: Why should I have to label it twice?
<Birkir> title is a source of accessible name (the last
fallback admittedly).
MK: That's a worthy issue being addressed
JN: It's like suggesting longdesc in our document
... “warning: this is the last fallback!”
MK: I would never put title as a best practice
... We circle back around to thinking not recommending title
... Should only be done by people totally in the know
CP: Maybe makes sense if you know what you're doing
AA: Title is not part of APG/ARIA, we can leave it out
Birkir: good point
<jemma> I agree with annabbott about title
Review text of section 2.18 listbox
[13]https://rawgit.com/w3c/aria/master/practices/aria-practices.html#
Listbox
[13] https://rawgit.com/w3c/aria/master/practices/aria-practices.html#Listbox
[14]http://w3c.github.io/aria/practices/aria-practices.html#Lis
tbox
[14] http://w3c.github.io/aria/practices/aria-practices.html#Listbox
MK: Have done some edits
... ARIA doesn't include a definition of “static”
... So I made up wording for it
A listbox widget allows a user to select one or more items from
a list of choices or options. A listbox that allows a single
option to be chosen is a single-select listbox; one that allows
multiple options to be selected is a multi-select listbox.
JN: We have child stuff as the option
MK: Open that in a dialog
JN: No you focus into the child option
MK: You're going to have a screen reader issue
... You can tab around in it, but content in it is invisible
JN: No, if you go in it, you can arrow around in it.
MK: Must not be contained in an option elements
JN: Let me check that
MB: Should we drop “choices” from the first line?
MK: Was an editorial thing
AA: Think we can lose “choices”
JN: Will make a bug
*discussing the weather around the globe*
MK: Conclusion: we will remove choices
MB: Should everything after second sentence be a note?
Birkir: the one that starts with “This is because?”
MB: yes
... Good information, but adds more text
MK: Okay with removing it
... Let's move to the third paragraph
Birkir: explanation should be last
MK: Good point
... Instruction should be before explanantion
... Let's move to last/fourth paragraph
JN: Seems like a general problem
... (not SR specific)
MK: I found it important enough to include
JN: I would argue you don't want repeated start strings for
anyone
<jamesn>
[15]https://www.w3.org/Bugs/Public/show_bug.cgi?id=29469
[15] https://www.w3.org/Bugs/Public/show_bug.cgi?id=29469
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [16]scribe.perl version
1.144 ([17]CVS log)
$Date: 2016/02/15 19:32:30 $
__________________________________________________________
[16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[17] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34
Check for newer version at [18]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/make it/make the input/
Succeeded: s/to toolbar//
Succeeded: s/disabled/focusable/
Succeeded: s/worthy/worthy issue being/
Found Scribe: MichielBijl
Inferring ScribeNick: MichielBijl
Present: AnnAbbott Bryan_Garaventa CharuPandhi JamesNurthen JonGunderson
MattKing MichielBijl jemma jongund Birkir
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Got date from IRC log name: 15 Feb 2016
Guessing minutes URL: [19]http://www.w3.org/2016/02/15-aria-apg-minutes.
html
People with action items:
[19] http://www.w3.org/2016/02/15-aria-apg-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of [20]scribe.perl diagnostic output]
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Monday, 15 February 2016 19:35:28 UTC