<giacomo-petri> Hello Carlos! :)
scribe+
Carlos: We have 3 1 week review items
Carlos: Not much progress as
waiting on reviews on #1502
... #1845 - 2 reviews from site improve so want more
... #1655 I have to look at Wilco's suggestion, but I did open
a new issue - to be discussed next time
... #1560 again more reviews wanted
Wilco: Working on TF stuff life a valid ARIA-Valid value - I'm considering splitting it up
Helen: #2022 - I would like someone to write examples for me
Giacomo: I am working on #2007
and am getting closer to finishing
... Jean-Yves has suggested lots of items
Sean: No big updates - I finished on #2003 and it is waiting on being merged
Carlos: The procedure is you send
a mail to the mailing list asking for reviews like the ones
Jean-Yves sent
... ignore me - this change doesn't require the review as just
editorial
... I will merge it
Harris: I have no updates
Carlos: There are issues that are open to being picked up as lots of beginner issues there for Harris/Sameera
Sameera: Thanks
<Wilco_> https://wai-wcag-act-rules.netlify.app/standards-guidelines/act/rules/#deprecated-act-rules
Wilco: Pretty brief - we are
publishing a separated list of the deprecated rules, and it
will be published today
... We have a new rule from site improve that we love
<Wilco_> https://w3c.github.io/wcag-act/act-rules-format.html#secondary-requirements
Wilco: We are working our way
through lots of rules and would love your review on secondary
requirements
... SC 4.1.1 the CG asked me to take it back to the TF, and
they decided to not to do this until AG decide on what is the
official stance on 2.0 and 2.1
Carlos: I was not ware they might do that - interesting
Wilco: I am going to approach the AG chairs to prioritise it
<CarlosD> scribe+ CarlosD
<CarlosD> Helen_: I've created a draft manual rule #2022
<CarlosD> Helen_: Giacomo also has one manual rule #1914
<CarlosD> ... I'm looking for people to help me write the code for examples in #2022
<CarlosD> ... We're also looking for people to contribute rules that cover aspects that current rules don't yet
<Wilco_> https://github.com/act-rules/act-rules.github.io/pull/2022/files
Scribe+
Carlos: I would suggest to reach out to Dan, and is more involved so a good place to start
Carlos: Wilco - what does this relate to and why are we discussing it?
Wilco: Here is a good link for it
Wilco: this is what I ended up
with, and Jean-Yves and Carlos agree this is getting
complicated
... ID refs are not required except if they are using ARIA
controls like scroll bar or a combobox if expanded is set to
true
<Sean> exception inception
Wilco: so you have an exception
to the exception so I believe we need to split this up
... So ARIA controls reference ID must exist if it is on a
scroll bar or expanded combobox
Carlos: So we would remove the exceptions?
Wilco: It would reference this to
make it more atomic
... We have been discussing this and Aron had a few ideas on
this, as we have grouped the rules together too much, so we
want to split this up to be more atomic
Carlos: And more focused yep
Wilco: And Harris has been working on one too so whenever we state something is an exception then we make a new rule
Sean: Can we state this is the proposed format?
Wilco: Yep - we will update it, and we want to start here and we will have a rule mentioned in the background and then we can write it
Carlos: Sounds good
Carlos: The use of valid
properties that should not be case sensitive but they are
... AT doesn't really handle the case changing in the ARIA
properties and Wilco wanted to address this in the rules
... so should they be case sensitive? And how does it affect
AT?
Wilco: I created this as last
case was FF and it was fixed
... I was trying to find it and 80% sure this is the case, so
the rules shouldn't be case specific now
Carlos: I agree
... Next steps is to update the rules or ID the ones that need
amending
Wilco: Yep
Sean: It is not clear to me what AT was used - can we get some clarity? Like VO/Safari get checked?
Carlos: Yes it was Windows only as using the commonly used combinations only
Giacomo: Can we have a table of the combinations we can test as I do not have Windows machines right now
CArlos: That should be enough to
start thanks!
... update the issue and feel free to ask for help
Sean: I can check the others
Giacomo: Should we add ChromeVox too?
Carlos: If anyone has the device we will ask them
Carlos: Another oldie - also
opened by Wilco
... the rule has not been updated since the issue was
created
... so we have negative tabindexes on iframes and use the inert
attribute, and Wilco asked should they fail or be Not
Applicable?
... So do I understand the reach of this? So if I make an
iFrame inert, the inner parts will not be focusable either?
Wilco: Yes
Carlos: So the author must remove the inert property?
Wilco: Yes the parent or the
ifrrame using the inert attribute will translate to the
children, and reading the applicability of this rule it states
that focusable items should not be focusable or
actionable
... Or is the list empty?
... <has inner argument over this>
... are the buttons part of the sequential order or are the
buttons hidden if in an inert iframe
Sean: Is there a way to negate the inertness for the children?
Wilco: Not that I know of?
Carlos: So the rule always passes?
Wilco: Right so the rule might fail when it shouldn't
<Sean> I need to drop to prep for a presentation. Thank you, all.
Carlos: So what Wilco is stating - the sequential order is not affected but it should be...
Wilco: The problem is it is a bit of an edge case with an open modal - and it will inert everything in the page, so this is an exception
Giacomo: Would the accessibility tree help here?
Wilco: Well not always the case,
some items are focusable but not in the accessibility tree as
that is more of the tab focus items
... The definition of inert needs to be updated
Carlos: No the definition of
sequential focus needs updating
... to be contiunued
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) Default Present: CarlosD, giacomo-petri, harris, Helen_, Sameera, Wilco_, Sean Present: CarlosD, giacomo-petri, harris, Helen_, Sameera, Wilco_, Sean No ScribeNick specified. Guessing ScribeNick: Helen_ Inferring Scribes: Helen_ 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]