The WCAG, as far as I know, claims to serve all languages of the world. However, it was written mostly by people from the US, European and Japanese language areas, so other languages may be underrepresented.

For example, 1.4.8 explicitly states:

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

It would be helpful if you could explain why 1.4.8 and 1.4.12 do not apply to Japanese?

These are ones we noticed.

• Line spacing (leading) is at least space-and-a-half (1.4.8)
  Line height (line spacing) to at least 1.5 times the font size; (1.4.12)

Japanese text (and probably Chinese?) requires wider line spacing compared to English. For example, regular books for ones with normal eyesight have line spacing of around 150% to 200%. Books for ones with special needs have wider line spacing. I believe I can post an example later.

paragraph spacing is at least 1.5 times larger than the line spacing (1.4.8)
Spacing following paragraphs to at least 2 times the font size; (1.4.12)

Japanese do not use an empty line to indicate a paragraph. Instead, the first character of a paragraph is indented. While many recent digital contents, such as the web, follow the English style, books follow the traditional rule, including ones created for dyslexia. I guess this one falls into the exception category described in the last part of 1.4.12 (but the exception clause is not in 1.4.8).

Letter spacing (tracking) to at least 0.12 times the font size;(1.4.12)

The letter spacing in Japanese text is zero, including contents created for dyslexia.

Text is not justified (aligned to both the left and the right margins). (1.4.8)

I have a question on this. What is the reasoning behind this rule? I would like to figure out if this one equally apply to Japanese.

Please note that these are ones we happened to notice. Also there are rules that apply to Japanese text (and possibly to some other languages) but not to English such as handling of ruby.

WCAG aims to be applicable to all languages, although I'd note most people working on it are from western countries. It also goes through an internationalisation review process.

@MakotoUeki is probably the best person to ask how the current criteria have been applied in Japanese. There is also an unofficial translation of WCAG 2.0 into Japanese which might have some clues.

Here is a screen copy of a Japanese DAISY reader (ChattyBooks).

The default value for line spacing is 2.6 and that for letter spacing is 0.2. I guess that 2.6 means 260%.

P.S. The line-spacing value 2.6 is recommended by a group of Japanese DAISY textbook creators. It certainly assumes that lots of ruby is present.

ah, the letter spacing was not zero. I misunderstood. Thank you for the image.

I think WCAG should aim to apply to all cultures, all languages, and all writing systems. I understand that this is not the case. This should be fixed. Regarding writing systems, criteria 1.4.8 and 1.4.12 should be adjusted.

For 1.4.8, I have no idea regarding the maximum number of characters (40 and 80).

For 1.4.12, it might be possible not to define values relative to the font size, but only relative to the default spacing (e.g. the line spacing must be able to be increased to 1.5 times the default line spacing). However, I don't know if the browsers define a uniform default spacing for each language.

@alastc Can you please assign the correct labels: 1.4.8, 1.4.12 and a new one: "internationalisation"? "Discussion" is a bit too general. This seems to me to be an important topic that should not be lost.

Interesting topic.

Here is the historical note. I was involved in the development of both WCAG 2.0 and JIS X 8341-3.

The JIS X 8341-3 working group checked success criteria in WCAG 2.0 which could introduce language specific issues, including 1.4.8, when JIS X 8341-3 adopted WCAG 2.0 success criteria in 2010.

For example, there is a note for "large scale text" in 1.4.3, which reads:

The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size.

So the JIS X 8341-3 working group looked for the "equivalent" sizes in Japanese and set different font sizes based on the standard large print sizes. The sizes were specified in the JIS X 8341-3:2010 and Japanese translation of WCAG 2.0.

For another example of 1.4.8, JIS working group asked the WCAG working group to specify the number of characters for Japanese. Then the 1.4.8 had "(40 if CJK)" at last.

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

This is my personal opinion, but we'll be able to address any other language issues in the same way. I think JIS X 8341-3 will be updated once WCAG 2.2 become the W3C recommendation and it is adopted as the new version of the ISO/IEC 40500. That will be the next opportunity for us.

@kidayasuo
If you have any suggestions for Japanese web content, that will be super helpful for the next update of JIS X 8341-3. The JIS X 8341-3 working group will need the research-based evidence to address these issues.

And I'm very curious about how China and Korea has been addressing these language issues.

@GreggVan would have insights and thoughts on how we should address these kind of issues in WCAG.

Here goes my first comment.

This is my personal opinion, but we'll be able to address any other language issues in the same way.

I do not believe that WCAG can cover details of all natural languages. Who knows appropriate line spacing for Korean, Mongolian, Tibetan, Arabic, Hebrew, Thai, and so forth? Rather, I would like to allow each language group to create a separate specification for that language when the group is ready. This is similar to JLreq, ILreq, CLreq, KLreq, HLreq, ALreq, and so forth.

Who knows appropriate line spacing for Korean, Mongolian, Tibetan, Arabic, Hebrew, Thai, and so forth?

The SC is intended to help PWD who have difficulty with fluid reading. This includes dyslexia and people who need larger fonts, but who do not routinely use AT such as screen magnification. The SC is agnostic in regards to the appropriate default line spacing, but does presume that the ability (for the reader) to add additional line and/or paragraph spacing can be helpful with non-western writing for some PWD.

The letter spacing in Japanese text is zero, including contents created for dyslexia.

What are the special properties for Japanese content created for dyslexia? For example, in the U.S. there are specialized font faces and AT that highlights word-by-word.

Text is not justified (aligned to both the left and the right margins). (1.4.8) ... What is the reasoning behind this rule?

Fully justified text introduces essentially random extra white space between words. The resulting uneven spacing between words makes reading harder, for everyone, but for some people the difficulty is quite significant.

I would like to figure out if this one equally apply to Japanese.

Please share if you think this is applicable (or not)!

So either we formulate the SC universally and if that is not possible, it should be mentioned in the Understanding that they only apply to certain writing systems.

@MakotoUeki thank you very much for your comments:

If you have any suggestions for Japanese web content, that will be super helpful for the next update of JIS X 8341-3.

I am not knowledgeable about this area, so I just listen to what experts, like you, say. The Japanese Language Enablement Task Force is planning to develop a digital text version of JLReq, called JLReq-d. In this new document, we plan to include rules and guidelines to make text layout more accessible to a broader audience; it is something everybody who deals with text content needs to be aware of. We need help from area experts like you, and I would very much appreciate it if you could.

The JIS X 8341-3 working group will need the research-based evidence to address these issues.

I agree that basing on research-based evidence is important. I wonder that not necessarily all practices applied by books developed for dyslexia are backed by research however. Some of them are based on accumulated feedback from its users, and many of them would be, I guess, legitimate. How do you handle them in JIS X 8341-3?

Text is not justified (aligned to both the left and the right margins). (1.4.8) ... What is the reasoning behind this rule?

I am particularly interested in this rule. Are there research papers that back up this rule for English and/or Japanese text? I would like to learn.

The sizes were specified in the JIS X 8341-3:2010 and Japanese translation of WCAG 2.0.

Should they be reflected back in WCAG considering it aims to cover all languages?

How do you handle them in JIS X 8341-3?

The working group should also hear users voices where possible, especially when the research-based evidences are not available.

When the JIS was revised in 2010 to adopt WCAG 2.0, the working group solicited public comments and invited opinions on the draft as much as possible. The working group addressed the issues they got from the public. Since 1.4.8 was at level AAA, the public may not have shown much interest though.

If you know there is an issue for some users, I'd like to listen to them so that I could share it with the working group and the committee (WAIC) at least. And they will be able to discuss the issue for the next update.

I am particularly interested in this rule. Are there research papers that back up this rule for English and/or Japanese text? I would like to learn.

@bruce-usab explained the rationale above. And I'm not sure if there is the back-up for Japanese text, but it is understandable that some users would get overwhelmed if letter spaces are not equal line by line.

If the issue won't happen or different issue happens in Japanese text, it would be possible to add a note to next version of JIS X 8341-3 and Japanese translation of Understanding WCAG document.

Should they be reflected back in WCAG considering it aims to cover all languages?

I don't think so. It would be difficult to set an universal numeric criterion especially for text/font related issues, which covers different languages.

WCAG says "For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size."

This would be enough. JIS working group addressed this and found the "equivalent" sizes for JIS X 8341-3. Any other non-English speaking countries can do the same way if WCAG shares how it was set/defined for English text like this success criteria.

@murata2makoto

Rather, I would like to allow each language group to create a separate specification for that language when the group is ready.

I agree with you. That is exactly what JIS X 8341-3 has addressed the language issues when adopting WCAG 2.0.

Let me give more background information. I am the chair of the technical committee of the Japan DAISY Consortium. I was the chair of the JIS Committee for EPUB Accessibility. I am also the leader of a research project for evaluating the readability of Japanese text using eye-tracking machines (Tobi). More about this project is available here (but in Japanese).

What are the special properties for Japanese content created for dyslexia? For example, in the U.S. there are specialized font faces and AT that highlights word-by-word.

Ruby between lines obviously makes line-spacing difficult. No space occurs between words in typical Japanese text, but this might not be good for dyslexic people. (This is the main topic of the research project mentioned above. Adding space between words is good for some (though not all) dyslexic users.)) I know little about character-spacing, but the Japan DAISY consortium chose 0.2.

The JIS X 8341-3 working group will need the research-based evidence to address these issues.

I agree that basing on research-based evidence is important. I wonder that not necessarily all practices applied by books developed for dyslexia are backed by research however. Some of them are based on accumulated feedback from its users, and many of them would be, I guess, legitimate. How do you handle them in JIS X 8341-3?

Having done the research project mentioned above for three years, I start to trust feedback from practionners more. Research is not allmighty. ;-(

If you know there is an issue for some users, I'd like to listen to them so that I could share it with the working group and the committee (WAIC) at least. And they will be able to discuss the issue for the next update.

I am afraid that JDC has not provided enough feedback. Will try harder next time.

Rather, I would like to allow each language group to create a separate specification for that language when the group is ready.

I agree with you. That is exactly what JIS X 8341-3 has addressed the language issues when adopting WCAG 2.0.

But the hands of JIS drafting committees are tied. There are some strict rules about changes to normative requirements. It would be much better if WCAG does not say anything not applicable to all natural languages.

@murata2makoto

Having done the research project mentioned above for three years, I start to trust feedback from practionners more. Research is not allmighty. ;-(

Yes, feedback from practitioners can also be the evidence. No doubt about it.

As to SC 1.4.12, it was introduced in WCAG 2.1 which means JIS X 8341-3 hasn't include it yet. JIS working group will discuss it once the working group is organized for the next update. And they will look for papers and inputs from experts.

It would be much better if WCAG does not say anything not applicable to all natural languages.

I'd like WCAG to share the rationale where possible so that the criterion can be applied to any languages. I think we are on the same page. And I'll keep it in my mind as one of the participants in the AG working group.

Fwiw, these are some related issues (all now archived):

• Letter/Word spacing for CJK languages - SC 1.4.12 Text Spacing wcag21#677
• Adapting Text: Line height and leading wcag21#388
• Adapting Text: font-family wcag21#389
• Adapting Text: Letter spacing wcag21#390

It is perhaps worth mentioning that @kidayasuo is particularly interested in the rationale for not using full justification because full justification in Japan (unlike in the West) is the norm, to the extent that most layout approaches actually start from the expectation that lines will be flush on the left and right (or top and bottom in vertical text). However, Japanese and Chinese also use an entirely different approach to justification (see this): the essential characteristic of which is that gaps are applied between each han and kana character equally across the whole line, regardless of word boundaries. ( In reality, however, there is much more complexity involved, such as reducing spacing around punctuation first, introducing hanging punctuation, accommodating ruby annotations, introducing 'word'-based separation as a special case for accessibility, etc.) Hope that helps.

Will this issue be addressed before WCAG 2.2 becomes a REC?

Changes to WCAG 2.0/2.1 criterion were not in scope of the 2.2 update, with the exception of removing 4.1.1 which started in #770 back in 2019.

Changes to normative text for previous SCs are very difficult to get agreed, as they are then not aligned with where WCAG has been used in laws and regulations. Previously we've only done additive updates, where requirements are added but not changed/removed. That means that passing the latest version automatically passes previous versions.

The suggested update above removes the values from the normative text, which would run into issues of backwards compatibility.

In the short term, if we can come up with what is considered the best practice for non-western languages, that could be added to the understanding document, or even a separate note.

In the longer term, I think we should look at having multiple guidelines/methods/tests for different languages.

@alastc

The suggested update above removes the values from the normative text, which would run into issues of backwards compatibility.

Can we then make clear that currently recommended values apply to Western languages only and that different values are required for non-Western languages in WCAG 2.2?

Or perhaps add a new requirement that for non-Western languages (which probably actually means non-Latin orthographies), local adjustments should be made to typographic aspects of text based on the writing system being used? Add to that the admonition to develop local guidelines, as suggested above.

WCAG 2.2 will become an ISO/IEC standard and a Japanese Industrial Standard. Having seen WCAG 2.1 did not become an ISO/IEC standard, I guess that any version beyond 2.2 is unlikely to become an ISO/IEC standard in the foreseeable future. Thus, I very strongly want to address this issue in 2.2. I think that I have to take any possible action to get this issue addressed before WCAG 2.2 becomes a recommendation.

WCAG aims to be applicable to all languages, although I'd note most people working on it are from western countries. It also goes through an internationalisation review process.

@MakotoUeki is probably the best person to ask how the current criteria have been applied in Japanese. There is also an unofficial translation of WCAG 2.0 into Japanese which might have some clues.

I agree with this. Chinese commonly have line spacing of 150% to 180%. So it seems not applicable to Chinese.

For those who have been looking for rational, it is worth reading the links @r12a posted above, which was from the WCAG 2.1 horizontal review (the expected time to raise issues on WCAG 2.1 criteria). I scanned back and was reminded that:

• The aim of the SC is to allow for more spacing, it is not intended to say that those values are what the user must have. Users adjusting (for example) Japanese text-spacing do not have to use the values specified, they can use the most appropriate values for them.
• From 677 we added the exception ("Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.")
• From 388, the criterion does say "at least", so there is no need to reduce line height to test the condition. If a language uses larger values (e.g. line height), the SC wouldn't have any effect.

So when there are questions such as:

"Japanese text (and probably Chinese?) requires wider line spacing compared to English. For example, regular books for ones with normal eyesight have line spacing of around 150% to 200%."

The SC will have no effect if the value is already greater than the value from the SC. It isn't requiring an increase, or a decrease, or for the author to test at a lower value than they are already using.

Going back to the original question (coverage of languages): The aim was to provide a benefit to people with disabilities in the languages where this SC makes sense, and not harm others.

For a normative update to the SC, I think there would need to be evidence of harm to other languages. Lack of benefit for some languages was already understood. Also, this would need to apply to WCAG 2.1 as well, so we would need to apply the errata process rather than the PR process that WCAG 2.2 is currently in.

If experts in non-latin based languages can provide research and/or alternative values, that would be great. We could add that to the understanding document, or create a separate note document to provide preferred values for different languages.

However, requiring that WCAG 2.2 include different values normatively would mean an indefinite delay for something that the AG group does not have the expertise to add.

Also, this would need to apply to WCAG 2.1 as well, so we would need to apply the errata process rather than the PR process that WCAG 2.2 is currently in.

Is this claim backed by the W3C process? In the ISO world, any mechanism in a new version can be revisited during the ballot. Updating WCAG 2.1 certainly requires the errata process, but this does not imply that 2.2 has to be updated using the errata process.

"Japanese text (and probably Chinese?) requires wider line spacing compared to English. For example, regular books for ones with normal eyesight have line spacing of around 150% to 200%."

The SC will have no effect if the value is already greater than the value from the SC. It isn't requiring an increase, or a decrease, or for the author to test at a lower value than they are already using.

Going back to the original question (coverage of languages): The aim was to provide a benefit to people with disabilities in the languages where this SC makes sense, and not harm others.

But in this case, this SC is less useful (and potentially harmful) for these writing systems, because these writing systems ​​need a larger minimum value than Latin, and if the author uses the minimum value from the SC, it may have a negative impact on the readability of the text.

Is this claim backed by the W3C process? In the ISO world, any mechanism in a new version can be revisited during the ballot. Updating WCAG 2.1 certainly requires the errata process, but this does not imply that 2.2 has to be updated using the errata process.

I'm not sure, I don't think it is explicitly covered in the process. As mentioned, WCAG 2.2 has added some features, but this was not one of them. The time in the process to object to a 2.1 SC was during the 2.1 process.

But in this case, this SC is less useful (and potentially harmful) for these writing systems, because these writing systems ​​need a larger minimum value than Latin, and if the author uses the minimum value from the SC, it may have a negative impact on the readability of the text.

Why would an author use the SC as a minimum value, unless they misunderstand the SC?

If the value they wish to use is greater, that passes the SC. The point of the SC is that users can increase the sizing, and the SC says what authors should test. If they have already tested to a greater value, there is nothing for them to do.

@alastc

The time in the process to object to a 2.1 SC was during the 2.1 process.

I don't buy this argument.

In Success Criterion 1.4.12 Text Spacing, it is required that spacing following paragraphs to at least 2 times the font size.

In Japan, no additional spacing is used between paragraphs. Even DAISY textbooks in Japan do not have such additional spacing.

In Success Criterion 1.4.12 Text Spacing, it is required that spacing following paragraphs to at least 2 times the font size.

Not quite. The SC doesn't require authors to set a specific spacing at all. The SC requires that if a user sets their own browser to have those particular metrics, the content doesn't get cut off or otherwise unusable/unreadable.

Not quite. The SC doesn't require authors to set a specific spacing at all. The SC requires that if a user sets their own browser to have those particular metrics, the content doesn't get cut off or otherwise unusable/unreadable.

Then, do some perfectly accessible fixed-layout Japanese contents become non-conformant because unnecessary space between paragraphs are required by WCAG 2.2?

if i understand your premise correctly, yes - a fixed-layout site (Japanese or otherwise) that can't adapt to users setting larger spacing metrics will fail

@patrickhlauke

Thanks for your clarification.

We spoke about this issue during a working group call today, and I would like to suggest those who have raised concerns in this issue to provide suggestions on what might be updated in the understanding doc to make the requirements of this SC clearer.

As @alastc has mentioned in this issue, and the understanding doc already states - the SC's minimum metrics are not author requirements. Rather what is required is that web authors don't prevent users from being able to apply these metrics through their own user styles they've applied to a web page.

In an attempt to help move this issue towards resolution, here are a few modifications to the Author Responsibility section. If there are other changes that could be helpful for the understand document, please make those suggestions so that the WG might incorporate them. Or, if there is a specific Note that someone would like to draft for consideration, that would be very helpful.

Drafted text for potential update (new text is bold and wrapped in [[ ]] characters to help identify the changes):

This SC does not dictate that authors must set all their content to the specified metrics, [[nor does the SC intend to imply that all users will adjust the specified metrics]]. Rather, it specifies that an author's content has the ability to be set to those metrics without loss of content or functionality. The author requirement is both to not interfere with a user's ability to override the author settings, and to ensure that content thus modified does not break content in the manners shown in figures 1 through 3 in Effects of Not Allowing for Spacing Override. The values in the SC are a baseline. [[For content written in languages where the specified metrics would help increase readability]], authors are encouraged to surpass the values specified. [[These metrics are not meant to represent a ceiling for authors to build to, nor as minimum requirements to adhere to, as some metrics may not even be applicable to certain languages. For example, languages such as Japanese do not use spacing following paragraphs, meaning that users won't necessarily force any paragraph spacing metrics in practice]]. If the user chooses to go beyond the metrics specified any resulting loss of content or functionality is the user's responsibility.

Feedback and additional suggestions more than welcome.

Hello WCAG, I18N reviewed this issue and some investigation performed by members of our working group in our call yesterday (2023-08-10). I intend to file new issues with specific commentary/requests, mentioning this issue (so that followers of this issue can find the others easily), so that this issue does not become clogged with comments on separate threads of commentary.

Some of the above discussion is helpful. In general, we think the specification is unclear about the scope of its applicability with regard to non-Latin-script languages. There are many languages in the world that are neither Latin script nor CJK and for which non-specificity could result in issues. There are also places where reasons behind the guidance are difficult for us to guess.

Under separate cover I have contacted the WCAG chairs in hopes of arranging some joint meetings ASAP to discuss. In the meanwhile, watch for a few new issues with the i18n-needs-resolution label which we hope will allow for progress.

(Note: I have just seen @scottaohara's comment just above and will respond to it separately. Perhaps copy @xfq, @r12a, and myself @aphillips on any PR to assist in reviewing wording??)

I find that Success Criterion 1.4.8 Visual Presentation does not cover vertical writing. It mentions "width", "left", "right", and "horizontally".

The time in the process to object to a 2.1 SC was during the 2.1 process.

I don't buy this argument.

In Success Criterion 1.4.12 Text Spacing, it is required that spacing following paragraphs to at least 2 times the font size.

In Japan, no additional spacing is used between paragraphs. Even DAISY textbooks in Japan do not have such additional spacing.

In the 2.1 process we had issue 677 on this topic, which was resolved at the time. (Well, it was on word spacing, but the same resolution would apply to all the characteristics included.) That may not be satisfactory now, but it has been in place for 5 years. (15 years for the WCAG 2.0 SC mentioned.)

We should tackle these issues in the understanding documents and potentially as errata for WCAG 2.1 and 2.2, but I'm going to ask for clarification on how it would impact the 2.2 publication process.

Now that separate issues have been raised on each item, is this issue needed?

@alastc Are you saying that changes to 2.2 to address I18N's concerns is not a possible outcome?

I am mainly interested in ensuring that we collectively produce the "right" Recommendation.

I'm going to ask for clarification on how it would impact the 2.2 publication process.

Please include me in any clarification.

@aphillips I don't know, but it seems odd to have a horizontal review process, wide reviews, and then publication if it can be picked apart 5 / 15 years later.

I'm also interested in the "right" recommendation, but also by the right process. These are WCAG 2.0 / 2.1 SCs, so (IMHO) the process should be errata rather than the WCAG 2.2 PR.

As this has been split into multiple issues (and at @aphillips suggestion) I'll close this issue.

Overall, WCAG aims to cover all languages, but there are some issues which are being picked up in different threads, and we're putting in a process for WCAG 3.0 to incorporate i18n early in the development of requirments.