Accessibility Violations about react-widgets

[jquense]

hey there,

This is awesome, the extra ARIA help is much appreciated. Thanks for taking the time to submit this. There are a few points I am a bit confused by though.

1. I am not sure I understand what "associated text" means in this case, any insight?
2. I am not sure this is correct, but maybe i am just missing the documentation. This here doesn't make mention of needing an explicit role. That would totally make sense if I was using <span> tags, but buttons have implicit roles, any thoughts?
3. oops, yeah typo! Already fixed upstream
4. This makes sense, but I am not sure what to do about it, I could use the datepicker-input as the the "anchor" in the DateTimePicker widget, but in the case of the calendar, there are no tabIndex >= 0 elements to use, and setting one would mess will a user's own tabIndex duh, i can just set it to zero or pass down tabIndex from datepicker
5. Any thought on how I would fix that? <tables/> can't have a name attribute as far as I know.
6. Fixed!

[redji]

1. This is a tool output for this: Associate text with each FORM control that is not of type "hidden". INPUT controls of type "submit", "reset", and "button" require text to be set in the "value" attribute. INPUT controls of type "image" require text to be set in the "alt" attribute. All other FORM controls are associated with text via the LABEL element. A LABEL is attached to a specific form control through the use of the "for" attribute. The value of the "for" attribute must be the same as the value of the "id" attribute of the form control.
   So it I think it goes down to adding a label.
2. I get this from the tool: "An element that does not have a role must reference only valid WAI-ARIA global properties to enable compatibility with assistive technologies.
   Here is the list of WAI-ARIA global properties that may be applied to any element. Properties that do not appear in this list are considered widget specific properties (e.g., aria-pressed).
   -aria-atomic
   -aria-busy
   -aria-controls
   -aria-describedby
   -aria-disabled
   -aria-dropeffect
   -aria-flowto
   -aria-grabbed
   -aria-haspopup
   -aria-hidden
   -aria-invalid
   -aria-label
   -aria-labelledby
   -aria-live
   -aria-owns
   -aria-relevant
   -aria-required"
   It's not on the list, so I guess it needs to have a role.
3. Nice.
4. Yeah. It's a tricky one.
5. I get this: "To help users navigate a page, WAI-ARIA widgets must have an accessible name specified with aria-label, aria-labelledby or the widget's inner text."
   So maybe aria-label would suffice.

[redji]

So is there a chance for remaining to be fixed anytime soon?

[jquense]

Hey there. I have a few fixed in master I just need to get around to bumping and releasing maybe tomorrow

1. Isn't an issue with the widget persay, providing a name prop to the datepicker will fix this.
2. I don't think I agree with your tool here, buttons have roles and explicitly setting it is weird. So for now I am leaving it alone
3. Fixed
4. Fixed
5. I'm not sure about this. Labelledby doesn't make sense here and the table is not really a widget its a part of one, for now I'm passing until I can look into it more
6. Fixed!