This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23371 - Strong Native Semantics table appears to imply @hidden trumps @aria-hidden
Summary: Strong Native Semantics table appears to imply @hidden trumps @aria-hidden
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: steve faulkner
QA Contact: HTML WG Bugzilla archive list
Keywords: a11y, CR
: 23370 (view as bug list)
Depends on: 18574 23370
  Show dependency treegraph
Reported: 2013-09-26 15:05 UTC by steve faulkner
Modified: 2014-01-13 17:18 UTC (History)
9 users (show)

See Also:


Description steve faulkner 2013-09-26 15:05:57 UTC
+++ This bug was initially created as a clone of Bug #23370 +++

The Strong Native Semantics table:

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"?
Comment 1 steve faulkner 2013-09-27 09:21:05 UTC
Agree that aria-hidden on elements without hidden should be allowed, have added this to spec:
Comment 2 James Craig 2013-09-27 19:15:32 UTC
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.
Comment 3 steve faulkner 2013-09-27 19:17:05 UTC
(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
Comment 4 James Craig 2013-09-27 19:17:52 UTC
*** Bug 23370 has been marked as a duplicate of this bug. ***
Comment 5 alexander surkov 2013-12-16 18:23:09 UTC
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
Comment 6 Rich Schwerdtfeger 2014-01-09 16:55:56 UTC

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.
Comment 7 steve faulkner 2014-01-13 17:18:05 UTC
see related bugs