Prohibit authors from causing conflict resolutions

[WilcoFiers]

I was on an ACT related call yesterday, where there was pretty unanimous agreement that accessibility tools should flag occurrences of presentational roles conflict resolution as a best practice issue. Something has clearly gone wrong if you put role="none" and aria-label on the same img element. Right now it seems like ARIA condones this, and just relies on UA to address it. it seems to me that in addition to having the UAs address the problem, authors should be prohibited from doing this in the first place.

As a comparison, in HTML, browsers always use the first title element as the page title, but despite that it is still invalid HTML to have more than one title element. I think that idea, of both prohibiting an obviously bad practice, while still ensuring UA handle things consistently is a good one to follow here too.

[pkra]

Something has clearly gone wrong if you put role="none" and aria-label on the same img element. Right now it seems like ARIA condones this,

In the current draft, role=presentation lists aria-label under "Prohibited States and Properties":

aria/index.html

Lines 6409 to 6416 in 646f093

	<th class="role-disallowed-head" scope="row">Prohibited States and Properties:</th>
	<td class="role-disallowed">
	<ul>
	<li><pref>aria-label</pref></li>
	<li><pref>aria-labelledby</pref></li>
	</ul>
	</td>
	</tr>

[carmacleod]

@jnurthen I think this issue can just be closed as "resolved in ARIA 1.2", and does not need to be deferred to ARIA 1.3?

As @pkra mentioned, the ARIA 1.2 Working Draft for role="presentation" explicitly prohibits aria-label and aria-labelledby in its Characteristics table.

[jnurthen]

closing as suggested

[WilcoFiers]

I don't think this should have been closed. Yes, aria-label is now explicitly prohibited on role=presentation. But the problem is just as valid on other global ARIA attributes. There is nothing in ARIA that prohibits content authors from doing stuff like this, which causes role=none to be ignored:

<h1 role="none" aria-hidden="false">

[pkra]

@WilcoFiers your #1489 was added to the v1.4 milestone on the last WG call (which is where most issues related to aria-hidden are right now).

[joanmarie]

There's this example in our spec:

<!-- 1. [role="presentation"] is ignored due to the global aria-describedby property. -->
<h1 role="presentation" aria-describedby="comment-1"> Sample Content </h1>

I agree with @WilcoFiers that we don't want to encourage this. Setting none/presentation to having 0 properties in its characteristics table seems like it might be a way to discourage authors. Perhaps also we can add a note like, "If you make this focusable, you are a bad person." 😀

[WilcoFiers]

I opened a PR that sort of fits with what I discussed with @jnurthen on Slack.

[Jym77]

Another case for this is when the conflict resolution is triggered by the (possibly) presentational element being focusable.

In ACT rules, we have a rule Element with presentational children has no focusable content. However, with ARIA 1.2, the conflict resolution tells to ignore the inherited presentational role and expose the focusable element (act-rules/act-rules.github.io#2000).

If causing the conflict resolution was an author error, we could keep flagging that (and map to ARIA rather than WCAG 4.1.2); but if it is not, we should probably just deprecate that rule.

Here's an example of a failure:

<button>
  Save
  <span role="button" aria-label="save options" aria-expanded="false" tabindex="0">▼</span>
</button>

[scottaohara]

seems like deprecating the rule would be premature, since behavior is inconsistent depending on navigation method (virtual cursor vs tabbing), the platform and the screen reader / browser pairing.