Update role-supports-aria-props.md: fix code sample

[n-chardon]

fixes #938

[ljharb]

what needs fixing here exactly?

[n-chardon]

the aria-required attribute must have a "true" value to work properly with assistive technology. Without the value, the attribute does not work to inform screenreaders of the "required" state of the group.

Without ="true" in devtools :

With aria-required="true" :

[ljharb]

Thanks. It seems like we don't have any rule or option that can catch this currently - @jessebeach, does this seem like a good addition? Perhaps an option to aria-props or something?

[jessebeach]

@ljharb and @n-chardon, honestly, it strikes me as something that requires its own rule, something like no-empty-boolean-attributes. The attributes that such a rule would apply to are:

aria-atomic
aria-busy
aria-disabled
aria-modal
aria-multiline
aria-multi selectable
aria-readonly
aria-required

And, confusingly, there is a tri-state version (true/false/undefined) of these "boolean" attributes that allow "undefined", which indicates that the attribute is not applicable. Such a state shouldn't exist, but it exists in the spec, so it needs to be accounted for here:

aria-expanded
aria-grabbed
aria-hidden
aria-selected

A good solution is pulling the properties map from https://github.com/A11yance/aria-query/blob/main/src/ariaPropsMap.js and refactoring it into a util. A better solution is referring to aria-query to get the information about the allowed props and their value types rather than having this information hard-coded in this lint rule plugin.

@n-chardon would you like to write up this rule?

[sangikhan29]

@ljharb, do you know why the tests here are failing for this simple update to a md file? I was working on a draft and found similar tests failing. I ran npm run jest on the master branch itself locally and found the same thing.

[ljharb]

Yes, see #937; you can ignore it for now.