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/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23377

--- 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.3.1 : Wednesday, 7 January 2015 15:05:35 UTC