W3C

- DRAFT -

ACT Rules Community Group Teleconference

20 Mar 2025

Attendees

Present
giacomo-petri, Kathy, Sage, Wilco, filippo-zorzi, Helen, Wilco6
Regrets
Chair
SV_MEETING_CHAIR
Scribe
giacomo-petri

Contents


scribe+

ACT standup

Daniel: act rules format 1.1 we want to move forward!

<Wilco6> scribe+

Kathy: no much work this week

Wilco6: I presented at CSUN ACT Rules, 40 people in room! Good! 2 people interested in participating

Shunguo: I reviewed some rules, added comments, looking at browser conflict resolution part from few specs (aria, aria in html) and try to understand their usage and consequences

Sage: didn't get too much done this week

sashanichols: I'm new, no work

Filippo: I'm new too to the group

Clarify ACT processes

Daniel: this issue contains a link to the old process that we had. Focus on reviewing it, and understanding if what is there if it still stand, or if need to be amended
... Another thing we should be doing, look for some other place where we should put it. Where it is right now should be dismitted; CG Chairs should be involved here. If someone would like to be envolved that's great
... we may want to put this all thing into a Google Doc or somewhere else to enable people to comment, provide feedback, and so

Wilco6: we should put it in a new PR in GitHub rather than google doc.

Daniel: agree, I could take the transition and put this page in a PR
... this will be the starting point

Clarify the purpose of the wcag-act-rules repo

Daniel: I replied to that. This repo is where we copy and we put the rule (thanks Wilco for this work - automation work). This can be addressed simply by updating the readme
... it's mainly for automation, there shouldn't be PR here

Wilco6: this is where templates are (W3C templates) plus where implementors submit implementations

Deprecate 46ca7f (Element marked as decorative is not exposed)

Daniel: we started the discussion during F2F

Wilco6: what's new here? I'm not sure why it is in agenda

Helen: a couple of comments have been added and maybe that's why

Shunguo: I added 2 comments, especially for browsers resolution for these items. Indeed ARIA and ARIA in HTML have something about conflict resolution
... Even though there is conflict resolution, it doesn't mean browsers/UA do it right
... Browsers follow conflict algorithm, but browsers do not know the author intent
... so it's a 50-50 proability that it works as intended

Wilco6: do we need explanation for presentational conflict roles resolution
... ARIA specifies what to do when an element with role presentation has a conflicts in terms of focusability or attributes
... so basically ARIA says that in specific circumstances, the presentational role should be ignored

giacomo-petri: I'm ok with the example provided by Shunguo, but it's not the whole rule that should be deprecated, but only specific items

Shunguo: yes, I focused only on specific items
... there are other rules that are triggering conflicts; e.g. aria-checked on elements that already have checked attribute (input type="checkbox")
... specs in favour of native rather than ARIA
... although there is a resolution in specs (e.g., for user agents), in our rules we should report there is a conflict, rather than a passs

Daniel: the way we can address this, is using the acc support sections and noting these aspects
... the conflict has implications in how elements are exposed

Shunguo: you are right, like when you have invalid HTML and browsers fix it. But the fix might not be the one that authors are expecting

<Wilco6> https://w3c.github.io/aria/#conflict_resolution_presentation_none Here's the spec for conflict resolution

<Wilco6> I found the PR I was talking about earlier: https://github.com/act-rules/act-rules.github.io/pull/2195/files#diff-622fe5a58330c226f9921002e8a87528abab53acf2bbaab5e01ebd40f644cd66

Shunguo: I'd like to have our examples as clean as possible (align with specs)

Daniel: the way to address this is to add details in accessibility support section

Wilco6: I've added reference to the PR created by giacomo-petri to address conflict resolution stuff
... do we want these rules instead of the generic that we have?

giacomo-petri: it could be a combination of both, since the Passed Example 1 with img with empty alt for example is not addressed by the new rules

Daniel: definitely it should be addressed in a PR offline
... do people have strong opinion on that or should we delay?

Wilco6: leaving it as is
... this rule is a best practice rule, doesn't map to any SC

Daniel: Shunguo you said you can live with it, keep it as is for now, right?

Shunguo: yes

Wilco6: close this issue?

Daniel: we should do, yes

CG Chairs transition

Daniel: Jean-yves is going to be back in October
... Helen will be co-chair with Carlos

Helen: I'm going to help out with things that do not require technical aspects
... We'll miss Jean-Yves!

Daniel: 1st thing: for combobox role aria-controls is no longer required, what should we do with that?

Shunguo: Resuming the discussion we had last week about aria-controls not required for combobox; this one is to consistently apply the same resolution also to this rule
... 2nd and 3rd issues I've reported are to improve the rule

Wilco6: ARIA 1.3 is a draft, should we follow it?

Shunguo: good question, ARIA are living specs, they are changing

Daniel: everything in ARIA is evergreen

<Helen> scribe+

<Helen> Helen: Should we ask the Aria group to follow the W3C process and not stick to their own way?

(lost connection for 2-3 mins, I'm back)

<Helen> Shunguo: I agree as I get lots of questions from our clients

Wilco6: we don't get the opportunity to review changes
... and provide feedback, but if the group is not releasing editor drafts, we are behind the specs

Daniel: that's fair, one aspect is ARIA 1.3 for example, the public working draft was published last year, there was a time for reviews
... ARIA is still discussing how we can improve it

Wilco6: I'd like to have more communications so we can review the edited/new stuff as they are available

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: 2025/03/20 15:02:20 $

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)

Default Present: giacomo-petri, Kathy, Sage, Wilco, filippo-zorzi, Helen
Present: giacomo-petri, Kathy, Sage, Wilco, filippo-zorzi, Helen, Wilco6
No ScribeNick specified.  Guessing ScribeNick: giacomo-petri
Inferring Scribes: giacomo-petri

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: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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]