ACT 2.4.6 atomic rule Update

[grifare]

<< Describe the changes >>

Closes issue(s):

• closes #XXX (ADD ISSUE NUMBER HERE)

Need for Call for Review:
<< choose one of the following and remove the rest >>
<< check Process Document on Call for Review >>
This can be merged with 1 approval << choose reason: editorial changes to website/test code, adding new contributor, other (explain). >>
This will not require a Call for Review << choose reason(s): editorial changes (including to the applicability, expectation or examples section), changes to assumptions, background, accessibility support, change to website/test code (not rule), other (explain). >>
This will require a 1 week Call for Review << small changes affecting a small number of examples, if in doubt do not use this. >>
This will require a 2 weeks Call for Review << new rule, or substantial changes affecting a large number of examples, if in doubt, use this. >>

---

Pull Request Etiquette

When creating PR:

• Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
• Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

• Add yourself (and co-authors) as "Assignees" for PR.
• Add label to indicate if it's a Rule, Definition or Chore.
• Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
• Optionally request feedback from anyone in particular by assigning them as "Reviewers".
• If your PR is for a new rule with an Accessibility Support note, or for updating the Accessibility Support note of an existing section, make sure to open a corresponding Accessibility Support issue.

When merging a PR:

• Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

• Go to the “Files changed” tab
• Here you will have the option to leave comments on different lines.
• Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
• Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

[CLAassistant]

All committers have signed the CLA.

[netlify]

❌ Deploy Preview for act-rules failed.

Name	Link
🔨 Latest commit	44fc44d
🔍 Latest deploy log	https://app.netlify.com/projects/act-rules/deploys/6a52ee90a490300008f2bfa4

[WilcoFiers]

Thanks for putting this together @grifare. Just as a reminder, the thing that kicked it off was that a heading shouldn't only have to describe the first thing after it. That's a real issue with the current rule. The reason we wrote it that way is we couldn't figure out how to say how much a heading should describe, or where a section actually ends.

I do have to be straight with you about the big problem though. Your rule doesn't follow the ACT Rules Format or the style guide. We can't invent new sections or change how rules are written, like the whole "Situations A–F" thing, the "Limitations" bit, turning Expectation into a bulleted list, or writing test cases as prose instead of full HTML. What you've written is so fare removed from a valid ACT rules that I don't think we can do this with just inline comments on a pull request.

This is all about the format. The ideas are a different story, and a bunch of them I like. Quick take on each:

The "anything that functions as a heading" idea. I get the intent, but I think it makes the rule too complicated. It's really hard to say what has to be a heading. Usually the actual requirement is that content has a relationship, and a heading is one good way to do that but often not the only one. We can't just say "anything that looks like a heading". Sometimes a heading is a list item, sometimes it's a figcaption, sometimes a table caption, sometimes it's none of these and it should be. It's hard to say what an applicability like this means. If think this problem of "should it be a heading" is worth tackling, but I think that's done in a separate rule.

Pulling content quality apart from other failures, the misleading-heading case, and the editorial-vs-accessibility line all seem reasonable. We just need a good spot for them. We usually do things like this through a definition, rather than a new section. That would be where I'd start.

The one I'd push back on is making it subjective / human-only / test-to-pass. Rules should stay neutral on how they get tested. If a tool can do it, good on them, and full transparency, I'm building exactly that right now. Descriptiveness is something tools can test quite well these days.

What I'd suggest: let's take the core problem, how much a heading should describe and where a section ends, and hash it out in a smaller PR first. We can look at what it means to be descriptive separately, and split the applicability idea into its own rule. Once we agree on direction the PR gets a lot easier to write. Let's discuss during an upcoming ACT call.

[grifare]

Okay, thanks for the clarification. Given that it was the first time I was trying to write an ACT rule, there would certainly be format errors. I tried my best to follow the format. I am eager to adapt it exactly as required. I am also open to other changes. For example full HTML is a very easy change. See you at 10::00.