search

act-rules / act-rules.github.io

Accessibility conformance testing rules for HTML
https://act-rules.github.io/
Other
136 stars 69 forks source link

One element relevant for multiple success criteria #1049

Closed EmmaJP closed 2 years ago

EmmaJP commented 4 years ago

Following a comment (https://github.com/act-rules/act-rules.github.io/pull/1028#discussion_r351308532) 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:

spanchang commented 4 years ago

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 commented 4 years ago

Other rules that are affected by this:

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 commented 4 years ago

@Jym77 will come up with a proposal.

EmmaJP commented 4 years ago

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):

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 commented 4 years ago

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

Current situation

Problems:

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 https://github.com/act-rules/act-rules.github.io/issues/1049#issuecomment-573675407 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

Problems:

Proposal 3 (focus on element and simplicity)

ditch current rules and have instead single rule

Problems:

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

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:

Proposal 4 (dirty trick with composite rule)

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:

Proposal 5 (@EmmaJP)

ditch/amend current rules for the following:

Problems: (@Jym77)

EmmaJP commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Other rules that are affected by this:

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 commented 4 years ago

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

Not from the top of my head…

WilcoFiers commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

EmmaJP commented 3 years ago

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:

(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?

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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.