Re: Resize content (#77)

Mike commented on Github with some good word-smithing, but there is another question for the group:

Can the test be at the content level?

I.e. for this updated wording:
“Content can be resized to 400% without loss of content, functionality or two-dimensional scrolling, except where fixed spatial layout is essential to use or meaning.”

If a data table is added that expands out of the viewport, that is fine, but does it mean the rest of the page is exempt as well?

If we can tackle that in the Understanding docs I’m happy with that, but if that exemption means the whole page is then exempt we’ll have to go back to the previous wording for that aspect.



From: Alastair Campbell <>
Date: Tuesday, 24 January 2017 at 10:18
To: WCAG <>
Subject: Resize content (#77)
Resent-From: WCAG <>
Resent-Date: Tuesday, 24 January 2017 at 10:19

Hi everyone,

I can’t make the meeting today, but I’ll like to get issues 77 ‘done’ (as far as possible for FPWD). This is a status update + specific things to agree or disagree with at the bottom.

The current proposal for SC text is:

 “The content of the Web page can be increased up to 400% without loss of content, functionality or two-dimensional scrolling, except where spatial layout of some the content is essential to that content's use, that part of the content is exempt.”

NB: The second exception for mobile-style zooming was removed on the basis that it is not a factor of the content, but it will need to be noted in the Understanding doc, especially for testing.

There is an overview to compare this SC with “Reflow to single column” (now “Linearise”) and the (now defunct) Line length SC:

There has been considerable discussion on the issue:

All of the comments have been answered, but there are specific issues to consider and agree:

1. There is a clear divide between how mobile & desktop browsers deal with layout and zooming, we have avoided referencing UAs in the SC text, but does the SC text need to acknowledge it?

As it stands, authors are required to ensure the *content* can be re-sized upto 400%, which in practice means testing on desktop-style browsers. Most mobile UAs don’t support zoom + reflow, but that isn’t the authors problem to change. We have been through iterations which call out that difference (see the description on Github), but came to the point of removing it.

Also note that it is the uptick of mobile & responsive design that *enables* us to go for 400% without horizontal scrolling, on capable browsers.

2. 400% was chosen as it is the upper end of the practical limit for web development (1280px / 4 = 320px, which is the typical small mobile screen size so what developers already test with), does anyone have good reason to reduce that to 300%?

3. Should we set a starting point for window size when testing? I am inclined to, and use the width 1280px.

4. Level A was chosen by LVTF due to the impact 2D scrolling has on people with LVTF, and I didn’t argue with that as it is relatively easy to do, is that appropriate?

Speak now or forever hold your peace… (well, until the next round anyway).

Kind regards,


-- <>

tel: +44 (0)117 929 7333 / 07970 879 653

follow us: @we_are_nomensa or me: @alastc

Nomensa Ltd. King William House, 13 Queen Square, Bristol BS1 4NT

Company number: 4214477 | UK VAT registration: GB 771727411

Received on Tuesday, 24 January 2017 18:09:11 UTC