Zoom & Reflow Accessibility Requirement

Correctly understanding what reflow is represents a key factor in accessibility testing, as it's one of the criteria for Level AA. If properly evaluated from the design phase, implementing reflowing logic in a project could be much easier. If not, it could single-handedly delay your project significantly, as it may force you to refactor part or all of your final design.

1. What is Reflow?

Users with impaired vision, as well as devices with very small displays or those viewed at great distances, should be able to operate the website or application correctly, even in tiny-sized viewports. To achieve this, everything should be laid out in a completely vertical format, with horizontal scrolling maintained only for limited cases where logic and meaning strictly require it (more about this later). Text should be able to break into new lines independently of its size, without the need to change the line width. Success in this criterion means that content will not extend outside the viewport horizontally (or potentially vertically, if you're working with a vertically written language).

2. Viewport and Zoom Requirements

It can be difficult to define the environment for testing and developing appropriately: what does it mean to zoom 400%? If you're lucky (or wealthy) enough to code with an ultra-wide display, you could potentially have a large resolution even at 1000% zoom! Luckily, WAI-ARIA suggests setting the viewport at 320x256px, approximately equal to 1280x1024px at a 400% zoom level. Quite a tiny area, isn't it?

3. Responsivity

Even though it’s not synonymous with “reflow” (I love semantics, but that’s out of scope for this article), “responsive web design” is the design approach used to achieve reflow. There's no longer a “desktop-only” project, I'm afraid: take this into account when planning deadlines and workflows, treating it as a challenge to reach a higher level of quality, not as an obstacle for your project.

4. Exceptions to Reflow Direction

Earlier, we briefly mentioned that some cases can be exceptions to the “single-scroll-direction-only” policy. Some types of content require a two-dimensional layout to convey important meaning. Consider data tables, where you need to intersect rows and columns to understand data and relationships. Or a map, where you should be able to “reposition” the viewport to see specific areas and their surroundings. WAI-ARIA also provides an example of toolbars and interfaces. In all these cases, if you cannot find an alternative way to present your content, it's acceptable to allow horizontal scrolling.

5. Some Techniques and Tricks

5.1 Mobile-First Approach

If you've already ventured into responsive design, you've probably heard the mantra “mobile first.” Let me tell you: they're right. If you still have doubts, I can bet you've never been in a project where accessibility issues emerged late in the development stage. If you have, you know that this single requirement could cause significant delays (and consequent costs). Start with a single-column layout, and you'll save a lot of effort later while obtaining a more robust layout structure. You can use a desktop-first approach, but it can get trickier in some cases, forcing you to rethink some components.

5.2 Use Media Queries Wisely

Media queries are a great tool, but don’t rely solely on them. Many techniques can manage reflow and adaptability dynamically, without the limitations of media queries tied to specific breakpoints. Explore flex and grid layouts, max, min, min-max, calc(), and dimensions in percentages and rem. Leveraging these will save you time and effort, as well as reduce extra lines of code!

5.3 Grid and Flexbox

As mentioned earlier, try to master both (or at least one of them). With their many properties and elements, these two display types can effectively solve many of your design issues. Each has its pros and limitations, but both help reduce the need for many media queries, adapting and changing not just at specific breakpoints.

5.4 Fixed Elements

Fixed elements are extremely useful with large displays, but they can completely fill the viewport on smaller screens. Remember that we are dealing not just with a mobile phone portrait display, but with a tiny 320x256px one! Plan carefully about at what screen size your elements should become sticky.

5.5 Max-Width CSS Property

In many cases, a max-width can come in handy, forcing an element to not exceed a certain width relative to the viewport (percentages and rem are the way to go). For instance, if you consider an image (with no margins and placed directly in the <body> element), setting max-width: 100% tells the browser, “make this image the size you want or that I have specified, but never larger than the window that displays it.” Max-height works the same way, but it's less critical for a single-column layout (though more important for a single-row layout).

5.6 Rethink Simple Tables

I know we have already stated that tables are exceptions to reflow, as their structure intrinsically conveys meaning. However, for simpler tables, before giving up, ask yourself: “Is there any way I could represent this data without using a table?” Perhaps a set of cards or an alternative descriptive text? For complex or larger tables, this may be impossible or make content harder to understand, but it’s worth considering if you have a simple one.

5.7 Dynamic Measuring Units

It can be easy to rely on pixels; they are simple to measure and calculate. However, they lack dynamicity and are static. Using pixels for font sizes denies users the capability of resizing text to those users that want or need to increaseor decrease font size. Additionally, using only pixels in layouts often requires many media queries to address various resolutions and zoom levels. Instead, use rem, percentages, vw, and vh, which change dynamically relative to the font size set by the user, the container, or the viewport. Be mindful in choosing the most appropriate measuring unit for your elements, and when in doubt, at least use rem: your elements will resize dynamically based on the font size chosen by the user.

5.8 Manage Really Long Strings

If you have a long string without spaces or symbols, it may overflow its container in a small viewport. CSS can help with properties like word-break and overflow-wrap, and if you need an HTML tag, you can use the <wbr> tag to suggest a “word breaking” opportunity when the text exceeds the limit (e.g., in long URLs, insert a <wbr> before any point or slash).

6. How Should Reflow Look?

If you have done your homework properly, content should smoothly wrap within the viewport (window's boundaries), regardless of whether the user resizes the window, zooms in, or increases the font base size. All content and functionalities should remain present and visible (compressing and expanding sections, if correctly implemented, is still a success criterion, like a navigation menu compressed into a simpler hamburger icon) and usable.