Make emergency callback notification markup a11y friendly.

RESOLVED FIXED in 1.3 Sprint 5 - 11/22

Status

Firefox OS
Gaia
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: yzen, Assigned: yzen)

Tracking

(Blocks: 1 bug, {access})

unspecified
1.3 Sprint 5 - 11/22
All
Gonk (Firefox OS)
access
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
Right now a number of elements that belong to the emergency callback functionality are visible to the screen reader even though they are not visible to the sighted user. This needs to be addressed with proper attributes.
(Assignee)

Updated

4 years ago
Blocks: 923139
(Assignee)

Comment 1

4 years ago
Created attachment 831279 [details] [review]
Pull request for 937859
Attachment #831279 - Flags: review?(gweng)
Comment on attachment 831279 [details] [review]
Pull request for 937859

Well, I'm not familiar with the emergency call. So even there seems only a little change, Steve is still the better reviewer than me.
Attachment #831279 - Flags: review?(gweng) → review?(schung)
Comment on attachment 831279 [details] [review]
Pull request for 937859

I think Alive should be the right person for reviewing here. But I got a question for the patch: if you apply the hidden html attribute here, do we still need the css class for controlling the show/hide?
Attachment #831279 - Flags: review?(schung) → review?(alive)
(Assignee)

Comment 4

4 years ago
Well the classes such as .displayed and .visible seem to do more work than just handle visibility, in one case display is set to block, in other to inline-block. Those classes also define pointer-events and overflow for some of the panels.
BTW,
I dislike the way we overload fixed notifications and filed https://bugzilla.mozilla.org/show_bug.cgi?id=938954
Summary: Make emergency callback markup a11y friendly. → Make emergency callback notification markup a11y friendly.
(In reply to Yura Zenevich [:yzen] from comment #4)
> Well the classes such as .displayed and .visible seem to do more work than
> just handle visibility, in one case display is set to block, in other to
> inline-block. Those classes also define pointer-events and overflow for some
> of the panels.

I wonder if we could have a golden rule for screen readers. I don't think everything in system is friendly with it.
For example, I use aria-hidden=true in app-window, but you use hidden in this case, which one is correct? Or both?
Comment on attachment 831279 [details] [review]
Pull request for 937859

r+ but looking forward to a general screen reader friendly plan.
Attachment #831279 - Flags: review?(alive) → review+
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
I see a Travis CI failure for this pull request. The error doesn't look directly related, but I would double check. Also, maybe a rebase an re-push.
(In reply to Alive Kuo [:alive][NEEDINFO] from comment #6)
> (In reply to Yura Zenevich [:yzen] from comment #4)
> > Well the classes such as .displayed and .visible seem to do more work than
> > just handle visibility, in one case display is set to block, in other to
> > inline-block. Those classes also define pointer-events and overflow for some
> > of the panels.
> 
> I wonder if we could have a golden rule for screen readers. I don't think
> everything in system is friendly with it.
> For example, I use aria-hidden=true in app-window, but you use hidden in
> this case, which one is correct? Or both?

tl;dr aria-hidden is a last resort that should never be used casually.

There are several ways of hiding an element: CSS visibility/display, 'hidden' attribute, and 'aria-hidden'. All but the last actually remove the element from visual layout. They will all hide an element from the screen reader.

aria-hidden is a semantic hiding, and should only be used with great caution. The only two legitimate cases I could think of for aria-hidden are:
1. partial, but insignificant visiblity. For example, elements that are obscured by a modal dialog with little translucency (opacity: 0.8), or a drawer layer that is mostly clipped off the screen.
2. Due to performance or gecko rendering limitations. A good example of that is the app-window, like you mentioned. If we actually style that as hidden, the contents of the iframe are not allocated space, and there will be issues with background audio from apps that are styled as hidden.
(Assignee)

Comment 10

4 years ago
Re-pushed to re-run Travis CI
Keywords: checkin-needed
Took a few tries, but it did eventually pass on Travis :)

Master: https://github.com/mozilla-b2g/gaia/commit/7797d9092cd4e2f9fc2fe8a1dfc80458ef44ec6c
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.3 Sprint 5 - 11/22
You need to log in before you can comment on or make changes to this bug.