This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
(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.
(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?
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?
(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" '''
>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
(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
(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?
(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>
(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". """
(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.
mappings moved to html acc API spec. http://www.w3.org/TR/html-aam-1.0/