The Paciello Group comment on SC 1.4.10 Zoom content

[patrickhlauke]

It seems the normative part of the SC is missing the actual core idea here of allowing users to zoom content sufficiently. While the 320 CSS px size is good and testable, this SC could be nominally passed if the content was zoomed to 101% (as long as content fits in 320 CSS px). The current normative wording only guarantees that content doesn't start creating horizontal scrollbars in viewports that are 320 CSS px wide, not whether or not that content is readable or if the user was in fact able to zoom at all up to that point. Suggest that the idea of allowing up to 400% zoom, coupled with minimum viewport width, would better serve the original idea/outcome. "Content can be zoomed up to 400% and it will still fit into a viewport of 320 CSS pixels width without..."

[allanj-uaag]

lvtf

[guyhickling]

I agree with Paciello's comment. The problem lies in spurning W3C's own principle of "clear and simple language".

This SC existed back in April as "Content can be resized to 400% without loss of content or functionality, and without requiring two-dimensional scrolling except for parts of the content where fixed spatial layout is necessary to use or meaning". The meaning was understandable to everyone (except that bit about two-dimensional scrolling), even if it might have needed a little further technical explanation in the Understanding document to clarify any possible ambiguity. But that's what the Understanding documents are for.

Since then it has degenerated into the present meaningless phraseology about "equivalent width" (which noone understands), and doesn't mention 400% text sizing at all! It is not understandable, and now it has been pointed out that it isn't even correct technically. That's what comes of thinking that clear and simple language can somehow be improved by replacing it with incomprehensible jargon!

I hesitate to criticise some of the remaining phrasing in it (which I don't think is much clearer), because we desparately need this SC to be accepted into the WCAG for the sake of low vision users everywhere. But we really need the text to be restored to its initial glory before it is released upon an unsuspecting world!

We are the ones that are going to have to explain the new WCAG to the IT world next year. How on earth do you explain "can be zoomed to an equivalent width of 320 CSS pixels"? And why should we have to explain something that was perfectly clear originally?

[alastc]

@guyhickling wrote:

How on earth do you explain "can be zoomed to an equivalent width of 320 CSS pixels"? And why should we have to explain something that was perfectly clear originally?

Principally because providing a relative measure of zoom was not testable. How do you test (reliably, across platforms and screen sizes) whether a page could be zoomed to 400%?

@patrickhlauke wrote:

The current normative wording only guarantees that content doesn't start creating horizontal scrollbars in viewports that are 320 CSS px wide, not whether or not that content is readable or if the user was in fact able to zoom at all up to that point.

If content can be zoomed so that it appears as 320px wide without creating scrollbars, and without a loss of content or functionality, surely that means it is readable? (And hasn't lost functionality).

I appreciate there might be niche cases where you could create a fixed-width site (at 320px), but actually, that means someone can zoom in on a desktop browser to 400%. Is it a big issue that the 101% to 399% zoom levels have the same layout? It would be odd for a site to do, but not a negative thing from an accessibility (discrimination) point of view.

Suggest that the idea of allowing up to 400% zoom, coupled with minimum viewport width, would better serve the original idea/outcome. "Content can be zoomed up to 400% and it will still fit into a viewport of 320 CSS pixels width without..."

So we'd have: "Content can be zoomed up to 400% and show a viewport of 320 CSS pixels width without loss of content or functionality, and without requiring scrolling on more than one axis, except for parts of the content which require two-dimensional layout for usage or meaning."

I like the idea, but it still has the problem of missing a starting point. If you have a 1024px screen (or 1920) you'll get different results. E.g. my 1920px screen can zoom to 400%, and the content can be shown at 320px, but not necessarily at the same time. It can't be tested from the face of the SC.

Logically, it needs either:

• Only an end point (as the current draft does), or
• A start point and the zoom factor.

E.g. "From a starting point of 1280px CSS pixels wide, content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling on more than one axis, except for parts of the content which require two-dimensional layout for usage or meaning."

As a content guideline, defining what the content has to do would seem to be more appropriate. (And avoids looking even more technology-specific, although I'd admit that mainly just perception.)

I'm open to changes, but the terms have to be testable.

[patrickhlauke]

If content can be zoomed so that it appears as 320px wide without creating scrollbars, and without a loss of content or functionality, surely that means it is readable? (And hasn't lost functionality).

then lose the "can be zoomed" and just require that content fit in 320px wide viewports, and in the understanding explain that this value was chosen because on an average desktop screen, this means that it can be zoomed up to 400% ?

[guyhickling]

Certainly the testability has to be worked out, and the Understanding document will have to set out how to do that. If a starting point must be specified then so be it. My concern is that if the actual SC is incomprehensible we'll never get to the testing of it.....because the development world will simply ignore it as a mystifying piece of jargon they don't understand.

The principle behind 400% zoom will become one of those "good practice" rules that it's good to follow when designers don't want to do something else that breaks it entirely, but they won't think of it as something that has WCAG backing behind it because they won't realise it is there. And we will spend the rest of our days trying to explain, to every new audit client we deal with, what the SC means.

Far better to have an SC that everyone basically understands, then explain the detail inside the Understanding. So I think the wording you have just suggested may be the way to go:

"From a starting point of 1280px CSS pixels wide, content can be zoomed up to 400% without loss of content or functionality, ....."

I also feel that if the W3C as an organisation genuinely wants to promote its principle of "clear and simple language" (and it seems important to me that it continues to do this), and if it wants to tell others to use it, then it needs to be seen to be following the same principle in its own backyard!

[alastc]

then lose the "can be zoomed" and just require that content fit in 320px wide viewports

Um, the original TPG comment was to include "zoom"! I'd also argue that saying 'can be zoomed' means you should use that mechanism to test it, which means you do test from 100-400, rather than just at 400 (/320px).

Also, we don't want someone to just open it on a phone and think 'yep', done that. Because the effects can be different compared to zooming in on a desktop. (E.g. sticky headers.)

Certainly the testability has to be worked out, and the Understanding document will have to set out how to do that.

The understand doc will detail the process, but the SC text has to be 'testable', which means that regardless of the separate doc the content must pass/fail that statement.

I appreciate that it is difficult to understand to start with, but we need something that means the same thing, i.e.

• you can start at 1280px in a desktop browser and zoom in 400%,
• you don't lose content or functionality when doing so,
• you don't get scrolling horizontally, or for vertical-reading languages vertical scrolling,
• unless the nature of the content is two dimensional, such as images, maps diagrams, or IDEs.

The above is easier language, but longer and less precise. We went through a lot of revisions in #77 to get here.

If you can think of a way of saying that better, please let me know...

Cheers,

-Alastair

[patrickhlauke]

Also, we don't want someone to just open it on a phone and think 'yep', done that. Because the effects can be different compared to zooming in on a desktop. (E.g. sticky headers.)

the normative text doesn't say anything about desktop browser though. the understanding document can clarify that testing should be carried out on desktop browsers as well as mobile browsers. the difference in behavior here is a difference in how the UA handles certain CSS.

[alastc]

No, but in order to zoom, you'll need to use a user-agent capable of zooming (in a way that affects the pixels / layout). That is implied in the SC text, and outlined in the testing procedure of the understand (or at least the draft in #77 so far).

[guyhickling]

So using the wording you have used just above (slightly rearranged to fit in with the formal nature required here), and most of your earlier suggestion higher up for the first part of it, the SC would become:

From a starting width of 1280px CSS pixels, content can be zoomed up to 400% without loss of content or functionality, and without requiring horizontal scrolling, or for vertical-reading languages vertical scrolling except for parts of the content which require fixed layout.

Now that really is clear, and to the point. It's testable and, equally important, everyone would understand an SC worded like that. And if brevity is important it's only one word more than the version in the draft - and does away with the first Note completely.

I appreciate the time it took in #77 to reach the current draft form (I read it all through when I first saw it), but I think it is still worth trying to achieve a clearer and more understandable version than the current draft, to make things easier for everyone in the future.

[alastc]

I'll put that to the group, but issues I'd anticipate are:

• The starting point appears to be too technology specific. That's a perception thing though, we can probably handle that.
• It is not a clear relationship between language and which way scrolling should happen (which is why it was vaguer before). E.g. some (most?) vertical language sites still have vertical scrolling by default.
• Fixed layout is too broad, partly because it refers to layout not content, it should be the content that is inherently 2 dimensional (i.e. loses information if linearised).

The latter two are the more difficult ones.

[alastc]

I've been trying to address the issues I raised above, but I keep ending up with the same wording as before.

Even with a minimal change to the start like this:

From a starting width of 1280px CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling in more than one dimension, except for parts of the content which require two-dimensional layout for usage or meaning.

I think that leads to issues in testing horizontal scrolling sites as there is no starting height. It was a bit of a fudge before (320px height is a smaller zoom factor for most desktop browsers), but it worked.

Does anyone have ideas about how to make this work for horizontally scrolling sites?

[guyhickling]

Well, I'm beginning to wonder if this is even a problem! I was talking to a Chinese friend last week, and he said Chinese websites were written horizontally.

So I started taking a look at Chinese, Japanese, and Korean websites (all allegedly vertically written languages), and in the first 5 or 6 sites I looked at in each of those languages, all without exception were written horizontally across the page, and had to be scrolled vertically, in just the same way we scroll in English sites, to see more content on the longer pages. Text was written horizontally, and if the page wasn't reponsive designed a horizontal scroll bar appeared when I made the window smaller, just as on an English website.

In short, I found no websites that scrolled horizontally when pages or content were over-long, they all scrolled vertically, as we do in our language.

I took a look at Omniglot (http://www.omniglot.com/writing/direction.htm). It lists about 150 horizontal languages and only 20 vertical ones, including Chinese, Japanaese and Korean, and some little known languages the three of which I tried I couldn't find websites in.

It then says "Until the 1980s Korean was usually written from right to left in vertical columns. Since then writing from left to right in horizontal lines has become popular, and today the majority of texts are written horizontally. Chinese is often written vertically in Taiwan [not in the Taiwanese websites I looked at it wasn't!-gh], while in China and Singapore it is usually written horizontally. Vertical and horizontal texts are both used in Japan."

For Japanese, another source says, "Traditionally, Japanese was only written vertically, and most historical documents are written in this style. However, with the introduction of western materials, the alphabet, Arabic number and mathematical formulas, it became less convenient to write things vertically. Science-related texts, which include many foreign words, gradually had to be changed to horizontal text. Today most school textbooks, except those about Japanese or classical literature, are written horizontally. Young people mostly write this way, though some older people still prefer to write vertically as it looks more formal."

When you think about it, it's not really surprising that these formerly vertical languages follow the same methods as we do on websites. The web is written in HTML, and that is designed to create text horizontally and then wrap down and to the left at the end of lines. Other language sites are still written using HTML, mostly by computer people who speak English whatever their first language might be, for the same browsers that we all use which are also designed for horizontal content direction, and that's just the way it is. It looks like previously vertically written languages have just fitted themselves into that framework, and in fact were already doing so for business reasons before the web was born! However if anyone knows of a language where websites normally do it differently I would be interested to hear of any examples.

So maybe a Note, or just a paragraph in the Understanding document, would be enough to cover this whole matter, rather than make the SC itself overly complex and hard to understand for no need (- it has taken us long enough to understand it, we shouldn't put the same load on everyone else if it isn't really necessary). I'm not saying vertically written websites don't exist; I am just saying the numbers may be so vanishingly small that we can keep the text Success Criterion itself simple, always a good thing, and cater for the other possibility elsewhere.

It looks like we may be worrying about something that just doesn't happen in normal life!

[alastc]

It is worth reading the previous conversation in the issue.

The bottom line there is that although non-horizontal text is fairly rare now, support is improving so it could become more common. There is a good primer for Chinese language and writing mode.

Even in western sites, it is possible to have text going in different directions.

I think that if we don’t account for it, the SC will be rejected when it comes to wider comments.

[guyhickling]

I have had a think about the wording issue you raise over the two dimensional scrolling matter. Instead of the "without requiring scrolling in more than one dimension", perhaps "without requiring both vertical and horizontal scroll bars simultaneously"? would be a bit clearer?

But that has the same loophole as most of the "two dimensional" attempts tried so far. To illustrate, take a page with just a few lines of text, say 7 lines for argument's sake, each stretching across most of the width of a normal width PC screen. And we will assume that, due to the bad coding used, these lines won't wrap responsively so a horizontal scroll bar appears when they are zoomed.

Now Increase to 400% zoom. The lines will now be four times the height, but seven lines won't cause a vertical scroll bar (in practice the average PC screen will hold a browser with around 30 lines or more of text at normal text size without needing to scroll down, so a quarter of that at 400% zoom. So we only have scrolling in one dimension, horizontally.

Such a page won't meet the case of two dimensional scrolling so won't fail the SC as currently written - but it has failed the aim we are trying to achieve with this SC because horizontal scrolling back and forth is needed to read each of the long lines of text.

This leads me to think that the wording mentioned in the June conversations about this, "without requiring scrolling in the direction of the text" is the only kind of wording that actually fits what is wanted from this SC. It has the failings that were mentioned then, but it covers both cases of horizontally and vertically written languages better and without the above loophole. So expanding on that to meet the failings it had, how about "in the direction of reading the words of text".

That also brings in the idea of not wanting people to have to scroll along as they read.

So the SC now becomes (using the text you had above, three posts ago on 26 Sept):

From a starting width of 1280px CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling in the direction of reading the words of text, except for parts of the content which require two-dimensional layout for usage or meaning.

That works whether there are one or two scroll bars, and is hopefully a bit clearer as well.

[detlevhfischer]

I think (re)introducing "scrolling in the direction of reading" makes this SC immediately clearer to the reader as it captures the LV problem of (usually horizontal) scrolling.

[WayneEDick]

Knowbility has a good resource for evaluating this wording and this wording. His name is Anthony Vaquez, he has a Masters in Eastern Studies from Standard and is fluent in Chinese as a second language. Anthony is also blind and did all his learning of Chinese using a screen reader and refreshable braille. He works for Knowbility. His email is avasquez@ knowbility.org.

Wayne

On Tue, Sep 26, 2017 at 7:29 AM, Alastair Campbell <notifications@github.com

wrote:

I've been trying to address the issues I raised above, but I keep ending up with the same wording as before.

Even with a minimal change to the start like this:

From a starting width of 1280px CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling in more than one dimension, except for parts of the content which require two-dimensional layout for usage or meaning.

I think that leads to issues in testing horizontal scrolling sites as there is no starting height. It was a bit of a fudge before (320px height is a smaller zoom factor for most desktop browsers), but it worked.

Does anyone have ideas about how to make this work for horizontally scrolling sites?

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

[alastc]

and without requiring scrolling in the direction of reading the words of text,

But what happens when you have text going in more than one direction?

As soon as a western site uses vertical text (e.g. at the side as a style) a regular page fails. It is quite common for Chinese sites to have text going in multiple directions (apparently), and many current sites have text going vertically, with vertical scrolling. It doesn't work.

[guyhickling]

We can go in one of three ways:

1) The SC can stay with the wording we have now arrived at above:-

From a starting width of 1280 CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling in more than one dimension, except for parts of the content which require two-dimensional layout for usage or meaning.

and just add a Note to explain the vagueness of the "scrolling in more than one dimension" phrase, and to explain the loophole I raised above.

2) It would be possible to have two, almost identical sections in the SC (some of the SCs in WCAG 2.0 have several sections) , one for "horizontally written languages" and the other for "vertically written languages". They would differ only in the two dimensional scrolling phrase. One would say "without requiring horizontal scrolling when the text is written horizontally" and the other would have the equivalent for vertical languages.

3) We can continue to look for a different way of phrasing it. That is possible, I think, and tomorrow I'll put my thoughts on that if you like. But it will involve more words in the SC to explain it clearly. The problems of lack of clarity and/or loopholes arise when we try to explain, what is quite a complicated thing to describe, in just two or three words. As soon as we use too few words, people start asking what it means, or it contains discrepancies and loopholes!

[WayneEDick]

I am really thinking that this is less of a problem than it appears to be.

It cannot be dismissed because people have web pages discussing classical literature in western languages. We could expect these examples exist in CJK formats. The literary samples would be in vertical text orientation. That is just one example. There are probably hundreds.

I think Alastair's original language will suffice for three reasons:

1. It is testable.
2. It is sufficient to describe both formats.
3. Formats are, by necessity, simplified to fit in 320 pixels.

The last is important because text that goes in two directions is less likely in small space formats. A developer will not want to waste 20 to 40 pixels in a 320 pixel format for a banner of vertical text. Developers will get very economical in small confines to preserve functionality.

Lastly, text should wrap, even if it is oriented vertically or horizontally, even if the page mixes the formats. Alastair's wording convers that.

The wording is a little dense, but spreading it out would probably add more confusion.

This will require a good understanding section with examples.

Wayne

On Sun, Oct 1, 2017 at 6:50 PM, Guy Hickling notifications@github.com wrote:

We can go in one of three ways:

1. The SC can stay with the wording we have now arrived at above:-

From a starting width of 1280 CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling in more than one dimension, except for parts of the content which require two-dimensional layout for usage or meaning.

and just add a Note to explain the vagueness of the "scrolling in more than one dimension" phrase, and to explain the loophole I raised above.

1.

It would be possible to have two, almost identical sections in the SC (some of the SCs in WCAG 2.0 have several sections) , one for "horizontally written languages" and the other for "vertically written languages". They would differ only in the two dimensional scrolling phrase. One would say "without requiring horizontal scrolling when the text is written horizontally" and the other would have the equivalent for vertical languages. 2.

We can continue to look for a different way of phrasing it. That is possible, I think, and tomorrow I'll put my thoughts on that if you like. But it will involve more words in the SC to explain it clearly. The problems of lack of clarity and/or loopholes arise when we try to explain, what is quite a complicated thing to describe, in just two or three words. As soon as we use too few words, people start asking what it means, or it contains discrepancies and loopholes!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/335#issuecomment-333424225, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF266Oop7T2Z3cFl7yYumbiUlhtZEks5soEF-gaJpZM4PB1Pn .

[alastc]

So the downsides of the two approaches are:

1. The current text (preventing 2d scrolling) misses a circumstance: where you have a few lines of text in the page which only scroll horizontally when zoomed, meaning you have to scroll to read.
2. The 'in the direction of reading' catches instances it should not: where vertical text is used (and it only scrolls vertically), or where text directions are mixed.

The first is possible in some scenarios but unlikely - it would also be a rubbish experience on mobile devices as well, you'd have to go out of your way to have a website that mostly passes but then fails this in one place.

The second would fail some fairly popular websites aimed large swathes of the non-western world without intending to.

I think Wayne has a good point that (in western contexts at least) developers would probably drop vertical-text from the zoomed/small-device view as it doesn't work. However, that still leaves vertical text which is intended to scroll vertically, and mixed direction text for languages like Chinese.

If you can think of a way of closing the first without impacting the second, please do chip in!

[guyhickling]

@WayneEDick wrote:

We could expect these examples exist in CJK formats. The literary samples would be in vertical text orientation..... There are probably hundreds.

"Could expect...would be... probably hundreds". But are there? In all these discussions I don't think anyone has actually shown a real life example. I'm certainly not saying there aren't, but it would be nice to have some live examples of actual websites written vertically.

To start the ball rolling on that here are three sites I picked at random, one listing lots of Chinese sites, one with Japanese sites, and the same for some Taiwanese websites. They list some "top rated sites". I don't know what the listed sites are all about as I don't know any of those languages (so I hope there is nothing objectionable there!) but we can all browse them. The ones I looked at, again picking random ones, are are all written with horizontal text:

http://www.chinesetop100.com/ https://www.alexa.com/topsites/countries/JP ​​https://www.alexa.com/topsites/countries/TW

(you have to cut and paste from the Alexa ones or you just get the alexa page).

Formats are, by necessity, simplified to fit in 320 pixels....A developer will not want to waste 20 to 40 pixels in a 320 pixel format for a banner of vertical text

It seems as though this is only thinking about mobile format. But this SC is primarily about websites on desktop PCs - designers aren't going to stop writing for the desktop, and they don't fit into 320 pixels! It is about very long lines of text on a desktop screen, and making sure they don't become wider than the screen requiring scroll bars.

[guyhickling]

@alastc said:

If you can think of a way of closing the first without impacting the second, please do.

It is the back-and-forth type of scrolling for every line of text (or column of vertical text) that makes reading tedious and frustrating after zooming. So the SC wording should say that. Therefore I suggest, instead of "two dimensional scrolling" or "scrolling in more than one dimension" with all their associated questions and need for clarification:

...without requiring scrolling backward and forward to read multiple lines of text in a horizontally written language, or scrolling up and down to read multiple columns of characters in a vertically written language...

Yes, it takes a few more more words to say it (33 actually, but there are much longer SCs than this one). But something like that will be accurate, clear and understandable, doesn't leave the loophole mentioned earlier, and it says precisely what we mean which is always a good thing! No further Note or explanation needed (hopefully). We can adjust that wording slightly if anyone spot's a real issue in it, but basically we need something like that. There's nothing to beat saying exactly what we mean!

[alastc]

In all these discussions I don't think anyone has actually shown a real life example. I'm certainly not saying there aren't, but it would be nice to have some live examples of actual websites written vertically.

It is hard for me to point to examples, I can look at the sites and not know! However, there is a W3C requirements doc with some good info:

Traditionally, Chinese publications were composed mainly in vertical writing mode, and this tradition has been largely preserved in the regions using Traditional Chinese. However, with the increasing amount of translated publications and mixed-text publications, and the default mode of writing modes in the character processing software, horizontal writing mode is becoming more and more popular. In the Taiwan area, government departments, educational materials and books of natural science mainly use horizontal writing mode while literary works such as poetry and novels still use vertical writing mode. Vertical writing mode still stands as an important cultural characteristic of regions where Traditional Chinese is used.

Languages (or rather: text in various languages) is not just horizontal or vertical. Consider the possibilities, text can be vertical with 'horizontal' characters, or vertical with vertical characters. Pages can be a mixture of different directions, so I honestly can't see how describing the connotations will work.

It seems as though this is only thinking about mobile format. But this SC is primarily about websites on desktop PCs - designers aren't going to stop writing for the desktop, and they don't fit into 320 pixels!

I think you're missing a key bit: When you zoom you get the mobile view. The point is that it is requiring either responsive site, or a version which can be zoomed to 400% (e.g. a small fixed-width version). I think Wayne's point was that when reflowed, devs have the option to simplify certain aspects.

[guyhickling]

@alastc wrote:

Consider the possibilities, text can be vertical with 'horizontal' characters, or vertical with vertical characters.

Actually which way the letters or characters within the text are oriented doesn't matter for this SC. They can be upside down for all that matters!

The only thing that matters is long strings of text (lines horizontally, or columns of characters vertically), and whether they wrap or not on zooming. If they wrap, fine. If they are fixed so that on zooming they go beyond the edge of the screen and cause a scroll bar, then they fail the SC. But within those pieces of text it makes no difference, to the triggering of scrolling, which way the individual characters are displayed. Sorry, I should have thought of that in the discussions earlier in the summer.

It means, however, that we come down to only two variations that the SC need be concerned about - long lines of horizontal text causing a scroll bar on zoom, and long vertical columns of characters causing a vertical scroll bar on zoom. It seems to me those two variations can be described easily enough, either with the wording I suggested in my last post above or something very similar.

[alastc]

So I think that would be:

From a starting width of 1280 CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling backward and forward to read multiple lines of text in a horizontally written language, or scrolling up and down to read multiple columns of characters in a vertically written language, except for parts of the content which require two-dimensional layout for usage or meaning.

The advantage is that it deals with content that has multiple directions of text.

The disadvantage is that it undermines the ‘starting width’. (Or rather, it highlighted to me the disadvantage of using ‘starting width’ from before.) What should the starting point be for a vertically written language that is zoomed in? It may default to scrolling vertically and be designed to stay within a certain height. Or it might be horizontally scrolling.

Previously there was an assumption that the 320px would work in either direction, but starting with a vertical height of 1280px is not easy, far fewer laptops / screens have that much height.

Going down this approach, I think it would need to separate the cases so be something like:

From a starting width of 1280 CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling backward and forward to read multiple lines of text written horizontally, except for parts of the content which require two-dimensional layout for usage or meaning. For text written vertically the starting height should be 960 CSS Pixels and zoomed 300% without loss of content or functionality, or scrolling up and down to read a column of characters.

That needs refinement as the 2d exception should apply across both, but do you think that’s improving?

[guyhickling]

That's a very good point; we didn't think about the start point for vertical language, so just as well you spotted it! Starting at 960 looks good to me, it's one of the standard heights for a 1280px width screen.

Did you mean only 300% for the vertical case? I think it would need to be 400% for both horizontal and vertical languages, partly for the same reason vertical languages are being included in the SC in the first place, to be seen to be truly international. But also because I think a low vision reader of vertical languages is just as likely to want to go to 400% as a Western language person (some low vision users increase text size even beyond 400% if their browser lets them).

I like your revised wording. As you say, we can separate out the "two-dimensional layout" bit and place it afterwards so it applies to both the horizontal and vertical cases, and then word the two contrasting phrases exactly the same way so there is no seeming difference in the approach to the two kinds of language, as in:

From a starting width of 1280 CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling backward and forward to read multiple lines of text written horizontally.

From a starting height of 960 CSS pixels content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling up and down to read multiple columns of characters written vertically.

Parts of the content that require two-dimensional layout for usage or meaning are excepted.

How does that look?

[alastc]

Hi Guy,

The 960 & 300% was intentional, that gets you to the same 320px, otherwise it is 240px equivalent in height.

There might be some further refinement, I'll think more during daylight hours...

[alastc]

With a little refinement of the wording for scrolling & text, and starting each one with the relevant condition, how does this read?

For content with horizontal lines of text, content can be zoomed up to 400% from a starting width of 1280 CSS pixels without loss of content or functionality, and without requiring horizontal scrolling to read horizontal lines of text.

For content with vertical lines of text, content can be zoomed up to 300% from a starting height of 960 CSS pixels without loss of content or functionality, and without requiring vertical scrolling to read vertical lines of text.

Parts of the content that require two-dimensional layout for usage or meaning are excepted.

That way if you don't have vertical text you can ignore the second part, but it works for mixed content as well as both then apply.

[guyhickling]

Yes, that looks excellent, I think. It is very clear, and more concise than I had it (my only reservation being about the 300% figure as I don't think it has to be related to the starting point sizes, but I can accept this).

So I believe this wording is just about what we want. It also allows for text in both directions on the same page, while allowing them to be tested separately.

There will likely be comments from some of the other people involved in this, of course. If not, will it be in time to go into the next draft?

[alastc]

It is a substantive change, so I'll put it to the group. If there's no stumbling blocks, it will need to go through a CFC for approval of it going in to the next draft.

[mbgower]

This ongoing saga takes me back to a thought I had in January! Why not have put a succinct, easily understood description of the goal at the start of the intent, for instance:

"Goal: Authors support the resizing and reflow of content as allowed by the browser."

That allows for some more arcane language in the SC short descriptions. Speaking of which, I think so long as we define clearly what is meant by "lines of text", which is about text strings oriented horizontally or vertically, the new language can be adopted.

Is there any danger of people construing that their content must always default to a "starting width of 1280 CSS pixels"?

[guyhickling]

@mbgower wrote:

Is there any danger of people construing that their content must always default to a "starting width of 1280 CSS pixels"?

That is a good point. I'm not sure many would think that, but some probably would. I think the answer is that, on a technically complex matter like this, however it is worded it will still need a few few things to be clarified in the Understanding document just to be absolutely certain it is all clear to everyone. The possibility you mention needs to be one of them I think. However, the clearer the SC itself is, the less chance of subsequent misunderstanding. Hopefully we have a good balance now.

[alastc]

Hi Mike,

Do you think there are others that would really benefit from the stated goal approach? It is a change to structure that could hit some, er, stumbling blocks for 2.1?

Is there any danger of people construing that their content must always default to a "starting width of 1280 CSS pixels"?

How ever we put it, there is a danger people misunderstand, it is something that most developers grok easily, but some others involved in the process may not get. The question is whether it is better than the 320 equivelent width approach?

For the lines of text aspect, would it be better to talk in reading direction perthaps? something like:

For content with a horizontal reading direction, content can be zoomed... and without requiring horizontal scrolling to read horizontal lines of text.

[guyhickling]

My first thought on your "For content with a horizontal reading direction" was that I could be ok with that if it was preferred. But then it occurred to me that it re-opens the possibility that was discussed back in the summer of people saying "What about pages (in a Western language) that have have streams of characters in a vertical column but with the letters facing forward horizontally?" (or vice versa in a vertically written language).

We have highlighted above in this issue that in fact it makes no difference to the scrolling which way the characters are oriented inside the line or column of text, but just having a wording that could leave it open for people to raise the idea as an objection would mean we had lost clarity.

So I would recommend leaving it with the wording we have now arrived at, i.e. as you last showed it on October 5 above of:

For content with horizontal lines of text...

It is clear, I think, and understandable.

[steverep]

For content with [ horizontal | vertical ] lines of text, ...

I would not be able to support this because it effectively scopes the criterion only to content with "lines of text", but what if there is no text? Remember this SC is about zooming all content, and the goal is to have that content reflow to reduce visual workload. It's not just about lines of text.

Furthermore, I'd also read this as a fixed 3-column layout would pass so long as each column was 320 pixels or less, but that's not what we want.

I'd be much more comfortable if the horizontal vs. vertical distinction had crystal clear ties to the CSS writing-mode because that defines the flow of block-level elements and not just the text. We don't want authors trying to control vertical scrolling in Latin scripts just because they have a fancy table header or something with CSS transform: rotate(90);.

Maybe that's as simple as:

For content with a [ horizontal | vertical ] writing mode, ...

And an explanation that all content has a writing mode, not just content with text.

[alastc]

Guy wrote:

it re-opens the possibility that was discussed back in the summer of people saying "What about pages (in a Western language) that have have streams of characters in a vertical column but with the letters facing forward horizontally?"

I assume you mean the text flows down the page, but with the characters upright?

Like this example from Jen Simmon's article:

I raised the issue and it depends on the term we use for writing-mode. If we can use the right term, I think we can pretty much ignore that example that because you cannot 'read' it in a normal way anyway, you have to scan the letters in a odd way. It is for effect, the writing-mode is not being used in the normal way for the language of the text.

The more common decorative effect would be this example:

In that instance it falls into the vertical text part of the SC.

Stephen wrote:

I would not be able to support this because it effectively scopes the criterion only to content with "lines of text", but what if there is no text?

The things that can reflow are layout and text, non-text content predominately falls into the 2D exception. (I can't think of anything off-hand that is non-text content that wouldn't fall into that exception.)

Perhaps there is an issue with single-word elements though? E.g. navigation which uses single words.

Furthermore, I'd also read this as a fixed 3-column layout would pass so long as each column was 320 pixels or less, but that's not what we want.

That's a good point, which points to the end of the main paragraphs as the issue: "...without requiring horizontal scrolling to read horizontal lines of text."

It could finish: "... and without requiring horizontal scrolling."?

However, in that case any page with mixed content-directions (like the example above) cannot pass unless it fits into a 320 x 320px square without scrolling.

Perhaps: "and without requiring horizontal scrolling to view the content.", I'm trying to think of some way of saying you don't have to scroll to view this content, but you might have to scroll to view other content which might have a different reading flow.

Writing mode is fairly CSS-specific, would this be better?

For content with a [ horizontal | vertical ] flow of text...

Then we define flow of text with reference to the CSS writing mode.

And you are right, the key thing is that it doesn't matter if it has text or how much, just which direction it would flow if it were there text.

That leaves us with this (for the top paragraph):

For content with a horizontal flow of text, content can be zoomed up to 400% from a starting width of 1280 CSS pixels without loss of content or functionality, and without requiring horizontal scrolling to view that content.

I'm not happy with that last bit though.

[steverep]

The things that can reflow are layout and text, non-text content predominately falls into the 2D exception. (I can't think of anything off-hand that is non-text content that wouldn't fall into that exception.)

The way I think about it is a very simple image gallery. Each individual picture obviously has a fixed 2D layout and thus must be exempt, but unless the gallery's grid is required for meaning of some sort, the gallery should reflow when zoomed. This was clear to me as the requirement in the existing language, but this new proposal says that only content with text matters.

For content with a [ horizontal | vertical ] flow of text...

At least to me, this is only a minuscule improvement and still sounds like it only applies when there is text. I don't see any issue with using "writing mode" because we can just define it in the glossary similar to CSS and even link to the spec.

You're right about the scrolling part being tricky... I'll give that some thought.

[alastc]

I agree with the requirement (e.g. the gallery), the starting part was intended to mean the general direction of text flow without meaning it must have text, and it does, but I see the implication.

How about starting:

For content with a horizontal flow of text, all content can be zoomed.

[guyhickling]

This SC started off originally to primarily solve one particular problem that low vision users have with paragraphs of text when it is zoomed - having to scroll backwards and forwards for every single line of text, because the words aren't allowed to reflow. That is a huge burden to low vision users.

That is why the Description for the SC, in issue #77, says "The impact of horizontal scrolling can increase the effort required to read by 40-100 times, so avoiding scrolling should be the aim whenever feasible." It cites Operational Overhead Caused by Horizontal Scrolling Text, about reading text, by Wayne E. Dick at http://nosetothepage.org/Fitz/2dScroll.html. It is also why the SC has contained various variations of "scrolling in the direction of text", because it is the above text problem that is the primary target for solving.

With the new comments in the last 2 days the SC is now being asked to legislate for the whole matter of responsive content layout reflowing to fit the screen. Which is not necessarily bad, so long as the solution we have achieved for the original problem isn't muddied in the process - something which looks to me is in danger of happening.

We have, after several long discussions, arrived at a wording that we think describes and solves the text problem clearly and without any serious misunderstanding, and I would hate that to lose its clarity by trying to make it do too much.

Add a separate paragraph

If the SC is going to cover images and other content as well, then please can that be done by adding a complete new paragraph for that purpose? As is done for instance in SC2.2.2, or SC1.4.3. Otherwise the wording will become so general purpose that it will not mean anything specific to either text or images.

So taking the current wording form above it would become something like:

For content with horizontal lines of text, content can be zoomed up to 400% from a starting width of 1280 CSS pixels without loss of content or functionality, and without requiring horizontal scrolling to read horizontal lines of text.

For content with vertical lines of text, content can be zoomed up to 300% from a starting height of 960 CSS pixels without loss of content or functionality, and without requiring vertical scrolling to read vertical lines of text.

For content that is a stream of images, content can be zoomed up to 400% [add whatever solution is arrived at for images here].

Parts of the content that require two-dimensional layout for usage or meaning are excepted.

If not that, then this new problem should be entrusted to a new, separate SC to go in the next dot release or into Silver.

A difference between text and images

Could I also mention that a large array of small images (such as in the image gallery mentioned aobve) is not the same as a large block of text. Suppose a page has several rows of gallery images filling half the width of the screen. And assume they haven't been allowed to reflow. Then at 400% the page will be twice the width of the screen. But they differ from text because most users will look at the images in the left half of the page first, then they have to scroll just once to see the images in the other half of the page. That is very, very different to a block of, say 20 lines of text, where the user of necessity must scroll forward and back 20 times (40 scrolls in all) to read the text!

[alastc]

Hi Guy,

The original user-requirements were essentially to make everything bigger (much bigger, like 1100%), but we refined down to what is useful & possible on the web.

Most of the research is based on reading text, so the description is biased towards that, but the requirement is more general.

With the new comments in the last 2 days the SC is now being asked to legislate for the whole matter of responsive content layout reflowing to fit the screen

I don't think that has changed from before, it is trying to refine how it is defined.

I really don't think we need a paragraph to cover images etc, we already have this note clarifying the two-dimensional aspect:

Note: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.

So an image is a piece of content that cannot be reflowed, and we cannot usefully ask people to enable it to be zoomed by any %, because we don't know how much of the viewport it started at.

An image that starts at 300px wide is fine, but if you have an image that starts at 100% of the viewport, any amount of zooming will cause scrolling.

As an author, you will want to use a max-width on images anyway, and we should allow for that (which we do, by excepting images).

Given that we ask for 400% without scrolling, the natural thing for an author to do is reflow the layout (including things like image galleries), and use a max-width on images that might overflow the viewport.

[guyhickling]

So are you saying there won't be any further change to the wording to cater for non-text content? I would be happy with that. I was just a bit concerned that we might be trying to change the wording to make it fit text and non-text content all in one sentence, which would have diluted the meaning and left it not being clear for either of them!

[alastc]

No, I'm not suggesting a change for the images aspect, I think that is covered.

I think the only issue left with this formulation is the end of each paragraph: "and without requiring vertical scrolling to read vertical lines of text."

Scrolling is page level, but the content requirement is for 'the content', which can be elements within it. That has advantages, but if you have the 'common' example of vertical text I put above, it is mixed content. It triggers both horizontal and vertical clauses.

If it finishes "and without requiring [vertical] scrolling to read [vertical] lines of text", then you don't have to scroll to read that chunk of content. If the scrolling to read only applies to chunks of content, that undermines the aim of the SC as a whole: You could have a fixed layout with 3 columns of 320px wide text (as someone pointed out above).

If it finished "and without requiring scrolling in the direction of text flow.", you can't have scrolling in either direction when both clauses are true.

From that point of view, the original (current SC text) version would be better, as it specified only scrolling in one direction...

[steverep]

Hi @guyhickling. I wanted to offer some thoughts on your previous comments.

It is also why the SC has contained various variations of "scrolling in the direction of text", because it is the above text problem that is the primary target for solving.

Actually, the original text simply prohibited 2-dimensional scrolling as a whole, but folks found that too confusing, then it went to horizontal briefly, then to the text direction to make an internationalization attempt. Nowhere in there was the intent to emphasize text as the primary problem.

With the new comments in the last 2 days the SC is now being asked to legislate for the whole matter of responsive content layout reflowing to fit the screen. Which is not necessarily bad, so long as the solution we have achieved for the original problem isn't muddied in the process - something which looks to me is in danger of happening. We have, after several long discussions, arrived at a wording that we think describes and solves the text problem clearly and without any serious misunderstanding, and I would hate that to lose its clarity by trying to make it do too much.

First, as @alastc pointed out, the text already in the draft clearly applies to all content, so I think the reverse question is pertinent: Why would you want to throw that away?

Second, this new wording proposed is far from automatic and needs to get working group consensus. Personally, I find it more confusing to be talking about "lines of text" without defining what that means, and I would object to any new wording which seems to eliminate block-level responsiveness and not apply to all content. v

Could I also mention that a large array of small images (such as in the image gallery mentioned aobve) is not the same as a large block of text. Suppose a page has several rows of gallery images filling half the width of the screen. And assume they haven't been allowed to reflow. Then at 400% the page will be twice the width of the screen. But they differ from text because most users will look at the images in the left half of the page first, then they have to scroll just once to see the images in the other half of the page. That is very, very different to a block of, say 20 lines of text, where the user of necessity must scroll forward and back 20 times (40 scrolls in all) to read the text!

Actually, there's nothing in Wayne's scroll counts that is specific to text. You could apply it to anything where the order is meaningful. Text is just convenient to understand because you obviously have to read the characters and words in order. If the order of those images in the gallery was important, then the assertion that you can view the left, then the right goes out the window.

Consider another example where I have a large article where I insert many images to accompany it, and maybe I even alternate things so the text wraps to the right, then the left, then right, etc. I'd have no choice but to keep scrolling back and forth.

The bottom line is that any new language needs to be clear that block-level reflow is the goal, or you're going to open it wide to loopholes.

[guyhickling]

@alastc wrote:

I think the only issue left with this formulation is the end of each paragraph: "and without requiring vertical scrolling to read vertical lines of text."

As I understand it the stage that was reached was as shown in your comment of 5 Oct above, and adjusted on 9 Oct which, put together, makes this:

For content with a horizontal flow of text, content can be zoomed up to 400% from a starting width of 1280 CSS pixels without loss of content or functionality, and without requiring horizontal scrolling to view that content.

For content with a vertical flow of text, content can be zoomed up to 300% from a starting height of 960 CSS pixels without loss of content or functionality, and without requiring vertical scrolling to view that content.

Parts of the content that require two-dimensional layout for usage or meaning are excepted.

I hope that correctly summarises the wording currently reached? To improve those last words that are still in question: ".....and without requiring horizontal scrolling to view that content." (and the similar words in the second paragraph.), I think we have to more clearly express what is wanted, even though that will undoubtedly take more words to say it.

To state the problem first, then: those words are trying to avoid the case where users have to repeatedly scroll back and forth to read every line in a block of text (and likewise in the vertical situation). So we need to capture that repeated aspect of it in words.

No one minds having a longer statement if it is clear - it is statements that are so short that they aren't clear that give problems in understanding! So how about this:

".....and without requiring the reader to scroll repeatedly backwards and forwards to read every line in a block of horizontally-flowed content."

And for the vertical version in the second paragraph:

".....and without requiring the reader to scroll repeatedly up and down to read every column in a block of vertically-flowed content."

I know people are also concerned about a situation where there is horizontal text and vertical text on the same page. But a person reading content can only read one item of text at a time, so they only want to avoid repeated scrolling while reading that particular block. Once they have read that, they can read another block, and if that's in a different direction then they only want to avoid repeated scrolling in that new direction. So there shouldn't be a problem there.

[alastc]

Hi Guy,

That still leaves the 3-narrow column problem, where you could have a 3 col layout, each of which fits, but then you have to scroll across them, which Steve talked about earlier.

[guyhickling]

I think there comes a point where we have to stop thinking of every possibility, because the number of possibilities is endless. If there are particular designs, such as the three column one, that need a little explanation as to how they fit in, then maybe they should be discussed in the Understanding document.

What we have now is a wording that is in plain language, with a meaning that is clear, and is still as general purpose as we can make it. If everyone can understand it then the majority of people will do their best to follow it.

Whereas, with the wording currently in this SC's draft, people will spend most of their time arguing about what it means, or trying to explain it to others, and many will simply dismiss it as just another piece of meaningless double-talk that they will not bother to try to understand. I would like to say that, even as a web developer myself, I have the greatest difficulty in understanding how to get from "can be zoomed to an equivalent width of 320 CSS pixels" to a low vision user zooming to 400% on their desktop PC screen. And yes, I have read the explanations.

Those of you who were in on that discussion right from the start no doubt understand how the connection works, but I don't think many people coming to it from outside that conversation will do so.

I'm also conscious that deadlines are looming close. The December limit is only a month away, and I understand that even after the November draft comes out it will be difficult to make further changes.

So I would urge you to accept the wording we have reached here, and put it forward to whoever has to decide between the two. I do not think they should be left with only one choice. They should be given this second version, and be allowed to make a decision based on the merits of the two alternatives.

[alastc]

Hi @guyhickling,

This issue was the main topic of the working group this morning, both versions were presented (see the wiki page) a few key points from the discussion:

• Some sites 'reduce' the font size at smaller screen sizes, which is a legitimate thing to do for usability reasons (See apple.com's top heading, currently "iPhone X", or BBC homepage). Therefore we can't require content is 400% bigger, that would penalise sites which use large text in larger screen sizes.
• It would be best to combine the current text-size (1.4.4) with this one, and focus this one on the reflow to 320px.
• Another approach would be to have a minimum text-size, but hopefully don't need that by combining with current 1.4.4, it would bring other difficulties.
• Ultimately, what we are trying to require is a 200% increase in text-size (at least), and that it can reflow to a 320px width. In practice many sites will have a greater than 200% increase in text size when zoomed to that level (for body text), but we need to allow for sites with large headings that would simply go too big at 400%.
• Talking to the internationalisation folk, sites with text in vertical & horizontal directions are something we should worry about, recent browser support has improved and it is becoming more common.

Change of SC text proposed by the WG at TPAC:

Reflow: Content can be presented at a width equivalent to 320 CSS pixels without loss of information or functionality, and without requiring scrolling in two dimensions, except for parts of the content which require two-dimensional layout for usage or meaning.

[guyhickling]

Thank you for the links. Thank you also for placing our alternative wording before the Working Group. That is much appreciated.

I think my first question would be, what do they mean by "Need to combine the current text-size (1.4.4) with this one".

Does that mean they will change to 200% figure in SC1.4.4 to 400%? I thought they were aiming not to change any of the 2.0 criteria?

Or does it mean that the current 1.4.4, as it stands now at 200%, will now be the only requirement for text sizing? Lower down in the wiki they say "Therefore the formulation of text requiring 400% increase in content does not work", so it seems to me that they are throwing out the whole idea of 400% zoom. Is that correct?

[alastc]

Sorry, that was confusing, I didn't mean to combine the two SC, but to use them in combination.

What has now been proposed is that this SC focuses on reflow, and we rely on the current text-resize SC to ensure that text does actually increase in size.

The nuance is that it does require the equivalent of 400% zoom by making sure you have to display at 320px wide/high without 2D scrolling. We had comments about the level of testing needed if you have to test every size between 100% & 400%, so took out the zoom aspect.

We rely on the 1.4.4 SC to ensure that text does actually increase, so (for example) sizing text with VW units would fail. Not all text would increase 400%, but a lot would, and certainly more than 200% (with no horizontal scrolling).

Another factor was that pages with text in both directions are becoming more common because browsers have better support for vertical text now. Also, the low-vision folks would rather avoid horizontal scrolling, even for layout, not just blocks of text.

I hope that makes sense?

[steverep]

@alastc, just repeating my survey comments here for posterity. We briefly touched on this in the midst of whirling through LVTF issues, but I don't think we came to a conclusion.

In concept, I understand the difficulty in trying to cover zoom and reflow in one SC, so I'm fine with separating the two. However, this proposed language does not require reflow at all, but rather a single working presentation at 320 pixels. A single media query for 320px and a fixed layout at larger sizes would pass, but gives little to no benefit to low vision users.

Reflow is a dynamic and continuous response, and the SC needs to be clear that is the content requirement because that is the user accessibility requirement. I would suggest the following wording to resolve this:

Reflow: Content can be presented at widths equivalent to 320 CSS pixels and greater without loss of information or functionality, and without requiring scrolling in two dimensions, except for parts of the content which require two-dimensional layout for usage or meaning.