- From: <bugzilla@jessica.w3.org>
- Date: Sat, 28 Sep 2013 08:19:41 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23377 --- Comment #6 from steve faulkner <faulkner.steve@gmail.com> --- (In reply to James Craig from comment #4) > (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.) Hi james, > I could accept the behavior you want Do you consider the use case i outlined is reasonable? I will follow you advice and move into implicit only table, but will keep restraint that when required is present aria-required, if specified, must be set to true. Sound OK? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Saturday, 28 September 2013 08:19:42 UTC