This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #23370 +++ The Strong Native Semantics table: http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-strong-native-semantics Seems to imply that @hidden and @aria-hidden are identical in semantic meaning. Element with a hidden attribute... The aria-hidden state set to "true" If that's what this implies, then it means that @aria-hidden="true" could not be applied on an element that was missing the @hidden attribute, then we’d have some real problems. It's a common practice to aria-hidden on visually rendered elements to remove redundant or otherwise problematic interface elements from the accessibility APIs. I'm either misinterpreting the intent of this table or the row in question is a bug in the HTML spec. My confusion may be due to the fact that the table column is called "Strong native semantics *and* default implicit ARIA semantics" which are actually two separate things. Does this row represent "Strong native semantics" or does it represent "default implicit ARIA semantics"?
Agree that aria-hidden on elements without hidden should be allowed, have added this to spec: https://github.com/w3c/html/commit/fc876ff6f25e34af6ed46de9c2810c87de707cd4
You can't have [hidden] be strong semantics and :not([hidden]) be weak native semantics. That doesn't make sense. These both have to be in the weak table.
(In reply to James Craig from comment #2) > You can't have [hidden] be strong semantics and :not([hidden]) be weak > native semantics. That doesn't make sense. These both have to be in the weak > table. OK, will make an edit and post for feedback
*** Bug 23370 has been marked as a duplicate of this bug. ***
Thinking more on the argument made on the call that if aria-hidden="true" overrides for AT the absence of @hidden attribute on the element then it's logical if aria-hidden="false" would override the presence of @hidden attribute. But it gets different from case of aria-disabled and disabled, i.e. <input aria-disabled="true"> disabled input but <input aria-disabled="false" disabled> still disabled
@Alex, In the case of aria-hidden="true" FF does indeed expose the tree to the AT but provides the attribute. In the case of hidden being present we are asking you to do the same thing. Expose the subtree to the AT and expose the object attribute to the AT. All the other browser agreed with this approach and FF is not being consistent with its implementation if it is not following this approach. So, all the other browsers agree with exposing the tree when @hidden is applied and exposing the aria-hidden attribute. FF should support consistency in its implementation with the other browsers and with its own implementation. Allowing this would allow future browser implementations to expose structural semantics of hidden elements - which is the use case we are trying to meet. As for aria-disabled and disabled having aria-disabled="false" override it makes no sense for the following reasons: - It will still be functionally disabled as aria is not allowed to override the functionality of the interface. - making it false provides no value to the disabled user and there is no use case benefit that would help the disabled user by allowing aria-disabled="false" to override it. So, for these reasons aria-disabled="false" really does not buy anything for the disabled user and the two examples really can't be compared. Please correct the Firefox implementation to be consistent with what was agreed on by the other browsers.
see related bugs