- From: <bugzilla@jessica.w3.org>
- Date: Sun, 11 May 2014 19:42:43 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25614 --- Comment #2 from steve faulkner <faulkner.steve@gmail.com> --- (In reply to James Craig from comment #0) > Follow-on to: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23377#c6 > > @required and @disabled need to be listed in the Strong native semantic > table as they are the exact same semantic as @aria-required and > @aria-disabled. If an author does not want the default style of > html:*[required], he or she should override it with a CSS style block. If an > author does not want the default handling of a form that contains elements > with @required specified, he or she should fix it with a custom submit > handler. > > As it is, we've got conflicting boolean values that still need to be > resolved by browsers heuristics. That's an anti-pattern. @disabled is in the strong semantics table. @aria-required is not as its false/absent state can be overridden by authors I think this is sensible because there is a common pattern of declaring the required state of a control via the use of text/image/symbol name * <input> name (required) <input> name <img alt="required"> <input> Other considerations: aria-required does not equal HTML5 required: Setting required on a control sets the state of the control to required and invalid the equivalent of: <input aria-required=true aria-invalid=true> Setting required invokes UI behaviour: auto validation auto display of error message(s) The above can be suppressed via the use of the formnovalidate attribute [3] Why would we want to force developers to add required to explicitly indicate to AT users that a particular control is required? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Sunday, 11 May 2014 19:42:44 UTC