JLReq TF meeting notes 2024-6-25

（日本語）

Attendees

atsushi, kida, murata, shinyu, suzuki, tajima, taro, tlk, toshi

WCAG 3 Working Draft is now up

https://www.w3.org/blog/2024/the-wcag-3-working-draft-update-is-ready-for-your-review/

Updates from Murata-san:

• Murata-san is a member of an international WCAG committee and is attending the meeting.
• The terms "right/left margin" that assume horizontal text do not appear in the WCAG 3 draft. This is a progress for CJK.
• The draft uses the term “characters” when it probably should use "graphemes". While this does not affect CJK, it is important for some complex languages. It needs to be more language-neutral.
• Murata-san believes that WCAG should separate language-neutral principles and language-specific techniques. However, although there is a mechanism (WCAG and WCAG-technique), it is not well utilized. As of WCAG 2.2, WCAG is specific to English or similar languages. This needs to be improved.
• Kida commented that if the separation is achieved, the WCAG’s target audience would be people who write WCAG-techniques for each language. Murata-san agreed.
• Murata-san thinks this is a big job that will probably take 20 years.

Review of GH Issues

Should breaks before small kana be prohibited in “line-break: normal”?

w3c/csswg-drafts#10363

The following is a summary of the discussion:

The current JLReq forbids small kana from appearing at the beginning of lines, as stated in section 3.1.7. In appendix C.3 addendum, it defines looser levels that allow breaks before small kana and some other characters. In traditional printing, there has been pressure to avoid kinsoku (prohibition of line breaks at certain points) as much as possible to reduce the need for adjustments for justification, which affects the productivity of line layout work. Additionally, when a justified line is shorter, the adjustments result in visible widening of character spacing. The looser levels were defined to accommodate such requirements.

Text on the web has different properties. The cost of line adjustment is negligible. The default on the web is ragged right, meaning that adjustments do not negatively affect character spacing. Another reason to avoid separating small kana is that they are diacritical marks modifying the phonetic value of the previous character. Separating them forces readers to read the base character differently. Upon reaching the beginning of the next line, readers find that it actually had a different pronunciation. This effect would be worse for people with reading difficulties (However, Murata-san doubts if there are any research papers concerning the issue, as research in this area is critically understaffed).

It is important that editors and designers have options like those defined by CSS. For example, when a justified line is shorter, one might prefer looser rules to prevent the spacing between characters from becoming too wide.

Recommendation: As a unified position, JLReq TF recommends in normal, forbid breaks before small kana, as well as the prolonged sound mark. Kida will add a comment (done).

Jukugo-ruby examples in HTML Ruby Markup Extensions document

w3c/html-ruby#22

JLReq document explains that jukugo-ruby will be rendered just like group ruby when the whole base text fits within a line. In its Appendix F, it explains a more sophisticated method, illustrated in the first example as well as Figures 1 and 2 in the link.

Bin-sensei feels that explaining the sophisticated method as something that is expected is a bit too much. This is because the method is far more complicated. The TF members agreed.

Additionally, we feel that the example used is not optimal because it allows multiple interpretations. For instance, you can treat 京都 as one jukugo and handle 市 separately, or you can treat 京都市 as a whole as one jukugo. Bin-sensei to send us examples that he has (done, and added to the issue comment).

Murata-san explained that while JLReq assumes the size of the ruby text is 50% of the base text, some textbooks use condensed Kana with 33% width but taller. This allows three characters to fit above the base Kanji. It sounds like a sophisticated option.

Bin-sensei is not certain if we should explain the sophisticated method in jlreq-d. This is because even the basic jukugo-ruby is not implemented in InDesign. (Kida’s comment: InDesign is for fixed layouts where the editor can manually change group ruby to mono-ruby when the base text reaches the end of a line. On the contrary, on the web, you cannot predict if a ruby base text will come at the end of a line. This means it might be more important to implement jukugo-ruby on the web than in applications for printing). We will discuss this further later.

Recommendation: Kida will comment based on the discussion (done).

Line breaks within ruby element?

w3c/html-ruby#18

We were not sure what it is about. Kida will comment for clarification (done).

ruby code examples

w3c/html-ruby#17

JLReq TF does not have specific comments. Murata-san might add his comments.

Vertical forms

w3c/clreq#616

Kida’s todo. Will add comments to the base issue.

text-autospace: what gets copied?

w3c/csswg-drafts#8511

When we discussed this in February, we could not reach a unified consensus. We want to revisit the issue as the discussion is ongoing.

Discussions:

Yamaguchi-san: When you copy justified text, the source text gets copied without additional spacing characters. Similarly, it would be better to copy the source for text-autospace. If we base the discussion on “user expectation from the look of the text,” the same can be said for many other cases on the web, which goes against the principle. What is the boundary between cases where the source is copied? I believe the source should be copied.

Murakami-san: I completely agree for the case where space is inserted. However, how about the removal case? I think extra space characters should be removed when “replace” is specified. It is similar to the HTML rule of removing extra space characters and can be considered a normalization.

Kida: I oppose. Collapsing multiple space characters into one and removing them completely are entirely different. Removing spaces can alter the semantics of the text. It cannot be considered normalization of the input stream.

Shimono-san: Removing a space character can be thought of as a text beautifier. It is similar to removing a line feed.

Murakami-san: I retract my previous comment. The source text should always be copied.

Conclusion and Recommendation: As a unified position, JLReq TF recommends that the source text should be copied for Japanese text. We do not have any opinions or comments regarding the French issue.

The next meeting is on 7/9

Shimono-san might not be able to make it.