See also: IRC log
<scribe> scribe: jamesn
https://rawgit.com/a11ydoer/practices/master/examples/checkbox/checkbox-3.html
JN: this has the changes we talked about last week?
JK: yes
MK: maybe should say how the
group semantics are being exposed
... then have a consistent way of saying what you are doing
across all 3
... group semantics for the set of checkboxes are exposed to
screen readers...
... 1) Using fieldset containing the set, labelled by a
legend
... 2) using an aria group with a label on the group,
containing the checkoxes
... 3) using aria-labelledby on each checkbox to refer to its
own label as well as the label for the set
JN: I like what is written already about the grouping label
JG: 3rd example the group label is defined in the checkbox label
MK: interesting to me that all condiments is inside the group
JG: think it should be
MK: with virtual cursor jaws
exposes the group
... with tab it doesn't
JG: the first 2 the screen reader
decides when to announce
... the 3rd we force it
... still a label but doesn't effect APIs for No 3
... maybe that needs to be a little more tweaked
MK: everything looks good w/ JAWS
JK: what would we say for No 3
MK: delete 1st bullet
... 2nd needs to be more explicitly worded
... trying to figure out how to refer to the different parts of
the label
JG: maybe talk about that at the beginning
JN: big improvement over what we had previously
JG: need a big discussion over
non-interactive roles
... talk nexy monday
MK: some editorial things that need fixing
JN: tab and shift tab should allow moving to address bar before going bACK TO THE top/bottom of the dialog
MK: justification for this is
weak IMO
... don't feel that that is an actual justification
... staying in context, especially for a screen reader or
magnifier user is strong
... enter key should not always be the case
remove - if the purpose of the dialog is to gather information
click behaviours outside the dialog. Should we be addressing this in APG?
should we remove the line "Even if the user clicks outside of the dialog on the application which invoked the dialog, focus remains in the dialog. "
MK: is this just a design
choice?
... should this just be deleted?
MB: to me it is the same as the
escape keyt
... I think we can mention it - to me it is the same kind of
thing as the escape key to close the dialog
MK: I am wondering if it is somethign the APG should be talking about at all
JN: moving to me depends on why the move is available.
MK: our guidance and notes needs to be understandable why it is there in relation to a11y
<jongund> OK with me
JN: anyone disagree with removing the thing about mouse moving the dialog
MK: from a best practices
standpoint it seems we should scratch the part about what to do
when the dialog has no focusable item
... also nothing about large dialogs which may involve
scrolling
JN: classic example would be a license agreement
MB: clicking outside a modal
equals wanting to close it
... many lightboxes do this
JN: very much disagree - many
dialogs require entry
... but think there are 2 types of dialogs. for lighboxzes i
agree
MK: think this is a general UX
issue
... not sure whether clicking outside the dialog is a severe
accessibility issue.
... think the APG should be silent on the matter
... last bullet seems to be not useful
JN: "make sure your interface works"
MK: remove last bullet
... do we want the extra alertfialog stuff in the roles and
properties section
... add aria-desribedby in the roles states and properties
section
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) Succeeded: s/MB: I am/MK: I am/ Succeeded: s/mullet/bullet/ Found Scribe: jamesn Inferring ScribeNick: jamesn Present: Jaeun_Jemma_Ku James Jon Matt Michiel_Bijl Got date from IRC log name: 23 Nov 2015 Guessing minutes URL: http://www.w3.org/2015/11/23-aria-apg-minutes.html People with action items:[End of scribe.perl diagnostic output]