<jamesn> no
<scribe> scribe: Mark_McCarthy
CFC is out, approve by Friday 6pm Boston
JN: need certain number of reps
to approve CFC, if not could create problems
... we're about halfway there, if you haven't had a rep
approve, try to have them look at it
Joanie: Matt is now working with an automated testing colleague
Matt: Will work on getting items forwarded to AC Rep
Janina: APA would appreciate votes
JN: Will send survey links to Matt
JN: If you're coming, register by July 31 or price goes up
JN: Planning on meeting next weeks through summer, unless there's a week where many aren't available
<jamesn> https://github.com/w3c/aria/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+created%3A%3E%3D2018-06-28+
<jamesn> https://github.com/w3c/aria/issues/788
JN: 2 issues since last meeting, 788 about specifying an activation point on a large object (like a slider)
<jamesn> https://github.com/w3c/aria/issues/787
JN: issue 787 regarding unclear
specification for default values
... propose targeting for 1.2 milestone
joanie: +1
<jamesn> * Clarify whether alt attribute is valid alternative text for role="img”
<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/785/8b9d3c5...carmacleod:d6521d5.html
JN: in my opinion, if image is
decorative, don't label as such
... aria-label="" would be ignored as if it wasn't there
Matt: in order for it to be perceivable, there's no other option, so i'm okay with it
JN: no objections to merging pr
joanie: merging pr into stable
<jamesn> Allows menuitems and menuitemcheckbox to have group parents.
<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/784/8b9d3c5...bb80ff8.html
JN: allows the above to have
group pairings like radio buttons do
... prev incosistencies to specification, but want to discuss
whether people think this is the right direction
... if people want more time to look through the diff, we can
do that.
Matt: we can step through
JN: instead of saying menu items are owned by menu or menubar, authors must ensure items owned by a menu OR group element below
Matt: yeah that makes sense.
JN: in order to get this issue through to stable, we'll need to create APG examples
Matt: we don't have to show
everything allowed by the spec, but we have to update the
pattern
... we have in the menubar some checboxes, but I don't remember
if they have groups
JN: we should add it even if we don't have to, better for AT
Matt: we could talk about
labelling of groups in testing of APG
... when things are grouped in a menu, what should calculation
of pause and set be?
joanie: I remember that discussion, but don't remember if I filed an issue or made a change. I'll look around and see what we did
MK: I think it might not be
related to this pr, i'll raise a separate issue related to
that
... we should try to get some consensus about if groupings
affect separators etc., does numbering matter?
... should be driven by spec
... this pr shouldn't address this issue
JN: this issue was present for menu-item radios, so I don't think this pr makes that worse, but could add more instances of problems
MK: that makes sense, I'm good with this
joanie: group should still have same mapping, as far as I'm aware
JN: that was for the other pr, not this one
joanie: I don't think we need to change anything. is there an html equiv for this?
JN: no
joanie: we'll need test cases for this
JN: this can merge into master but no further
joanie: when I make test cases, if it's deliberately weird, I'll open an issue
MK: question related to this
pr
... menu item radio doesn't require a group, but if they're
not, does selection restriction apply similarly to
role=group?
JN: the next paragraph says if there are only radios, they don't need a group
MK: ok, I'm good with that
JN: any issues moving to master?
<jamesn> * Allows group child of listbox (containing options)
<jamesn> https://pr-preview.s3.amazonaws.com/w3c/aria/782/8b9d3c5...afc8460.html
JN: this is a pr to give us the equiv of opt-group
MK: we definitely need an APG for
this, and test labeling
... i support this pr
JN: this is just master correct?
joanie: correct
MK: are you creating issues Joanie, or...?
joanie: whoever is driving
changes, they could file
... Matt, please file issues for the things james is
merging
MK: when we have downstram dependencies, does each pr get its own project?
joanie: I stopped doing the
projects. since editors are present at meetings, no need
... the way 780 is written... aria-orientation's default might
be different based on the item
<joanie> https://github.com/w3c/aria/issues/780
joanie: I think two cases where
there's a 50/50 chance of default, scrollbars and buttons
... when it's important to communicate a default to AT is when
there's a UI need
... something that i'm bothered by is focus values. if we say
it's required, maybe it shouldn't be vertical
... should be required, but value should be undefined
JN: my opinion is that I think
it's hard to remove what's the current default, will break lots
of content
... if it goes from a default to undefined, developers may have
problems with that
MK: what's your response joanie?
joanie: unfortunate we hadn't
realzed that sooner. through authoring prac guidance, hopefully
we can educate people about ARIA 1.2
... a screen reader can fall back on vertical, wouldn't break
existing behavior
... i don't think the pr is the right solution
MK: if something is required and
has a default, dev shouldn't have to specifiy
... as far as that's concerned, we're on the same page
joanie: i'm okay with removing default value, and having validators flag it
MK: but that essentially makes
default undefined, could break things
... we have many places where there's a default, could be a
problem to remove the value. could be done selectively based on
widget
CB: validators might not catch these problems, QA might have to
MK: i agree
JN: what's the process to determine when required?
MK: if ARIA says focus should be managed, then should be one dimensional. should be required on tab
BG: i disagree on tab, there are cases where it could be horiz or vert
MK: if you have a default and property is req, you don't have to specify if you want default
JN: so tablist has a supported state of property, but isn't required
MK: I'll retract what I said earlier about managed focus stuff. maybe it gets down to following patterns. spec can't enforce everything
BG: a lot does come down to
patterns, especially in automated environments
... i don't think it's possible to automatically validate a lot
of this
<joanie> https://github.com/w3c/aria/issues/780
MK: we'd have to look at all this on a case by case basis, James and Joanie
joanie: what we'll need to do, if you have an opinion, add it to the comments of the issue so we have a thread and concensus
rrsagennt, make minutes
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/CB: yeah/Matt: yeah/ Succeeded: s/CB: we/Matt: we/ Default Present: MichaelC, curbellew, janina, Joanmarie_Diggs, jamesn, Irfan_Ali, Mark_McCarthy, Matt Present: MichaelC curbellew janina Joanmarie_Diggs jamesn Irfan_Ali Mark_McCarthy Matt Regrets: Jemma Stefan Melanie Jon Found Scribe: Mark_McCarthy Inferring ScribeNick: Mark_McCarthy Found Date: 12 Jul 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]