Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accessibility Violations #39

Closed
redji opened this issue Jan 25, 2015 · 4 comments
Closed

Accessibility Violations #39

redji opened this issue Jan 25, 2015 · 4 comments

Comments

@redji
Copy link

redji commented Jan 25, 2015

Hi, I am using react-widgets in my project and I also happen to have automated policy tester tool in company I work for. Testing date picker control resulted in ~40 violations. So here it goes:

3 Each form control must have associated text.

  • First is for input.rw-input in div.rw-widget.rw-datetimepicker
  • Second and third is for button.rw-btn-left and button.rw-btn-right in div.rw-header in the popup.

35 The WAI-ARIA property aria-selected is not supported global property on element BUTTON that does not have a WAI-ARIA role.

  • These are for buttons in table.rw-calendar-grid

1 The attribute aria-labeledby referenced by the element TABLE is not a valid WAI-ARIA State or Property.

  • This one is for table.rw-calendar-grid I think author missed a second "l" in "labelledby".

1 Elements having an aria-active descendant property must also contain a tabindex attribute with a value greater than or equal 0

  • This is also for table.rw-calendar-grid

1 A WAI-ARIA widget must have an accessible name

  • This is also for table.rw-calendar-grid

And two potential violations:
2 Elements that use 'role' must contain required child elements for the role

  • First one is for input.rw-input with role="combobox" for which a required child is a "listbox" or "textbox"
  • Second one is for table.rw-calendar-grid with role="grid" for which a required child is "row"
@jquense
Copy link
Owner

jquense commented Jan 26, 2015

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!

jquense added a commit that referenced this issue Jan 26, 2015
jquense added a commit that referenced this issue Jan 26, 2015
@redji
Copy link
Author

redji commented Jan 26, 2015

  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
Copy link
Author

redji commented Feb 2, 2015

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

@jquense
Copy link
Owner

jquense commented Feb 2, 2015

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!

@jquense jquense closed this as completed in f2dd5b8 Feb 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants