Accessibility/usability review

[blackfalcon]

General Support Request

While generally, the auro-flight element passes the bar on accessibility, there is room to improve. These areas are:

1. Screen readers and time, e.g. 2h 45m
2. Reading back time that sounds human, e.g. 7:30 am
3. Updating the readback of airport stations as the actual city, e.g. Seattle versus SEA, which reads back as see.

Support request

Using a spike, look into areas of opportunity where we can improve the readback of screen readers in these key areas.

Possible Solution

I am curious if there is an opportunity to explore an option for the screen reader to read back a phrase that explains the flight data, much like Alt text, versus simply reading back all the data in the element.

[geoffrich]

Is this a duplicate of https://github.com/AlaskaAirlines/auro-flight/issues/8?

[geoffrich]

A few notes here:

1. Introducing substantial screen reader only text has the risk of becoming out of date when the element is updated. For instance, if we apply aria-hidden to the rendered content and add an sr-only text alternative, it would be easy to forget to update the text alternative when we add something new to the rendered element.
2. Existing users may be used to how the flightline is read out, and changing it could disorient them. If we make the element more verbose, this could also slow them down when shopping for a flight.
3. I would be wary of changing how times/dates are represented in an effort to "fix" screen readers. Daily screen reader users are likely used to how these common formats are read out (see quote below). I don't think we should be doing things like replacing "am" with "a m" because it sounds better to us.
4. If we need to expose additional information for screen reader users, why not expose it for everyone? e.g. reading "Seattle" instead of "SEA". Is the concern there that screen reader users won't understand what "sea" refers to? The same concern could apply to sighted users who aren't familiar with airline abbreviations. Can we instead expose the "Seattle" text for everybody?

I say these things with the caveat that I am not perfect and have done many of these things! But I want to make sure that whatever changes we make here will provide a better experience for assistive tech users instead of just changing things because it sounds better to us. Are there/is it possible to get a UX study on this?

Some further references:

For those of us who depend on screen readers and use them all the time, we tend to become use to how the screen reader reads text. As long as you use common formats for text information, we should be able to pick up that information--even if the way the screen reader speaks it sounds unusual.

In fact, sometimes if you listen very carefully to a screen reader user talking, you can catch that we will pronounce words the same as our screen readers do--and we are not even aware of it.

WebAIM email list archives

Most screen reader users are already familiar with how words are spoken by their tools, the quirks associated with abbreviations, dates, times, etc. By trying to override it you run the risk of confusing your users.

Adrian Roselli

It's worth mentioning screenreader users generally use their screenreaders day in and day out, and are familiar with its quirks.

It's a lot like how if your GPS mispronounces a street, you go on with your day.

But workarounds like this can introduce complexity & risk.

The plethora of assistive tech, OSes, browsers, and user settings make it difficult to guarantee what "the screenreader" will announce.

And monkeying with markup to control the pronunciation can in turn make things worse for, for instance, braille display or voice control users.

Ben Myers

[geoffrich]

This article from GOV.UK is also worth a read:

Received wisdom is that users are accustomed to screen readers pronouncing things strangely sometimes, especially if they use more than one screen reader on a regular basis.

If the user is unsure of the way a word is spoken, they can choose to read it one character at a time, or have the screen reader spell it out for them. Some screen readers also have dictionaries where it's possible to change the way a word is pronounced, or add pronunciations for new or unusual words.

So the best answer seems to be: don't write content that works specifically for screen readers, write content that works well for everyone. Use correct punctuation, spelling and grammar, use standard conventions for acronyms and abbreviations, and use words that are appropriate for your audience.

[geoffrich]

Update: in talking with Dale, it turns out there is existing UX research around this. So, points 1 & 2 are less of a concern (though still worth considering). Nothing I commented about should be considered a show stopper, just points of consideration. I just want to make sure that whatever changes we make are backed up by testing with assistive tech users, instead of making assumptions based on our own limited screen reader experience.

[blackfalcon]

Much was discovered with the spike PR. I feel that there is a strong argument to go in this direction, additional consulting with the flight search team is needed prior to execution.

Aside from that, there is nothing stopping the update for SEO which does much of the same thing as the a11y update. I feel that Auro can move forward with that update and then come back to this one in retrospect.

No appending this issue to the v2.0 release just yet.

[blackfalcon]

:tada: This issue has been resolved in version 2.1.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: