Expand 1.4.10 to apply 'down to' instead of 'at'

[patrickhlauke]

While 1.4.10 was written with the "zoom up to 400%" idea in mind, does it - as a perhaps unintended side effect - essentially disallow two-dimensional scrolling at any screen/viewport size (because the values of 320 CSS px / 256 CSS px are only the minimums, and we should test sizes / zoom factors leading up to that)?

So, if a page at 100% zoom, in a maximized browser window on a 1920x1080 display (or even larger) presents the user with both horizontal and vertical scrolling...does it fail 1.4.10 even though no zooming was involved?

I'd argue that yes, it does, but the normative language may give the impression that only those two minimum sizes (320 CSS px / 256 CSS px) actually count.

[alastc]

I think "without requiring scrolling in two dimensions for:" scopes it to the sizes specified, so no.

Also, it is scoped to the 'content', which can be sub-sections of a page. So I think you could argue that a horizontally scrolling section of a (vertically scrolling) page is limited to 256px tall, but that's a slightly different question.

[patrickhlauke]

I fear this brings us back to similar discussions about “up to”/“down to” we’re having elsewhere. Because if we’re saying that we literally only care about the exact sizes of 320 CSS px for vertical content / 256 CSS px for horizontal, we’re essentially saying that violations that result in bidirectional scrolling are all passes for all other sizes (and also, even taking the 1920x1080 starting point, any zoom that is LESS than 400%). Which defeats the purpose this SC sets out to address?

Basically, to me at least, the sensible interpretation here is: content should reflow to whatever size viewport the user has, with those hard values there as a minimum...but any sizes above that count as well.

On 17 Apr 2019, at 23:46, Alastair Campbell notifications@github.com wrote:

I think "without requiring scrolling in two dimensions for:" scopes it to the sizes specified, so no.

Also, it is scoped to the 'content', which can be sub-sections of a page. So I think you could argue that a horizontally scrolling section of a (vertically scrolling) page is limited to 256px tall, but that's a slightly different question.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[patrickhlauke]

Further, I’m not so sure about the distinction you make here between “content” and the page as a whole, unless you mean that bidirectional scrolling is fine as long as each discrete piece of content/page element can be viewed in the viewport width (so a larger page with “islands” of content that individually fit in, say, 320 CSS px width display, but are strewn around a page with lots more width). This also seems rather odd and defeating the point of the SC somewhat (not to mention that things like navigations etc are also “content”, i’d argue?)

On 17 Apr 2019, at 23:46, Alastair Campbell notifications@github.com wrote:

I think "without requiring scrolling in two dimensions for:" scopes it to the sizes specified, so no.

Also, it is scoped to the 'content', which can be sub-sections of a page. So I think you could argue that a horizontally scrolling section of a (vertically scrolling) page is limited to 256px tall, but that's a slightly different question.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[alastc]

the sensible interpretation here is: content should reflow to whatever size viewport the user has

Indeed, and the sensible (least work) approach would be to do that. However, saying that normatively brought up other issues.

For the 'content' aspect, imagine a data table (which is exempted) creating horizontal scrolling in a page. The rest of the page is not exempt.

Or a netflix/amazon/bbc video selection page with rows of horizontally scrolling panels. They can be done well if they aren't too tall.

[patrickhlauke]

Indeed, and the sensible (least work) approach would be to do that. However, saying that normatively brought up other issues

So if you are saying that the only thing that does count is (just to stick to vertical content) 320 CSS px exactly and nothing else, does that mean that the following would pass this? Perhaps slightly contrived, but to make the point: a media query that checks for exact viewport width of 320 CSS px and makes sure paragraphs fit the width without causing horizontal scrolling, but has them fixed to a defined size which will cause horizontal scrollbars as soon as the viewport is anywhere between 320 CSS px and 1920 CSS px?

p { width: 1920px; }
@media (width 320px) { 
  p { width: 100%; }
}

As for the netflix example, that's a case of nested scrolling which is fine - the page overall scrolls one way, and a discrete component scrolls the other way. What I was getting at is the opposite: what if the page itself (the overall outer part) has bidirectional scrolling, at viewport sizes other than 320 CSS px width?

[WayneEDick]

Now, let's be serious. If you were a user with 20/60 vision and needed 300% enlargement, or if you had a 33% visual field would you really want to go to 400% enlargement or 1/4 field width just to get reflow. Of course not. You would like the size you need with reflow so that you could read.

Of course if you need 250% or if you needed a visual field of .4 you should get reflow at 512 CSS px. Nobody can read without word wrapping.

Regarding 2-d scrolling. It is only a reading barrier if it involves scrolling in the direction of lines of text to perceive hidden text. Jumping from column to column is no big deal, given you know the content that is off the screen exists. Scrolling from section to section has no combinatorial implications. Scrolling in the direction of lines of text increases scrolling complexity by the number of lines times the number of scrolls per line.

1.4.10 is trying to fix a prejudice that has existed for a long time: The false belief that people with low vision can somehow read effectively when they are forced to scroll in the direction of lines of text just to see text. I proved that this premise was false. I published my results. They passed peer review. It is established fact that nobody can read effectively if they must scroll in the direction of lines of text.

1.4.10 is a minimally invasive way to minimize this problem.

On Wed, Apr 17, 2019 at 11:54 PM Patrick H. Lauke notifications@github.com wrote:

Indeed, and the sensible (least work) approach would be to do that. However, saying that normatively brought up other issues

So if you are saying that the only thing that does count is (just to stick to vertical content) 320 CSS px exactly and nothing else, does that mean that the following would pass this? Perhaps slightly contrived, but to make the point: a media query that checks for exact viewport width of 320 CSS px and makes sure paragraphs fit the width without causing horizontal scrolling, but has them fixed to a defined size which will cause horizontal scrollbars as soon as the viewport is anywhere between 320 CSS px and 1920 CSS px?

p { width: 1920px; } @media (width 320px } { p { width: 100%; } }

As for the netflix example, that's a case of nested scrolling which is fine - the page overall scrolls one way, and a discrete component scrolls the other way. What I was getting at is the opposite: what if the page itself (the overall outer part) has bidirectional scrolling, at viewport sizes other than 320 CSS px width?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/698#issuecomment-484379321, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F5PEZKGHEN5AYW2KXDPRALLVANCNFSM4HGWUYQA .

[patrickhlauke]

so wayne, in short your answers to my question seem to suggest:

• you agree that it's not just the 320 CSS px / 400% zoom that's the situation where problematic two-dimensional scrolling fails, but any zoom factor at any size, with the SC providing the minimum below which it's difficult for content authors to ensure reflow?

• if a page was at 100% zoom at 1920 x 1080, but it had lines of text that required two-dimensional scrolling, this would also be a failure of this SC?

[WayneEDick]

Hi Patrick,

Yes. Failure to word wrap text is always a profound barrier to reading, at a any size. Your first bullet point is the take away.

As far as failure to wrap at 100%, well any site that chooses to not provide word wrapping for its primary audience is simply foolish. I wouldn't fail such a site, but just warn the developer of a foolish choice.

Best, Wayne

On Sat, Apr 20, 2019 at 4:53 PM Patrick H. Lauke notifications@github.com wrote:

so wayne, in short your answers to my question seem to suggest:

-

you agree that it's not just the 320 CSS px / 400% zoom that's the situation where problematic two-dimensional scrolling fails, but any zoom factor at any size, with the SC providing the minimum below which it's difficult for content authors to ensure reflow?

if a page was at 100% zoom at 1920 x 1080, but it had lines of text that required two-dimensional scrolling, this would also be a failure of this SC?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/698#issuecomment-485200032, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F4I44CY3XIUXCJLXN3PROUI3ANCNFSM4HGWUYQA .

[patrickhlauke]

wayne, your statements are in contradiction. if you're saying that failure to word wrap text is a failure at any size, how is it then NOT a failure at 100%/1920x1080? are you saying the important thing is simply "if it word wraps at any zoom factor other that 100%? and if so, at what point do we draw the line? what if it's at 110%? is it only when it's not 100% that you deem it to apply, as 100% is not a low vision scenario? what about 101% (if a UA allowed such fine-grained control)?

[WayneEDick]

Dear Patrick, Not really. You certainly could claim failure at some higher resolution. It would be a kindness to the developer, but really. How often will such a site occur. A 16px font on a 1920 width screen would require lines of more than 190 characters to overflow. That is not a realistic scenario. Best, Wayne

On Sun, Apr 21, 2019 at 5:42 PM Patrick H. Lauke notifications@github.com wrote:

wayne, your statements are in contradiction. if you're saying that failure to word wrap text is a failure at any size, how is it then NOT a failure at 100%/1920x1080? are you saying the important thing is simply "if it word wraps at any zoom factor other that 100%? and if so, at what point do we draw the line? what if it's at 110%?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/698#issuecomment-485294606, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F7E4VYWCB5IYETMD7LPRUCYFANCNFSM4HGWUYQA .

[patrickhlauke]

How often will such a site occur.

Oddly enough, I came across a customer site just last week (sadly can't share) that was designed purely for 1920x1080, with an embedded scrollable area with very long lines of text set to about 80% width, and once you sized the window down a bit / zoomed to around 120%, it developed horizontal as well as vertical scrollbars on that content area.

In any case, similar to the "how would this work?" question i got in a similar discussion https://github.com/w3c/wcag/issues/635#issuecomment-474618442 ... I would say it's not the point to ask how likely something like this is, but rather to make sure the normative language of the SC does not leave giant loopholes for situations where it does indeed happen. Otherwise, this just results yet again in one of those "where's the cut-off point then" circular arguments. Normatively right now, it reads like the ONLY scenario addressed is 320 CSS px width for vertical scrolling content / 256 CSS px height for horizontal scrolling content, and failures at ANY other sizes are irrelevant and a pass.

and, late reply to this by @alastc

However, saying that normatively brought up other issues.

From memory (correct me if i'm wrong), the main issue was one of having a reasonable lower bound below which it was simply unrealistic authors would be able to reflow, and those mobile-inspired/400% inspired values then came into existence. But they were meant, I believe at the time at least, as lower bounds, not "this is the only set of values that matters". so having it phrased/rephrased as something closer to that original intent, a la "content should reflow to whatever size viewport the user has, down to and including 320 CSS px / 256 CSS px", seems sensible and feasible? (unless we're in the "it's now too late, we can only add, never take away/rephrase" part of WCAG 2.1 SCs going forward.

[WayneEDick]

Patrick, Does it work at 320px? Wayne

On Mon, Apr 22, 2019 at 12:46 PM Patrick H. Lauke notifications@github.com wrote:

How often will such a site occur.

Oddly enough, I came across a customer site just last week (sadly can't share) that was designed purely for 1920x1080, with an embedded scrollable area with very long lines of text set to about 80% width, and once you sized the window down a bit / zoomed to around 120%, it developed horizontal as well as vertical scrollbars on that content area.

In any case, similar to the "how would this work?" question i got in a similar discussion #635 (comment) https://github.com/w3c/wcag/issues/635#issuecomment-474618442 ... I would say it's not the point to ask how likely something like this is, but rather to make sure the normative language of the SC does not leave giant loopholes for situations where it does indeed happen. Otherwise, this just results yet again in one of those "where's the cut-off point then" circular arguments. Normatively right now, it reads like the ONLY scenario addressed is 320 CSS px width for vertical scrolling content / 256 CSS px height for horizontal scrolling content, and failures at ANY other sizes are irrelevant and a pass.

and, late reply to this by @alastc https://github.com/alastc

However, saying that normatively brought up other issues.

From memory (correct me if i'm wrong), the main issue was one of having a reasonable lower bound below which it was simply unrealistic authors would be able to reflow, and those mobile-inspired/400% inspired values then came into existence. But they were meant, I believe at the time at least, as lower bounds, not "this is the only set of values that matters". so having it phrased/rephrased as something closer to that original intent, a la "content should reflow to whatever size viewport the user has, down to and including 320 CSS px / 256 CSS px", seems sensible and feasible? (unless we're in the "it's now too late, we can only add, never take away/rephrase" part of WCAG 2.1 SCs going forward.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/698#issuecomment-485528346, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F34TLV3VMRWLWVHPR3PRYI2BANCNFSM4HGWUYQA .

[patrickhlauke]

it's funny you should ask. it does, as they switch to a very different arrangement that's targeted at mobile. it's just anything that's bigger than their idea of "mobile" and smaller than "it's a big modern desktop" that has both horizontal and vertical scrollbar. so...in my book, that's still a fail (and the fact that you're asking this makes me assume that YOU assume things that cause horizontal scrollbars at any size will also do so at 320 so it's fine and there's no gap in the SC...whereas nowadays, it's trivially easy to have sites that pass at 320 but fail at any other sizes)

[alastc]

Hi Patrick,

I needed a reminder of how we got here, and found it from the TPG comment on reflow.

If we are finding gaps in practice then we could add something to address the 100-399% range, so long as it's testable.

they switch to a very different arrangement that's targeted at mobile

So (arguably) it works for low-vision / tunnel-vision as you can zoom in and/or adjust your window to get that version. I'm not saying that's perfect, but it puts in into the work-able range.

-Alastair

[patrickhlauke]

So (arguably) it works for low-vision / tunnel-vision as you can zoom in and/or adjust your window to get that version. I'm not saying that's perfect, but it puts in into the work-able range.

but again, it surely doesn't help users who only need a mild adjustment, forcing them to go to a magnification/zoom that's higher than what they actually need so they can avoid bidirectional scrolling

I needed a reminder of how we got here, and found it from the TPG comment on reflow

ah, the dangers of wooly/complex SCs. there's a lot of moving parts to these, and sometimes you need to stew on them and kick their tires in practice / hit real-life edge-cases ;)

[alastc]

So my question is then: How big an issue is the 'gap'?

1. How often do you find site which have horizontal scrolling at larger screen widths but pass at 320px? (Our assumption was that was fairly rare.)
2. How big an issue is it for users? (I can see that it is at least annoying, but it doesn't seem as important as the low-er vision end at 320px).

If it is (1) somewhat common, and (2) more than an annoyance, then it has the feel of a AAA criteria that builds on 1.4.10. E.g.

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

• Vertical scrolling content at a widths from 1920 to 320 CSS pixels;
• Horizontally scrolling content at a heights from 1024 to 256 CSS pixels.

(No exception.)

That would then require responsive design, and make it less applicable across technologies.

Personally, I think a new SC covering sticky elements would be more useful?

[patrickhlauke]

a few points to clarify: i'm not interested in now having "1920" or "1024" in normative language either. i'm really after making sure the SC doesn't give the impression of only applying to one very specific size, but showing that that size is a lower bound. so not "from 1920 to 320" or similar, but in theory applicable to any sizes, but with a lowest bound of 320, below which it's not a failure if horizontal scrolling happens.

in answer to your questions:

1. i think this is really a red herring. whether something passes or fails shouldn't really depend on "well yes, that fails the original intent, but it's unlikely to happen, so we don't need to explicitly say it's a fail". because that's exactly how gaps/loopholes happen.

2. this makes the assumption that 320 CSS px is the definitive size that low vision users will use/need. and it's based on the 1920 at 400% measure. what happens with a larger (physically) screen that is run at a higher resolution, and then zoomed to 400%? seeing 320 CSS px as a lower bound is fine, but it seems we're now focusing on this as if it were a standard size for desktop LV users? it may be for a specific set, with today's common resolutions. but this will age very poorly

also, as what we're talking about here appears (at least in part) to be the original intent, i'm more after an errata to 2.1 than any new SC - a clarification that no, it's not JUST 320 CSS px that counts. So, in essence:

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

Vertical scrolling content down to a width equivalent to 320 CSS pixels; Horizontal scrolling content down to a height equivalent to 256 CSS pixels. Except for parts of the content which require two-dimensional layout for usage or meaning.

unless the general consensus here is that this SC is really just about tackling the 400% case on desktop - not 300%, or any other sizes. just that one very specific setting (in the same vein that in 1.4.12 normatively it seems to have landed to one very specific set of settings for line height etc, rather than having them as an upper bound https://github.com/w3c/wcag/issues/635#issuecomment-474618442)

[patrickhlauke]

That would then require responsive design, and make it less applicable across technologies.

it doesn't necessarily. elastic/fluid layouts would also work just fine. but it would require NOT to use fixed width/height layouts.

[alastc]

I'm going from the normative text, so I don't think it does apply above 320px, which is what we settled on in 2.1. That's why I was talking about addition rather than errata.

Two of the points from the discussion previously are relevant, mine and the response.

[patrickhlauke]

i fear that in the various rounds of wordsmithing, this is one of those SCs that lost its way. so yes in essence, it's now ONLY catering to 320px? less of a line in the sand, more of a dot in the sand. as for @awkawk's response, as i'm not talking about going back to mandating zoom percentages (see the rewording that basically changes "at" to "down to"), it's possibly not relevant?

[WayneEDick]

Dear Patrick, The 320px only is not really a problem. Good developers will cover all levels. Less talented developers will squirrel it up. The latter group well, we can live with them. Our preferences can be stated clearly in the Understanding document and techniques.

1.4.10 was the first draft, and it is pretty brilliant. We couldn't solve the problem of line length for peripheral visual field loss. We had extreme difficulty with enlargement limits. 1.4.10 solves both by shifting the issue to a CSS pixel basis. There are holes, but we can clean them up.

I think of new criteria in WCAG 2.1 like WCAG 1. We are just at the initial level for low vision. We made significant progress. With 1.4.10 implemented as is we will get a good sample space of conformant web sites. It will allow us to test how important font size is for access by the target group. For example, currently a little more than half of people with low vision say 200% is enough. Will that change if 400% is available with word wrapping? We don't know, but we will.

Best, Wayne

On Tue, Apr 23, 2019 at 8:52 AM Patrick H. Lauke notifications@github.com wrote:

i fear that in the various rounds of wordsmithing, this is one of those SCs that lost its way. so yes in essence, it's now ONLY catering to 320px? less of a line in the sand, more of a dot in the sand. as for @awkawk https://github.com/awkawk's response, as i'm not talking about going back to mandating zoom percentages (see the rewording that basically changes "at" to "down to"), it's possibly not relevant?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag/issues/698#issuecomment-485863591, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4FZ7CCLXQLJHM3HK7V3PR4WFRANCNFSM4HGWUYQA .

[patrickhlauke]

first, an errata for all my previous comments here in this issue where i'm referring to 1920x1080 - by force of habit, i was talking about that resolution, but the actual starting resolution for the 400% thing was 1280. doesn't affect my comments, but for clarity/completeness.

with that out of the way though, the interesting side effect of having this SC literally only apply to the very specific 320 CSS px situation and no other larger size: if the user is running on 1024×576, 1152×648, 1366×768, 1600×900, 1920×1080 or any other popular resolution as a starting point, and they then use browser zoom, they will not be able to hit the exact 320 CSS px viewport width when their window is maximized (there's no zoom factor in common browsers that will resolve those widths to 320 CSS px) - meaning that they're unlikely to be in the exact situation where this SC is directly applicable. and if the only normative situation where the SC applies is 320 CSS px, and if the author has only exclusively catered to that exact normative 320 CSS px size and nothing else (to "pass WCAG"), these users could face two-dimensional scrollbars when they zoom in (even up to 400% or even 500%), and there's nothing that will fail this. and that (as well as even disregarding users on the mentioned 1280x720 display that only need zooming to 300% or 200%) is the gaping loophole this SC currently leaves.

[alastc]

1600 = 500% of 320, 1920 is 600%, anything over 960 can easily shrink the window and use 300%.

if the author has only exclusively catered to that exact normative 320 CSS px size

Indeed, that was what we went through during the 2.1 discussion, and that was the compromise. (Also note it was partially based on a 'linear representation' SC, not just about zooming.)

It is a loophole, but then my questions above are still the ones that need answering as to whether it is a loophole worth addressing.

Whether it comes up in practice isn't a red herring, that was one of the assumptions that went into the decision. Now we've "kicked the tires", how often does it come up? It hasn't in our audits, it seems like you've have one case, are there others?

What we've found is that people trying to achieve it take a responsive design approach, and therefore you don't get issues (barring sticky elements) with scrolling at intermediate levels. We've had one instance where someone had backwards-engineered 'responsive' onto a legacy system and it didn't reflow when zooming, but if you refreshed it was fine. We brought that up under 'best practice' rather than a fail.

[alastc]

[Proposed response]

In the normative text 1.4.10 is scoped to particular (CSS pixel) sizes, that it what must be used for pass/fail for conformance. However, as the Understanding document and techniques make clear, the preferred method is to have a flexible interface, such as a response website that does not require two directional scrolling at any size above the smallest.

[patrickhlauke]

for what it's worth, made an edge case example https://codepen.io/patrickhlauke/live/ZZqzaB (very broadly based on the example i saw in a live audit recently). the editable codepen is here: https://codepen.io/patrickhlauke/pen/ZZqzaB

it ONLY explicitly avoids horizontal and vertical scrolling at exactly 320 CSS px. in all other situations, it ends up causing bidirectional scrolling. (on the live audit, it wasn't explicitly hitting JUST the exact 320 CSS px breakpoint, but using a max-width to catch a few other common small sizes...but my example implements the strict normative requirement here)

[patrickhlauke]

What we've found is that people trying to achieve it take a responsive design approach, and therefore you don't get issues

that is assuming the people are trying in good faith to address this, rather than doing the absolute minimum to "just pass WCAG". if they understand that the requirement is only a requirement at exactly 320 CSS px width, they may well try to sneak that one past this way.

leaving known gaps because it's felt nobody would do such a thing/exploit them is...well...a decision, for sure. but if the rest of the WG feel that this is all fine, then well...feel free to close this then, i guess...

(as a final thought, i'd add: if the idea is "it won't be a problem in practice, they'll do it for intermediate zoom factors / sizes anyway", then what is the actual concern with mandating it explicitly? it can't be both "not a problem in practice" and "too difficult for sites to achieve")

[alastc]

leaving known gaps because it's felt nobody would do such a thing/exploit them is...well...a decision, for sure.

There were other factors (like not wanting to mandate responsive design, allowing for mobile-only sites to be a method of meeting it), but if anyone spots a trend towards 320px only sites, let us know.

[patrickhlauke]

not wanting to mandate responsive design, allowing for mobile-only sites to be a method of meeting it

assuming "mobile-only sites" in the sense of it uses media queries to swap out/trigger a completely separate layout (as a completely separate mobile site would not count as the same page, but an accessible alternative), but beyond that is not elastic/fluid/adaptive to the viewport width?

so if we DO have examples of many sites that do this and don't also have some modicum of fluid/elastic adaptation at viewport widths above 320 CSS px, then there we have the answer to the "not a red herring" question.

anyway, it seems then that the tl;dr here is: yes it's a gap, but we don't think it's a real gap. but it might be too difficult to mandate that sites don't fall into the gap...

[alastc]

Yep, as in alternative conforming versions. I know of one client who uses this, but primarily because they can't update their massive legacy site anytime soon. It is not ideal for them for many reasons, this is just another one. The rest of the new 2.1 SCs were not particularly difficult for them.

So yes it's a (known) gap, we don't think it will happen much, but open to new data.

[patrickhlauke]

Yep, as in alternative conforming versions. I know of one client who uses this, but primarily because they can't update their massive legacy site anytime soon. It is not ideal for them for many reasons, this is just another one.

but presumably their mobile site is not targeted JUST at 320 CSS px precisely. it works presumably on a more modern iphone with (taking the example of my iPhone 6) 375 CSS px viewport width. and presuming that this mobile site can be reached on desktop, and the user can still zoom to some other sizes than exact 320 CSS px (in which case this alternative conforming version would pass even if the SC said "down to 320 CSS px" rather than scoping it to EXACT 320 CSS px only).

but yes, i'll just add this to my "WCAG 2.1 oddities" file for now ;)

[detlevhfischer]

I would personally prefer to see this gap closed by way of errata in version 2.2 in a way that intermediate viewport widths down to 320px would be included (whatever the best formulation for this).

[patrickhlauke]

IF there was to be an errata, i think (unless i'm missing something) that just patching these two bits would do it...

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

[jake-abma]

We might get it in a Survey if we not all agree directly, personally I do like @patrickhlauke last proposal a lot: https://github.com/w3c/wcag/issues/698#issuecomment-486246694

[stephenhay]

I'm surprised to stumble upon this discussion at all. The question should be why is this even in a normative text, and how can it be replaced by a text representing the purpose behind it in a tech-independent way?

At least, that's what I—and I suspect many others—would expect from a spec that introduces itself as follows:

[...] written as testable statements that are not technology-specific. Guidance about satisfying the success criteria in specific technologies, as well as general information about interpreting the success criteria, is provided in separate documents.[...]

I'm assuming changing the abstract to allow for SCs like 1.4.10 hasn't been a point of discussion.

What's the reason for this SC to even exist? That should guide the normative text. Not specific tech details, and certainly not explicit pixel-based widths and heights. That simply opens the door for non-conformance in all scenarios not described, as @patrickhlauke points out. That's arguably worse than simply removing this SC altogether.

[alastc]

Hi @stephenhay,

There's a lot of factors here, one of which is whether we should have an SC take advantage of the benefits of responsive design for people with low vision even if it doesn't work across all technologies.

If you purely look at the "purpose behind it", that would be the user need. The user need originally was stated as up to 1,000% text size increase and the ability to have linear content that reflows without bi-directional scrolling. We then worked through was was feasible to ask of "authors" (generally designers & developers).

One aspect of that discussion was that the working group wasn't happy mandating responsive design, which would be the effect of "down to".

I'm happy to put that to the group again, but I suspect the answer won't change. The effect of the current SC has been (in my experience at least) a strong nudge towards a responsive design, whilst allowing for other approaches. The feedback on that from the LVTF has been good, so I think the comment about removing the SC is unfounded. I'd rather beef it up or look at minimum text-sizing as the improvements.

Regarding the pixel values: The SC needs to be testable. In many, many iterations of the SC we didn't find another way of doing that. Open to ideas though.

[mraccess77]

Having a limited SC that applies to specific scenarios is NOT worse than removing it. Removing this SC would be worse than not having it as in my experience it is something that we can use to affect change for screen widths that are common with higher degrees of zoom and also for people who use lower resolutions for web content. Many sites I see are mostly supporting it but there tend to be some issues with sites.

[stephenhay]

@alastc I respect the complexity of the discussion and the factors involved. Responsive design may not be the only way to achieve this. If it were, then "down to" might be considered mandating. But we also don't know what is to come. If other techniques achieve the same—as I assume they do since you're not mandating responsive—then the idea of a mandate is a moot point. I fail to see how requiring SC conformance in exactly two scenarios helps the user need more than it simply makes life easier for testers. Hence my comments about the real purpose. One can also ask why we're afraid of mandating responsive design, when this SC is essentially an example of it.

One way of testing responsive design could be testing at [x] "random" screen widths based on the number of MQs and their size. I think taking the tech-dependence out of the SC and coming up with a testing algoriithm that doesn't unfairly tax testers—but is more robust than taking only one common screen width—could be a useful exercise.

@mraccess77 I'll assume you don't actually think I'm seriously proposing removing this, and that my exaggeration to make a point was quiite obvious. The problem with basing a normative text on temporary contexts like "common" screen widths is that these are common right now. In fact, 320px is now less common than it was in, say, 2017. In my experience, many designers are beginning—irritatingly, I might add—to use 375px as their minimum, as this reflects the growing number of devices using that screen width. Who knows what will be common tomorrow. These assumptions simply should not be in an SC, but rather in informative text. Basically, we don't want 2-dimensional scrolling when we've zoomed text, excepting the very many chunks of content that themselves are allowed two dimensional scrolling in that situation, as stated in note 2 of the SC. Period. Correct? Requiring conformance at 320px but not at 375px (or [whatever]px) is great for testers, but not great for anyone outside the confines of this "common" scenario. The device landscape is more complex than that, and it's not trending toward becoming simpler.

[alastc]

I fail to see how requiring SC conformance in exactly two scenarios helps the user need

You help answer that yourself:

In my experience, many designers are beginning—irritatingly, I might add—to use 375px as their minimum

Then ask: If I were sitting down to design this site, and I know it has to work at 320px, how would I do it?

Without mandating RWD there is a strong nudge towards it, whilst leaving the option for single-column content in other technologies like PDF or legacy sites that have a mobile alternative.

Basically, we don't want 2-dimensional scrolling when we've zoomed text, excepting the very many chunks of content that themselves are allowed two dimensional scrolling in that situation, as stated in note 2 of the SC.

As you noted from the top of the spec, the SC are required to be testable, how would you test that? The other option we discussed last year was orienting it around zoom, where you say it must work whilst zooming to 400% from a 1280px starting point, which looks less tech-neutral (although it doesn't make much difference).

320px was picked as a compromise between the desired maximum zoom (1000%, ~128px wide) and what people generally design to now, which is usually (still in my experience) 320px as a small phone screen. Even if they don't, there is plenty of evidence that people can, so it is a feasible ask.

It isn't about the current or future device market, it is about what we can reasonably ask of authors and having evidence that it is possible.

Also, "CSS pixels" was chosen as it is a size based on an angle, so for non-web content that can be translated to the platform's device-independent pixel sizing (e.g. points in iOS).

The main option I can see here is to ask the group whether we wish to mandate RWD (across technologies?), if there answer were yes an update to the SC would be appropriate.

[stephenhay]

@alastc I understand your points. And I see that this does indeed nudge toward responsive design without mandating it. I also understand the choice for CSS pixels (though I wonder if there is a way of abstracting that). But my issue iis the explicit mention of 320px—which is based on a current idea of a mobile device. While testable, it seems too explicit for an SC for the reasons I mentioned.

I just wonder if there's a way to close potential loopholes—which seem to be handled now by the hope that the nudging toward RWD will cover them—and focus on usable tests. If we generalize the SC as I suggested above, is it not possible to create a test where (as a crude example) a page is tested at [three] random resolutions with [three] random zoom levels, with both resolutions and zoom levels each coming from a range that can be updated as common resolutions and zoom practices change?

Maybe it's just nitpicking, but I've just seen too many teams aim for conformance by actvely seeking out such loopholes rather than conforming to the spirit of such an SC.

[alastc]

But my issue iis the explicit mention of 320px—which is based on a current idea of a mobile device.

It does line up with that, but if watches become a major user-agent I would not be arguing we use 200px. Also, if there are no phones sold in 2019 with a screen size less than 400px wide, I would not be arguing for a change.

The key thing is that we have plenty of evidence that using 320px as a baseline size is possible across web content.

If we generalize the SC as I suggested above, is it not possible to create a test where (as a crude example) a page is tested at [three] random resolutions with [three] random zoom levels, with both resolutions and zoom levels each coming from a range that can be updated as common resolutions and zoom practices change?

That would give different results every time, we need to be able to test and have someone else test and get the same results. (Which we may not always live up to I'll admit, but we have to aim for that!)

Also, for the SC to "be testable on it's face" (odd term but comes up a lot) the measure needs to be built in.

We have more fun and games with SC that don't include specific measures, e.g. text-sizing which appears to be more general (you can make text 200% bigger). However, it assumed a desktop default size and was written in a time pre media queries. That is harder to deal with than this one now.

[patrickhlauke]

using 320px as a baseline size is possible across web content.

but the point is that the SC doesn't define a baseline ("a minimum or starting point used for comparisons"), but an absolute and ONLY size at which the SC applies...

[alastc]

It doesn't prevent people making wider versions, so I think "baseline" is accurate.

[patrickhlauke]

it doesn't prevent them, sure. it also doesn't require them to make sure things are accessible at ANY other size than the one normatively defined.

taking that line of reasoning further, not having any SCs doesn't prevent people from making accessible websites. "how likely are they not to do it?" ...

[alastc]

taking that line of reasoning further

Is a straw man. SCs are like adding a pressure to a complex system, it has a particular effect. We want to capture and adjust certain behaviors without capturing too much and having a negative impact. If an alternative doesn't have a downside, great. However, if there is a loophole that rarely comes up and the alternative creates other negative impacts, it is not a positive change.

Would you like to put the question above to the group? I.e. adding 'down to' and mandating responsive design?

[patrickhlauke]

Would you like to put the question above to the group? I.e. adding 'down to' and mandating responsive design?

Yes, might as well get everybody else to tell me how off-piste I am ;)

with the caveat that this does not require/mandate "responsive design" per se. A site that does NOT actively set a particular size for things (width or heights locked to particular values) will also pass this fine (in general terms). Using RWD (using the wider definition, which includes not just "using media queries / breakpoints" but also "using elastic/fluid layouts") is the best option, but there are other approaches that yield passes too.

[alastc]

Potential update to 1.4.10 Reflow for survey:

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

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

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

This would requires sites to have (a version that) either uses responsive design, or a media-queryless elastic / liquid layout that works down to 320px.

[WayneEDick]

Dear Group, I am wondering if the desired outcome can be accomplished is a softer way. First, I really support the goal. The "downto" approach was what I had in mind, and it is what I want to see.

Unlike Patrick, it has been a while since I've seen what the crazy world of random developers look like, so I may be ill informed. However, there are two powerful factors pushing in the direction of doing it the downto way.

1) (Human Factor) Users hate scrolling to read lines that are cut off by the viewport boundary. They will only use a site like this if there is no alternative.

2. (Hardware) There is plenty of platform variation between 3000+ pixels and 320px that will encourage sane developers to create intermediate cases that reflow. These factors will to encourage many developers to create acceptable reflow options to meet the needs of their target audience, and in most cases this will meet the accommodation needs as well.

The question is: How do we tip the scales in the direction of providing many suitable reflow options.

One approach is to require it. We may get push back, but if obeyed, it will produce the desired outcome.

Another way may be to develop really good techniques that work. In these, we always make sure that intermediate size cases are prominent. To conform now you will always need the 320 CSS pixel case. Lots of people will see how things look on the way to 320 CSS px and want that to look good too.

This is only conjecture, but I'm thinking the best use of 2.2 time might be to strengthen the non-normative support... Showing the best ways to do various tasks.

Please comment, Wayne

[alastc]

Hi Wayne,

We (in terms of AGWG/WAI) have pretty good coverage for techniques now, with techniques for grid, flex box, inputs, long URLs and max-width images covered in the understanding doc. And there are a whole bunch of responsive design articles out there from the last ~8 years, which mostly help in this regard.

The question for me is whether there are sites that would fail a 'down to' version of the SC, that do not currently fail reflow.

Is it odd niche cases (like Patrick's above), or is it fairly prevalent?

If it is fairly prevalent then I don't think it would be a huge change in our documentation. The push back would be to do with a fairly strong requirement for responsive design.

[patrickhlauke]

i find the argument oddly circular. if it's a niche case that sites would PASS this but fail the "down to" in practice - so in effect, the large majority of sites already do the "down to" without it being normatively required - then surely there would be hardly any push back to formalising this?

[edit: unless i'm misreading it then, the last sentence should be "if it is failry prevalent, then it WOULD be a huge change", in essence]

[guyhickling]

Is this amendment from "at" to "down to" going ahead? Nothing seems to be happening at the moment. And will it happen by actually amending that word in the SC, or will it be a Note?

The question was asked above "...are sites that would fail a 'down to' version of the SC, that do not currently fail reflow"? The answer is that every layout produced by media queries is independent of the other layouts of the same page. So each layout can have it's own failures that will not necessarily show in the mobile layout and 400% zoom. I am auditing just such a site at the moment. It fails just below 225% zoom but is perfectly ok at 400%! (Unfortunately I can't share it as it is in development and not yet made public.)