W3C home > Mailing lists > Public > public-html-admin@w3.org > September 2013

[Bug 23371] New: Strong Native Semantics table appears to imply @hidden trumps @aria-hidden

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 Sep 2013 15:05:57 +0000
To: public-html-admin@w3.org
Message-ID: <bug-23371-2495@http.www.w3.org/Bugs/Public/>

            Bug ID: 23371
           Summary: Strong Native Semantics table appears to imply @hidden
                    trumps @aria-hidden
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: faulkner.steve@gmail.com
        QA Contact: public-html-bugzilla@w3.org
                CC: jcraig@apple.com, mike@w3.org,
                    public-html-a11y@w3.org, public-html-admin@w3.org,
        Depends on: 23370

+++ 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"?

You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 26 September 2013 15:06:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:57:24 UTC