Create Reflow Tests by HelenBurge · Pull Request #2429 · act-rules/act-rules.github.io

HelenBurge · 2026-07-13T11:17:43Z

First draft of the content reflow test

Creating the first draft of a reflow test, one of three new rules

Closes issue(s):

closes Reflow tests to be written #2424

Need for Call for Review:
This will require a 2 weeks Call for Review

Pull Request Etiquette

When creating PR:

Make sure you're requesting to pull a branch (right side) to the develop branch (left side).
Make sure you do not remove the "How to Review and Approve" section in your pull request description

After creating PR:

Add yourself (and co-authors) as "Assignees" for PR.
Add label to indicate if it's a Rule, Definition or Chore.
Link the PR to any issue it solves. This will be done automatically by referencing the issue at the top of this comment in the indicated place.
Optionally request feedback from anyone in particular by assigning them as "Reviewers".
If your PR is for a new rule with an Accessibility Support note, or for updating the Accessibility Support note of an existing section, make sure to open a corresponding Accessibility Support issue.

When merging a PR:

Close any issue that the PR resolves. This will happen automatically upon merging if the PR was correctly linked to the issue, e.g. by referencing the issue at the top of this comment.

How to Review And Approve

Go to the “Files changed” tab
Here you will have the option to leave comments on different lines.
Once the review is completed, find the “Review changes” button in the top right, select “Approve” (if you are really confident in the rule) or "Request changes" and click “Submit review”.
Make sure to also review the proposed Call for Review period. In case of disagreement, the longer period wins.

First draft of the content reflow test

netlify · 2026-07-13T11:17:48Z

❌ Deploy Preview for act-rules failed.

Name	Link
🔨 Latest commit	`8de47f2`
🔍 Latest deploy log	https://app.netlify.com/projects/act-rules/deploys/6a54ef00cd05980008f5ed36

HelenBurge · 2026-07-13T14:34:47Z

I know I have to add references and definitions to the tests - TBD

G0dwin · 2026-07-25T03:09:38Z

+
+#### Failed Example 2
+
+Navigation items removed instead of adapted.


This looks like a repetition of the first example. Does this add or clarify something that the first example doesn't cover?

G0dwin · 2026-07-25T03:12:06Z

+
+#### Failed Example 4
+
+Content moved off-screen and not reachable.


It looks to me like this content would not be available at any viewport size, this is also a common valid technique for applying text only available to AT.

Yes, we need a default state where this is available. In any case, this also seems to contradict the expectation

G0dwin · 2026-07-25T03:27:41Z

+Each target element:
+Retains all content and functionality when viewed at 320 CSS pixels; and
+- Does not hide, remove, or make content unavailable as a result of viewport constraints, zoom, or responsive behaviour; and
+- Ensures that any content that is visually hidden at this viewport size is still programmatically available and accessible to users.


With the examples that you included that always hide content, I feel like we may need to define a way to compare before and after. For example, should we compare content at 1280 vs 320?

I'd agree with @G0dwin. We first need to define the default view

giacomo-petri · 2026-07-27T06:49:37Z

+
+## Applicability
+
+This rule applies to any element containing visible content or functional components. It is rendered when the viewport is set to 320 CSS pixels in the orientation of the text.


I would encourage following the wording of the requirement.

As described in the understanding doc:

This criterion requires non-excepted sections of content that are written in horizontal languages reflow when narrowed to a width equivalent to 320 CSS pixels. Similarly, sections of content that are written in vertical languages (which are not as commonly used on the web and so will be used much less frequently in examples) need to be able to reflow when rendered at a height equivalent to 256 CSS pixels.

the orientation of the text is relevant in determining the applicable requirement. As currently written, the text appears to imply that the requirement is always 320 CSS pixels, even for vertically oriented content, which is inconsistent with the criterion.

giacomo-petri · 2026-07-27T06:54:20Z

+Each target element:
+Retains all content and functionality when viewed at 320 CSS pixels; and
+- Does not hide, remove, or make content unavailable as a result of viewport constraints, zoom, or responsive behaviour; and
+- Ensures that any content that is visually hidden at this viewport size is still programmatically available and accessible to users.


I'd agree with @G0dwin. We first need to define the default view

giacomo-petri · 2026-07-27T06:56:34Z

+
+Each target element:
+Retains all content and functionality when viewed at 320 CSS pixels; and
+- Does not hide, remove, or make content unavailable as a result of viewport constraints, zoom, or responsive behaviour; and


I'd say this is ambiguous. For example, a navigation menu that is expanded by default on desktop but programmatically hidden on mobile until the user activates the hamburger menu could be interpreted as violating this requirement. I think we need more precise wording than "hide" to avoid unintentionally including these common responsive design patterns

giacomo-petri · 2026-07-27T07:11:10Z

+
+## Applicability
+
+This rule applies to any element containing visible content or functional components. It is rendered when the viewport is set to 320 CSS pixels in the orientation of the text.


We can refine the applicability even further. For example, it could apply only to visible content with:

a height of at least 320 CSS pixels on pages with vertical scrolling

a height of at least 256 CSS pixels on pages with horizontal scrolling

This would align the applicability more closely with the corresponding reflow requirements

giacomo-petri · 2026-07-27T07:13:01Z

+
+#### Passed Example 1
+
+Content reflows but remains fully available.


Suggested change

Content reflows but remains fully available.

Content remains fully available after reflow.

My feeling is that the use of "but" gives the sentence a negative tone

giacomo-petri · 2026-07-27T07:34:05Z

+Each target element:
+Retains all content and functionality when viewed at 320 CSS pixels; and
+- Does not hide, remove, or make content unavailable as a result of viewport constraints, zoom, or responsive behaviour; and
+- Ensures that any content that is visually hidden at this viewport size is still programmatically available and accessible to users.


Also, in the first bullet we are saying not to hide or remove the content, whereas here we're saying that content that cannot be hidden (and is visually hidden) is programmatically available. I understand that the intent (even though I don't agree) is for the first bullet to cover programmatically hidden content and the second to cover only visually hidden content. However, that distinction isn't clear from the current wording

giacomo-petri · 2026-07-27T07:35:20Z

+
+#### Failed Example 4
+
+Content moved off-screen and not reachable.


Yes, we need a default state where this is available. In any case, this also seems to contradict the expectation

giacomo-petri · 2026-07-27T07:38:18Z

+```html
+<div role="presentation">
+  Decorative content only.
+</div>
+```


There is no mention of decorative content in either the SC or this rule. As written, this cannot be marked as inapplicable. Also, even if we decide to move in that direction (and I'm not convinced we should), I would replace the text with a decorative image, since the concept of "decorative text" is debatable

giacomo-petri · 2026-07-27T07:41:26Z

+#### Inapplicable Example 4
+
+Content that is replaced by an equivalent alternative. The full content is replaced with an equivalent that preserves meaning.
+
+```html
+<p class="mobile">Short summary version</p>
+<p class="desktop">Full detailed version</p>
+```


There is no mention of alternative in this rule. As written, this cannot be marked as inapplicable.

giacomo-petri · 2026-07-27T07:43:35Z

+
+## Applicability
+
+This rule applies to any element containing visible content or functional components. It is rendered when the viewport is set to 320 CSS pixels in the orientation of the text.


It is rendered when the viewport is set to 320 CSS pixels in the orientation of the text.

the current wording implies that if the content is hidden at 320 CSS pixels, the rule is not applicable, which isn't our intent

Create content-present-reflow-sc9kkf

f89d5d3

First draft of the content reflow test

HelenBurge self-assigned this Jul 13, 2026

HelenBurge requested a review from G0dwin July 13, 2026 11:18

HelenBurge added the Rule Use this label for a new rule that does not exist already label Jul 13, 2026

HelenBurge added 2 commits July 13, 2026 14:12

Update content-present-reflow-sc9kkf

7aa38a5

Update content-present-reflow-sc9kkf

dd72c25

HelenBurge marked this pull request as draft July 13, 2026 13:31

HelenBurge added 4 commits July 13, 2026 14:36

Create orientation-scroll-reflow-acsmtl

c595151

Create orientation-scroll-reflow-acsmtl

0a6d522

Create text-cutoff-reflow-lf4ym8

4166678

Delete orientation-scroll-reflow-acsmtl

8de47f2

HelenBurge changed the title ~~Create content-present-reflow-sc9kkf~~ Create Reflow Tests Jul 13, 2026

WilcoFiers requested a review from giacomo-petri July 23, 2026 14:19

G0dwin reviewed Jul 25, 2026

View reviewed changes

giacomo-petri requested changes Jul 27, 2026

View reviewed changes


		#### Failed Example 2

		Navigation items removed instead of adapted.


		#### Failed Example 4

		Content moved off-screen and not reachable.


		## Applicability

		This rule applies to any element containing visible content or functional components. It is rendered when the viewport is set to 320 CSS pixels in the orientation of the text.


		#### Passed Example 1

		Content reflows but remains fully available.

	Content reflows but remains fully available.
	Content remains fully available after reflow.

Uh oh!

Conversation

HelenBurge commented Jul 13, 2026

Pull Request Etiquette

When creating PR:

After creating PR:

When merging a PR:

How to Review And Approve

Uh oh!

netlify Bot commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

❌ Deploy Preview for act-rules failed.

Uh oh!

HelenBurge commented Jul 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

netlify Bot commented Jul 13, 2026 •

edited

Loading