W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

Minutes for Monday, 15 February 2016 WAI-PF ARIA Authoring Practices Guide Taskforce

From: Michiel Bijl <michiel@agosto.nl>
Date: Mon, 15 Feb 2016 20:34:56 +0100
Message-Id: <65DC2302-76D4-401B-836D-5BFE222712CD@agosto.nl>
To: ARIA Working Group <public-aria@w3.org>
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>



      [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


          AnnAbbott, Bryan_Garaventa, CharuPandhi, JamesNurthen,
          JonGunderson, MattKing, MichielBijl, jemma, jongund,




     * [3]Topics
         1. [4]Continue review text of section "2.32 Tool Bar" in
            the keyboard interaction notes
         2. [5]Review text of section 2.18 listbox
     * [6]Summary of Action Items
     * [7]Summary of Resolutions


      [8] https://mit.webex.com/mit/j.php?MTID=m71a4dbc9d1dd947b1ad8eecfa8f1d0ff


      [9] https://github.com/ncjones/editorconfig-eclipse#readme

   <scribe> scribe: MichielBijl


     [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

   <jemma> "ungraceful shut down." ;-)


     [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

   <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

   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
   ... 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

   <jamesn> MK: I don't think there is a referencable section on

   <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


     [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


     [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/

     [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.
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

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:19 UTC