Incorrect aXe / Assure violation: Elements must only use allowed ARIA attributes: for aria-required on radio button

[spanchang]

Example: <input aria-required="true" name="contactme" value="email" type="radio">

The ARIA specs note that
i. aria-required is related to the HTML 'required' attribute
ii. Unless an exactly equivalent native attribute is available, host languages SHOULD allow authors to use the aria-required attribute on host language form elements that require input or selection by the user.

The HTML5 specs say:
For radio buttons, the required attribute is satisfied if any of the radio buttons in the group is selected.

To avoid confusion as to whether a radio button group is required or not, authors are encouraged to specify the attribute on all the radio buttons in a group.
Indeed, in general, authors are encouraged to avoid having radio button groups that do not have any initially checked controls in the first place, as this is a state that the user cannot return to, and is therefore generally considered a poor user interface.

===

Also IMO: It cannot be a best practice recommendation. Not having the attribute on radio button(s) does not enhance accessibility nor is it counter to the specs.

[WilcoFiers]

Yep, I think you're right. This looks fine to me. I did a quick test with VO, which doesn't seem to mind. I don't expect other AT will mind either but we'll need to be sure. Have you tested this with NVDA and JAWS to see if there are any support issues that come up?

[spanchang]

I do not encounter any problems with JAWS / NVDA. Thanks, Sailesh

…

On 9/20/17, Wilco Fiers ***@***.***> wrote: Yep, I think you're right. This looks fine to me. I did a quick test with VO, which doesn't seem to mind. I don't expect other AT will mind either but we'll need to be sure. Have you tested this with NVDA and JAWS to see if there are any support issues that come up? -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #540 (comment)

-- Sailesh Panchang Principal Accessibility Consultant Deque Systems Inc Phone 703-225-0380 ext 105 Mobile: 571-344-1765

[marcysutton]

We should check Mobile VO and TalkBack, as well.

[spanchang]

How At/ browser combos behave with standard code should not dictate whether something is a failure or not. If the AT/browser cannot handle the required attribute or aria-required, it is a limitation of that combo / platform and not a WCAG2 failure. Generally, in some circumstances (read: platforms), if one is limited to a single AT/browser that cannot handle some standard as-per-specs markup, then one can perhaps raise 'AT Support' issue for that platform. This issue does not warrant that and in any case it is working on Windows and OSX. Thanks, Sailesh

…

On 9/20/17, Marcy Sutton ***@***.***> wrote: We should check Mobile VO and TalkBack, as well. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #540 (comment)

-- Sailesh Panchang Principal Accessibility Consultant Deque Systems Inc Phone 703-225-0380 ext 105 Mobile: 571-344-1765

[dylanb]

@spanchang actually, according to the normative portion of the WCAG standard called "accessibility supported", it can be a WCAG failure https://www.w3.org/TR/WCAG20/#accessibility-supporteddef

Specifically, unless you can guarantee a specific combination of technologies where the technique does work (which a system like axe-core cannot assume), if it does not work on a platform your application users use, then it is a WCAG failure.

[KittyGiraudel]

Is axe-core reporting a false-positive regarding aria-required on radios and checkboxes then?

[WilcoFiers]

@hugogiraudel Yes. We'll have to allow aria-required on those. If you're interested, feel free to create a pull request fixing this issue.

[dylanb]

@WilcoFiers This creates a bit of a conundrum...

S.C. 4.1.1 is about forwards compatibility - and these attributes are not allowed on these roles per the current ARIA spec (so we should fail this)
S.C. 4.1.2 is about does it work (so we should pass this)

All the attributes are bunched into a single rule so we cannot differentiate.

What to do?

[dylanb]

Also, what does it mean (semantically) to have aria-required="true" on all the radio buttons in a group where you can only select one radio button?

[WilcoFiers]

I disagree about our ARIA rules falling under 4.1.1 in the first place. We've had that discussion before. 4.1.1 asks for 4 very specific things: 1) Have required start/end tags, 2) Correct nesting, 3) No duplicate attributes, 4) IDs are unique. Valid ARIA isn't one of them. I suppose you could argue that it's in line with what this is asking, sure, but the text of the SC isn't asking for it. In my mind, all of our ARIA rules should be 4.1.2, and for certain scenarios 1.3.1. We've never distinguished them at that level though, and I wouldn't think this is the PR to sort this out in.

[marcysutton]

I would love some clarification on this language:

Unless an exactly equivalent native attribute is available, host languages SHOULD allow authors to use the aria-required attribute on host language form elements that require input or selection by the user.

Isn't required an equivalent native attribute for INPUT? It's equivalent in terms of the accessibility tree, but I suppose not equivalent for HTML5 input validation.

[dylanb]

@marcysutton where did you pull that language from?

[marcysutton]

@dylanb from the description of this issue, @spanchang wrote it in the section on "ARIA specs note that..."

[spanchang]

That note is from https://www.w3.org/TR/wai-aria-1.1/ Also see HTML 5.1 https://www.w3.org/TR/html51/sec-forms.html#the-required-attribute which permits required on one or all radio buttons in the group. SC 4.1.1 will apply to ARIA attributes if they are duplicated. For instance: <input type="password" id="pwd" aria-describedby="pwdNote1" aria-describedby="pwdNote2" /> I am unclear about Dylan's assertion: "S.C. 4.1.1 is about forwards compatibility " and "S.C. 4.1.2 is about does it work ". Source, please? What's covered by 4.1.1 is likely to cause accessibility problems because these are required of markup validation in the first place . And if some browser-AT combo does not trip up on one of these it is likely some other combo on a different platform might. This is important as one cannot test all platforms everytime. That's why it is under Robust Principle. So running 4.1.1 test before running any other accessibility test is the best way to go especially as this can be automated. Best wishes, Sailesh

…

On 12/4/17, Marcy Sutton ***@***.***> wrote: @dylanb from the description of this issue, @spanchang wrote it in the section on "ARIA specs note that..." -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #540 (comment)

-- Sailesh Panchang Principal Accessibility Consultant Deque Systems Inc Phone 703-225-0380 ext 105 Mobile: 571-344-1765