See the sub-tasks and Willa Armstrong [X] to add to this description.

During Accessibility review to get 3.0.0 with Audiobooks ready for release, a few accessibility issues where found more difficult to fix and need either redesign or further investigation.

When a patron is using a screenreader, changes in status/affirmations need to be communicated.

Visually, patrons receives feedback in the form of buttons changing, buffering status.

Status changes happen in a few views for a few interactions.

The views are

• catalog
• book detail pages
• my books
• reservations
• audiobook player

The interactions are:

• Reserving an item (catalog, book details)
• Getting an item (catalog, book details, reservations)
• Downloading an item (catalog, book details, my books, reservations)
• Returning an item (catalog?, book details, my books)

For each of these a user will:
1. Put focus on a button ("Get", "Reserve", "Return", "Download", "Cancel", "Retry", etc.) and select that button.
2. The page will visually change to indicate that a change is happening (ex. "Downloading" with a progress bar.
3. The page will visually change and show either an error message or a new button(s). For example, after "Download" is selected, if the item is successfully downloaded, two buttons "Read"/"Listen" and "Return" will appear.

The issue is that for #2 and #3, that information is not conveyed to a user of a screenreader. In My Books and Catalog view, the download progress bar occasionally will announce, but it is not consistent. Where we need to get to is that #3 is consistently communicated with a screenreader: that that change gets announced and there is confirmation that an action was accomplished.

Error messages for all these interactions also need to be addressed.

Requirements:

1. All state changes during interactions as bulleted above must be announced to any patron using TalkBack screenreader
2. All errors during interactions as bulleted above must be announced to any patron using TalkBack screenreader

Acceptance criteria

1. Any patron using the Android-native TalkBack screenreader should not need to perform additional interactions with the page to be read state changes as they appear dynamically on the screen
2. Any patron using the Android-native TalkBack screenreader should not need to perform additional interactions with the page to be read new errors as they appear dynamically on the screen