Tab audio indicator is not a11y friendly

RESOLVED FIXED in Firefox 43

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Margaret, Assigned: mcomella)

Tracking

35 Branch
Firefox 43
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox42 affected, firefox43 fixed, fennec43+)

Details

Attachments

(3 attachments)

Reporter

Description

4 years ago
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.
Flags: needinfo?(mzehe)
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.
Flags: needinfo?(mzehe)
Reporter

Comment 2

4 years ago
(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?
Flags: needinfo?(mzehe)
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.
Flags: needinfo?(mzehe)
(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
No longer blocks: 1190301
Depends on: 1190301
This should land with bug 1190301, which is also tracking 42.
tracking-fennec: --- → 42+
Bug 1198084 - Remove unused tab audio strings. r=mhaigh

These appear to have been added in the initial implementation of this feature.
Attachment #8656337 - Flags: review?(mhaigh)
Bug 1198084 - Set appropriate content description on tabs playing audio. r=mhaigh

Tested using TalkBack on N4 Android 5.1.
Attachment #8656339 - Flags: review?(mhaigh)
Comment on attachment 8656337 [details]
MozReview Request: Bug 1198084 - Remove unused tab audio strings. r=mhaigh

https://reviewboard.mozilla.org/r/18139/#review16271
Attachment #8656337 - Flags: review?(mhaigh) → review+
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
Attachment #8656338 - Flags: review?(mhaigh) → review+
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
Attachment #8656339 - Flags: review?(mhaigh) → review+
Assignee: margaret.leibovic → michael.l.comella
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
Flags: needinfo?(francesco.lodolo)
Attachment #8656337 - Flags: approval-mozilla-aurora?
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.
Flags: needinfo?(francesco.lodolo)
Michael, are you ok implementing Flod proposal? If it is the case, we will approve it.
(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.
Attachment #8656337 - Flags: approval-mozilla-aurora?
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.
It was decided in bug 1018504 comment 32 and subsequent comments that this feature will be 43.
tracking-fennec: 42+ → 43+
You need to log in before you can comment on or make changes to this bug.