Tech media queries sticky

[alastc]

New technique for sticky headers / footers, you can preview Sticky headers / footers, and there is an associated example page.

[detlevhfischer]

I was slighly puzzled by the focus on landscape vs. portrait - should the point not be that headers / footers should be made unstuck if the screen is too small to allow enough space for seeing the scrolling content? We are also moving into dangerous territory as having situations where only one orientation might be usable is in conflict with 1.3.4 Orientation (AA).
If I look at the example page referenced, in any of the mobile screen sizes that can be selected in developer tools, there is hardly any (or no) space for the scrolling text.
I believe a better approach might be a page with sticky header at, say, 1280px that becomes unstuck as we move towards narrower viewports (potentially by zooming) - hasn't Alastair presented such a technique somewhere, recently? Here, orientation should not matter, just viewport width.
So this, IMO is not ready,

[mbgower]

I was also a bit puzzled about which SC this was supposed to be a sufficient technique for. As written, it seems to be for Orientation, but the requirement for Orientation is not that content needs to be transformed; just that it not be locked.
So it appears this is maybe a better fit with Reflow?
I would expect the technique to include a section on what SCs it is applicable to. Perhaps if this was added, it would help assess the technique.

[jake-abma]

Hi @detlevhfischer, @mbgower, @alastc, @mraccess77, @patrickhlauke, @DavidMacDonald and all others reading this

Good remarks but doesn't make the solution more easy. Think we have to come up with the proper conditions first. Here a small overview of sticky so far:

@detlevhfischer comments:

should the point not be that headers / footers should be made unstuck if the screen is too small to allow enough space for seeing the scrolling content?

Yes, that's exactly what's needed if you do not specifically mean width of the screen in portrait mode (like a small mobile) (well not the screen is too small but the "left over visible area NOT being sticky" is too small, but ok... :-). After more thought this may be pretty hard to define as a general rule as this may be different for each and every site in all kind of different circumstances but we'll give it a try.

We are also moving into dangerous territory as having situations where only one orientation might be usable is in conflict with 1.3.4 Orientation (AA).

Can you give an example for this?

If I look at the example page referenced, in any of the mobile screen sizes that can be selected in developer tools, there is hardly any (or no) space for the scrolling text.

Not sure what you mean here, if I check the example out in Chrome dev tools and set device to iPhone5, iPad, Galaxy S5 etc. more than 70/80% of the screen is scrollable content?!

I believe a better approach might be a page with sticky header at, say, 1280px that becomes unstuck as we move towards narrower viewports (potentially by zooming) hasn't Alastair presented such a technique somewhere, recently? Here, orientation should not matter, just viewport width.

All information I've received so far was about the height / horizontal / landscape like issues with sticky headers. So zooming / narrower viewports was not the basis for this technique. I'm not saying you may have a good point here to have a good look at but this was not how the need for this technique was born. I'll provide a couple of examples later in this comment with the proper Github issues.

@mbgower comments:

As written, it seems to be for Orientation, but the requirement for Orientation is not that content needs to be transformed; just that it not be locked.
So it appears this is maybe a better fit with Reflow?

Yes, correct, it should be all about Reflow, but as you're both puzzled we need to adjust this technique so it will be clear what we mean / want and come up with proper criteria / conditions.

@jake-abma My comments and references for this technique:

The assignment / text for this technique can be seen at: https://www.w3.org/WAI/GL/wiki/Wcag21-techniques#Reflow
It uses the term "vertical media queries", which is about height not width: "Using vertical media queries to un-fix sticky headers / footers (New, advisory)"

The example shown previously from Patrick can be seen here: https://codepen.io/patrickhlauke/pen/RyOQZE and used "@media screen and (min-height: 20em)". Instead of height you may / can also use "portrait / landscape" which is more of a general approach while 20em is more specific and relies on what has been defined as the default size. Without the default size and some calculations the "portrait / landscape" seemed more clear as a technique.

This was also supported by some comments from @mraccess77, not sure if this was by phone or in Github messages but Jon mentioned the sticky problem turned up when using mobile phones and using them in landscape mode for better reading purposes. Please correct me if I remembered wrong!

@DavidMacDonald is also talking about landscape at: w3c/wcag21#850
"If the site has to work at 320px and then is turned on its landscape on the phone, sticky headers that have vertical media queries for anything over 320 pixels will often cause clipping."

The issue from @WayneEDick and the comment from @StommePoes is also about the height: w3c/wcag21#846
"it should also be okay to simply remove their stickiness at a minimum height as well"

Sticky turns up here:

• 1.4.4 Resize Text - Misunderstandings Update - Interpretation wcag21#883
• Are Reflow, Text Size and Orientation cumulative? wcag21#850
• Reflow: Fixed Position Fields wcag21#846
• Success Criterion 1.4.10 Zoom content wcag21#343
• The Paciello Group comment on SC 1.4.10 Zoom content wcag21#335

Conclusion:

Sticky headers / footers are, or will be a burden when they take up too much space and the leftover scrollable area / content is not enough to easily read the text. Although we've talked a lot about height in previous issues it shouldn't matter if it is width or height.

The exact condition for a technique need to be more clear to make sure it covers what we want here. Maybe more than one technique is needed to cover sticky headers / footers.

Need to dive deeper into this topic with a fresh mind before I start adjusting the technique...

[alastc]

Hi everyone,

And thanks Jake for tackling this. A few notes from having been involved in the development of the reflow SC:

• This technique was intended to be an advisory (but very recommended) technique for supporting reflow.
• We never got to the point of being able to say exactly how big a sticky header was too big, which is why it isn't a failure/sufficient, but is advisory.
• I think it would be simpler to focus on the height (and/or width) rather than orientation. I can see why using the orientation might help define your approach, but there is a simpler way.

What I'd like to encourage with this is a progressive-enhancement approach, the main issues we've come across in testing are:

1. Sticky headers and/or footers that leave desktop-zoomers with a narrow slit of content.
2. Pop-out or floating menus that assume a certain height is available, and prevent scrolling, thus prevent people from getting to all the options.

By progressive enhancement, I mean that the application of 'stickyness' or non-scrolling is enabled when there is sufficient space.

For example, if a header is 100px tall and we assume that taking less than 25% of the vertical height is reasonable, then it should only stick if the height is 400px or greater.

If the menu is 500px high, then it should only prevent scrolling when there is 500px vertical height available.

In this way it doesn't matter what device is being used, it is about the content.

Cheers,

-Alastair

[jake-abma]

Hi @alastc, thx for the inspect and suggestions, after my vacation will do the changes and techniques. Cheers!

[allanj-uaag]

+1

[lauracarlson]

+1

[jgrieves]

+1

[jake-abma]

@detlevhfischer @alastc @mbgower / all,

NEW OBJECTIVE:

The objective of this technique is to be able to present content without sticky headers and footers when the space of the viewport is limited. This may be because of a device held in landscape mode or by zooming on a dektop.

Changed the example already and wondering if this suits the needs more...

https://rawgit.com/w3c/wcag/example-css-sticky/working-examples/css-sticky/index.html

In short there are just a couple of MQs at different sizes so:

• You'll see sticky headers on a mobile in portrait but not landscape.
• You'll see sticky headers on a tablet in portrait but not landscape.
• Sticky will be there on desktop but when you'll start zooming they disappear, depending a bit on viewport size.
• Sticky will be there on desktop but when you'll start changing the viewport they appear / disappear, depending on viewport height / width.

Please provide feedback before I start to re-write the technique as this may change if the example is not sufficient. It may not cover all size scenarios but I think we're on the save side here.

Cheers!
Jake

[alastc]

Hi Jake,

I wonder if it's possible to simplify even further? I'd suggest switching it around to more of a progressive enhancement approach, so:

    header {
      height: 100px;
    }

    @media (min-height: 480px) {
      header {
        position: sticky;
        top: -50px;
      }
    }

So the objective is to only use the sticky header when there is sufficient vertical space.

Or does it need to be the max-height verison to get the same effect?

[jake-abma]

Like this?

https://rawgit.com/w3c/wcag/example-css-sticky/working-examples/css-sticky/index.html

[alastc]

Yep, I just think it's slightly clearer, and maps to progressive-enhancement more easily. Doesn't make much difference in this case, but a good principle across the board.

It should also help in the wording, 'have enough space to include a sticky element' rather than removing it when there isn't.

[jake-abma]

Hi @alastc

I can add another style for tablet landscape like:

@media (min-width: 576px) and (max-height: 768px) {
header {
position: static;
top: auto;
}
}

and

@media (min-width: 576px) and (max-height: 768px) {
footer {
position: static;
top: auto;
}
}

This way we give a hint / idea to automatically get rid of the sticky part when in landscape mode.
For our sticky example the space of the header and footer is not that high but in other cases this might be the case but makes the example just a bit more complex...

Do or Don't?

[jake-abma]

Correction, made the following change:

@media (min-device-width: 576px) and (max-device-width: 1024px) and (orientation: landscape) {
header {
position: static;
}
}

and

@media (min-device-width: 576px) and (max-device-width: 1024px) and (orientation: landscape) {
footer {
position: static;
}
}

Hope it's not too controversial, any case / edge case objections for this case?

[jake-abma]

UPDATED: technique for sticky headers / footers, you can preview Sticky headers / footers, and there is an associated example page.

Please Re-review...

[StommePoes]

So, this says one can use viewport sizes (in px). What would a developer do who wants a sticky on a small screen, but only if the user hasn't set their font size larger/has enough vertical space? Or is that not detectable if it's set by OS? Would measuring viewport height or media queries in em work more flexibly?

Also, does it have to be a CSS technique if developers were using, say, JS to measure the sizes of things to determing the % of screen area a sticky takes up?

[patrickhlauke]

@StommePoes

Would measuring viewport height or media queries in em work more flexibly?

Yes, that'd make more sense i'd say

does it have to be a CSS technique if developers were using, say, JS

techniques don't have to be exhaustive / you don't really NEED to have techniques for any possible way of doing things. i'd say nowadays, media queries are likely the tool of choice for this sort of thing, rather than JS. (you can also do CSS MQs in JS with window.matchMedia, so an unholy mix of the two https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia)

[alastc]

So, this says one can use viewport sizes (in px). What would a developer do who wants a sticky on a small screen, but only if the user hasn't set their font size larger/has enough vertical space?

All the units are relative to something, so it really depends on what the content of the container is, and how it is laid out.

If you set the container to 100px, then using a vertical height media query in PX makes sense.
If you set the height in EMs, then set the media query in EMs as well.

Whether text wraps is another matter, and not really the target of this technique. (Especially as setting the height in EM wouldn't prevent text-wrapping and increasing the height of the container. Making sure the background extends would solve that problem.)

does it have to be a CSS technique if developers were using, say, JS

Extending what Patrick said, each technique should be focused and clear. We can have another technique that's very similar, but for JavaScript. Given that it would be adjusting style properties, I think it's natural to start with a CSS one.

[jake-abma]

Changed "height" to "min-height", scaling if fine now.

Cheers!

[WayneEDick]

+1 I really love this example. Wayne

…

On Mon, Sep 17, 2018 at 11:27 PM Jake Abma ***@***.***> wrote: Changed "height" to "min-height", scaling if fine now. Cheers! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#389 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF3uQY1IuxB7S-woMNBj_pZU2x7K-ks5ucJJggaJpZM4U7La7> .

[detlevhfischer]

Looks good to me. I cannot reproduce the situations where there was hardly any space for scollable content, not sure whether this is because the example changed or I am doing it differently now...

[jake-abma]

Hi @detlevhfischer , in our case the content has enough space because the sticky header / footer are not that 'high', but when you'll have higher ones you'll end up with not enough space and only a narrow view left for the content. The technique shows what happens / sticky becoming UNsticked... but indeed the need in this example page might not be / seem that important. Would you say to have the header keep it's height at all times so the needs seems more clear?

[detlevhfischer]

I'd say a header of substantial height make the need for getting it 'unstuck' more obvious - but the example works as it stands.

[jake-abma]

adjusted the example to bigger headers and footers, will this be more clear?

example page

[jake-abma]

https://www.w3.org/2018/10/09-ag-minutes.html#item08

• Removed: "Medium complex" and now it is: "Example 1: Un-fix sticky headers / footers in HTML and CSS"

• Adjusted the example to bigger headers and footers, will this be more clear? example page

• @detlevhfischer comment not answered yet: "in user testing sticky header when user tabs backward focus can be behind sticky header. Should we point out those potential problems? Or is this a specific technique? I've checked this by adding some links and indeed the focus end up behind the sticky header. But this is indeed also not what this technique is all about...

• @awkawk mentioned something about: "The basic principle of un-fix sticky headers / footers is to:", not sure what the exact issue is here anymore...

@alastc will you do the "It would be good to have a quick refinement on the text and check in with Jake to make sure we have not changed anything significant. "?

Cheers!

[jake-abma]

https://rawgit.com/w3c/wcag/tech-media-queries-sticky/techniques/css/media-queries-sticky.html

changed CSS example to bigger header/footers / simplified

[detlevhfischer]

Hi @jake-abma , I am in two minds about this: while I like short and succinct Techniques, I think there is perhaps an obligation to call out significant disadvantages of certain design patterns when they exist, such as those caused by the use sticky headers. Looking at this Technique, authors will otherwise implicity assume that using sticky headers is great if you just take care of un-sticking them.

My suggestion for a re-formulation to include of a warning about issues brought upon uses by sticky headers would be this:

Old:

Sticky regions always stay visible in the viewport while the other content will disappear underneath when scrolling.
This often is no problem on desktop, or in portrait mode for mobile devices, but may block a big portion of the screen in landscape mode or when zoomed because of the height of the sticky regions and leave only a small part of the screen for users to profit from.
This is an effective way to create designs that present well with enough available space while when users prefer different reading and zoom preferences, or landscape mode, the sticky regions will be disabled.

Proposed change:

Sticky regions always stay visible in the viewport while the other content will disappear underneath when scrolling.
In terms of content visibility, this is often not a problem on the desktop and on mobile devices in portrait orientation. However, when using mobile devices in landscape orientation or when zooming in on the desktop, sticky regions may block a big portion of the screen: the height of the sticky region may leave only a small part of the screen for the display of page content.
Disabling -- or un-fixing -- sticky regions is an effective way to allow for enough available space when users prefer different reading and zoom preferences or when using landscape mode.

Note: Be aware that sticky regions can create disadvantages for keyboard users and should therefore be used judiciously. The problem for keyboard users tabbing through a page with a fixed header is that once the page has started to scroll, tabbing backwards to reach interactive elements higher up on the page will often mean that the focus becomes invisible once it moves behind the sticky header. Users must then scroll up to be able to see the focus - something they may not necessarily be aware of. In the same way, the visible focus can disappear behind a sticky footer, so users would need to scroll down to be able to see their focus position, which is a major inconvenience.

[StommePoes]

Detlev: I wouldn't remove the bit about zoomed desktops-- developers who think only mobile who happen to have a dedicated mobile site separate from the "desktop" one would then miss that this is still relevant to them.

[detlevhfischer]

@StommePoes Thanks Mallory, I have modified my recommended edit to reflect your concern.

[jake-abma]

Great @detlevhfischer, changed!