feat(checkout): CHECKOUT-6652 provide accessibility label for Address…

[huntario]

What?

Add aria-labelledby attribute to class name "dropdown--select" and added an ID to the a tag link to which the aria-labelledby can be pointed.

“Some elements get their accessible name from their inner content. For example, the accessible name for a , , or comes from the text between the opening and closing tags.”

“… All interactive elements must have an accessible name. aria-labelledby can be used to reference another element to define its accessible name, when an element's accessible name needs to use content from elsewhere in the DOM.”

Based on this I’ve gone with using aria-labelledby within the element with class name "dropdown--select" directed at the tag link containing the text “Enter a new address” -

aria-labelledby - Accessibility | MDN

...

Why?

CHECKOUT-6652
https://bigcommercecloud.atlassian.net/browse/CHECKOUT-6652
...

Testing / Proof

BEFORE:

AFTER:

...

@bigcommerce/checkout

[bc-peng]

Hi there, Thanks for creating the PR.
Could we record a demo video to show this is working? On a mac, we can use VoiceOver function to test accessibility issue.

[huntario]

Thanks for taking a look @bc-peng . I have to admit, not knowing much about accessibility before taking this on, I took the ticket requirements at face value without considering an actual screen reader. Thank you for being the voice of reason on this. Getting this working with VoiceOver was a bit more involved than I had initially anticipated, but here are the results.

Before:

CHECKOUT-6652-before.mp4

After:

CHECKOUT-6652-after.mp4

Why make AddressSelectButton its own component?
-Needed to use translate, and the pattern within the app seems to be exporting the component withLanguage()

Why “aria-description”?
-“In cases where providing a visible description is not the desired user experience, authors MAY set the accessible description of the element using aria-description. “
https://w3c.github.io/aria/#aria-description

Since we communicate this visually with a down arrow (not words) we need to use description for the screen reader to explain the equivalent with words, and those words are not directly provided on the page. Changing the down arrow to words would be cluttered and undesirable, so “aria-description” seems appropriate.

What about this warning?
“Warning: Invalid aria prop aria-description on tag. For details, see https://fb.me/invalid-aria-prop”

-This warning seems to be an error with React and will be fixed in React 18 - facebook/react#21035 - the error is not valid (see Why “aria-description” above”)

What’s with the changes to checkout-js/src/app/shipping/ShippingAddress.spec.tsx ?
-Without these changes 'calls onAddressSelect when an address is selected' will fail, because the withLanguage() Higher Order Component will not be rendered with mount(). I copied this idea from checkout-js/src/app/address/AddressFormModal.spec.tsx:22~48

Why Remove Combobox?
Combobox seems to be more for a text input box with auto-fill. https://www.w3.org/TR/2019/NOTE-wai-aria-practices-1.1-20190814/examples/combobox/aria1.0pattern/combobox-autocomplete-both.html We want it to read the address and then let the user know that they can select more saved addresses or enter a new address. Using aria-label or aria-labeled by will override the address reading and does not provide an equivalent to the down arrow icon. With combobox, the screen reader expects there to be immediate text input available, so the suggestions are not accurate to what’s going on in the UI (see videos above).

[bc-peng]

@huntario I believe you did an excellent job improving checkout accessibility. 👍🏻👍🏻👍🏻
Just want to confirm this PR won't break BCapp functional tests. What do you think? @animesh1987

[animesh1987]

Looks good to me, we are mostly adding ids and not changing anything specifically.