One element relevant for multiple success criteria

[EmmaJP]

Following a comment (#1028 (comment)) and meeting discussion, it would seem there are different points of view on how rules should handle multiple success criteria that apply to the same element.

Should there be different rules for an element that needs to meet multiple success criteria?

Or should multiple rules call out pass/fail on the same element?

---

The rule that raised the comment checks if a button (anything with a semantic role of button) has an accessible name, but excludes input elements of type="image" because they also have to satisfy an additional success criteria.

So currently we have two rules checking that buttons have accessible names. And no rule checking that the accessible name of an image button describes its purpose (the additional requirement in SC1.1.1 that isn't part of SC4.1.2).

For these rules, I propose that "Button has accessible name" (97a4e1) should also apply to image buttons. Inapplicable example 1 should be removed and Passed and Failed examples of image buttons added. And that "Image button has accessible name" (59796f) should be reworked as "Image button has accessible name that describes its purpose".

An image button could then pass both rules, or pass the first rule but not the second giving implementers an opportunity to provide clearer error information.

---

Of course, these two rules could have been split out to reduce complexity in the first rule. In which case I propose that "Image button has accessible name" as it currently stands does not relate to SC1.1.1 and an additional rule about the accessible name describing the purpose of the image button is still required.

(incidentally, Passed examples 1 and 6 are essentially the same in "Image button has accessible name")

---

For reference:

• https://github.com/act-rules/act-rules.github.io/blob/93a2a770ad1d8286a8a74a3c7a7baad7edd8f3d8/_rules/button-accessible-name-97a4e1.md
• https://github.com/act-rules/act-rules.github.io/blob/93a2a770ad1d8286a8a74a3c7a7baad7edd8f3d8/_rules/image-button-accessible-name-59796f.md

[spanchang]

Q: "Should there be different rules for an element that needs to meet multiple success criteria?
Or should multiple rules call out pass/fail on the same element?"
Comment: My vote is: multiple rules should call out pass/fail on the same element.
e.g.

1. Consider a span element that functions as a search submit button with a CSS img to indicate functionality visually. The element may fail SC 2.1.1, 2.4.3, 1.1.1, 4.1.2.
   The individual rule for each SC should fail the issue.

2. Then consider a data table with row headers not identified which has a 'Delete' link in the last column.
   The link fails SC 2.4.4 'link purpose in context' so long as the row header issue is not fixed (SC 1.3.1).
   In this case, the rule for SC 1.3.1 data table is simple: to check for row headers in a data table.
   On the other hand, SC 2.4.4 needs to check for context: same para, row/col headers if link is in a table etc.
   The Delete link fails a single SC but is dependent on conformance with another.
   Thanks,
   Sailesh

[Jym77]

Other rules that are affected by this:

• ARIA required context role;
• and Rule: aria-required-owned-element #245

Both are targeting element "with an explicit role different from the implicit role" (and fail 1.3.1: Info and Relationship) because for element with an implicit role, this is also a failure of 4.1.1: Parsing. That makes the applicability super weird, and forces the examples to be like <div role="list">, breaking the First rule of ARIA and thus not being super good examples to show…

[WilcoFiers]

@Jym77 will come up with a proposal.

[EmmaJP]

Following discussion, the potential need for 2 atomic rules to apply only to image buttons does give a reason for "image button has accessible name" to be a separate rule. A composite rule does not have its own applicability and is applicable to all elements that the atomic rules apply to.

For the rule that raised this discussion, it feels odd to flag a success criteria that, while applicable to the element, is not being checked as part of the rule. I'm not sure it (1.1.1) is relevant for a rule that is only checking something else (4.1.2). Possible ways forward (that I can see):

• an additional atomic rule is created toward a composite rule that checks image buttons;
• or the existing rule also checks that the accessible name is meaningful.

My understanding of composite rules was they are used for when a SC cannot be checked via a single atomic rule.

The note added as part of #1101 is relevant to this.

[Jym77]

Trying to sum up and make some proposals… None of them being perfect…

Current situation

• rule "button (not image button) has accessible name" (fails 4.1.2)
• rule "image button has accessible name" (fails 4.1.2 and 1.1.1)

Problems:

• weird applicability of "button (not image button)"
• missing rule "image button accessible name is descriptive" (fails 1.1.1)

I feel the "weird applicability" issue is even weirder for rules "ARIA required context role" and "ARIA required owned element", notably because it forces Passed examples that are doing bad ARIA thing (not using native semantic elements when possible), see #1049 (comment)
All proposals below can be adapted to these rules and (I hope) to any further similar cases.

Proposal 1 (keep going)

Don't change anything, add rule "image button accessible name is descriptive" (fails 1.1.1) (applicability: image button with non-empty accessible name, expectation: name is descriptive).

Problem:
the weird applicability stays

Proposal 2 (focus on element)

ditch current rules and have instead rules

• "button (all) has accessible name" (fails 4.1.2) (applicability: button, expectation: non-empty accessible name)
• "image button has accessible name" (fails 4.1.2 and 1.1.1)
• "image button accessible name is descriptive" (fails 1.1.1).

Problems:

• an image button without accessible name is going to fail 2 rules for the exact same reason. Not a big deal, but annoying. Notably for tool vendors who probably won't like showing the same issue twice to their customers (not a major concern for ACT rules per se, but could be a concern if this result in less implementations being written because tool vendors don't want to spend the effort).

Proposal 3 (focus on element and simplicity)

ditch current rules and have instead single rule

• "button (all) has accessible name" (fails 4.1.2)
• "button (all) accessible name is descriptive" (but that doesn't really fails any SC given that 4.1.2 doesn't require the accessible name to be descriptive 🙄)

Problems:

• We don't detect and flag that an image button without an accessible name is failing 1.1.1. This is not a major problem either given that there are a lot of things we don't detect, but still pretty annoying, especially given that we do know that the problem is here and just can't flag it…
• the second rule is not failing any SC because 4.1.2 doesn't require descriptive accessible name.

Not Proposal 4 (because we can't do it…)

• have an atomic rule "button (all) has accessible name" (fails 4.1.2)
• have an atomic rule "image button accessible name is descriptive" (fails 1.1.1).
• have a composite rule "image button has descriptive accessible name" (fails 1.1.1) that rule would be applicable to image buttons and pass if both atomic rules pass.

An image button without an accessible name would fail both the atomic and the composite rule, but they do not map to the same SC. The composite rule is here just used to add the extra mapping to 1.1.1. Plus the link between both failures is made obvious and explicit by the composition, hence easier to understand for end users or to explain for tool vendors.

Problems:

• we are not allowed to do that because the ACT rule format requires that composite rule has an applicability equal to the atomic rules it uses (union of, to be precise). And I don't think that we have much chances of success if we ask the ACT rule format to charge that…

Proposal 4 (dirty trick with composite rule)

• have atomic rule "button (all) has accessible name" (fails 4.1.2)
• have atomic rule "button (all) is image button" (fails nothing), applicable to all buttons, passes if it is an image button.
• have atomic rule "button (all) accessible name is descriptive" (fails nothing because WCAG has no issue with button (not image button) having crappy accessible name…)
• have composite rule "image button has descriptive accessible name" (fails 1.1.1) that rule would be applicable to all buttons and have expectation "each test target that passes 'button is image button' also passes the two other atomic rules" (i.e. "B(target) implies A(target) and C(target)" in term of logic); or, equivalently, "for each test target, either the test target fails 'button is image button'; or it passes both 'button has accessible name', and 'button accessible name is descriptive'".

A button which is not an image button will pass the composite rule (because it fails "button is image button" and "false implies (whatever)" is true in logic terms).
The only way to fail the composite rule would be to be an image button with no or non-descriptive accessible name, hence we have the correct fail-on-fail relationship with 1.1.1.
There's no duplicate flagging of targets+SC (and the duplicate flagging of target (for different SCs) is made explicit by composition). And all that is allowed by ACT rules format 😁.

Problems:

• it is a bit of a dirty trick with composite rules. All that is perfectly "legal" under the letter of the ACT rule format, but maybe not that much within the spirit…
• the composite rule is going to have weird expectation. Is it weirder than the current applicability (excluding image button)? Not sure…

Proposal 5 (@EmmaJP)

ditch/amend current rules for the following:

• have an atomic rule "button (all) has accessible name" (fails 4.1.2)
• have an atomic rule "image button accessible name is descriptive" (fails 1.1.1) that is only applicable to image buttons that have an accessible name.

Problems: (@Jym77)

• For image buttons without accessible name, we only flag 4.1.2 and not 1.1.1.

[EmmaJP]

Using page title as an equivalent example, there is no composite rule for page title existing and being descriptive. The page title is descriptive sets existing as part of the applicability.

Proposal 5

ditch/amend current rules for the following:

• have an atomic rule "button (all) has accessible name" (fails 4.1.2)
• have an atomic rule "image button accessible name is descriptive" (fails 1.1.1) that is only applicable to image buttons that have an accessible name.

This would cover both accessibility failures for image buttons while not duplicating results.

However, proposal 3 could also work, as 2.4.6 and 1.1.1 have similar intention and could both be brought into play, as a button is a form control and should be appropriately labelled.

[Jym77]

Copying proposal 5 to get all proposals in the same message.

One problem with it is that an image button without any accessible name would only fail the first rule ("button (all) has accessible name") and thus we'll only flags the failure of 4.1.2 and not the failure of 1.1.1.

[kasperisager]

I'm leaning towards your second proposal, @Jym77, as it seems like the simpler approach. Yes, there will be "duplicate" outcomes for the rules developed by the ACT-R, but this is likely to manifest itself anyway once rules from different rule sets are put to practical use. Either way, I'm in favour of pushing the concern of deduplication onto rule implementors if it makes for simpler and easier to follow rules. Otherwise, I fear that we'll quickly run into cases of Chesterton's fence.

[EmmaJP]

Proposal 1 sees an image button with no accessible name fail against 2 rules.
Proposal 2 sees an image button with no accessible name fail against 3 rules.
Proposal 5 sees an image button with no accessible name fail against 1 rule and be an exception to the second rule (though maybe it should fail rather than be inapplicable).

If an image button with no accessible name fails against 4.1.2 and 1.1.1, then there are wider consistency implications for any rules where absent accessible text would also fail a SC that requires it to be descriptive (page titles, headings, form labels, media alternatives).

[Jym77]

Proposal 1 sees an image button with no accessible name fail against 2 rules.
Proposal 2 sees an image button with no accessible name fail against 3 rules.
Proposal 5 sees an image button with no accessible name fail against 1 rule and be an exception to the second rule (though maybe it should fail rather than be inapplicable).

In Proposals 1 and 2, the (proposed) rule "image button accessible name is descriptive" is (should be) only applicable to image buttons with non-empty accessible name (same as in Proposal 5). So Proposal 1 sees it fail 1 rule, and Proposal 2 sees it fails 2 rules.

Sorry if the applicability wasn't clear enough.

[EmmaJP]

I think that's why I raised this issue. In my mind, if an element is failing 2 SC then it should show 2 rule fails, a fail for each applicable SC, rather than one fail for both SC.

In regard the image buttons, having no accessible name fails 4.1.2 and is also one way to fail 1.1.1.

Perhaps there are things I don't understand about this conversation.

[spanchang]

I disagree with:
"Image button has accessible name that describes its purpose".
There should be two distinct tests, one for each SC. Yes there will be two violations flagged.
The description for accessible name rule may include: see also SC 1.1.1 requirements" or similar.
There are many instances where multiple SCs apply to an element. The fix may involve a single action (as in above case where the alt assigned to the button states the purpose of the button) or may require different actions from the developer to resolve the failure for each violation.
Thanks,
Sailesh

[WilcoFiers]

Decision from the group:

1. Include image buttons in the button-acc-name rule
2. Add a new rule testing that the acc name of an image button describes the purpose of the image

[EmmaJP]

This would be more consistent with existing rules, for example the rules around page titles or headings or form controls having an accessible value, and being descriptive of content or purpose.

[EmmaJP]

Other rules that are affected by this:

• ARIA required context role;
• and Rule: aria-required-owned-element #245

Both are targeting element "with an explicit role different from the implicit role" (and fail 1.3.1: Info and Relationship) because for element with an implicit role, this is also a failure of 4.1.1: Parsing. That makes the applicability super weird, and forces the examples to be like <div role="list">, breaking the First rule of ARIA and thus not being super good examples to show…

@Jym77 Do any other rules need to be adjusted following the decisions that lead to #1184?

I think what actually changed was not having what was essentially the same check carried out by 2 different rules. In reality I suspect there will be other times when something like a missing accessible name would cause an element to fail 2 rules for different reasons, and there always will be times when a single rule is relevant for several SC.

[Jym77]

@Jym77 Do any other rules need to be adjusted following the decisions that lead to #1184?

Not from the top of my head…

[WilcoFiers]

I think we were too hasty when we made this decision. The ACT rules format explicitly calls out this example of image buttons.

https://www.w3.org/TR/act-rules-format/#accessibility-requirements-mapping
When an ACT Rule is designed to test conformance to one or more Accessibility requirements documents, the rule must list all accessibility requirements from those documents that are not satisfied when one or more of the outcomes of the rule is failed. For example, when designing a rule for WCAG that tests if image buttons have alternative text, the rule maps to success criteria 1.1.1 Non-text content, and 4.1.2 Name, Role, Value. That ACT Rule will list both success criteria in its accessibility requirements mapping.

The logic is a little convoluted, but it is there. If we write a rule for buttons, including image buttons, because image buttons without an accessible name fail 1.1.1, that rule must map to SC 1.1.1. Secondly because text buttons don't fail SC 1.1.1, and the rules format does not let us write a "failed: further testing needed" mapping, there is no way to write a valid rule that includes both text buttons and image buttons using the ACT rules format. The rules format requires those be put in separate rules, be it indirectly, through the interplay of two requirements:

1. the rule must list all accessibility requirements from those documents that are not satisfied when one or more of the outcomes of the rule is failed.
2. When one or more of the outcomes for a test target is failed, the accessibility requirements are not satisfied for the test subject.

If I remember right, the reason we did this is because we wanted to avoid differences in WCAG mapping, where testers get to essentially just pick if they want to report things like image buttons under 1.1.1, 4.1.2 or both. That too is a source of inconsistency that the rules format aims to address.

[Jym77]

I think there is a problem with that part of the format:

When an ACT Rule is designed to test conformance to one or more Accessibility requirements documents, the rule must list all accessibility requirements from those documents that are not satisfied when one or more of the outcomes of the rule is failed.

The problem is that depending on the test target, failing one rule can result in some SC being satisfied or not. Look for example into the "valid lang" rules. If the document has an invalid lang, it fails rule HTML page lang attribute has valid language tag it currently maps to 3.1.1 only. Yet, in many (not all) cases, failing this rule also violates 3.1.2. We can't have the mapping to 3.1.2 (as fail-on-fail is not guaranteed). But we still have many cases where failing this rule causes 3.1.2 to be not satisfied.

We didn't feel the need to carefully craft the rule so that it target documents whose elements have no lang attribute and thus can also map to 3.1.2 and have a separate rule for documents whose elements have a lang attribute that would only map to 3.1.1.

I think this is a similar situation. I am OK with reading the format as "failing is rule is guaranteed to not satisfy at least these SCs, maybe some more" instead of "failings this rule is guaranteed to not satisfy exactly these SCs, no more, no less". The "no less" part is a strong requirement (fail-on-fail, no false positives). I'm OK with "failing this rule might not satisfy more SCs but this is not always the case so we can't map to them".

I'm not too worried about differences in mappings as long as the ruleset is decent. If we have both "Button (text or image) has accessible name" (mapping to 4.1.2) and "Image button has accessible name" (mapping to 1.1.1 and 4.1.2), then a tool which implement both would report the correct failure.

[EmmaJP]

I will try to have a look at this after GAAD week.

[EmmaJP]

I think this list of possible rule applicability and outcomes summarises the above:

1. Button has accessible name: meets 4.1.2 (and could be considered as contributing to meeting 1.1.1 for some)
2. Button does not have accessible name: fails 4.1.2 (and could be considered a fail of 1.1.1 for some)
3. Text button has accessible name: meets 4.1.2
4. Text button does not have accessible name: fails 4.1.2
5. Image button has accessible name: meets 4.1.2
6. Image button does not have accessible name: fails 4.1.2 and 1.1.1
7. Image button accessible name serves equivalent purpose: meets 1.1.1
8. Image button accessible name does not serve equivalent purpose: fails 1.1.1

Existing related rules appear to be:

• Button has non-empty accessible name which does not cover "image buttons"
• Image button has non-empty accessible name which does not cover SC1.1.1

(Note: Image accessible name is descriptive also does not cover "image buttons")

Pull request #1184 covers the 1/2 and 7/8 pairings exclusively. The earlier decision being that an empty accessible name would fail both rules, but that checking for an accessible name existing would only map to 4.1.2.

Are we instead leaning toward a Proposal 6 where there are 3 rules that cover the 3/4, 5/6 and 7/8 pairings?

• "text button has accessible name" (fails 4.1.2) - applicability: button that's not an image button, expectation: non-empty accessible name
• "image button has accessible name" (fails 4.1.2 and maybe 1.1.1) - applicability: image button, expectation: non-empty accessible name
• "image button accessible name is descriptive" (fails 1.1.1) - applicability: image button, expectation: accessible name serves equivalent purpose to the image

As previously observed, there could be wider implications anywhere something expected to be descriptive might be considered not to be because it is empty. And also anywhere else that an image with alt text may provide the accessible name in place of other text, or where the accessible name needs to describe something in an equivalent way.

[EmmaJP]

Having read everything through, and summarised my understanding above, I'm not exactly sure what I'm supposed to be doing. @WilcoFiers @Jym77 do you know anything more?

[EmmaJP]

Should I update the existing PR to only update the existing rules and add the missing rule? Rather than combine the existing rules.

Or should I create a new PR? It's been a long time since the PR was created, so it probably won't merge well.

[Jym77]

Create a new PR, that will be much cleaner.
And from yesterday's discussion, let's just add a rule "image button accessible name is descriptive" (more or less copied from "image accessible name is descriptive").

[WilcoFiers]

I'm going to close this. The direction the conversation about implementations is going, this is going to matter more than it did before. I don't think we can change this.