1198084 - Tab audio indicator is not a11y friendly

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[:Margaret Leibovic]

In bug 1190301, I'm updating the tab audio indicator UI to use a compound drawable instead of an image button, which means we lost a view with a content description to describe the tab that is playing audio.

My initial idea was to update the tab title view's content description to explain that the tab is playing audio, in addition to the tab title, but maybe it would make sense for this content description to be on a different view.

Marco, do you have any ideas about what Talkback users would expect here? For a bit of context, the UI we built for this feature displays a speaker icon next to the tab title to indicate that the tab is playing audio.

Comment 1

[Marco Zehe (:MarcoZ)]

So, is that speaker icon tapable to mute the audio? If so, the contentDescription for the tab itself should be an indicator "plays audio - " or something similar, followed by the tab title. The reason being that the most important info should come first. In this case, the fact that this is the one making noise and possibly drowning out the speech. And the contentDescription for that speaker icon should say "Mute audio" or something other appropriate. Obviously, once tapped, the contentDescriptions should be updated to reflect the new status. E. g. if you can resume audio playback, the speaker icon needs to reflect that, and the tab title is then "muted audio " followed by the tab title. Of course, if it just goes away and returns to be a normal tab, the tab's contentDescription should just be the tab title itself.

Comment 2

[:Margaret Leibovic]

(In reply to Marco Zehe (:MarcoZ) from comment #1)
> So, is that speaker icon tapable to mute the audio? If so, the
> contentDescription for the tab itself should be an indicator "plays audio -
> " or something similar, followed by the tab title. The reason being that the
> most important info should come first. In this case, the fact that this is
> the one making noise and possibly drowning out the speech. And the
> contentDescription for that speaker icon should say "Mute audio" or
> something other appropriate. Obviously, once tapped, the contentDescriptions
> should be updated to reflect the new status. E. g. if you can resume audio
> playback, the speaker icon needs to reflect that, and the tab title is then
> "muted audio " followed by the tab title. Of course, if it just goes away
> and returns to be a normal tab, the tab's contentDescription should just be
> the tab title itself.

I originally implemented the icon as tapable to mute audio (similar to the desktop Firefox implementation), but we decided that the tap target is too small, so we are reverting this to just be a visual indicator to help you select the tab playing audio.

So, following your advice, I can update the content description to something like "Playing audio - <tab title>". Does that sound reasonable?

Comment 3

[Marco Zehe (:MarcoZ)]

Yes. And please mark the image/speaker icon as uninteresting for accessibility (not sure how this is done in Android exactly, though), so it doesn't even appear for TalkBack users. It's purely decorative, the information is in the contentDescription for the tab already.

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Marco Zehe (:MarcoZ) from comment #3)
> Yes. And please mark the image/speaker icon as uninteresting for
> accessibility (not sure how this is done in Android exactly, though), so it
> doesn't even appear for TalkBack users. It's purely decorative, the
> information is in the contentDescription for the tab already.

On Android views you can set the importantForAccessibility attribute to "no"[1]. Unfortunately only Android 4.1+ will read and evaluate the attribute. But in this case we are using a compound drawable that is part of the TextView and no separate View, so we are safe. :)

[1]: http://developer.android.com/reference/android/view/View.html#attr_android:importantForAccessibility

Comment 5

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

This should land with bug 1190301, which is also tracking 42.

Comment 6

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: MozReview Request: Bug 1198084 - Remove unused tab audio strings. r=mhaigh

Bug 1198084 - Remove unused tab audio strings. r=mhaigh

These appear to have been added in the initial implementation of this feature.

Comment 7

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: MozReview Request: Bug 1198084 - Add strings for tab playing audio. r=mhaigh

Bug 1198084 - Add strings for tab playing audio. r=mhaigh

Comment 8

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Attachment: MozReview Request: Bug 1198084 - Set appropriate content description on tabs playing audio. r=mhaigh

Bug 1198084 - Set appropriate content description on tabs playing audio. r=mhaigh

Tested using TalkBack on N4 Android 5.1.

Comment 9

[Martyn Haigh (:mhaigh)]

Comment on attachment 8656337 [details]
MozReview Request: Bug 1198084 - Remove unused tab audio strings. r=mhaigh

https://reviewboard.mozilla.org/r/18139/#review16271

Comment 10

[Martyn Haigh (:mhaigh)]

Comment on attachment 8656338 [details]
MozReview Request: Bug 1198084 - Add strings for tab playing audio. r=mhaigh

https://reviewboard.mozilla.org/r/18141/#review16273

::: mobile/android/base/locales/en-US/android_strings.dtd:82
(Diff revision 1)
> +<!-- Localization note (tab_title_prefix_is_playing_audio): This string is not

Nice description

Comment 11

[Martyn Haigh (:mhaigh)]

Comment on attachment 8656339 [details]
MozReview Request: Bug 1198084 - Set appropriate content description on tabs playing audio. r=mhaigh

https://reviewboard.mozilla.org/r/18143/#review16275

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/da20a87bda3b
https://hg.mozilla.org/integration/fx-team/rev/a965f4b9c202
https://hg.mozilla.org/integration/fx-team/rev/7dcf817255d2

Comment 13

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Comment on attachment 8656337 [details]
MozReview Request: Bug 1198084 - Remove unused tab audio strings. r=mhaigh

This request applies to all patches in this bug.

Approval Request Comment
[Feature/regressing bug #]: bug 1018504
[User impact if declined]: visually-impaired a11y users will not know which tab is playing sound

[Describe test coverage new/current, TreeHerder]: Tested locally via TalkBack on my Android 5.1 N4

[Risks and why]: Low – we're updating a content description with a String, so I don't forsee many issues.

[String/UUID change made/needed]: YES – NI flod for awareness

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/da20a87bda3b
https://hg.mozilla.org/mozilla-central/rev/a965f4b9c202
https://hg.mozilla.org/mozilla-central/rev/7dcf817255d2

Comment 15

[Francesco Lodolo [:flod]]

While the uplift decision belongs to release-driver, I don't think we should break string freeze (that includes removing strings) on aurora mid-cycle, especially for a "spring" release like 42.

One potential solution for Aurora would be to use tab_audio_playing in the tab title ("This tab is playing audio"), and let the proper fix ride the trains in 43.

Comment 16

[Sylvestre Ledru [:Sylvestre]]

Michael, are you ok implementing Flod proposal? If it is the case, we will approve it.

Comment 17

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #16)
> Michael, are you ok implementing Flod proposal? If it is the case, we will
> approve it.

Yep - working on a patch.

Comment 18

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

I forgot bug 1190301 needed to be uplifted too and it doesn't apply cleanly so I'm actually proposing bug 1018504 be backed out, removing the need for this change to be uplifted – I'll update when I know more.

Comment 19

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

It was decided in bug 1018504 comment 32 and subsequent comments that this feature will be 43.