Allow aria-hidden one elements with hidden

[masi]

Allow aria-hidden together with hidden, because the latter will a) be overriden by CSS and b) may be changed with JavaScript.

The purpose of hidden is to define an initial state. It's a perfect use case to use them together.

This rule only triggers unwarranted errors in HTML validators, see https://github.com/validator/validator/issues/1084

[scottaohara]

As was already mentioned in the linked thread, hidden in its default state already serves the purpose of hiding content both visually and from the browser's accessibility tree.

In the default state the use of both together is redundant and thus unnecessary.

Per your points, yes JS can be used to remove the attribute all together, or CSS can be used to overwrite its intended semantics/obscuring of the element from the a11y tree. However, you've then created a situation where you are advocating for revealing content visually, but not exposing it to the accessibility tree as aria-hidden=true remains. So without further context beyond not wanting to receive HTML validation errors, I am unsure why we would modify this rule since it:

1. is indicating unnecessary redundancy to the author
2. is flagging a situation where content could be exposed visually (per your use case) but still hidden from users of assistive technologies.

If point 2 is a situation that is desired, then it should be for very good reasons (e.g., the visually revealed content is also revealed to assistive technology users via other means). However, even in this situation, there are other conforming ways to achieve this behavior without creating validation errors.

[masi]

My point is that some customers and a11y audits simply cry loud when they see any warning. For my taste the W3C validators is too noisy. Mere redundancy should be labeled "notice" or "info" as nothing bad will happen except a few wasted bytes.

But I asked for that at the validator project. They have been pointing me to this project. Full circle.

https://github.com/w3c/html-aria/issues/254

[scottaohara]

but what's your use case that you need this? again, aside from not wanting a validation error. please provide a good argument for why what you're proposing should be valid, because so far you have not.

[stevefaulkner]

My point is that some customers and a11y audits simply cry loud when they see any warning. For my taste the W3C validators is too noisy. Mere redundancy should be labeled "notice" or "info" as nothing bad will happen except a few wasted bytes.

But I asked for that at the validator project. They have been pointing me to this project. Full circle.

The w3c validator is a HTML conformance checker it is not designed as an accessibility checker, although a small potential subset of potential errors can indicate a failure of WCAG 2.1 4.1.1 Parsing. You can suppress errors and warnings, if you find them distasteful, in the validator interface.

[stevefaulkner]

This rule only triggers unwarranted errors in HTML validators, see validator/validator#1084

a Warning is not an Error this article may be helpful in understanding the difference Short Note on HTML conformance checking

[masi]

@scottaohara If I cannot convince you that the attribute hidden was design to be overridden by CSS, so using it together with aria-hidden is perfectly valid, then we have to agree to disagree.

Is stated initially the use case for it. IMHO this use case justifies that hidden and aria-hidden may be used together.

@stevefaulkner thank you for pointing out the filtering option. But I insist that I don't want to suppress the warnig on astethic reason but on semantic ones.

Please accept my apologies sor writing errors where I should have written warning.

[scottaohara]

@masi you don't have to convince me that the hidden attribute was designed to be overwritten by CSS. I'm well aware of that. What you have failed to convince me of is why what you are proposing wouldn't cause issues that you don't seem to be considering.

So I will outline this again:

The following example is using hidden in the default state, where it applies a low specificity display none to the div. Here aria-hidden=true is redundant to the native hidden semantics. The validator warns the author of this because what they're doing is unnecessary.

<div hidden aria-hidden="true">
  ...
</div>

Here the author has overwritten the hidden semantics and revealed the content visually. However, because they have not modified the aria-hidden attribute or removed it, the content remains hidden to assistive technologies and produces an actual accessibility issue preventing all users equal access to the nested content. Granted, as I mentioned before, there may well be a corner case situation where the revealed content is purposefully hidden but an accessible alternative is also exposed to ensure all users can access the content. A warning here is still good to have because without that described corner case, the likelihood of this producing an accessibility barrier is high.

<div hidden aria-hidden="true" style="display:block">
  ...
</div>

Now, let's say that the author did remember to modify the aria-hidden attribute to be in parity to the overriding of the hidden attribute's semantics:

<div hidden aria-hidden="false" style="display:block">
  ...
</div>

Now we are back to the original example of an author using ARIA when there is no need. A warning again is noted for the unnecessary redundancy. However, this situation is slightly more concerning than the first per this note from the ARIA 1.2 specification:

At the time of this writing, aria-hidden="false" is known to work inconsistently in browsers. As future implementations improve, use caution and test thoroughly before relying on this approach.

So, I ask you again what use case is the doubling up of these attributes necessary? I have outlined above that using both is either simply redundant, or will produce actual (ex 2) or possible (ex3) accessibility issues. What have I missed that you need to use these together, but have not provided evidence of?

[masi]

My use case is that the element will have aria-hidden="true" all the time. Neither the the nullifying of hidden via CSS nor JS would have changed the aria attribute. Settingn aria-hidden to false never crossed my mind.

In the light of the use case you describe I understand that it's not only redundant but dangerous.

I like "hidden" because it doesn't require me to use inline styles. So I came with my use case. But maybe I have still missed a point you made. If so feel free to close the issue. If you see my point but it isn't convincing you then also close the issue.

Cheers.