W3C

- DRAFT -

ACT Rules Community Group Teleconference

24 Nov 2022

Attendees

Present
CarlosD, Jean-Yves, Dan_Tripp, giacomo-petri, aron, Helen, Wilco
Regrets
Chair
SV_MEETING_CHAIR
Scribe
CarlosD

Contents


scribe+ CarlosD

<Jean-Yves> scribe: CarlosD

Call for review https://github.com/act-rules/act-rules.github.io/issues/461

Jean-Yves: Nothing in 2 weeks call
... one PR in 1 week call
... have a look at it

Assigned issues + help wanted https://github.com/act-rules/act-rules.github.io/issues?page=1&q=is%3Aissue+is%3Aopen

Jean-Yves: I have a bunch but I haven't worked on them... doing mostly reviews

CarlosD: Same here

Wilco: Working on priority issues and resolving feedback from WG on Image of text rule

Helen: Just working on the manual test group

aron: Thought about recording accessibility support table but haven't put anything forward yet
... been working on PR1971... still in draft, but I'll ask for reviews when ready
... issue 1517 could be closed because most examples already use table? I'll leave it open for a couple more days if someone wants to comment

giacomo-petri: The issue for image buttons have accessible name can be closed
... for 1928 I've opened a PR
... In the last meeting we discussed how Safari overwrites the semantic role for list items
... their decision is documented in https://bugs.webkit.org/show_bug.cgi?id=170179#c1
... a second similar issue for table documented in https://bugs.webkit.org/show_bug.cgi?id=248273

<Jean-Yves> https://github.com/act-rules/act-rules.github.io/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22

Jean-Yves: Help wanted issues available for picking

Call for review https://github.com/act-rules/act-rules.github.io/issues/461

Update from the ACT Task Force https://github.com/w3c/wcag-act/pull/522/files

Wilco: 8 rules going for AGWG for approval, which can take us to 30 approved rule
... we're in touch with the ARIA WG... they might review some of the ARIA rules

<Wilco> https://wai-wcag-act-rules.netlify.app/standards-guidelines/act/implementations/#accessibility-linters

Wilco: We've added a new category of implementations
... the new category is Linters
... they are allowed to skip certain test cases, since they only check static code

Jean-Yves: How do you detect it's a dynamic rule?

Wilco: I've hard coded checking for CSS or scripts
... the TF is discussing if we need to define what can be checked by linters

Jean-Yves: We can have categories of examples: mandatory, optional for linters, optional for all

Wilco: Been working on secondary requirements... we hope to have an editor's draft soon

Jean-Yves: We've discussed the usage of the Priority label
... and in specific when it is also something that asks to skip the call for review

Wilco: We did it this first time because the entire ARIA 1.2 update was at risk because of a small issue
... but the normal procedure should be followed

Update from Manual Test Rules subgroups https://github.com/act-rules/act-rules.github.io/issues/1952

Helen: PR1979 as a first attempt at a template for manual test rules
... and I've invited people to review yet
... the goal will be to fill as much as the author can, and then mail the chairs to ask for people that could contribute with writing of the examples

Text spacing rewrite https://github.com/act-rules/act-rules.github.io/pull/1923

Jean-Yves: We found cases where the current text spacing rules were not working
... a first attempt at fixing it was too complex
... PR1923 tries to do it in a simpler fashion
... even simpler than the current version, and fixes issues 1687 and 1688
... but Wilco prefers to focus on the style attribute

Wilco: Yes!

Jean-Yves: But the solution to the issues would make it barely readable

Wilco: I was thinking of looking at the largest font size of the visible text

Jean-Yves: But the letter-spacing might also change (as in 1687)

Wilco: We have different preferences... we can go with what the majority of the group prefers

CarlosD: I prefer the simpler version, but would change the applicability to the element which has the text node

Wilco: OK, let's change it

Jean-Yves: I'll update it, then
... We have a passed example with an autocomplete token that is not allowed in the type of the element
... some tools might check that, but the rule forces them to pass the example
... Wilco commented that it is something used in practice, and browsers allow it

<aron> +1 Wilco

Wilco: The rule was originally written as Tom suggests, but then we started adding exceptions because types did not cause accessibility problems
... because we didn't think it should be called a WCAG failure we added that example

aron: Agree with Wilco
... we removed since none of the browsers implement it per the spec

giacomo-petri: This is very frequent for address fields

Jean-Yves: In issue 1562 we discussed this and made several tests
... should we revisit this from time to time in the instance browsers start following the spec and discard the autocomplete with incorrect type
... do have an accessibility support note about this?

Wilco: we do

Jean-Yves: There are good reasons to keep it as is, but I would like to have Tom check it

Wilco: Perhaps suggest to Tom to raise it in the TF or the AGWG
... I found it odd that this rule requires things to be in the accessibility tree

Jean-Yves: You're saying if there is an error message that is not in the accessibility tree you wouldn't fail it under 3.1.1?

Wilco: I would fail it under 1.3.1

Jean-Yves: And what if it was in the AT and not visible?

Wilco: I would fail it under 3.1.1

CarlosD: The understanding document for 3.1.1 mentions screen-reader users

giacomo-petri: In my opinion it fails 3.1.1... it might also fail 1.3.1
... the normative part only mentions "in text"... but why "in text"?

Wilco: we had another rule with a similar requirement

<Wilco> https://github.com/act-rules/act-rules.github.io/pull/1926/files

Jean-Yves: Would it make more sense to split the two expectations in two rules?

Wilco: I would be more inclined to have a rule on aria-hidden attributes used in visible content
... that would catch both of these scenarios

Jean-Yves: I agree with would be useful, but does not reply to the question about failing 3.1.1

Wilco: can we handle this in the same way we did for heading is descriptive?

Jean-Yves: but for that we removed the visible part
... let's keep this in mind

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.200 (CVS log)
$Date: 2022/11/24 16:08:21 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/when it also/when it is also/
Succeeded: s/ARIA 1.2/ARIA 1.2 update/
Succeeded: s/will be fill/will be to fill/
Succeeded: s/complext/complex/
Succeeded: s/different problems/different preferences/
Default Present: CarlosD, Jean-Yves, Dan_Tripp, giacomo-petri, aron, Helen, Wilco
Present: CarlosD, Jean-Yves, Dan_Tripp, giacomo-petri, aron, Helen, Wilco
Found Scribe: CarlosD
Inferring ScribeNick: 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]