<MarkRogers> present
scribe+
<MiriamF> +
Jean-Yves: 2 one-week call for review, no two-week
Jean-Yves: working in the target size rule
CarlosD: not much
Wilco: task force work
MarkRogers: looking at the target size rule and how browsers handle it
dan_tripp: working on the label
in name PRs
... and on #2075, that might be moved out of draft status
Todd_: not much
Wilco: 3 rules parked with the
AGWG
... might be approved next week
... 3 more at the ARIA WG
<Wilco> https://w3c.github.io/wcag-act/act-rules-format.html
<Wilco> https://w3c.github.io/wcag-act/act-rules-format.html#Change_History
Wilco: working of the first
working draft of the act rules format 1.1
... still other considerations, like updating the applicability
section
... where objectivity requirements could change from a "must"
to a "should"
Jean-Yves: Talk about ACT at CSUN accepted
Jean-Yves: the old website is not
updated but people are pointing to it
... we should deprecate it and redirect to the current
website
... the few pages that are not on the WAI website should be
moved to the CG page on the w3c site
Wilco: we could also leave it on
github
... this is on my todo list for a long time
... but if someone wants to take this on please do
Jean-Yves: I've been working on
this rule since TPAC
... the main issue for me is coming up with the definition of
clickable area
... and the definition for target size enhanced also considers
area occlusion which makes this further complicated
... also, CSS transformations makes getting the bounding box
for an element that is fully visible, may result at a bounding
box that is larger than the clickable area
... Mark suggested looking at hit testing from browsers
... and I've created a lot of tests in https://github.com/act-rules/act-rules.github.io/pull/1919
Wilco: is there a way to define a minimum area that we can agree upon?
Jean-Yves: There are some options we can look at, and that is a probable avenue
MarkRogers: I've been looking at the behaviour of clickable areas and they work differently with HTML elements and SVG
Jean-Yves: I considered discarding elements with transforms, but then we would end discarding everything that content authors change
Wilco: Can we capture the most common cases and start with those?
Jean-Yves: Agree with simplifying and capture what we can
Wilco: We can revisit this later
MarkRogers: another problem is actually knowing what is clickable
Jean-Yves: the applicability now is focusable widget, which are likely to be clickable
MarkRogers: it might be worth dropping the focusable requirement, since there are a lot of widgets that are not focusable
Jean-Yves: I'm hearing that we
should discard elements that have a lot of changes from CSS and
see if we can work within this simpler framework
... also, everyone have a look at the examples on the PR
Wilco: I see you are using
buttons in some of the examples
... wouldn't it be easier to use links to avoid the browser
styling of buttons
Jean-Yves: with links there was a mess with white-space around them, so I styled the buttons
MarkRogers: what happens on the target size rules with composite widgets, like comboboxes?
Jean-Yves: I'm not aware of specifics on this from the understanding documents
giacomo-petri: If labels are linked to the inputs are they target areas?
Jean-Yves: Yes, if they are equivalent, and the rule also considers this
giacomo-petri: But, how many users know they can click on a label?
Jean-Yves: Agree, but it should not be a reason for failing the SC
Wilco: About the controls, if a control is composed by sub-controls, that have distinct functions, then the sub-controls need to meet the target size
Jean-Yves: Thanks for the inputs... I'll further work on this now
https://github.com/act-rules/act-rules.github.io/pull/1919
Wilco: our rule has a false
positive!
... the rule has an exception for when the role mimics the
native behaviour
Jean-Yves: I'm not sure this is failing the rule because the checked attribute is setting the aria-checked attribute
<Jean-Yves> https://www.w3.org/TR/html-aam-1.0/#att-checked-absent
Wilco: that is an interesting way to read it
CarlosD: I think that is correct, the property is set
giacomo-petri: We need to reference the AAM in the rule
<Jean-Yves> https://www.w3.org/TR/html-aria/#el-input-checkbox
Wilco: We have multiple ways to read what it means for a property to be set. Do you need a definition for that?
Jean-Yves: We maybe do
<Jean-Yves> https://github.com/w3c/html-aam/issues/349 (applying to implicit roles)
Wilco: By reading it this way, do
you fail a checkbox with a role button?
... we need to handle explicit and implicit semantics
differently
Jean-Yves: A definition of explicitly set and another for implicitly set are needed
<Wilco> https://developer.mozilla.org/en-US/docs/Web/API/ElementInternals
This is scribe.perl Revision VERSION of 2020-12-31 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/present// Succeeded: s/present// Succeeded: s/objectively/objectivity/ Succeeded: s/objectively// Succeeded: s/are/area/ Default Present: dan_tripp, CarlosD, Jean-Yves, Todd_, Wilco, MarkRogers, MiriamF, giacomo-petri Present: dan_tripp, CarlosD, Jean-Yves, Todd_, Wilco, MarkRogers, MiriamF, giacomo-petri No ScribeNick specified. Guessing ScribeNick: CarlosD Inferring Scribes: CarlosD WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: 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]