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

[Bug 23376] New: ARIA: Strong Native Semantics table should defined implicit non-required state on form elements (Currently defines required state, but not the implicit inverse)

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 Sep 2013 23:28:39 +0000
To: public-html-a11y@w3.org
Message-ID: <bug-23376-3290@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23376

            Bug ID: 23376
           Summary: ARIA: Strong Native Semantics table should defined
                    implicit non-required state on form elements
                    (Currently defines required state, but not the
                    implicit inverse)
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML a11y Task Force
          Assignee: dave.null@w3.org
          Reporter: jcraig@apple.com
        QA Contact: dave.null@w3.org
                CC: public-html-a11y@w3.org

@required is a Boolean attribute in HTML.
@aria-required is a "true/false" (boolean) attribute in ARIA.

The spec currently defines in the Strong Native Semantics table that:

input element that is required = The aria-required state set to "true"…
select element with a required attribute = The aria-required state set to
"true"…
textarea element with a required attribute = The aria-required state set to
"true"…

but since the HTML host language attribute is Boolean, the same elements
*without* the required attribute defined are implicitly *not* required.
Therefore, the strong native semantics table should also include:

input element that is not required = The aria-required state set to "false"…
select element without a required attribute = The aria-required state set to
"false"…
textarea element without a required attribute = The aria-required state set to
"false"…

Otherwise, the spec is implying that "HTML true is in conflict with ARIA false"
but "HTML false is not in conflict with ARIA true", and defining one-way
conflict resolution does not make sense for a Boolean state like this.


Likewise:
Element that is disabled = The aria-disabled state set to "true"

So the table should also include:
Element that is not disabled = The aria-disabled state set to "false"

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 26 September 2013 23:28:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:35 UTC