25614 2014-05-08 21:35:58 +0000 @required and @disabled need to be moved to the Strong native semantics table 2015-06-05 14:46:32 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC All RESOLVED MOVED a11y P2 normal --- 1 jcraig faulkner.steve jcraig lwatson mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 105487 0 jcraig 2014-05-08 21:35:58 +0000 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. 105488 1 jcraig 2014-05-08 21:37:24 +0000 (In reply to James Craig from comment #0) > 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. Otherwise, if you don't want to do either of these things, don't use a native form field. Use <div contenteditable role="textbox" aria-required="true"> or something else. 105644 2 faulkner.steve 2014-05-11 19:42:43 +0000 (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? 105704 3 faulkner.steve 2014-05-12 10:12:16 +0000 I can see an argument for moving 'input, select or textarea element with a required attribute The aria-required state set to "true" If specified, the aria-required state must be set to "true"' to the strong table as it can't be overridden leaving 'input, select or textarea element without a required attribute aria-required set to "false" If specified, the aria-required state set to "true" or "false"' http://www.w3.org/html/wg/drafts/html/master/dom.html#sec-implicit-aria-semantics in the implicit table as it can be overridden. thoughts? 105804 4 jcraig 2014-05-13 02:12:40 +0000 (In reply to steve faulkner from comment #3) > I can see an argument for moving > > 'input, select or textarea element with a required attribute > The aria-required state set to "true" > If specified, the aria-required state must be set to "true"' > > to the strong table as it can't be overridden > > leaving > > 'input, select or textarea element without a required attribute > aria-required set to "false" If specified, the aria-required state set to > "true" or "false"' If you leave the second piece in, we get conflicts where HTML5 @required is false (implicit via missing boolean attribute), but @aria-required is true: <input aria-required="true"> I understand the argument that this may be an HTML4 retrofit, and the author clearly intended it to be required, so I agree that the ARIA attr should win here. However, I think there should be an validation error if aria-required="true" is defined and the required attribute is missing. Would you be amenable to that change? Also... Since the @disabled boolean attribute has been available longer, do you have any objection to including these two in the Strong table? ''' input, select, or textarea element with a disabled attribute. The aria-disabled state set to "true". If specified, the aria-disabled state must be set to "true"' input, select, or textarea element without a disabled attribute. The aria-disabled state set to "false". If specified, the aria-disabled state must be set to "false" ''' 105819 5 faulkner.steve 2014-05-13 08:34:53 +0000 >If you leave the second piece in, we get conflicts where HTML5 @required is >false (implicit via missing boolean attribute) the ARIA mapping tables is full of conflicts - authors can override many native accessibility semantics 105820 6 faulkner.steve 2014-05-13 08:36:51 +0000 (In reply to James Craig from comment #4) > Also... > > Since the @disabled boolean attribute has been available longer, do you have > any objection to including these two in the Strong table? > > ''' > input, select, or textarea element with a disabled attribute. > The aria-disabled state set to "true". > If specified, the aria-disabled state must be set to "true"' > > input, select, or textarea element without a disabled attribute. > The aria-disabled state set to "false". > If specified, the aria-disabled state must be set to "false" > ''' can do if you think it makes what is already there clearer 105864 7 jcraig 2014-05-13 16:20:57 +0000 (In reply to steve faulkner from comment #5) > >If you leave the second piece in, we get conflicts where HTML5 @required is >false (implicit via missing boolean attribute) > > the ARIA mapping tables is full of conflicts - authors can override many > native accessibility semantics But attributes with identical semantics (disabled, required, etc.) are the one place ARIA defers to the host language. I understand the conflict here. I just think we should discourage it with a validation error. Something like this: """ Error: aria-required="true" is used on a form element that does not include the required attribute. Note: The input, select, and textarea elements support the boolean 'required' attribute in HTML5. If the element is required, use required="" in addition to aria-required="true". """ Mike Smith, since you work on the validator, what do you think of this? 105865 8 faulkner.steve 2014-05-13 16:30:36 +0000 (In reply to James Craig from comment #7) > (In reply to steve faulkner from comment #5) > > >If you leave the second piece in, we get conflicts where HTML5 @required is >false (implicit via missing boolean attribute) > > > > the ARIA mapping tables is full of conflicts - authors can override many > > native accessibility semantics > > But attributes with identical semantics (disabled, required, etc.) are the > one place ARIA defers to the host language. I understand the conflict here. As I pointed out the semantics are not identical in Comment 2 >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> 105866 9 jcraig 2014-05-13 16:34:04 +0000 (In reply to steve faulkner from comment #6) > (In reply to James Craig from comment #4) > > > Also... > > > > Since the @disabled boolean attribute has been available longer, do you have > > any objection to including these two in the Strong table? > > > > ''' > > input, select, or textarea element with a disabled attribute. > > The aria-disabled state set to "true". > > If specified, the aria-disabled state must be set to "true"' > > > > input, select, or textarea element without a disabled attribute. > > The aria-disabled state set to "false". > > If specified, the aria-disabled state must be set to "false" > > ''' > > can do if you think it makes what is already there clearer Are you talking about this one row or is there something more I missed? > Element that is disabled. The aria-disabled state set to "true". Yes, I think it's more clear because it would allow validation errors on examples like this: <input aria-disabled="true"> (missing @disabled). Seems like you could also use this format if you preferred. """ Element that is disabled. The aria-disabled state set to "true". If specified, the aria-disabled state must be set to "true". Element that is not disabled. The aria-disabled state set to "false". If specified, the aria-disabled state must be set to "false". """ 105867 10 jcraig 2014-05-13 16:38:58 +0000 (In reply to steve faulkner from comment #2) > Why would we want to force developers to add required to explicitly indicate > to AT users that a particular control is required? To mitigate the error cases where the author has remembered to update one attribute but forgotten the other. I developers forget to update their @aria-required, @aria-invalid, and even @aria-checked states frequently. We can't stop them from doing this, but we can encourage them to keep the native and ARIA values in sync. 120737 11 faulkner.steve 2015-06-05 14:46:32 +0000 mappings moved to html acc API spec. http://www.w3.org/TR/html-aam-1.0/