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 23378 - ARIA: Strong Native Semantics table should defined implicit non-required state on form elements (Currently defines required state, but not the implicit inverse)
Summary: ARIA: Strong Native Semantics table should defined implicit non-required stat...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard: ARIA
Keywords:
Depends on: 23376 23377
Blocks:
  Show dependency tree / graph
 
Reported: 2013-09-27 08:30 UTC by Simon Pieters
Modified: 2014-01-02 21:31 UTC (History)
7 users (show)

See Also:

Attachments

Description Simon Pieters 2013-09-27 08:30:24 UTC 
+++ This bug was initially created as a clone of Bug #23377 +++

+++ This bug was initially created as a clone of Bug #23376 +++

@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"
Comment 1 Ian 'Hixie' Hickson 2013-09-27 18:09:10 UTC 
According to ARIA, false is the default, so it doesn't have to be specified explicitly. See http://www.w3.org/TR/wai-aria/states_and_properties#aria-required
Comment 2 Ian 'Hixie' Hickson 2013-11-13 21:18:04 UTC 
In one of the ancestors of this bug, steve points out that it's reasonable to have an element that's not marked as required="" to be marked as aria-required="" because the element might be labeled in prose as required even though it isn't required="", since the semantic of ARIA's 'required' is merely informative to the user, while required="" implies UA behaviour.

The contrary doesn't make sense.

So required="" should strongly imply aria-required=true (and disallow not having aria-required or saying aria-required=false), and the lack of required should only weakly imply aria-required=false (not disallow setting aria-required=true).

This, as far as I can tell, is what the WHATWG spec says. (Note that the W3C spec has forked from this and seems to be bogus now, e.g. pointing to the wrong definition of "required" on the HTML side, having strong ARIA semantics in the weak ARIA semantics table, unnecessarily setting aria-required to its default, etc. The same mess seems to afflict aria-hidden for some reason.)
Comment 3 steve faulkner 2013-11-13 22:25:00 UTC 
"pointing to the wrong definition of "required" on the HTML side"

thanks for pointing out this bug, as to the rest we can agree disagree :-)
Comment 4 Ian 'Hixie' Hickson 2014-01-02 21:31:53 UTC 
Since there's not been any rationale provided that contradicts what the spec says, and since there's been rationale provided that supports what the spec says, I'm marking this WORKSFORME. Please do reopen the bug if there's a reason why the logic in comment 2 is wrong in some way.