React dom invalid aria hook #7744
Conversation
ghost
added
|
I think this might be a move in the wrong direction, as ultimately we'd like to remove the attribute whitelist all together. This is why we've started warning for unknown DOM properties, as eventually we'd like to render all provided attributes. See #140 and specifically #140 (comment) |
|
@aweary We should at least do this for 15.x. Not sure when 16 will happen but we can make the situation better short-term until we actually solve the attribute whitelist problem. (This is one of the downsides of discussions happening outside GitHub - we talked with Jesse and think we should do this as accessibility is an important thing to focus on) These were always an afterthought from the get-go and while they probably shouldn't have been, we can and should change that. This is a great way to do it. but… What if we made these more first-class citizens so they actually fit in with the other props? It would be hard for the white-list removal situation, but maybe better for React. These attributes don't fit in with the rest at all. They have a dash in them and they aren't camelcase. It's because we just passed anything through (based on the I guess we could do that separately (we talked about it for |
|
@aweary that's a great discussion, thank you for linking me to it. I understand the hesitation to add yet another whitelist. In this case, we have a finite and known set of attributes; one that is arguably an extension of the DOM spec (or should have been 😄). @zpao You highlight an issue that leads to frustrating variations in the components I encounter: |
|
Yes, I wasn't aware you guys discussed this already 😄 I agree, accessibility should always be a focus, so this looks good to me overall.
I really like this idea for |
| 'tag. For details, see https://fb.me/invalid-aria-prop' | ||
| ); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
Can we also add a test verifying we get a warning when passing in a valid aria- attribute with invalid casing?
There was a problem hiding this comment.
Certainly. Good call.
| expect(console.error.calls.argsFor(0)[0]).toContain( | ||
| 'Warning: Invalid aria prop `aria-hasPopup` on <div> tag. ' + | ||
| 'For details, see https://fb.me/invalid-aria-prop' | ||
| ); |
There was a problem hiding this comment.
Since we're using injectDOMPropertyConfig these aria- properties should be populated in DOMProperty.getPossibleStandardName. ReactDOMUnknownPropertyHook uses that to make a recommendation when warning for improperly cased props.
Can you do the same in ReactDOMInvalidARIAHook? That way if someone passes down aria-hasPopup it will ask if they meant aria-haspopup.
There was a problem hiding this comment.
Great suggestion. I added the changes to address this change request.
|
@jessebeach looks great, thank you! |
|
Thank you all for the good discussion and getting this into React 🎉 |
* Add a hook that throws a runtime warning for invalid WAI ARIA attributes and values. * Resolved linting errors. * Added a test case for many props. * Added a test case for ARIA attribute proper casing. * Added a warning for uppercased attributes to ReactDOMInvalidARIAHook (cherry picked from commit 59ff774)
* Add a hook that throws a runtime warning for invalid WAI ARIA attributes and values. * Resolved linting errors. * Added a test case for many props. * Added a test case for ARIA attribute proper casing. * Added a warning for uppercased attributes to ReactDOMInvalidARIAHook
|
thank you @jessebeach |
Currently, React treats all
aria-*props as custom props. There are 46 ARIA attributes; we can easily enumerate all of them and verify that anaria-*prop on an element exists in the spec.https://www.w3.org/TR/wai-aria-1.1/#states_and_properties
I've included the list of props from the upcoming ARIA 1.1 Working Draft. I work with one of the editors of this specification. It's currently taken about 3 years to update from 1.0 to 1.1. We should not expect any churn in this list of props in the short- or mid-term future.