Width of 80 glyphs (40 in CJK) unclear for other languages

[aphillips]

https://www.w3.org/TR/WCAG22/#visual-presentation

One of the items in section 1.4.8 is:

Width is no more than 80 characters or glyphs (40 if CJK).

The link to this document makes this requirement clearer. The I18N working group is unclear on the source of the 80 glyph limit or of the 40 glyph limit for CJK languages. We note that the numbers 80 and 40 are suspiciously similar to terminal device limits (from the days when CJK characters required two bytes each and took two "screen positions"), but the understanding guide says that research backs these numbers.

Our primary concern here is that there are many writing systems in the world and it is unclear how the 80/40 SC should be applied to those writing systems or if other guidance should be provided. For example, is there any evidence that South Asian or Arabic scripts would apply one or another of these limits (or something else)? What is the driver behind the limit?

[aphillips]

Mentioning #2680 (forgot to do so the first time)

[r12a]

https://www.w3.org/WAI/WCAG22/Understanding/visual-presentation contains:

Lines should not exceed 80 characters or glyphs (40 if CJK), where glyphs are the element of writing in the writing system for the text. Studies have shown that Chinese, Japanese and Korean (CJK) characters are approximately twice as wide as non-CJK characters when both types of characters are displayed with characteristics that achieve the same readability, so the maximum line width for CJK characters is half that of non-CJK characters.

I'm not sure that the best way to derive the equivalent figure for CJK is to simply divide the English? figure by 2. Chinese and Japanese text has no spaces between words, which may affect the preferred line length for readability. Characters are also square and mono-spaced, and lack the word shaping that may help the English reader to chunk up the text while reading. It seems a bit of a leap to assume that an appropriate metric can be derived from the experience of Western readers. There may, in fact, be local recommendations for accessible line length, and it seems a bit presumptuous to simply base it on the width of Western lines.

[r12a]

And now some notes on the proposed 80 character line length, which also to me doesn't sound as if it's based on research into readability. Robert Bringhurst has the following recommendation in 'Elements of Typographic Style':

Anything from 45 to 75 characters is widely regarded as a satisfactory length of line for a single-column page set in a serifed text face in a text size. The 66-character line (counting both letters and spaces) is widely regarded as ideal. For multiple-column work, a better average is 40 to 50 characters.
If the type is well set and printed, lines of 85 or 90 characters will pose no prblem in discontinuous texts, but as bibliographies, or, with generous leading, in footnotes. But even with generous leading, a line that averages more than 75 or 80 characters is likely to be too long for continuous reading.

He goes on to make further points, and includes a copyfitting table that spits out target line lengths depending on the size of the text. But the general conclusion appears to be that less than 80 characters is better.

The other i18n issue here is what is meant by 'character'. Most complex scripts (and emoji) combine sequences of Unicode characters into one 2-dimensional arrangement, and a count of 80 will come up much shorter than 80 characters of English text. On the other hand, in some scripts the characters can be much wider than english letters, and this can be compounded by the addition of spacing combining marks, especially to the special forms used to represent consonant clusters.

It may be slightly better to rephrase the text quoted in the previous comment to say something like 'the width of a line should not exceed that of a line of 80 English letters', although that's still not ideal.

The basic issue here is that the text can be perceived to have been written in English and with no consideration of non-English users, other than a Western-biased calculation for CJK. I think that it should at least own up to that, and recommend that locally-appropriate requirements should be substituted where available.

[murata2makoto]

The number of characters per line in horizontally-written Japanese and that in vertically-written Japanese are different.

[alastc]

For all of the Visual presentation issues it is worth remembering that the SC text includes:"a mechanism is available to achieve the following".

That mechanism (in practice) will be the user-agent, i.e. the user has the ability to achieve this by over-riding the site defaults.

The authors responsibility is to ensure the site doesn't break when people use adjustments such as zoom level, window size, and user-styles for colours.

Discussions of an ideal reading width isn't really reverent, it is whether it is worthwhile having the layout adapt when people adjust it to those values. That might be for cognitive or low-vision reasons.

The point of the SC is to have robust and adaptable layouts, rather than specify particular line lengths. I think the values were chosen as practical targets rather than user-ideals.

Given how browsers and CSS works, and how everyone in the world started from 640px (then 800 then 1024 then 'bigger') monitors, it seems logical that robust layouts are helpful across writing systems?

The I18N working group is unclear on the source of the 80 glyph limit or of the 40 glyph limit for CJK languages...

The research going into WCAG 2.0 would have been from the early 2000s, 10 years before I joined the group. I'm not sure who would know about that now. (Perhaps @GreggVan?)
My hunch is that the research would have given a range of values, and this was picked as a practical level to aim for.

it is unclear how the 80/40 SC should be applied to those writing systems or if other guidance should be provided.

Is there any feedback from folks implementing this 15 year old requirement on those writing systems? It isn't my area but the SC has been available for a long time, surely any problems should be apparent by now?

[aphillips]

@alastc That's interesting: it suggests my original surmise was the correct one--that this is related to terminal and line-printer conventions (which were still somewhat relevant to some technologies back in the day). For example, it might be the assistive devices, such as Braille readers, might be optimized for 80 (Latin) character lines of text.

Is there any feedback from folks implementing this 15 year old requirement on those writing systems? It isn't my area but the SC has been available for a long time, surely any problems should be apparent by now?

It might be that this requirement is being ignored? Is there really a browser mechanism for limiting text to 80 graphemes? And for many languages, the relationship of character to grapheme to screen position is complex.

--

In our teleconference today we agreed to focus on the exception/note issues. I'm going to close this issue, not because it is fully addressed but because we will be better served by specific work on the tasks needed to unblock progress now and in the future. We might recreate such an issue in the future as part of that effort.

[r12a]

I suspect that this issue will continue, but as a commentary on the Understanding doc, rather than on the SC doc.

Note that my 2 interventions above are related to https://www.w3.org/WAI/WCAG22/Understanding/visual-presentation

Perhaps we should just change the labels?