When a web page’s height exceeds the viewport, a user may scroll past moving, blinking, or scrolling content to “hide” it.
In an adversarial reading of SC 2.2.2: Pause Stop, Hide, could the scrollable viewport itself be considered a sufficient “mechanism” for hiding?
The SC’s stated concern for “parallel” content implies — but does not seem to actually require — that the user be entitled to a motion-free viewport in which to consume this parallel content at their leisure. The references to moving content as a “severe distraction” and “not tying up the user” gesture at this intention, but never seem to close the loophole.
Side note: with <marquee> long behind us, doesn’t this SC’s use of “moving” already cover “scrolling” (by which we mean “auto-scrolling”)? Not to be confused with the user-initiated scrolling? 😵💫
When a web page’s height exceeds the viewport, a user may scroll past moving, blinking, or scrolling content to “hide” it.
In an adversarial reading of SC 2.2.2: Pause Stop, Hide, could the scrollable viewport itself be considered a sufficient “mechanism” for hiding?
The SC’s stated concern for “parallel” content implies — but does not seem to actually require — that the user be entitled to a motion-free viewport in which to consume this parallel content at their leisure. The references to moving content as a “severe distraction” and “not tying up the user” gesture at this intention, but never seem to close the loophole.
Side note: with
<marquee>long behind us, doesn’t this SC’s use of “moving” already cover “scrolling” (by which we mean “auto-scrolling”)? Not to be confused with the user-initiated scrolling? 😵💫