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	22fd9bb
🔍 Latest deploy log	https://app.netlify.com/projects/act-rules/deploys/6a76038aebc64700085bb320

[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.

[grifare]

I started to make both format and content changes in light of your feedback above. First of all, I removed the word "meaningful" from everywhere, as you were right in the meeting when you said that almost anything could be deemed meaningful.
I will divide the work into 2 parts. Please see the changes I made in the first section that will precede the examples.

I am open to further guidance. Let's first finish this section as you suggested. I am also looking froward to having the one-on-one meeting with you.

As for just the format of the "Examples" section (the examples will be discussed when the first section is done), can you say whether this is okay so that I can work on these as well?

Instead of this

Test Cases

Passed (Situation A)

Headings that are compliant under this criterion, while exhibiting no other accessibility or structural failures under WCAG.

Passed Example 1

This h1 element provides a relevant heading that states the functional purpose of the page content.

<h1>Renew Your Passport Online</h1>
<!-- Followed by a page that has instructions, images, and a form about how to make the renewal application -->

Is this how it should be?

Examples

Passed

Passed Example 1

This h1 element provides a relevant heading that states the functional purpose of the page content. It is a heading for a page that contains instructions, images, and a form about how to make the passport renewal application

<h1>Renew Your Passport Online</h1>

[WilcoFiers]

This new applicability is ambiguous. That's not allowed in the rules format. You're not defining when a bold or large text is a heading and when it isn't. As I mentioned before, I think that's a problem we should leave for another rule. Many rules we wrote rely on other rules to address gaps. That way we keep a rule atomic and understandable. Instead of making this one rule do both jobs of determining which things should be headings, and which headings are then descriptive, we're better off separating those.

The way I'd break that down is to write three rules:

1. Things that look like headings have heading markup (1.3.1)
2. Elements with heading markup is only used to convey page structure (1.3.1)
3. Elements with heading markup describe their section (2.4.6, this rule)

That covers the full spectrum of testing needed for headings, giving each rule a specific task. I think we should keep the applicability as it is today. This follows the suggestion of the rules format to put subjective and objective applicability into separate rules. Rule 1 would have a subjective applicability, the rest wouldn't need it because it can build on rule 1.

[grifare]

I agree with you that using bold style as an example without defining when to consider it as a heading will be ambiguous and puzzling for testers. It can have many adverse effects. (I copied that text from your feedback.)

However, if we keep the applicability as it is today, I think it will be incorrect. The current text explicitly refers to the semantic headings only. According to the current wording, <p class="h1">Non-semantic heading</p> is out of scope, am I mistaken?
https://www.w3.org/WAI/standards-guidelines/act/rules/b49b2e/proposed/#applicability

Unless we clearly say this rule applies to all elements that can be perceived as headings as well as the real headings, we will not be accurate. I don't think there is no way to describe something as subjective as this criterion unambiguously in one sentence or two. That is what examples are for.

Therefore, in addition to the existing test, I insist that something like this should be present:

Applicability

This rule applies to any semantic heading element that is included in the accessibility tree and has a non-empty "" accessible name. It also applies to other elements that are not semantically heading elements, but that are presented as headings.

For now, I made the change as shown above, but I am 100% open to any edits you would suggest there. "Presented" could be "perceived" or there are lots of other alternatives. I just want to underscore the difference of 2.4.6 from others, which is evaluating plain text, not the inspected code or not what screen readers announce.

[WilcoFiers]

We don't need this.

Suggested change

	### Applicability Type Designation:
	Rule contains subjective applicability, depending on whether the element evaluated as a heading by implementers should be considered a heading.

[grifare]

I don't understand why this option exists at all, if it will not be used even here.

Rules can optionally include an applicability type identifier signifying whether the rule contains an objective or a subjective applicability. This identifier is intended to benefit rule readers and implementers by clearly stating the rule author’s intention of the applicability and reducing confusion due to different reader and implementer interpretations.

https://www.w3.org/TR/act-rules-format-1.1/#applicability-type-designation-atomic-optional

I can see that we are trying to avoid the word "subjective", but if there is one rule that word applies to, it is this rule. If AI will decide what headings humans should write using the "accessibility" card, that will be yet another step towards ending human creativity.

I suggest we discuss this with others. I am keeping it for now with some simplification. It can easily be deleted if others do not want it.

[WilcoFiers]

This seems fairly ambiguous. Here are the questions I had about it:

1. What does it mean for a heading to be relevant to a section?
2. If the heading is relevant to the page, does it not need to be relevant to any section?
3. What are sections?
4. How do I know which heading goes with which section?
5. Can a heading belong to multiple sections?
6. What does it mean for a heading to be intelligible?
7. How do I know if a heading is sufficiently intelligible?

Having read through understanding docs, and some other people's writing about 2.4.6 I no longer think we should change "descriptive" to "relevant". If a heading is irrelevant to the section its in, than I think its either in the wrong section, or it shouldn't be a heading at all. Either one is a failures of 1.3.1. Where 2.4.6 comes in is when headings are relevant, but insufficiently descriptive. On a recipe page using "Recipe 1" instead of "Vegetarian lasagna" for example is a heading not being relevant.

I'd recommend doing a few things with this expectation:

1. Create a new definition for "section". Something like "A visually distinct region of the page" Sections are separated through visual clues, including changes in background, borders, dividing lines or images, a change in width, a change in column numbers, or a starting heading. Sections may contain sub-sections.
2. Create a section heading definition, that builds on the section definition. Something like: A section heading is the first semantic heading of the section.
3. I think we'll want an inline definition of "descriptive". So after this first sentence of the expectation, you could say something like: "A heading is descriptive when ..."
4. I don't think intelligible is needed here. Make that part of the inline definition of descriptive.

[grifare]

Descriptive versus relevant

Replacing "descriptive" with "relevant" was my proposal right from the start and we began working on this assignment after you accepted it. I also proposed "meaningful" but then we removed it upon your request, as you were right in the sense that anything could be considered meaningful by itself.

But I still think the devil is in the word "descriptive". A tester can fail anything using that. Here is what reports will be reading: "this is not descriptive enough because, that is not descriptive enough because". To avoid that, the "first perceivable content" term was introduced, but then the rule became an artificial requirement of writing 2 sentences that repeat each other.
Replacing any proposal not existing before with the existing text may be not be a very meaningful study.

On a recipe page using "Recipe 1" instead of "Vegetarian lasagna" for example is a heading not being relevant.

I assume you provided the example above as a "PASS" example, right?

That is why I created situations in examples. (I will remove all situations to use the existing format, no doubt about it. I am pasting it here for now just to make my point.)

Passed (Situation B)

Headings that serve as structural or sequential identifiers, which are inherently compliant regardless of the specific content that follows.

Passed Example 4

This h1 element provides a sequential identifier for a major document section. The content that follows makes no difference to the outcome of this test.

<h1>Chapter 4</h1>

I also had a section like this, which was not using the format. However, I think it is helpful section and it could be used elsewhere, as you would suggest.

### None of the following is within this rule's scope:
- The sequential order of heading levels, such as evaluating whether a heading skips levels in the hierarchy (e.g., moving from an `h2` directly to an `h5`)
- Coding or parsing errors in headings (assuming that the heading is visible or exposed to assistive technologies), such as mismatched tags like `<h2>Meaningful and relevant heading</h3>` which browsers automatically correct in the DOM
- Factual accuracy of headings, such as the verification of historical dates, including names, locations, technical facts
- Technical mistakes related to numeration or ordering in headings, such as skipped numbers, sequencing or arithmetical mistakes, chronological validity, incorrect ordering of section headers
- Objective truth in headings, such as editorial biases, opinions, or controversial theories
- Grammar or spelling errors in headings (unless they render the text entirely unintelligible), such as common typos or minor translation mistakes like "Command your food" instead of "Order your food"
- Headings of highly specialized or technical domains consisting of advanced scientific, technical, or academic material, where evaluating the relevance of the terminology requires domain-specific expertise
- Headings of abstract or creative content consisting of literary works, poetry, or avant-garde text where relevance is interpretive or non-linear rather than purely informational
- Headings of legally mandated or standardized statements, documents, or user interfaces where their heading text and structure are rigidly dictated by statutory, regulatory, or legal mandates (e.g., standardized privacy disclosures) that should not be altered by the author
- Compliance with other WCAG success criteria applicable to headings that are evaluated independently

##Comments about recommendations

Item 1, "Create a new definition for 'section'"

Very good idea, but it will take time if I am to do this, as it may become a back-and-forth discussion topic. I am eager to copy-paste whatever you would suggest for this (or directly commit here).

Item 2, "Create a section heading definition"

Not sure if it is needed. It will be very much ambiguous no matter what you describe, especially when the description of the heading is not clear yet.

Item 3, "we'll want an inline definition of 'descriptive'"

Respectfully I disagree. That is going back to square one. The vast majority of the existing headings of the most prominent institutions all around the world will suddenly become non-complaint with WCAG. All that I listed under the "None of the following is within this rule's scope" above will be failed by testers.

Item 4, "intelligible"

I am also not 100% sure about it.
If you think these hypothetical situations I wrote are not encountered in the real world, just tell me to remove it, I will remove all examples that include such cases as well.

Headings containing errors due to copy-pasting, forgotten placeholder text along with the actual heading, or left-over markup code that should not be visible. These headings are considered failing if the text no longer remains meaningful and relevant, introducing a risk for user misunderstanding

Failed Example

This h3 element contains fragmented, truncated text resulting from a catastrophic copy-paste error. It fails this rule because the remaining text fragment fails to convey any meaningful topic, leaving it entirely irrelevant to the underlying content.

<h3>ortcontact Custo</h3>

[WilcoFiers]

I don't know why you deleted the examples. We'll need those.

[grifare]

I have all the examples locally saved as an md file.
I temporarily removed them from GitHub in order to:

• Make required format changes to comply with the official format, such as removing the HTML comments I used and including the case in the description
• Add or remove examples depending on how this section proceeds, what feedback you will provide
• To repost all examples as one commit, once this intro section is fixed

I am now waiting for your approval of the format I should use for examples. Will the examples' format be okay like this? (No situations list whatsoever.)
#2425 (comment)

[WilcoFiers]

Assumptions are about the content, not about the tester. This is more like an input aspect, although I'm not sure that we should make this an actual aspect. That might be worth a discussion in the group.

[grifare]

Please see the following comment.

[WilcoFiers]

As above, assumptions should be about the content. If a tester is unable test something, that's there problem to figure out. it's not an exception to the accessibility requirement. Testers always have the option of reporting a test as incomplete because they were insufficiently confident.

[grifare]

Testers always have the option of reporting a test as incomplete because they were insufficiently confident.

You are the rule writers, we testers are the rule getters.
Perhaps you don't interact with testers daily anymore. As a tester, let me tell you the truth: testers are all too confident at all times and they love to record "errors" force-fitting anything they dislike in one WCAG criterion or another. One reason I volunteered for this job was that a tester started to fail any heading that did not repeat the next paragraph relying on this page I am trying to rewrite.

I believe the official ACT page should include these somehow, somewhere:

• Subjectivity must be mentioned
• Limitations should be listed
• Test-to-pass versus test-to-fail concept, which will reduce false positives

Perhaps "Assumptions" was not the right section or what I wrote was not the right way to point these out.

• It could be re-worded so that similar points can be made while referring to content rather than the testers?
• Issues could be called "limitations" within this section?

For now, I made the following changes:

• Removed language-related clause, as it is almost obvious that one would not evaluate a language they have no clue about.
• Changed a few words.

[WilcoFiers]

Same as above. This seems like it belongs in a testing methodology (such as Trusted Tester). That's not the purpose of an ACT rule. Different testers can handle this differently, it is not up to us to prescribe these kinds of things.

[WilcoFiers]

Can you use the default phrase from the template: https://github.com/act-rules/act-rules.github.io/blob/develop/pages/design/atomic-template-empty.md

[grifare]

Like this? Done.

Accessibility Support

There are no accessibility support issues known.

[grifare]

Thanks so much. I made some changes, had some objections, and will make other changes once you confirm.
I would appreciate, if you could also verify the examples format I should use.