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 17:26:02 +0000
To: public-html-a11y@w3.org
Message-ID: <bug-23377-3290-bBs1DEzh4V@http.www.w3.org/Bugs/Public/>

--- Comment #4 from James Craig <jcraig@apple.com> ---
(In reply to steve faulkner from comment #2)

> 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 could accept the behavior you want, but as it's written in the spec, it
conflicts with itself because @required is a Boolean attribute. You need to
make either one of these changes:

1. Either define the "false" state of @required in the Strong Native Semantics
table, where you currently have only the "true" state. (This would effectively
mean @aria-required had no effect on form elements that accept @required.)

2. Move all the mentioned of @required and @aria-required from the Strong
Native Semantics table to the implicit ARIA semantics. (This would allow the
behavior you appear to desire and have outlined above.)

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:29 UTC