Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
290 changes: 290 additions & 0 deletions _rules/content-present-reflow-sc9kkf.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,290 @@
---
Comment thread
HelenBurge marked this conversation as resolved.
id: sc9kkf
name: Content is not missing at 320 CSS pixels
rules_format: 1.1
rule_type: atomic
description: |
This rule checks content is not missing when the viewport is set to 320 CSS pixels in the orientation of the text.
accessibility_requirements:
wcag21:1.4.10: # Reflow (AA)
forConformance: true
failed: not satisfied
passed: further testing needed
inapplicable: further testing needed
input_aspects:
- DOM Tree
- CSS Styling
acknowledgments:
authors:
- Helen Burge
previous_authors:
-
---

## Applicability

Starting from a baseline mid-range desktop resolution of 1280 x 1024 pixels, this rule requires content to scale cleanly down to smaller viewports without forcing users to scroll in two dimensions. It applies to any element containing visible content or functional components that excludes components that inherently require a two-dimensional layout to be understood. When scaling down to a width of 320 CSS pixels for horizontal languages (or a height of 256 CSS pixels for vertical languages, equivalent to 400% browser zoom), content must smoothly reflow.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the previous comment:

WilcoFiers
Member
Author
"non-excepted" What does that mean?
did you mean (visible content) or (functional components) or visible (content or functional components)?
"requiring text to reflow" How do I know if the text requires reflow? I would probably pull this and say regardless of if it requires reflow, if content disappears on.a 320x256 viewport that's a failure.
"320 CSS pixels for horizontal languages" WCAG doesn't say this only applies to horizontal writing systems. Why would we limit it that way? Horizontal text can easily end up being clipped vertically when the width of the viewport changes.
"to align applicability more closely with these reflow requirements..." I don't understand what this means or what its doing here.
Does this include decorative content? For images, are you sure ANY truncation should result in a failure?
Is it acceptable to replace larger things with smaller ones? Like a text "home" with a home icon for instance?
You're not accounting for text that was clipped/hidden in the original view. Presumably content that's cut off in any resolution shouldn't fail this requirement.
I think we need to specify the original viewport. If I start at 321x257 and then go to 320x256 that isn't likely to make much of a difference. I don't think people can test this consistently if we don't establish the starting resolution.

HelenBurge
Collaborator
Start with 1280 x 1024 resolution going down to 320 to 256

HelenBurge replied

HelenBurge
Collaborator
https://www.w3.org/WAI/WCAG22/Techniques/general/G224

HelenBurge replied

HelenBurge
Collaborator
Example - non-wrapping code - Wilco wants a pass - if the code must maintain a line then do not wrap it.

Procedure for code snippets
Display the web page in a user agent where the page can be zoomed, or the user agent can be resized.
Zoom in or resize the browser window so that the viewport is equivalent to 320 CSS pixels wide.
The code snippets fits within the width so that it is only necessary so scroll vertically to read each line of code.
Or, for code where non-wrapping lines are not essential, the code wraps or a mechanism is provided to allow line wrapping.
Or, the indentation and linebreaks are meaningful to the code language.

HelenBurge replied

HelenBurge
Collaborator
Explain in background that the tester knows the language requirements

HelenBurge replied

HelenBurge
Collaborator
Clarify the reflow tests specifically
Text is not cutoff at 320 CSS pixels
Orientation scrolls do not exist at 320 CSS pixels without a content exception
Content is not missing at 320 CSS pixels - this is this one

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to add the passing example

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@WilcoFiers - I think I have addressed what you outlined.


## Expectation

For each target element, when the viewport is set to 320 by 256 CSS pixels, the content is not cut off, removed, or obscured by another element, except if one of the following is true:

- the hidden content can be scrolled into view, or
- an [instrument][] is available to reveal the content.

## Background

This rule supports WCAG 2.1 Success Criterion 1.4.10 Reflow, which requires that content be presented without loss of information or functionality at a width equivalent to 320 CSS pixels. When content is missing at smaller viewport sizes, users may lose access to essential information or controls, even if the layout appears functional. Responsive design should reposition or adapt content, not remove it entirely, unless an equivalent mechanism provides access.

The person testing the content is aware of the content's requirements to allow word wrap and specific spacing, for example, a programming language like Python.

### Assumptions

There are no assumptions.

### Accessibility Support

There are no accessibility support issues known.

## Examples

### Passed

#### Passed Example 1

Content remains fully available after reflow.

```html
<div style="max-width: 100%;">
<p>
All text content remains visible and accessible when the viewport is reduced.
</p>
</div>
```

#### Passed Example 2

Navigation collapses into a menu but remains accessible. Content is not removed, only not immeditately visible behind an accessible control.

```html
<button aria-expanded="false">Menu</button>
<nav hidden>
<ul>
<li>Home</li>
<li>About</li>
<li>Contact</li>
</ul>
</nav>
```

#### Passed Example 3

Content is visually hidden on the first view but remains available programmatically and visual in a sub page.

```html
<p class="visually-hidden">
Additional instructions available to screen reader users.
</p>
```

#### Passed Example 4

Content is moved in the layout but still present.

```html
<style>
.sidebar {
order: 2;
}
</style>
<div class="sidebar">
<p>Sidebar content is still available, just repositioned.</p>
</div>
```

#### Passed Example 5

Images resize but are still visible.

```html
<img src="example.jpg" style="max-width: 100%;">
```

#### Passed Example 6

Form fields collapse in an accordian but remain accessible when expended.

```html
<form>
<label for="name">Name</label>
<input id="name" type="text">
</form>
```

#### Passed Example 7

Content requiring two-dimensional layout (covered under reflow exceptions).

```html
<table>
<tr><th>Column</th><th>Column</th></tr>
</table>
```

#### Passed Example 8

Python code that allows a scroll as cannot include a word wrap to function.

```html
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Passing Code Reflow</title>
<style>
/* Prevents wrapping and allows scrolling at 320px wide */
pre {
max-width: 320px;
overflow-x: auto;
white-space: pre;
background: #f4f4f4;
padding: 10px;
}
/* Visual cue for keyboard users */
pre:focus { outline: 2px solid #005a9c; }
</style>
</head>
<body>
<!-- tabindex="0" ensures keyboard-only users can scroll the long line -->
<pre tabindex="0" role="region" aria-label="Python code"><code>def check_data(items):
for item in items:
if item.status == "active" and item.value > 100:
print(f"Valid ID: {item.id} with high value.")</code></pre>
</body>
```

### Failed

#### Failed Example 1

Static content removed at smaller viewport.

```html
<style>
@media (max-width: 400px) {
.important-content {
display: none;
}
}
</style>
<div class="important-content">
This content disappears on smaller screens.
</div>
```

#### Failed Example 2

Navigation items removed instead of adapted.

```html
<style>
@media (max-width: 400px) {
nav li:nth-child(n+3) {
display: none;
}
}
</style>
<nav>
<ul>
<li>Home</li>
<li>About</li>
<li>Services</li>
<li>Contact</li>
</ul>
</nav>
```

#### Failed Example 3

Content visually clipped and inaccessible.

```html
<div style="height: 50px; overflow: hidden;">
<p>
Important content is hidden and cannot be accessed or revealed.
</p>
</div>
```

#### Failed Example 4

Content moved off-screen and not reachable when it should be visible.

```html
<div style="position: absolute; left: -9999px;">
Hidden content that cannot be accessed by users.
</div>
```

#### Failed Example 5

Interactive element missing at smaller viewport.

```html
<style>
@media (max-width: 400px) {
button {
display: none;
}
}
</style>
<button>Submit</button>
```

#### Failed Example 6

Image removed without alternative.

```html
<style>
@media (max-width: 400px) {
img {
display: none;
}
}
</style>
<img src="important-diagram.png" alt="Important diagram">
```

#### Failed Example 7

Collapsed content has no mechanism to access it.

```html
<div style="display: none;">
<p>This content is permanently hidden.</p>
</div>
```

### Inapplicable

#### Inapplicable Example 1

Content explicitly hidden from all users.

```html
<div hidden>
Hidden content not intended for display.
</div>
```

#### Inapplicable Example 2

Content outside the user viewport by design (e.g. off-canvas patterns before interaction).

```html
<div aria-hidden="true" class="offscreen-menu">
Menu content appears only when activated.
</div>
```

[instrument]: #instrument 'Definition of instrument'
Loading