14:59:14 RRSAgent has joined #act-r 14:59:19 logging to https://www.w3.org/2026/01/22-act-r-irc 14:59:19 RRSAgent, make logs Public 14:59:20 Meeting: ACT Rules Community Group Teleconference 15:00:09 present+ 15:00:40 present+ 15:00:42 zakim, agenda? 15:00:42 I see 5 items remaining on the agenda: 15:00:43 1. ACT stand-up [from Jean-Yves] 15:00:43 2. [b49b2e] Accessibility support note on empty headings being exposed — https://github.com/act-rules/act-rules.github.io/pull/2351 [from Jean-Yves] 15:00:43 3. Add merge and publication policy — https://github.com/act-rules/act-rules.github.io/pull/2363 [from Jean-Yves] 15:00:43 4. Rule-writing for WCAG 3 [from Jean-Yves] 15:00:44 5. Review work (if time permits) [from Jean-Yves] 15:01:11 giacomo-petri has joined #act-r 15:03:34 scribe+ 15:03:38 Shunguo has joined #act-r 15:03:40 Wilco has joined #act-r 15:03:41 present+ 15:03:42 zakim, take up nexxt 15:03:42 I don't understand 'take up nexxt', Daniel 15:03:52 zakim, take up next 15:03:52 agendum 1 -- ACT stand-up -- taken up [from Jean-Yves] 15:04:34 Jean-Yves: Worked on one of my PRs 15:04:40 scribe+ 15:04:47 Daniel: I've done publication stuff with Remy 15:05:00 ... There were some broken links he raised, which we fixed. 15:05:12 ... I updated actions we were using for publications. Thank you JY for approvals. 15:05:31 ... We've also been thinking about how we can work on implementation data vs approval updates. 15:06:04 Sage: Curious if there's anything yet for the topic we discussed last meeting 15:06:19 Sage has joined #act-r 15:06:27 giacomo-petri: Some reviews during our last office hours 15:06:28 present+ 15:07:04 Wilco: Planning around ACT. I think we're reaching a pivot point for the group. We need to think about things AGWG is asking us to do 15:07:16 ... Some of my planning is on the agenda today, some is waiting for Kathy 15:08:00 Shunguo: A couple of reviews 15:08:03 zakim, take up next 15:08:03 agendum 2 -- [b49b2e] Accessibility support note on empty headings being exposed — https://github.com/act-rules/act-rules.github.io/pull/2351 -- taken up [from Jean-Yves] 15:08:29 Jean-Yves: Recurring question, change to an acc-support note 15:08:58 ... giacomo-petri opened an issue and is not happy with this PR 15:09:10 giacomo-petri: First of all there is no agreement on AGWG 15:09:36 ... Group is split in half (some think it should fail 2.4.6, others also 1.3.1) 15:10:05 ... In our tool we have a manual note for empty headings under 2.4.6, browsers still expose it in the accessibility tree. It's still a heading, even if it's empty 15:10:24 ... Stricter requirement of the SC is also not very clear 15:10:35 ... Heading is not defined in the glossary, other terms are 15:10:53 ... We shouldn't say that an element which browsers expose as heading is not a heading 15:11:06 ... I strongly believe we cannot force people not to fail 2.4.6 15:11:31 Wilco: Labels is defined as something that has the function of a label. It isn't programmatic labels 15:11:44 ... It identifies another component 15:12:06 ... IMO it doesn't make sense at all to put in under 2.4.6 15:12:40 ... If you extend the logic of the label definition to the headings, and more specifically to empty headings, it'd be a non descriptive heading, so it wouldn't make sense 15:12:47 Kathy has joined #act-r 15:13:10 giacomo-petri: If a heading is not meaningful then probably shouldn't be a heading 15:13:40 present+ 15:14:09 Jean-Yves: In the background we already have notes that we consider headings that are visible but not in the acc tree are failures of 1.3.1 15:14:27 q+ 15:16:52 q+ 15:17:17 Jean-Yves: The problem is we'd have an accessibility support note and we'd have examples that targets the note specifically, which is problematic 15:17:38 ack d 15:17:43 ... Also Wilco thinks these examples do not fail 2.4.6 15:18:59 giacomo-petri: We are now focusing on AT (screen readers). What about people using extensions to highlight certain parts of the page, like headings, they'd have empty areas on the page, it's difficult to assess the impact 15:19:30 ... The user agent is still exposing the element 15:20:18 Wilco: We've established a principle a while ago that mismatches in the content and the accessibility tree are 1.3.1 issues 15:20:38 ... We had a heading rule that checked both the accessible text of the heading and the visible content of the heading 15:21:10 ... We stepped away from it because we ended up thinking this is a 1.3.1 issue 15:21:22 q+ 15:21:25 ... IF we want to revisit that decision there are broader implications 15:22:02 ack g 15:22:03 ... aria-hidden problems go on 1.3.1. I'd continue with this approach, otherwise we'd have to make broader decisions 15:22:16 giacomo-petri: I'm not saying we should revisit that 15:22:58 ... But we are assuming this empty heading shouldn't be there 15:23:10 ... Thee authors may forget to enter its value, but there should still be a heading 15:24:04 Jean-Yves: If it wasn't a heading, for instance if it was a link, would it fail 2.4.9 or 1.3.1? 15:24:53 Wilco: s/ or 1.3.1// 15:25:01 Wilco: I don't think we have had this conversation 15:26:07 Kathy: The SC talks about the purpose of the link being ambiguous to users in general 15:26:29 giacomo-petri: Are we now say that empty links shouldn't fail 2.4.4? 15:26:44 Jean-Yves: I'm just pointing out the differences between links and headings 15:27:35 Wilco: The definition of text does require it to be programmatically determined 15:27:46 ... 2.4.4 and 2.4.9 are specifically about programmatic 15:28:04 ... It makes more sense for me there 15:28:08 q+ 15:28:16 ... Labels is not programmatically, just things that function as a label 15:28:41 giacomo-petri: Why using headings? Labels include heading in that context, but if the SC specifies heading, then it is a heading 15:29:01 ... Half of the rules could be removed because we're not clear if the role is correct 15:29:25 ... IF the author defines it as heading we should take it into account 15:29:49 ... The problem is if headings is not defined. But even so, we cannot assume that headings or role heading is not included 15:30:08 Wilco: Disagree, without a definition I can only think of them as functioning as heading 15:30:39 Jean-Yves: I'd agree with Wilco. A button is not a button because an author put the role of button. What makes a button is its functionality, that someone can click or press it 15:31:38 Shunguo: If you have a role button and then you have to provide other things then there's something wrong. There are many cases of mismatch between the accessibility tree and content, cannot simply say it's 1.3.1 15:31:59 ... in ARIA, for example, role defines functionality 15:32:21 ... If you have a component where you define a button with ARIA, you have to provide all functionality 15:33:40 giacomo-petri: If we have an empty button without an accname and the button doesn't behave as a button, it's failing 4.1.2. We may also raise 1.3.1 on the next iteration or something 15:34:05 ... Not sure we should be skipping elements intended to be used in a different way 15:34:19 Wilco: The failure is that it shouldn't have been a button, not that it doesn't have an accessible name 15:34:49 ... There is something wrong, which is it has that role to begin with 15:35:03 giacomo-petri: What if it's a button and should be a link? 15:35:42 ... Let's assume 4.1.2 is only about form controls 15:36:23 ... IF we assume that an element can be whatever and we don't take into account its current semantics, then the whole automation approach would fail, as we couldn't really rely on what the author has set 15:36:55 Wilco: That is true, you cannot be 100% sure, you do have to base you assessment on some further judgment 15:37:58 Shunguo: That's right if the role is correct. 15:38:45 Wilco: I am not saying I am right. Agree that this is open to interpretation. What I am saying is that these decisions we took are based on this underlying assumptions of ACT Rules 15:39:47 Shunguo: If something has a specific SC like 2.4.6 or 2.4.4 then we should pay attention to what's there, otherwise we should use a more generic rule 15:40:13 ... Let's imagine you report a missing link or heading, which is easy to spot by the user. But there are other cases where this is more complicated 15:41:08 Jean-Yves: We do have a rule for heading having a non-empty accessible name, but only fails ARIA. Should that fail 1.3.1 as well? 15:41:41 ... Then we could flag empty headings as something more serious 15:41:58 Shunguo: Not directly objective this. To me empty text is not descriptive, because it's empty 15:42:45 Jean-Yves: What is heading in WCAG terms? That's not defined. Not sure that an empty h element would be considered as a heading 15:43:25 Wilco: Would then be true that empty headings don't fail WCAG at all? 15:43:55 Jean-Yves: And will it be sufficient to have 1.3.1 as secondary requirement for that rule? 15:44:03 Wilco: I don't think we should 15:46:22 Wilco: I keep insisting here because this work got started to push for more consistency. We changed failing empty heading in one direction, if we push in another direction we should be really clear why. 15:46:58 ... I'm pretty sure we don't fail empty headings 15:47:05 ... Allowing either option we probably shouldn't do 15:47:40 Shunguo: The only thing for me is that ARIA requires an accessible name for headings. If you provide one it'd be oK for screen reader users ,but not for users who rely on vision 15:48:26 Wilco: The empty heading rule that we have fails only ARIA 15:48:44 ... If it's OK to the group I am proposing that we poll 15:49:06 Kathy: I just wanted to make sure we're all aware of the WG draft response 15:51:04 Kathy: We can take a decision but it'd be override by them at some point 15:51:22 Poll: 15:51:39 Option 1: remove the inapplicable example about an empty heading 15:51:49 Option 2: Leave it in, close the issue 15:52:19 Option 3: remove the inapplicable example, and put empty heading as a failure of 1.3.1 and 2.4.6 again 15:52:56 Kathy: IF we remove the inapplicable example, does that mean it's up for interpretation? 15:53:23 Jean-Yves: The applicability will still be attached to non-empty headings. It'd say that but we wouldn't be testing it 15:53:35 Wilco: Official failure but we're not enforcing it 15:53:44 Option 3 update: and revise the rule to fail empty headings 15:53:47 ... For option 3 we'd have to revisit the rule 15:54:03 Option 3 15:54:24 What is your preferred solution, and do you object to any of these? 15:54:35 Prefer 2, object to 1 15:54:45 preferred: 2; object to 3 15:54:51 prefer Option 3 15:55:00 Prefer 1, no real objection but not sure we have bandwidth for 3… 15:55:15 1 > 3 15:55:42 Prefer option 2, no objections 15:57:16 Wilco: Not come to an agreement, we'll put together a survey 15:57:57 rrsagent, draft minutes 15:57:59 I have made the request to generate https://www.w3.org/2026/01/22-act-r-minutes.html Daniel 15:58:32 q+ 15:58:48 Wilco: I apologize for this, but we've had this conversation several times. I do appreciate you bringing this in again, giacomo-petri 15:59:12 q- 16:03:01 Kathy: Good discussion, it shows how accessibility support can have an impact on interpretation 16:03:11 rrsagent, draft minutes 16:03:12 I have made the request to generate https://www.w3.org/2026/01/22-act-r-minutes.html Daniel 16:03:38 Chair: Jean-Yves 16:03:41 rrsagent, draft minutes 16:03:42 I have made the request to generate https://www.w3.org/2026/01/22-act-r-minutes.html Daniel