Invisible regions should be styled with visibility, and not just clipped off the screen

RESOLVED FIXED

Status

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: eeejay, Assigned: eeejay)

Tracking

({access})

unspecified
All
Gonk (Firefox OS)
access

Firefox Tracking Flags

(b2g-v1.2 fixed, b2g-v1.3 fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Currently, a screen reader user could swipe and access all the settings, not just the visible panel.
(Assignee)

Updated

5 years ago
Assignee: nobody → eitan
Blocks: 893789
Keywords: access
(Assignee)

Comment 1

5 years ago
Created attachment 802642 [details] [diff] [review]
Style clipped settings panels as invisible.

https://github.com/mozilla-b2g/gaia/pull/12095
Attachment #802642 - Flags: review?(kaze)
>-  transition: transform .4s ease;
>+  transition: transform .4s ease, visibility .4s ease;

I’m a bit worried by using a transition on `visibility' — especially with an “ease” timing function. Using `step-end' instead might make a bit more sense (at least for readability), but I’m not sure we should do transitions on boolean properties at all.

Nick, what’s your opinion on this?
Flags: needinfo?(ncameron)

Comment 3

5 years ago
(In reply to Fabien Cazenave [:kaze] from comment #2)
> >-  transition: transform .4s ease;
> >+  transition: transform .4s ease, visibility .4s ease;
> 
> I’m a bit worried by using a transition on `visibility' — especially with an
> “ease” timing function. Using `step-end' instead might make a bit more sense
> (at least for readability), but I’m not sure we should do transitions on
> boolean properties at all.
> 
> Nick, what’s your opinion on this?

Doing transitions on boolean properties is OK in terms of 'it will work' and do so deterministically. I believe that no matter what timing function you use the change will always occur at the end or beginning of the transition time, and for visibility it is visible throughout the transition (https://developer.mozilla.org/en-US/docs/Web/CSS/visibility?redirectlocale=en-US&redirectslug=CSS%2Fvisibility#Interpolation). So whether you should use them or not comes down to code style - for pure style reasons I would avoid them unless it makes the css much simpler - someone reading the code might think the property transitions when it just flicks over and that might be confusing.
Flags: needinfo?(ncameron)
(Assignee)

Comment 4

5 years ago
(In reply to Fabien Cazenave [:kaze] from comment #2)
> I’m not sure we should do transitions on boolean properties at all.
> 

I think visibility is designed to be used in a transition for exactly these kinds of cases.

(In reply to Nick Cameron [:nrc] from comment #3)
> Doing transitions on boolean properties is OK in terms of 'it will work' and
> do so deterministically. I believe that no matter what timing function you
> use the change will always occur at the end or beginning of the transition
> time, and for visibility it is visible throughout the transition

step-end, and step-start explicitly flip the boolean value at the end or start of the transition accordingly. Any other transition function seems to do the correct thing when it comes to visibility (ie. set to hidden at the end of a transition, and set to visible at the beginning).

So the ramifications are more than just style, if 'ease' is confusing, 'linear' might be more accurate.
Comment on attachment 802642 [details] [diff] [review]
Style clipped settings panels as invisible.

I’ll have learned something today. Thanks guys!
Attachment #802642 - Flags: review?(kaze) → review+

Comment 7

5 years ago
Comment on attachment 802642 [details] [diff] [review]
Style clipped settings panels as invisible.

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Initial accessible implementation for Gaia.
[User impact] if declined: Developers will have a hard time deciding which parts the screen reader sees are actually visible and can be acted upon, and which not. This might lead to a situation where a developer can no longer turn off the screen reader.
[Testing completed]: Yes.
[Risk to taking this patch] (and alternatives if risky): None.
[String changes made]: None.
Attachment #802642 - Flags: approval-gaia-v1.2?
(Assignee)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Attachment #802642 - Flags: approval-gaia-v1.2? → approval-gaia-v1.2+
Uplifted 4ef6ee9cc13709659537c51c06bdbdd6c2bbfea7 to:
v1.2: db15c772aaf2d0e673bee167e7b9f5e636bf9095
status-b2g-v1.2: --- → fixed
Uplifted 4ef6ee9cc13709659537c51c06bdbdd6c2bbfea7 to:
v1.3 already had this commit
status-b2g-v1.3: --- → fixed
You need to log in before you can comment on or make changes to this bug.