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

feat(ListBox): fix labels of trigger buttons #4820

Merged
merged 15 commits into from
Jan 9, 2020

Conversation

asudoh
Copy link
Contributor

@asudoh asudoh commented Dec 5, 2019

This change fixes an DAP error in <ListBox.Field> that happens because its aria-label not matching its text content. DAP takes aria-labelledby as a preferred label content (over text content or aria-label), and thus this change add aria-labelledby to <ListBox.Field>.

The original aria-label content, which is for letting user know that the UI can open/close menu, is replaced with a browser's native approach to tell assistive technology that the button is a pop-up button and let screen reader announce as such.

This change also changes <label> to <span> for dropdown and non-filterable multi select given there is no form control (<input>) associated with it.

Fixes #4531.

Changelog

New

  • A mechanism to map <ListBox.Field> to list box label.

Changed

  • Replaced <label> with <span> for the labels of dropdown and (non-filterable) multi select.

Removed

  • aria-label from the <div role="button"> in <ListBox.Field>.

Testing / Reviewing

Testing should make sure combo box, drop down, multi select, filterable multi select are not broken.

For reviewers - It's easier to review with whitespace change ignored, it can be done by clicking on the gear icon in Files changed tab and check off "Hide whitespace changes".

This change fixes an DAP error in `<ListBox.Field>` that happens
because its `aria-label` not matching its text content. DAP takes
`aria-labelledby` as a preferred label content (over text content or
`aria-label`), and thus this change add `aria-labelledby` to
`<ListBox.Field>`.

The original `aria-label` content, which is for lettting user know that
the UI can open/close menu, is replaced with a browser's native
approach to tell assistive technology that the button is a pop-up
button and let screen reader announce as such.

This change also changes `<label>` to `<span>` for dropdown and
non-filterable multi select given there is no form control (`<input>`)
associated with it.

Fixes carbon-design-system#4531.
@netlify
Copy link

netlify bot commented Dec 5, 2019

Deploy preview for the-carbon-components ready!

Built with commit 4894b65

https://deploy-preview-4820--the-carbon-components.netlify.com

@netlify
Copy link

netlify bot commented Dec 5, 2019

Deploy preview for carbon-components-react ready!

Built with commit 4894b65

https://deploy-preview-4820--carbon-components-react.netlify.com

@netlify
Copy link

netlify bot commented Dec 5, 2019

Deploy preview for carbon-elements ready!

Built with commit 4894b65

https://deploy-preview-4820--carbon-elements.netlify.com

@joshblack
Copy link
Contributor

One thing, do we even need the aria-label to call out Open menu? Screen reader software would be able to say whether the listbox is open/closed through aria-haspopup and aria-expanded if I understand correctly.

@asudoh
Copy link
Contributor Author

asudoh commented Dec 5, 2019

This PR removes aria-label to call out Open menu.

@joshblack
Copy link
Contributor

For sure! Sorry if I wasn't clear. I was just thinking through the DAP violation and it seemed like only removing the aria-label would be required as the violation seemed to be due to the mismatch of the aria-label being Open menu but the content being different.

What is the expected behavior for VO if the button/field is associated with the label? Specifically, how are we thinking the value would be announced?

@asudoh
Copy link
Contributor Author

asudoh commented Dec 6, 2019

If we just remove aria-label, the text content inside the trigger button is announced, which will introduce a regression losing the announcement of the trigger button's "toggling" nature.

@joshblack
Copy link
Contributor

joshblack commented Dec 6, 2019

introduce a regression losing the announcement of the trigger button's "toggling" nature.

This is why I said this above:

Screen reader software would be able to say whether the listbox is open/closed through aria-haspopup and aria-expanded if I understand correctly.

As a result, the idea was that this would not need to be communicated through aria-label.

@asudoh
Copy link
Contributor Author

asudoh commented Dec 6, 2019

Seems that you have a specific change you have in your mind, or specific lines in this PR that you think should be removed. Do you want to put the code snippet if it's the former? Do you want to put some links to the specific lines of code if it's the latter? Thanks!

@joshblack
Copy link
Contributor

If I understand correctly, the diff would be:

  • Remove aria-label from bx--list-box__field (already done)
  • Associate bx--list-box__field with bx--label (already done) and bx--list-box__label through aria-labelledby so that the value is communicated
  • Associate bx--form__helper-text with bx--list-box__field through aria-describedby

Could easily be wrong though, I believe the structure we have in general is inverted (e.g. trigger is a descendant of listbox, two nodes with role="listbox", etc.) and we need to correct those as well for ARIA to work as intended 👍 This also changes between different types (listbox vs combobox, etc)

Reference:

cc @dakahn just to confirm, don't want to steer anyone in the wrong direction here 👍

@asudoh
Copy link
Contributor Author

asudoh commented Dec 13, 2019

Associate bx--list-box__field with ... and bx--list-box__label through aria-labelledby so that the value is communicated

Did you mean a change to <div class="bx--list-box__field"> adding aria-labelledby pointing to <span class="bx--list-box__label"> or something else?

@joshblack
Copy link
Contributor

Yup! <div class="bx--list-box__field" aria-labelledby="bx-label-id list-box__label-id">

@asudoh
Copy link
Contributor Author

asudoh commented Dec 17, 2019

Above suggested changes are fine with me, updated.

@abbeyhrt
Copy link
Contributor

Hey @asudoh! For the MultiSelect component, it seems like this PR gets rid of the "Accessible name does not match visible text" DAP violation but then creates a "An interactive/widget must have an accessible name" violation. Not sure if we want/need to address this is in this PR but figured i'd point it out!

@asudoh
Copy link
Contributor Author

asudoh commented Dec 18, 2019

@abbeyhrt Thank you for testing - Not sure if it's a false positive or not, but fixed anyway.

@joshblack
Copy link
Contributor

@abbeyhrt do you have a chance to re-review?? 👀

const title = titleText ? (
<label htmlFor={id} className={titleClasses}>
<span id={id} className={titleClasses}>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like the id being used here and in ListBox is causing a DAP violation:
Screen Shot 2020-01-07 at 4 41 22 PM

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch @abbeyhrt! Was an error in rebasing. Fixed.

Copy link
Contributor

@abbeyhrt abbeyhrt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! 🎉

@asudoh asudoh merged commit f87a204 into carbon-design-system:master Jan 9, 2020
@asudoh asudoh deleted the listbox-field-labelref branch January 9, 2020 08:58
This was referenced Feb 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

AVT 1 - Dropdown had DAP violations
3 participants