Reflow: Fixed Position Fields

[michael-n-cooper]

From @WayneEDick on March 31, 2018 20:44

This problem occurs mostly with headers and footers but bands on the left and right can be just as disruptive.

My example is the worst I've ever seen, but secondary information with fixed position often crowds out real information. This occurs because the assumption at low resolution is a cell phone in portrait orientation. A person with low vision is using landscape.

At low resolutions headers and footers should scroll out of the way.

There is also a problem with applications that have non-collapsible vertical panes. If these enlarge with zoom, and no scrolling is provided, the page becomes unusable or difficult.

There are good examples
If you enlarge gitHub the header gets quite big, but when you scroll, it scrolls off the screen. That is much more useful.

The sidebar below enlarges but a scroll is provided for using the rest of the screen.

We need some techniques for this.

Any ideas?

Copied from original issue: w3c/wcag21#846

[michael-n-cooper]

From @WayneEDick on April 5, 2018 21:31

Would these examples simply represent non-functional pages?
I think there are at least three techniques:

1: In a responsive case that includes low resolution change position to static for fixed fields.
2: Provide buttons (hamburger etc.) for headers, footers, panes etc and limit their size to 10%.
3: Make fixed headers, footers and panes collapsible.

All of these work

[michael-n-cooper]

From @mraccess77 on April 5, 2018 22:4

Wayne, that sounds like a good list to me. In addition, there is some content that can merely be closed or dismissed once read. I brought up this issue in my low vision presentation at CSUN.

Other issues blur the line between this and the hover SC -- for example, I've hover content that appears off the side of screen with zoom and there are scrollbars to scroll to the content but scrolling causes it to go away. generally I've seen this horizontally but there isn't a reason that this could happen vertically as well.

Another issue is snap scrolling where the content is below vertically but if you try to arrow or scroll to it the page snap scrolls to the next section preventing you from accessing the content with zoom. The issue isn't so much about that the content isn't there but mechanisms on the page prevent you from getting to it. In addition I've also seen scroll jacking where the page takes away the control+mouse wheels capability to scroll and you have to use other browser features to use zoom.

[michael-n-cooper]

From @StommePoes on May 1, 2018 20:12

"Would these examples simply represent non-functional pages?"

Absolutely, in my opinion.

I get hit with these stickies all the time, and they are as bad as the screenshots for me because at just 150% I get maybe 3 lines of text on a 12" laptop. Medium.com is a particularly horrid site, as are several news sites.
I ding sites I audit that do this with text-enlarge fails because the solution for developers can be pretty simple: they're usually already doing width-based media queries. A height-based one using em's which removes crazy scrolling, sticky-crap and everything like that can do the trick while still allowing much of that styling to work as expected on a non-zoomed mobile device.
I don't think the fixed things need to be collapsable-- it should also be okay to simply remove their stickiness at a minimum height as well (often the content being sticky doesn't need it: headers showing what you already know, like the site name, or social media junk that's absolutely inessential). Side panes make more sense with the collapse bit-- Jira at my zoom level does mean if I want to access those buttons, I need to "open" it. So I'd adjust #3 to offer both options.

#2 may well hit some coga stuff. Since hamburgers and whatnot tend to appear when the developers expect the user to be on a touchscreen/mobile, would there need to be a note about not assuming no keyboards or user swipes for those mobile/zoom-appearing controls?

I did figure the new SC on hover regarding "Persistence" would cover scrolling losing hover content, since I thought "Persistence" would equally help whether it was browser zoom or something non-reflowing like ZoomText.

Here, I've zoomed out to read the message that popped up, but still not enough to close the popup message to read mail. Composing mail often only gave me 2 lines of text to see (the HTML version of Gmail is a godsend). Since "close" controls are unavailable it of course fails text-resize, but the cause in this case is the sticky-madness.

[michael-n-cooper]

From @WayneEDick on May 2, 2018 16:17

I agree Mallory. The fixed headings and footings breaks functionality.
Also, removing fixed position works well. That was an interesting letter.
Perhaps we need need to make them techniques.

Wayne

On Tue, May 1, 2018 at 1:12 PM Mallory [email protected] wrote:

"Would these examples simply represent non-functional pages?"

Absolutely, in my opinion.

I get hit with these stickies all the time, and they are as bad as the
screenshots for me because at just 150% I get maybe 3 lines of text on a
12" laptop. Medium.com is a particularly horrid site, as are several news
sites.
I ding sites I audit that do this with text-enlarge fails because the
solution for developers can be pretty simple: they're usually already doing
width-based media queries. A height-based one using em's which removes
crazy scrolling, sticky-crap and everything like that can do the trick.
I don't think the fixed things need to be collapsable-- it should also
be okay to simply remove their stickiness at a minimum height as well
(often the content being sticky doesn't need it: headers showing what you
already know, like the site name, or social media junk that's absolutely
inessential). Side panes make more sense with the collapse bit-- Jira at my
zoom level does mean if I want to access those buttons, I need to "open"
it. So I'd adjust #3 w3c/wcag21#3 to offer
both options.

#2 w3c/wcag21#2 may well hit some coga stuff.
Since hamburgers and whatnot tend to appear when the developers expect the
user to be on a touchscreen/mobile, there would need to be a note about not
assuming no keyboards or user swipes for those mobile/zoom-appearing
controls.

I did figure the new SC on hover regarding "Persistence" would cover
scrolling losing hover content, since I thought "Persistence" would equally
help whether it was browser zoom or something non-reflowing like ZoomText.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
w3c/wcag21#846 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AH0OFzInc5D_ojnB1ruZO_0sD0Q9kIibks5tuMGngaJpZM4TCmzy
.

[michael-n-cooper]

From @StommePoes on May 3, 2018 7:46

They'd certainly be useful techniques, I think. Devs just don't tend to think of them but once you point them out, as I said it's not a difficult or complex fix, plus it's pretty easy for them to check.

[michael-n-cooper]

From @alastc on May 22, 2018 12:49

We have a technique called "Using vertical media queries to un-fix sticky headers / footers (New, advisory)" in the techniques listed for reflow:
https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#Reflow

If anyone (in the working group) would like to add create a technique please add it there and follow the steps for creating it.

[michael-n-cooper]

From @mraccess77 on May 22, 2018 13:40

Hi Alastair, I happened to see the related technique "Text given viewport units that does not rescale" and was going to take failure technique. However, after starting it I realized that it might not really be a failure of SC 1.4.10 but instead is better a failure of SC 1.4.4. Would you agree?

[michael-n-cooper]

From @alastc on May 22, 2018 13:42

Yes, it has been triggered by our work around 1.4.10, but it fits under text-size.

Thanks,

[alastc]

Just reviewing old issues: We now have a technique for this, C34.

It is advisory though, as it isn't required by the normative SC. If people think it is a significant gap in WCAG 2.1, we need a couple of people to work on something for WCAG 2.2.

[mraccess77]

Sticky headers create reading viewports that are too short. This is definitely an issue -- but I'm not sure if we could get consensus on what height is acceptable and what is not for reading. If the sticky header completely covers the content that is already likely covered -- but what if a line, two, or three is visible and the user must be forced to narrowly read in that area. How would we measure something -- percent of viewport height? Number of lines of text that fit in the view? I'd be willing to take on something for 2.2 if we feel this issue actually has a solution under 2.2. Given the impression that folks in the working group think low vision issues are solved even for Silver and the LVTF has decided that the issues for 2.2 would be too challenging given the current framework and would be more likely to fit into the framework of Silver -- I'm honestly not sure what is possible or which specification is the right place to tackle these. We almost need an incubation call for some of these possible criteria.

[alastc]

I think it's possible. I've some ideas about it tying in with mobile device orientation, and we have a 'min' height of 256px for reflow, so I think we could build on that.

[StommePoes]

For the stickies on the sides like social media buttons and "drawer" components, maybe some of the existing rules about reading lengths and line-heights can also be brought in as well? Or if there's anything about minimum caption lines (isn't there research about how hard/easy it is to read scrolling text when there's only one line, two lines, three lines?) which can be transferred to excessive stickies causing a similar result (number of lines visible before the user needs to scroll to read more)?

That said, percentage-based seems like something that would work in the wild, as far as practicality: showing any designers sticky things taking up a quarter to a half of the viewport height never gets pushback-- it seems ridiculous to them as well to be taking up amounts more than a quarter.

[patrickhlauke]

i'd be in favour of something percentage / ratio based as well (along the rough lines of sticky/fixed elements not covering more than a third of the visible viewport, and in an understanding doc explaining that this must be tested both in portrait and landscape aspect ratios, down to 320 CSS px width for portrait / 256 CSS px height for landscape. but this time i'd definitely insist on the down to wording, and not just mandating it for that EXACT viewport dimension, as otherwise it becomes pointless.

[StommePoes]

but this time i'd definitely insist on the down to wording, and not just mandating it for that EXACT viewport dimension, as otherwise it becomes pointless.

Agreed. I've run into at least 2 instances of something which would pass 400% at 1280-width but somewhere around 250% a media query didn't kick in and things were broken, leaving the user to choose between somewhat too small (175%) or larger than they need (300+%). In a similar fashion, good designers expect their "responsive" designs to work in any fluid setting between whatever extreme endpoints they've set for their product, rather than "5 breakpoints".

[patrickhlauke]

@StommePoes i'll just point at this lengthy discussion here #698 and my example https://codepen.io/patrickhlauke/live/ZZqzaB ... and then just leave it at that with an exasperated shrug.

[jake-abma]

@alastc wrote;

I think it's possible. I've some ideas about it tying in with mobile device orientation, and we have a 'min' height of 256px for reflow, so I think we could build on that.

wondering about your idea, can you lift the veil on this?