<Adil> https://github.com/act-rules/act-rules.github.io/pull/1219
<Adil> AGENDA ITEM: Final call https://github.com/act-rules/act-rules.github.io/issues/461 taken up [from Adil]
<Adil> Final call, things seems ready to merge
<scribe> scribe: shadi
WF: #1219 approved
... #1210 has some comments
... editorial changes
... then will merge
WF: 2-week final call for
#727
... long conversation
... 242 comments!
... 3 approvals now
... but could do with more reviews
JyM: will review
WF: got 1 week
WF: 3 issues opened for the ACT TF to look at
<john> bonjour, sorry ... what's the zoom password ?
WF: thank you very much for
everyone who worked on this
... Jean-Yves and Jey
... ARIA states properties?
JyM: waiting for approvals
WF: meta-viewport
JyM: Carlos has been working on
this
... may also need review
WF: auto-play needs a lead
person
... anyone interested?
DM: I'll try
WF: will skip the ones with open
issues for now
... we already have a bunch in motion
WF: example of correct ARIA but
not corred HTML
... arguably does not meet SC 4.1.1 (Parsing)
... browsers can deal with this
... also this rule is mapped to 1.3.1
... does not say anything about 4.1.1
JyM: agree with that
... question of good example
... would it work with regular list item?
WF: no, that does not work
KI: this would fail our own rules for lists
WF: don't think it should
KI: this breaks the content model
for lists
... isn't that the point for these rules?
WF: not necessarily
... need to look at that
... but seems like a separate discussion
DM: major screen reader
combinations would not interpret this code
... voice-over on safari
... would at least update the accessibility support details
<EmmaJ_PR> Sorry to be so late
WF: not sure we should update the rule for this
<Wilco> https://act-rules.github.io/rules/ff89c9#passed-example-2
WF: voice-over/safari and JAWS/IE
<Wilco> https://github.com/act-rules/act-rules.github.io/issues/1174
<EmmaJ_PR> Ta
SAZ: how hypothetical is that code vs real-life issues?
DM: unusual construct
WF: valid ARIA
... accessibility tree works
... not too concerned about these combinations because they
generally do not support some of these ARIA attributes
<EmmaJ_PR> https://webaim.org/projects/screenreadersurvey8/#browsercombos
EPR: still in favor of
demonstrating good practice
... not just that browsers will deal with them
JyM: most examples rely on inherent bad practice
EPR: is there another example that is more likely to occur?
WF: only thing that comes to mind
is combo-box
... but that may be changing in ARIA 1.3
EPR: example in the
applicability
... maybe tab and tablist
... no native HTML elements for that
JyM: agree with Emma
... maybe tab and tablist better
... but may need example with explicit and implicit role
WF: yes, need to cover that
situation of mixed explicit and implicit roles together
... take out example?
EPR: if unneccassary
... this feels like bad practice
... not something we want to encourage
JyM: don't feel strongly
... think we will always get into this issue
DM: would add something to the
accessibility support
... and keep example
AH: agree with Daniel
KI: on board as well
RESOLUTION: keep example and add clarification
<Wilco> https://act-rules.github.io/rules/ff89c9#failed-example-3
EPR: why owned by aria-label
WF: to get it into the accessibility tree
JyM: duplicating the inner part might solve the case
WF: good idea, update all of them
WF: closing other people's issues
when you have a pull-request
... we close issues when we open pull-requests
KI: this approach has backfired
before
... don't particularly like it
... issue forgotten in the middle
WF: yes, maybe we should revisit
this approach
... we wanted to avoid duplicate threads
JyM: do not write rules in issues
anymore
... so maybe can revisit
EPR: also might close issue that is broader than just one related pull-request
WF: thinking of putting that into
a mark-down file
... linked from README
... not needed on website
EPR: does this exist anywhere already?
SAZ: we have someone working on
information design
... think this issue is part of that discussion
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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/situatuin/situation/ Default Present: Adil, Wilco, Jean-Yves, Kasper, Daniel, shadi, EmmaJ_PR Present: Adil Wilco Jean-Yves Kasper Daniel shadi EmmaJ_PR Found Scribe: shadi Inferring ScribeNick: shadi 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]