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

[Bug 23377] 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: Fri, 27 Sep 2013 09:07:03 +0000
To: public-html-a11y@w3.org
Message-ID: <bug-23377-3290-legT88aN65@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23377

steve faulkner <faulkner.steve@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from steve faulkner <faulkner.steve@gmail.com> ---
(In reply to steve faulkner from comment #0)
> +++ 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"

Hi james, 

I think there are legitimate use cases for allowing aria-required on elements
without the required attribute.

It is common practice to have a a control that is marked as required in text
for example using an asterisk:

<label>name * <input></label>

It is not a requirement in HTML5 that this pattern must use the required
attribute to mark the control as required, and there are reasons why an author
may not want to use the required attribute such as they do not want the
associated UI and behaviour that is implemented by some user agents for the
required attribute. Thus in the example above providing the author with the
means to convey the required state to acc APIs via aria-required will improve
the accessibility of the pattern.

I have defined the use of aria-required on controls without the required
attribute as allowed in the spec (see commit below)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 27 September 2013 09:07:04 UTC

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