Loading state not announced to screen readers

[geoffrich]

Do some research on what current solutions are out there and better understand the issue. Work with ux what the correct experience should be. It's possible that we don't want to say anything.

Describe the bug

The loading state of the button is not conveyed to screen readers.

To Reproduce

See this CodePen.

Tab to the button and trigger it. It will enter a loading state.

When the loading state is triggered, NVDA reads out "unavailable", presumably because the button is disabled. This does not properly convey a loading state.

Expected behavior

The message read by the screen reader includes the text "loading".

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Firefox w/ NVDA

Additional context

This likely needs to be fixed in auro-loader, but I'm creating the issue here because it directly impacts the button.

Bug exit criteria

This issue will be considered complete once a user can click on an element in the browser and the screen reader will announce that the button has moved to an active state per the user's interaction.

[blackfalcon]

Additional context This likely needs to be fixed in auro-loader, but I'm creating the issue here because it directly impacts the button.

I am going to say no on that. The auro-loader is only illustrates an animation. The point of the state is up to the consumer as we have no idea what this state is. "loading" is an assumption that can't be validated.

[geoffrich]

It's an animation, but the meaning still needs to be conveyed somehow to assistive tech, no? Could we have visually-hidden "loading" text by default but allow it to be customized using a slot?

I fear that if we don't do anything, users of the button/loader won't realize they need to add additional text.

Also, the loader already has "Loading" text that appears when prefers-reduced-motion is enabled. So we're already assuming that it's a loading state.

[blackfalcon]

All the loader elements allow for content to be placed within the tags and this is visually hidden by default.

The role of Auro is not to dominate all of the experience. There is still some responsibility left up to the user of the element. I prefer this position as this allows the user to customize this message any way they need. Especially when we get into localization.

I'd argue that there is additional documentation we can do in the demo page to educate users of this.

And with that, we are the consumer of this element so this issue is valid to update https://github.com/AlaskaAirlines/auro-button/blob/master/src/auro-button.js#L151 with a loading statement.

A solution I would like to see is that this is not hard-coded into the element. E.g. we need to consider options like localization and custom messaging.

This is slightly outside the scope of this issue, but how would this change from English to Spanish using loading as a default? How can a user pass in a custom string?

[geoffrich]

All the loader elements allow for content to be placed within the tags and this is visually hidden by default.

That wasn't clear to me -- this should definitely be documented.

A solution I would like to see is that this is not hard-coded into the element. E.g. we need to consider options like localization and custom messaging.

This is slightly outside the scope of this issue, but how would this change from English to Spanish using loading as a default? How can a user pass in a custom string?

If we want this to be customizable, we could provide a named slot in the button that lets the user pass in custom text, and fall back to "Loading" as a default.

I'm not sure how the localization would work in the default case. I think the current localization strategy on AS.com translates strings in the rendered page, but I have no idea how that handles Shadow DOM.

[blackfalcon]

To address this issue we could do:

${
  ifDefined(this.loading 
    ? html`<auro-loader pulse><slot name="a11y-message">Loading...</slot></auro-loader>` 
    : undefined)
}

... the current localization strategy on AS.com translates strings in the rendered page, but I have no idea how that handles Shadow DOM.

The goal is to get ahead of that by being more proactive in string management. But that doesn't change the scope of this update. I'd love to discuss an i18n API for a component.

[blackfalcon]

WAIT! No, this is NOT why this is not being read back to screen readers.

The button is disabled when the loader starts. A string of loading... is already in the element. This is a default string that shows up if a user sets their OS for no-animations.

[geoffrich]

I left a comment on the loader, but that string is not read to screen readers because it's display: none when reduced-motion is disabled.

[blackfalcon]

The issue you are reporting is clearly not an issue with button, but with loader. There is an update we can apply here to make this better, but the 1st update is with loader.

[blackfalcon]

This issue needs a little more research as to what is considered best practices with loaders and AT SRs feedback to users.

@blackfalcon will reach out to UX research team for any direction they may have.