1.4.4 and 1.4.10 – Refresh or not?

[JuliaTol-properaccess]

If you zoom in on a page to 200% or 400% and notice that part of the content falls outside the viewport, what would be your next step? Would you refresh the page to see whether the issue disappears?

This step — reloading the page — is not something I see explicitly mentioned on W3.org, in the techniques, or by Deque. I am therefore curious how you interpret this success criterion: should the content be visible immediately after zooming to 400%, or only after zooming to 400% and refreshing the page?

Arguments for refreshing

People who browse websites at a constant 400% zoom level typically do not zoom in on each page individually. Instead, they load every page directly at 200%/400% in their browser. Refreshing the page after zooming therefore better simulates the real-world experience of this group of users.
Additionally, a browser may occasionally fail to render a correctly implemented responsive element properly on the first load; a refresh can resolve this.

Arguments against refreshing

If a visitor zooms in while using a page to view a specific piece of content more clearly and that content disappears, it may not be obvious to everyone that they need to refresh the page. For people with cognitive or motor impairments, this could create an additional barrier.

How do you test this SC?

[TestPartners]

I have encountered a lot of issues when website layouts change between the desktop and mobile layouts, so this is definitely a problem that should be addressed in WCAG, so we all do our testing and reporting consistently. The issues can manifest themselves in many ways. A common issue is where a footer collapses into an accordion in the mobile layout, but the accordion functionality doesn’t work unless the page is refreshed. I have seen similar issues with main menus and elements that become sticky at some viewport sizes. As you say, the issue sometimes disappears if you refresh the page, so that is indeed the first thing I do. I then verify that the issue is repeatable and determine its extent. What happens when you increase the zoom level? What happens when you decrease it? What viewport widths do things happen? Next, I investigate exactly why the issues occur, and it’s not usually a pure CSS fault. In my experience it’s always when JavaScript is being used to modify the DOM on page load instead of just using media queries. It’s invariably repeatable once you understand the root cause. If the fault disappears after refreshing the page, I don’t report a WCAG non-conformance. However, it’s definitely an accessibility barrier, so I report all my findings and strongly recommend that the client fixes them. If there’s a consensus that we should report these issues as WCAG non-conformances, I would be perfectly happy with that. Steve Green Managing Director Test Partners Ltd

[yatil]

Success Criterion 1.4.4 Resize Text

Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

“Resized” is not defined, so it does not require resize in place. Reloading the page does not mean using assistive technologies. I would say this means no WCAG failure. (It’s bad for accessibility, but it meets the minimal threshold that WCAG requires.)

Success Criterion 1.4.10 Reflow

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

Changing the font size/zooming to 400% does not factor in the testing of this success criterion at all. Change the viewport to 320px wide and 256px heigh and see if there is scrolling in two dimensions that is not excepted.

I wrote about these Success Criteria in 2022: WCAG SC 1.4.4 Resize Text & 1.4.10 Reflow.

[TestPartners]

Changing the font size/zooming to 400% does not factor in the testing of this success criterion at all. Change the viewport to 320px wide and 256px heigh and see if there is scrolling in two dimensions that is not excepted.

This is actually irrelevant in the context of the initial question because the issue will still arise regardless of how the test is done. As I described in my previous post, all the issues I have encountered occurred because the reflowed content required a JavaScript function to run in order to display correctly, but the script only ran on page load. The fault occurs exactly the same regardless of whether the viewport is resized or the zoom level is increased.

As we have discussed interminably, my view is that changing the viewport to 320px wide or 256px high is arguably permitted by WCAG but it is a terrible way to do the Reflow test and I do not permit my team to do it. Your article is wrong when it says to set the viewport to 320px wide AND 256px high - the SC states that one dimension must be constrained depending on the direction of the text, but it says nothing about the other dimension.

[mraccess77]

I agree when testing content at 320 CSS pixels width no height is defined for the criteria. Use of 256 height is useful to help find other issues that impact users- but isn't strictly required. 400% zoom is not required.

I agree that reloading the page after changes is likely needed in some situations and if that solves the issue would not be seen as a failure.

I use browser zoom and while because of my display size and scale I start at a a higher effective zoom level - I often zoom in and out throughout the experience - so I do not keep the zoom level constant in many situations - although the fluctuations are often in a more narrow range.

[yatil]

As we have discussed interminably, my view is that changing the viewport to 320px wide or 256px high is arguably permitted by WCAG but it is a terrible way to do the Reflow test and I do not permit my team to do it. Your article is wrong when it says to set the viewport to 320px wide AND 256px high - the SC states that one dimension must be constrained depending on the direction of the text, but it says nothing about the other dimension.

Can you please point out where in the Success Criterion, which I quoted in full above, it says anything about the text direction? (In practice, it is unlikely that the height restriction comes into pass with left-to-right/right-to-left languages, but most of us test more than those.)

[TestPartners]

Can you please point out where in the Success Criterion, which I quoted in full above, it says anything about the text direction?

I would have thought it's obvious that I'm talking about horizontal and vertical text, not left and right. But you're right that my sentence should have said "the SC states that one dimension must be constrained depending on the dimension of the text, but it says nothing about the other dimension." To me, this makes less sense.

[bruce-usab]

…all the issues I have encountered occurred because the reflowed content required a JavaScript function to run in order to display correctly, but the script only ran on page load. The fault occurs exactly the same regardless of whether the viewport is resized or the zoom level is increased.

@TestPartners do you fail such behavior against an SC or just let the customer know about the bug?

[bruce-usab]

Absent a proposal to add something to Understanding, I have applied the “response only” label.

[TestPartners]

@TestPartners do you fail such behavior against an SC or just let the customer know about the bug?

I don't fail it, but I do strongly recommend that the client fixes it. As I said in my post a few days ago, if there’s a consensus that we should report these issues as WCAG non-conformances, I would be perfectly happy with that.