Reflow Red Flags

During the 2023 CSUN Assistive Technology Conference, I had the pleasure of presenting about WCAG 1.4.10 Reflow. One of my favorite audience questions after the session was along the lines of, “what are some of the most common design choices that you see that cause reflow issues?”

This got me thinking. There are many common design patterns on the web that cause 1.4.10 Reflow failures. But there are also situations where the failure is less obvious—or the site passes on a technicality but is still problematic for people with low vision.

In my CSUN presentation, I talked about how I test for conformance with 1.4.10 Reflow. (I’ll summarize that procedure in a moment.) I mentioned how the procedure isn’t perfect because there are nuances about this criterion that can make it tricky to test for. There are some scenarios where even if a site passes the basics of the test procedure, it may still be a good idea to double-check for false negatives by using browser zoom on various devices. I’m going to take that a step further by talking about those common design practices and when you should keep an eye out for those false negatives.

As a side note, why was this one of my favorite questions? I’m glad you asked! It’s because one of the most important things that you can to do to be more accessible is “shift left.” Shifting left is a concept in software development that means you should plan for things earlier in the project timeline. Accessibility shouldn’t be something that only comes after you’ve already built your website, otherwise, it’ll be orders of magnitude more difficult and more expensive to achieve. The thing that makes this question so great is that it stems from thinking about accessibility in terms of design choices rather than fixing things in production, where it can be more difficult to alter the design.

And now back to our regularly scheduled topic.

Testing for Reflow

I like using Chrome’s developer tools to test a site for 1.4.10 Reflow. In Chrome’s developer tools, you can apply custom device emulation where you can set up a viewport size that matches the dimensions mentioned in the success criterion. Create a custom device with a width of 320 px and a height of 256 px.

You can access the device toolbar using the Toggle Device Toolbar icon in Chrome’s developer tools, or using the shortcut Command+Shift+M (Mac) or Ctrl+Shift+M (Windows) while the developer tools are open. From the device dropdown at the top of the viewport, select “Edit” and the Emulated Devices pane will open. From there you have an option for adding a custom device.

The reason I test these dimensions together (even though WCAG technically lists them separately) is because when users zoom their browser, the height and width scale together. You’re rarely going to find a desktop device where zooming to a relative viewport width of 320 CSS pixels gives you an exact height of 256px.

You can use this custom device to test a site for 1.4.10 Reflow. View your webpage with that device enabled and check for loss of content, loss of functionality, or any areas that have both horizontal and vertical scroll bars. This approach tests against the specific wording in WCAG. But the wording focuses heavily on the 320 × 256 viewport size. And while that isn’t incorrect, it ignores that users’ devices rarely conform to those specific pixel dimensions. That’s why we need to look out for red flags.

What am I calling a red flag?

A red flag is something that you notice during testing that may be problematic even though your test case ostensibly passed. If you encounter a red flag, you should dig deeper and investigate the potential user impact. Digging deeper may uncover a less obvious WCAG failure. Or it may uncover a very poor experience for users with low vision, even though it technically passes WCAG. Remember: just because something passes WCAG, that doesn’t always mean it’s accessible! In the case of reflow, digging deeper means experimenting with different physical devices and using browser zoom rather than only using an emulated viewport size.

WCAG refers to testing viewports at 320 px wide and 256 px high. They chose these dimensions in part because they’re equivalent to a midrange desktop resolution when zoomed to 400%. Whenever you need to dig deeper, you should view the same content on one or two laptops and browser-zoom levels to check the experience at 400%. This will help give you a sense of how users with low vision experience the content on similar devices.

Note: The “dig deeper” screenshots in this article were taken using a Windows laptop at 1920 × 1080 resolution at the default 150% scale. For privacy reasons, I didn’t include my taskbar or browser chrome in the screenshots. But keep in mind that those are also factors that’ll take up space on the screen.

Red flag #1 – sticky content

Let’s start out strong with everyone’s (least) favorite: sticky content!

Sticky content refers to anything that uses CSS position:sticky or position:fixed to have content remain in the same part of the viewport as you scroll through the page. The most common examples are site headers, site footers, back-to-top links, live-chat buttons, and “please give us feedback” controls that follow along the side of your screen. Here are a few examples that I found in the wild:

Using the custom device emulation from the previous section, you can probably already see a few reflow failures to call out. Some controls overlap, which makes them difficult to use or read. But overall, most of the page content is visible as you scroll (which is a good thing!). In both cases, there are examples of sticky content: our first red flag!

• Both sites use a sticky header.
• YouTube has a sticky row of video categories below the header.
• Floor & Decor adds a sticky “Chat with us” button near the bottom of the viewport.

Warning—math ahead! As a reminder, the emulated device from earlier has a height of 256 CSS pixels.

In the YouTube example, the site’s header and categories together span a height of 112 px. That leaves only 56% of the viewport available below it for the actual webpage content.

The Floor & Decor header is 60 px tall. Their chat button is 46 px tall but it’s also positioned 12 px from the bottom of the viewport. That 12 px is effectively unusable since many text elements on the site are too tall to fit in that space. That’s a total of 118 px ruined by sticky content, which leaves only 54% of the viewport usable.

Those sticky elements must be the most important pieces of content on these sites—because they’re taking up almost half of what low-vision users will see (according to this test). Technically, these situations aren’t WCAG failures since they don’t completely block users from getting to the pages’ content. But it’s a red flag, so let’s dig into the user impact! Here are those same two pages viewed instead with browser zoom set to 400%.

That’s a huge difference from the previous test! After we lose space for things like the browser chrome, there’s very little left for any of the website’s content. The user is left to interact only with the sticky content—and the rest of the website is functionally useless. In most cases, there isn’t even enough room to read a single line of text without the words overlapping with the sticky content.

How to fix sticky content

The most straightforward recommendation that I can make for fixing this issue is simply to not use sticky content. The would-be benefits of sticky content rarely justify the negative effects on people with low vision. The main user experience “advantage” that’s often cited is that it supposedly lets users quickly access your site’s navigation without having to scroll back to the top of the page. But is that actually a problem?

How often do you spend interacting with a website’s header compared to the content in the body of each page? Most sites these days use header navigation as an entry point into relevant content or transactions, but from there, all the navigation you need is served within the page.

Of course, there will always be those moments when there’s someone three levels above you in the management chain who has an opinion, and you have little control over whether to use sticky content. In this worst-case-scenario, your best friend is going to be CSS media queries. Zooming a webpage triggers the same responsive breakpoints that come into play with responsive web design. Use these to swap out the sticky behavior so the content instead scrolls with the rest of the page in narrower viewports (or even for shorter viewports too, if you want to take that route, since the primary concern is about losing vertical space).

.my-sticky-element {
  position: sticky; //or position: fixed;
}
@media screen and (max-height: 400px) {
  .my-sticky-element {
    position: relative;
  }
}

Red Flag #2 – Text Overflow

Designer: “I want the text to cut off at one line instead of wrapping.”

Me: “…Why?”

This is one of those design patterns that has always boggled my mind. For some reason, people have gotten into the habit of thinking that a “clean” interface where everything lines up in a tidy grid is more valuable than presenting the actual information on the page. So much so that they’re willing to take content away from users to preserve the sanctity of the layout. Are we really in an age where people think that a good user experience means that users don’t need to read the words that are on your website?

Now and then, you’ll come across websites that use CSS text-overflow with other CSS properties to restrict the size of a text container and truncate the content inside it. Instead of the container expanding to fit its content (like it normally would), it instead truncates the text with something like an ellipsis to tell users that there’s more text there—they just aren’t allowed to read it. Again… why? If you see a site using text-overflow or you notice a “…” at the end of a line of text, that’s a red flag.

The reason that’s a red flag is because for low-vision users who rely on browser zoom, the amount of text that they can see becomes less and less the higher zoom level they might need.

How to fix text overflow

I’m not going to spend much time on how to fix text overflow since it was already covered in depth in The Ballad of Text Overflow by James Edwards. He did an incredibly thorough job exploring this CSS property and its negative impact, and ultimately came to the same conclusion that I did: Just don’t use it. It’s not only bad for accessibility but also often frustrating as hell for all users.

Red flag #3 – Popups

The word “popup” is ambiguous. It’s more of a catch-all designer term used to describe any interaction where a control causes additional content to appear next to or below it. Examples include custom <select> elements, tooltips, navigation lists, and disclosures. Even though these patterns are all quite different, they have a few things in common. The content that dynamically appears is often anchored to another element on the page, and it shows over the top of other page content.

The issue here may not be super obvious at first, but the fact that these popups are anchored to another element on the page means that at higher zoom levels they run the risk of being pushed outside the edges of the viewport. When this happens, users might not be able to scroll the popup’s content into view or they might not be able to reach the interactive elements inside it.

How to fix popups

This isn’t going to be as straightforward to fix. But with some custom JavaScript, you can take care of this with these steps:

• Detect the popup’s starting coordinates
• Detect the viewport’s current size
• Set the popup’s height and width so that it remains inside the viewport and its content can be scrolled into view

Here’s a few quick lines of JavaScript to get you started.

//detect the bounding box of the target popup
//you can use this to pull specific coordinate/size properties of the popup
let target = document.getElementById("target");
let rect = target.getBoundingClientRect();

//detect the viewport size
let vpWidth = document.documentElement.clientWidth;
let vpHeight = document.documentElement.clientHeight;

You might also need to rearrange the content inside the popup to make sure that it doesn’t require both vertical and horizontal scrolling. Consider how you’re sizing your content inside the popup to make sure that there’s enough vertical space to easily read the content. Try not to use more vertical whitespace than you might need to. And if you really want to go the extra mile, you can also detect when the viewport’s size changes—and that way, if the user were to resize their browser, you can have the popup automatically adjust its size so it’s still visible.

If that approach doesn’t work for whatever reason, you could also consider adjusting the interaction completely when viewed on a smaller viewport. This is similar to what you’d do when adjusting for responsive design, like when you might convert a horizontal header navigation into a hamburger menu. For instance, you could display your tooltip’s content inline on the page rather than as an overlay. Or you might expand your custom <select> element to overlay the page content instead of anchoring it to the trigger element’s position. Multiple aspects of reflow can benefit from a mobile-first design.

Red flag #4 – Not-for-mobile mentality

Speaking of mobile, how about the design trend that’s the opposite of mobile-first design: the “not-for-mobile” mentality. This is possibly the hardest red flag to notice because it involves looking for things that aren’t there. It stems from ideas like:

• “The mobile design needs to be a subset of the desktop experience”
• “People won’t use certain features on mobile devices”
• “We can’t include everything if we want to have a sleek, modern-looking mobile site”

It’s a red flag if your website’s content or functionality is intentionally removed when the viewport narrows below a certain threshold. At the same time, that can be hard to spot because you have to do a direct comparison with the full-width version of the site.

I once had a designer argue that it was okay to remove a custom print feature from their responsive breakpoint because “people on mobile devices don’t want to print things.” If you laughed at that as hard as I did, then congratulations: You’re a step ahead of the rest.

There are two problems with this logic.

1. Most of the time, being on a mobile device doesn’t limit the user’s desire to perform tasks.
2. The designer was assuming that everyone viewing the responsive breakpoint was on a mobile device.

Personally, I find it frustrating when I’m in the middle of doing something on my phone only to discover that the responsive version of a site doesn’t have something. Now I have to move to a different room to pull out my laptop and start the task over. You’re rarely, if ever, going to be doing users a favor by taking away their access to features.

As previously mentioned, zooming your browser triggers the same CSS media queries as when you view a website on in a mobile browser. So if your logic is “Well, the viewport is narrower than 500px, so we must be on a mobile device,” then you aren’t considering all your users.

How to fix a not-for-mobile mentality

Fixing this can take a lot of convincing. It requires designers to shift their thinking and understand that fragmenting the experience between devices isn’t necessary—or helpful. The bottom line is that there’s almost always a way to give users the same content and functionality across all device sizes without compromising your design. It may require some extra creativity, and you may have to think outside of your existing design toolbox. But I promise you that it’s possible.

Conclusion

1.4.10 Reflow is an easy guideline to overlook. It doesn’t get as much attention as others that focus on screen readers or keyboard support. But it’s worth putting in those extra couple of minutes of effort to double-check that your content reflows well. Even if it passes the normative WCAG wording, you may still find issues that can make it harder for people with low vision to read or use your website. Keep an eye out for these red flags. They can make the difference between meeting the letter of the guideline and actually being helpful to people with disabilities.