ACT Rules Review

[jnurthen]

From #1847
Please add comments about each ACT in the correct thread here
Please add a 👍🏻 to a thread if you have reviewed and have no comments

[jnurthen]

Role attribute has valid value

https://www.w3.org/WAI/standards-guidelines/act/rules/674b10/proposed/

[JAWS-test]

Perhaps the check that the ARIA role matches the HTML or SVG element should also be included here (e.g. <input type=text role=link> is not allowed)

This is an Atomic rule to test 1.3.1: Info and Relationships (Level A)

Shouldn't 4.1.2 also be mentioned?

This rule assumes that the role attribute is used to provide an ARIA semantic role to the elements. If it is used for other purposes, this rule shouldn’t be used.

What are other purposes?
ARIA can also be used to remove a role (role=presentation/none).

[scottaohara]

agreed that is seems a bit odd to categorize this under 1.3.1 when 4.1.2 is just if not more so relevant. but, if that's how the rules are written, 1 per SC, then I can see why it was done this way. I'm not sure I agree with it, but I don't have a strong enough opinion on the matter of how to flag overlapping SCs.

Re: roles that are not allowed on specific elements, this does seem something that should have a rule. but I'm not too concerned whether it's part of this rule or is a separate rule. Maybe that's how to qualify why this is a 1.3.1 rule where as the other rule could be flagged under 4.1.2? I dunno... just spitballing here since categorizing this rule under 1.3.1 vs 4.1.2 seems a little hand wavy to me without more context.

note:

Note: The HTML standard suggests setting the CSS display property to none for elements with the hidden attribute.

this is not entirely accurate with the introduction of the 'hidden until found' value for the attribute.

[adampage]

+1 to testing for an element’s permitted roles. I’d vote for it to be a separate “Role is permitted” rule.

[WilcoFiers]

Update from ACT TF. Thanks for the reviews. This rule now maps to both SC 4.1.2 and 1.3.1. I think a "Role is permitted" rule is a good idea, but would be better as its own rule. I've opened an issue for it in act-rules.

[jnurthen]

ARIA state or property has valid value

https://www.w3.org/WAI/standards-guidelines/act/rules/6a7281/proposed/

[scottaohara]

my only comment here is that it's a bit strange that "Role attribute has valid value" is being referenced as a 1.3.1 issue, where as this one is not referenced as an issue by defualt - but alludes to 4.1.2 in the bibliography section. There's an argument to be made that Role attribute has valid value, like this issue, could also be a non-issue in some cases.

[WilcoFiers]

ACT Task Force has been working on this question this year. What we've come up with is a new concept to the ACT Rules Format, that of secondary requirements. A secondary requirement is a requirement that has a strong correlation to the rule, but it isn't an exact match. Like valid ARIA isn't literally required by ARIA, but 95% of invalid ARIA does result in some in some accessibility problem that is a conformance issue in WCAG. Secondary requirements have been added to all ARIA ACT rules that do not already map to WCAG.

[jnurthen]

ARIA state or property is permitted

https://www.w3.org/WAI/standards-guidelines/act/rules/5c01ea/proposed/

[JAWS-test]

language feature: the test target is specified on an HTML element and is allowed on that element

Although the rule also applies to SVG, only HTML is mentioned here. This implies that I can't use non-global ARIA attributes on SVG elements unless they have an ARIA role. I suspect that this is not correct

[JAWS-test]

I am not sure if aria-controls is allowed to be empty, see #531 (comment)

[adampage]

<label><input type="checkbox" aria-checked="false" />My checkbox</label>

Adding to @JAWS-test’s feedback below, ☝🏻 this could be a helpful additional example to demonstrate failure of the “language feature” expectation and to bookend Passed Example 5.

[WilcoFiers]

I'm not sure this is necessary here. Passed example 1 and 11 both show the "language feature" situation. We're not trying not to have an exhaustive list of examples as that would be a little overwhelming to readers, and this is already a rule with an unusually large number of examples. I don't mind adding if this is insisted on, but I personally think this is sufficiently covered.

[jnurthen]

ARIA attribute is defined in WAI-ARIA

https://www.w3.org/WAI/standards-guidelines/act/rules/5f99a7/proposed/

[scottaohara]

seems a straight forward rule.

[jnurthen]

Element with role attribute has required states and properties

https://www.w3.org/WAI/standards-guidelines/act/rules/4e8ab6/proposed/

[JAWS-test]

If I understand correctly, the rule says that required states and properties must always come via an ARIA attribute. There are few ARIA roles where this is not so and even forbidden: e.g. <input type=checkbox role=menuitemcheckbox>:

• menuitemcheckbox must have a checked status
• but the status comes from the HTML checkbox and must not be submitted via aria-checked although menuitemcheckbox has: "Required States and Properties: aria-checked" - see https://www.w3.org/TR/html-aria/#el-input-checkbox and https://www.w3.org/TR/wai-aria-1.2/#menuitemcheckbox

[scottaohara]

Failed Example 1

Prior to WAI-ARIA 1.2 the heading role had an implicit default aria-level value of 2.

it would be nice to see this clarified that this is now defined in the handling author correction section, as otherwise it could be read as there no longer being a fallback value.

[scottaohara]

Applicability

This rule applies to any HTML or SVG element that is included in the accessibility tree and has an explicit semantic role, except if the element has an implicit semantic role that is identical to the explicit semantic role.

agree with @JAWS-test. Seems like this should also mention an exception for instances where the element already has native support for the required states/properties.

I see there's already an inapplicable example for input type=checkbox role=checkbox, but this is not clear enough to know if this rule would correctly allow for input type=checkbox role=menuitemcheckbox as well

[adampage]

<div role="checkbox" aria-checked="false"></div>
<div id="label">Check me</div>

In Passed Example 2, <div id="label">Check me</div> is an odd distraction. If this “passing” checkbox is going to have a label, why not make it well-formed?

[WilcoFiers]

Opened an issue and a PR to address this.

[jnurthen]

ARIA required context role

https://www.w3.org/WAI/standards-guidelines/act/rules/ff89c9/proposed/

[scottaohara]

Hmm. ideally failing example 3 would rather be a bug that browsers fixed rather than being a problem. The reference that aria-live is what causes the issue here isn't entirely accurate as with or without the aria-live attribute webkit/VO and NVDA+Chromium, for instance, each have their own issue with dealing with this pattern.

[WilcoFiers]

We're going to have to revisit this for ARIA 1.3. A lot has changed on the parent/child thing.

[jnurthen]

ARIA required owned elements

https://www.w3.org/WAI/standards-guidelines/act/rules/bc4a75/proposed/

[JAWS-test]

Passed Example 2 is wrong because of grid has cell, but it must have gridcell. Cell is only allowed in table.

But this is a bug in the ARIA specification. It is correctly written in the explanation of grid and table, but not in the tables for the allowed roles. Here the ARIA specification should be adapted and the same notation as for menu should be used

[JAWS-test]

The aria-busy exception occurs only in the this rule, but applies to all rules

[WilcoFiers]

The reason this rule has an aria-busy exception over all the others is because this deals explicitly with content that may still be loaded in. Something like an invalid role or state value, having an incorrect parent element, etc. is unlikely to be resolved once aria-busy is completed, although in theory they could be. I've opened act-rules/act-rules.github.io#2140 for ACT CG to discuss whether we should have an assumption about aria-busy in the other rules.