scribe+
<CarlosD> scribe+
Carlos: Couple things for
review
... 1920 has been in review for 3 days, and 1912 from Daniel,
which probably shouldn't be in review.
... It has requested changes. I'll need to go in review
again.
... The person who started the PR should set Call for
review
... The PR specifies how long the call should be, 1 week or
2.
Gaicomo: So I can send the e-mail?
Carlos: When there are three approvals
Carlos: Haven't been able to look, hopefully will get some work done in Dublin.
<CarlosD> Wilco: some priority issues that have been on hold... opened #1925 today
Helen: 0 issues
... Been busy organising F2F meeting
Gaicomo: No updates
Todd: Will look at 1922 today
Mark: One's a PR that I thought I'd reviewed. I'll take that offline
<CarlosD> Wilco_: a couple of rules are going to AGWG next week
<CarlosD> ... working on rules format to deal with the accessibility requirements mapping
<CarlosD> ... figure how to make the accessibility requirements optional
Carlos: E-mail for registration
went out. Less then a week to register. It closes next
Wednesday.
... I hope everyone here will attend in person.
Gaicomo: I won't be able to join in person, but I'll be present
Carlos: Don't forget to register.
We need to know if we'll have people remotely.
... Most of the time is work sessions, addressing open PRs and
issues. If time permits, we can work on new rules.
... We also have a few sessions in the afternoon of the first
day. Those will be easiest to attend for people in the US.
Carlos: There is a session for
beginners to become more familiar with ACT rules.
... We'll have another session on different ways people can
contribute.
... One part is on how people can contribute to the website.
You can also work on PRs during that time.
Helen: We'd be the first non-Optum group to meet. It'll be nice to meet with people in the office.
Carlos: We'll arrange that.
Helen: Once we have the numbers
next week I'll put together a time and place.
... Should be able to go for a meal.
Mark: On 1172, Wilco raised if
there was any real-world issue. We did testing, and the problem
seems to be that the rule talks about inconsistencies.
... But there don't seem to be any issues in modern browsers.
There probably where historically. This changed between
different versions of the spec.
... It seems that in all current ATs things are consistent for
pages served as text/html.
... Previously for application/xhtml+xml there used to be
differences between Chrome and other browsers.
... That was changed in Chrome 88. We discovered this during
testing.
... This changed 2 years ago. At the time this rule was
published there were inconsistencies, but now not so much.
Carlos: That's the real question. The rule doesn't seem to catch any true positives.
<CarlosD> Wilco_: The rule seems to be outdated. It should probably be deprecated.
Helen: +1
<ToddL> I have to shift to another meeting but I do have questions on a couple items.
Carlos: If we want to look at XHTML documents, that's a really small part of pages served. That doesn't seem to be any real-world relevance for the rule.
Mark: I'm in favor of deprecating this as well. At best it's probably going to be something like 0.05% of pages effected, and that number keeps going down. It's not really worth doing.
Carlos: Jean-Yves entered in GH,
he's also in agreement of deprecating this.
... This is one of the rules approved by AG. Do we have to do
anything to deprecate this?
<CarlosD> Wilco_: I don't know. This will be a first. Let's follow the procedure and the TF will bring this to AG.
Mark: If someone has evidence of
this causing problems in AT that's fine, but if we have no
examples that's good evidence it's not effecting anybody.
... It's easy to refute. Someone might have a combination that
doesn't work, in which case its fine.
RESOLUTION: Deprecate HTML page lang and xml:lang match
Carlos: While reviewing a PR from
Gaicomo, Jean-Yves suggested more than a couple improvements on
Error messages rule
... To improve this rule he suggests restricting the
applicability to fields that have aria-invalid=true
... Proposes replacing the definition that is not objective by
something that would be a programmatic error indicator.
Helen: I like it. It's not always clear, sometimes formatting varies browser to browser
<CarlosD> Wilco_: The change reduces the scope of the rule
Gaicomo: I agree, I think we'll
miss 90% of cases.
... The visual presentation of an error may not be
programmatic, but it's still valid.
... The current rule is designed to also look at visual
presentation, not just programmatic.
Helen: Part of it's down to making sure something that needs manual testing is programmatically checked.
Carlos: This would make a manual
rule into a semi-automatic one.
... Removing from manual to semi-automated would be the only
advantage
<CarlosD> acj Wilco_
https://www.w3.org/WAI/standards-guidelines/act/rules/36b590/proposed/#implementations
Carlos: The semi-automation that
would come out of the rule would be more targeted. It would
meet a lot of potential cases.
... Instead of changing the existing rule, we could have an
additional rule that looks at form fields which have
aria-invalid set to true. I'm not sure it adds a lot of
value.
Gaicomo: There should be come
definition of context.
... There's a definition of context which might be confusing.
In WCAG it talks about paragraphs as context.
... We can say something like input error with its context.
Helen: I know that errors are seldom linked programmatically to the field.
Carlos: From the tester's
perspective, if the errors aren't linked, this would still be
applicable.
... The rule that Jean-Yves mentions would be applicable.
<CarlosD> Wilco_: there may be here a rule related to status messages
<CarlosD> ... when an event causes the aria-invalid to change from false to true there should be a status message being updated
Helen: There might be something we might not be getting?
Carlos: We can link to the minutes and ask for further input. I'll do that.
https://www.w3.org/WAI/WCAG21/Understanding/images-of-text.html#dfn-essential
<CarlosD> Wilco_: the definition of essential from WCAG seems ambiguous
<CarlosD> ... who decides what is a fundamental change?
<CarlosD> Wilco_: this is a PR that is addressing this by redefining essential depending on the situation
<CarlosD> ... listing the scenarios we know are essential
<CarlosD> Wilco_: we need to do something similar for the image no text rule rule
Carlos: My main concern would be,
is listing out known cases doable?
... We can always abstract more and more so we can list
everything, but you'd get to such a level of abstraction it
might become ambiguous.
Gaicomo: It might be essential for some but not for others.
Carlos: I would disagree, when
you say WCAG doesn't address that. That's one thing WCAG does
address.
... If there was another way, the graph wouldn't be
essential.
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: Wilco_, giacomo-petri, Helen_, ToddL Present: Wilco_, giacomo-petri, Helen_, ToddL No ScribeNick specified. Guessing ScribeNick: Wilco_ Inferring Scribes: Wilco_ 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]