Meeting minutes
<r12a> https://
Ruby
<gb> Issue 22 Remove example 8 figure 3 to avoid canonicalising a not-yet-established approach (by r12a) [i18n-needs-resolution] [Needs: Edits] [i18n-clreq] [i18n-jlreq] [i18n-mlreq]
<gb> Issue 17 Add rb>rt>rb>rt example code to Example 1 (by r12a) [i18n-needs-resolution] [i18n-clreq] [i18n-jlreq] [i18n-mlreq]
[florian introduces issue #17]
<gb> CLOSED Action 17 Publish fpwd of korean gap analysis (on xfq) due 18 Jul 2023
r12a: my pref is have an rb opening and an rt opening
… we're asserting that an rb tag is a useful thing to have
… you could say here we're going to mark up a simple piece of two words with ruby
… and here are a few ways to do that
florian: the rest of the spec does that
r12a: my pref is always to front-load stuff and then explain it afterwards
fantasai: I'm happy to compromise on including the rb tag
… i'd rather not include all the patterns at this point
… there is a deliberate ordering in here
… growing in complexities in order to not overwhelm people initially
florian: I'll write it in the issue
Issue 22 Remove example 8 figure 3 to avoid canonicalising a not-yet-established approach (by r12a) [i18n-needs-resolution] [Needs: Edits] [i18n-clreq] [i18n-jlreq] [i18n-mlreq]
<r12a> https://
florian: this is an example discussing jukugo ruby
[florian introduces the issue]
florian: in the illustrations I'm using here
<fantasai> github: w3c/
florian: inside example 8
… if you go down there's a figure 1, 2, 3
… show at various size ratios between the base character and the annotation characters
… various ways you might want to lay out things in
… we need to have enough info in the spec to be able to distinguish the things
… maybe the layout chosen by CSS will be this one, maybe not
… if we didn't have that, the whole notion of jukugo ruby becomes irrelevant
… the strength of the tabular markup is it allows @@1
r12a: add some of that to the spec would be good
florian: I'll make an editorial change to this example to illustrate what i said, rather than what it seems to be saying
… afaik this is the i18n feedback on this
… privacy, and TAG gave thumbs up
… security and a11y did not get back to us and they've had 1.5 years
… I suspect we'll assume they're happy
… how do you read it on the screen reader
… this is a very important topic
… i would like to tackle it later
fantasai: maybe you can say that tts, copy & paste, findability is interesting but undefined
note that we have a document on find-in-page: https://
and an open issue related to ruby: w3c/
<gb> Issue 22 Non-body text (by xfq)
<fantasai> fantasai: you shouldn't have worse usability of a page by adding annotations to it
<fantasai> ... find needs to be able to find things while ignoring the annotations
[discussing what to discuss]
[florian recaps the situation with the logical properties stuff]
WCAG Debrief
r12a: The WCAG folks are trying to classify questions of readability
… whether general readability or related to accessibility issues
… e.g. inter-line gaps, justification, etc.
… They're trying to do that in WCAG 3
Minutes of the breakout session: https://
r12a: In WCAG 2, say that if you increase the font size etc. it shouldn't break the display
… but don't say that you should use a particular minimum size or whatever
… They want to say those specific things
… We're pushing for them to not specify for English and then leave other languages out
… They've started a group to work on this problem very slowly
… Started with a table they call "guard rail" recommendations.
… They have Chinese, Arabic, Latin, Hindi, and Russian
… This doesn't touch SE Asian languages, and has other problems.
… The approach is to say, "look for script similar to your script" but this isn't working.
… They don't know where to find the information, so we assume that whatever happens, this will be a set of information that grows over time
… as they find experts who can provide information about accessibility-related readability
… So we were pushing them to create a registry or set of documents or whatever outside the main core text
… that has all the details about what to do to ensure readability for a given script
… There may be groups of scripts that behave similarly, and could group together
… That's the summary
r12a: They also raised the issue of "ruby" and how you can use it for pronunciation of differnet lnaguages
… but I emphasized that it's primarily designed for East Asian languages
florian: I think I subtly disagree with you on this one.
… at this stage, might be the right way to say it
… but advice to spec authors and implementers should be what you said
… but if we design and implement ruby for its intended use cases
… but it turns out to be useful for other scripts, then it is perfectly fine to use it for other languages
r12a: People want to use it for glossing, which it's not well-adapted for
… I fear they'll stop work on ruby until they figure that out
… but I want to get ruby finished for the CJK market
… But rather than just jumping on ruby bnadwagon, if it's about pronunciation, what about SSML say-as or other ways of expressing pronunciation?
… CJK does it through ruby, but not necessarily best for other languages
fantasai: for rendering to audio
… ruby is designed primarily rendering to visual
… there's a little bit of a distinction here
r12a: you can also have the pronunciation between slashes/brackets etc.
… you can always a markup span with a class
r12a: Other thing is, the accessibility folks want to introduce a symbolic language (Bliss symbols)
florian: It's Chinese ideographs :)
r12a: They're not doing a fully system at the moment, but they want to attach pictures to bits of text (like nouns)
… won't have semantics or syntax or stuff like that
… but again, looking at ruby
… and we point out, well what if ruby is already being used for its intended purpose?
https://
r12a: so we have this constant problem with ruby appearing to be a panacea ...
florian: Playing devil's advocate ...
… Though I agree that ruby is targetted at CJK and should be designed for it
… we have somewhat struggled with adoption of it
… if it was made useful for more things, maybe it helps us get there?
r12a: maybe not
florian: Maybe not, but sometimes when you have more people pushing for a feature it helps adoption
duerst: Accessibility use case isn't big enough to have that effect
xfq: Did they discuss next steps?
r12a: Not really
xfq: How do we follow up?
r12a: There was talk about ruby specifically. Makoto was there, talked about his topics.
… Another topic was WCAG 2, which is not going to change
… and which currently has things about increasing font size shouldn't break, but doesn't have details about readability
… And then there's WCAG 3 where those things could be addressed
… Unfortunately all of those things were talked about at the same time in the meeting
… Mentioned that to the chair as a problem
… In terms of going forward, not much to do on WCAG 2
… I think Makoto will drive anything he's doing on ruby
… And I think we need to keep talking with Jan about this approach and getting rid fo the gurad rails table.
… But no definite plans
xfq: Ok, I guess we'll need to revisit this
r12a: Certainly felt like a re-run of previous conversations :)
… but we might need to get more involved with Jon and ??
fantasai: on removing the guardrails table and having an external reference
… externalizing it seems like the right thing to do
… in terms of finding the experts to provide that data
… maybe the daisy consortium would be helpful
… they work on very related stuff
… and might have contacts
r12a: One issue is testing
… if this is not normative text, the readability guidelines, they'r ea bit worried about whether people will actually follow those guidelines
fantasai: they can have a general statement that requires conformance
… qualitative conformance criteria
… and then these guidelines help you translate that into a specific test
florian: I agree
… if we're talking about wcag tests
… test content instead of impls
… if legislation says you're not allowed to publish a government website unless it's wcag AAA or some level
… it's hard to define
… in javanese my line height is this much, is it a pass?
fantasai: you would have to make an argument that the guidelines are wrong
r12a: the tests we're talking about is yes I conform to AAA
… and here's test to show that my content follows those
… and they've tied those to normative statements
florian: for some languages we have the abstract requirement
… for some languages we have the abstract req but not the detailed one
Bobby: Ruby is very important for bopomofo
<Bobby> https://
Bobby: I have posted the layout by font
<Bobby> https://
Bobby: My friend made a tool that uses ideographic variant to let you choose the different pronunciations for a single han character
… [missed]
… If you mark all han characters with bopomofo, the text to speech will recognize the bopomofo and spell the characters correcters
… but pronunciation ruby base + ruby text, ruby base + ruby text, etc. is a real problem
florian: this continues to be a known problem
… but the knowledge of it being a problem is spreading
… the correct solution isn't designed yet
… and browsers are starting to know about it, and that might make a difference
<br type=coffee duration=14m>
DOM localization
minutes of today's breakout session: https://
eemeli: this is the content I shared from the morning session
… an extract of how we localize the browser's front end
… where in the XHTML that is rendering parts of the UI
… we defined a link to an external resource
… a l10n resource
… the idea would be to introduce something similar to the web platform
slideset for the breakout session: https://
eemeli: if you look at the tabctx-new-tab-open
… Should we work on introducing localization as a capability of the web platform?
… Is the Internationalization WG an appropriate forum for standardizing the message resource file format?
… How specific to localization should the HTML capabilities be?
[eemeli shows what this could look like on the web]
eemeli: the next step arising from the discussion this morning is to propose to the WHATWG for the HTML parts of this
… one required part is beyond the HTML is the file format
… whether this WG is an appropriate forum to specify a message resource file format
… there's also potential for stretching to allowing for various DOM mutations
… should it be focus on supporting message formatting only?
… or would it be better to design it as a general purpose container for values?
… there is no one solution to these problems
… it's the discussions ought to take place
eemeli: we need to update the charter if we decide to work on it here
felipe: what's the scope of l10n?
eemeli: that is exactly the third question I have here
… there is a number of different existing l10n resource formats
… those could be reviewed
… Java .properties file
… Gettext PO files
… the Fluent format
felipe: even if you only translate strings
… it's not just a simple list of strings that get translated
… do you forsee this being a single global file, or maybe one per supported language?
eemeli: what I would envision would be that a single physical file for a one locale
… for multiple locales, you would end up with separate files
… same keys, different values
… HTML is unlikely the only place where such a file format would be used
… like CSS
felipe: in CSS you could add strings before or after an element
xfq: I think it could be incubated within this group
XML errata
[eemeli introduces the issue]
Murata: initially we tried to find all names for XML
… it's too difficult for the XML WG to study every character
… it's just not impossible
… I know some other committees in ISO did something similar
… but not very successful
… unless there's a very very strong reason to disallow them
… XML will allow them
… I dislike this decision
… but it's an sensible decision
martin: the errata from the 4th edition to the 5th edition should be documented somewhere
martin: XML parsers don't get changed very often
… this would essentially be backward-incompatible
… it would make some documents illegal
… also, Murata-san says the rule now is very, very open
Murata: I don't have to be familari with all languages around the world
… and the compatibility battle
eemeli: relatively high chance to use this character in localizable messages
martin: the issues of bidi formatting chars came up a few years ago in programming languages
… they're very scared
… they changed so that bidi formatting characters show up
… also for github
eemeli: you can have invisible characters in XML
… ALM is an invisible character
Plan for the 2025-11-14 meeting with WHATWG
https://
fantasai: I'm interested in w3c/
<gb> Issue 1819 Should dir=auto with no strong characters inherit directionality from parent or be ltr? (by w3cbot) [close?] [tracker] [s:html] [needs-attention] [i:bidi_text] [spec-type-issue] [alreq] [hlreq] [t:bidi_markup] [Agenda+I18N+WHATWG]
<gb> … [whatwg]
eemeli: I think the point 3 in whatwg/
<gb> Issue 10097 Should dir=auto with no strong characters inherit directionality from parent or be ltr? (by dbaron) [i18n-tracker] [i18n-alreq] [i18n-hlreq]
fantasai: I think we should consider using weakly-directional characters (point 2)
eemeli: my gut feeling is that it will occasionally make things right, but we will have more edge cases
fantasai: that makes sense to me
… I have a vague feeling that introducing inheritance is to @@3
… if it's empty then inherit the direction
… if it's not empty the default is ltr
eemeli: being a user who will never experience this I have no strong opinion except point 3
fantasai: I'm not familar with weakly-directional characters
… are they only LTR digits?
or do Arabic digits behave as LTR but resolve the paragraph to RTL or something?
eemeli: I think the Arabic-Indic numerals are weakly rtl
r12a: they're weakly ltr
fantasai: there's an advantage to be consistent with Unicode
… you could say that if the box is empty then inherit the direction
… if it contains content, then it's ltr
Proposed changes for WCAG 2.3
MM: [introduces himself]
MM: When WCAG 2.2 was created, there are some comments from CJK guys such as Kida-san, "is this only for western languages?"
… Answer was "no", but WCAG2.2 at that time was completely western-centric, and still is
… But some non-normative notes, and there was a formal objection
… There was an outstanding issue from Kida-san, which W3C didn't notice, and created PR. So there was an FO.
… But result was additional non-normative notes, like "this doesn't apply to non-Western languages"
… WCAG2.2 was submitted to ISO, and Japanese were interested in having an ISO standard
… AGWG said they would address the problem in WCAG3, and urged to not oppose the DIS
… And now we have an international standard for WCAG2.2
… So now it's time to discuss again. And we had a breakout session this morning.
MM: First I learned is WCAG is not HTML or EPUB only, but also PDF while it's on the Web.
… So I proposed this SC for Level A: When ruby is used, the association between the ruby base and its annotations must be programmatically determinable
… This applies to HTML and EPUB. But doesn't apply to PDF if accessibility 3 is not provided. 10 years ago no PDF publications provided accessibility tress for PDF, and 5 years ago Adobe started using such roles correctly; and now MSFT has also started.
… So some PDF documents satisfy this SC. Though many don't.
… Instead they have another line of text with small characters, which is completely inaccessible. Hence Level A.
MMM: I will demonstrate a DAISY reader, often used in Japan.
… Here we have some ruby text [in blue]. For some people, distinguishing ruby text from base text is challenging, so we need different colors.
… Foreground, background, ruby text color.
… Also we increased the size of the ruby
… THis is important for low-vision people.
… They often use non-square fonts.
… This reader can have full ruby, or no ruby, or ruby at jr. high school level
… It allows good controls based on demands of the user
… This is possible only because we have captured the relationships properly in the HTML.
florian: In addition to relation of base and ruby, you also have information about the level of difficulty
… Since the UA is able to add/remove ruby, it means there is some kind of standardized information about how difficult the ruby are
MM: This one has different documents, but we might want to standardize it
florian: Doing it in one document is easy. But doing it across multiple documents with a UA, is challenging
MM: Depends on the teaching schedule, so don't want to get into that discussion!
MM: This reader can change character spacing, line spacing, etc. in addition to font size.
MM: Anyway, having this SC is important.
… Some people in AGWG suggest it should be informative.
MM: Let me explain what happens if we don't have this SC. Ruby will be read aloud separately. It will be a complete mess to use text to speech.
… So lots of PDF documents don't have such ruby roles.
MM: Reason for Level A is because the document cannot be understood otherwise.
MM: Currently, we have ruby markup that can capture this information (though there is still some room for improvement).
… PDF was horrible and is better now. Tagged PDF can perserve the info.
… Hoping that accessibily trees can expose this information
MM: Because of comments and objections, htere were some non-normative ad-hoc notes added to other SCs, but this is not a solution.
… the abstract requirement is "relationship between elements should be captured"
florian: Agree that's too high level
MM: Some accessibilty requirements depend on the writing system or content language.
… goal is the same across all languages: text should be readable.
… But the appropriate line length, spacing, etc. may differ. And may have requirements specific to some writing system or other, e.g. ruby or bidi or whatever
MM: In my experience Japanese typographers know basically nothing about accessibility.
… probably true in other languages as well
… even when they are otherwise very knowledgeable
… when I learned from DAISY and explained to Kobayashi-sensei and Kobayashi-san, they didn't know beforehand
<gb> https://github.com/w3c/clreq/issues/718
MM: My hope is WCAG 2.3 will introduce natural language dependency.
… We say a requirement in general terms
… and if we have a language-specific requirement, we say which language it applies to
… But where do we stop? There are so many languages in the world.
… I hate idea that WCAG 2.3 covering "first-class languages" and other languages covered in non-normative documents as "second-class languages"
… This is what I explained in the breakout. i18nWG is supportive. Accessibility participants were mixed.
fantasai: what we do in the CSS spec
… we have a similar issue
… the behaviour of line breaking
… we have very little language or writing-system specific information about line breaking
… there's no specific requirements
… even our ref to UAX 14 is informative
… you don't have to follow it
… the normative req is that you have to break the lines according to the typographic tradition of the language
… for WCAG what they probably should do is the general req that the text should be readable
… and then to have the details of exactly what size/line height etc. in a separate document
MM: Now, we can provide very specific conditions, requirements, based on western languages.
… Partly because people in AGWG are western
… and partly because the EU governments want these requirements, and approved the text already
… This is what they said
… Why specify line height or length? Because even if somebody uses UA to achieve this layout, the contents shouldn't break.
… This is what they specify in WCAG.
… So it doesn't say what line height, just says even if someone tweaks the line height, the content shouldn't break.
fantasai: That's a reasonable requirement.
<Zakim> fantasai, you wanted to talk about abstract requirements and concrete guidelines, as in css-text
florian: I don't know exactly WCAG people work with this, but I suspect that when law and regulation requires a document, they tend to be very specific, and probably point to a dated version of WCAG.
… There is nothing in the W3C Process that says "when law references you, you cannot change".
… So we should change if we think we need a change.
… and the government can update their reference if they want to update their reference
MM: These people care a lot about backward-compatibility, meaning, if they produce a document that is WCAG-compliant against the latest spec, it is also conformat to older versions of WCAG.
… So they strongly argue that they cannot drop any requirements.
fantasai: is there a requirement that's problematic?
… or do we need to add more reqs?
MM: For example, paragraph separation is not common in Japan. It's not taught in schools. But WCAG requires that if you add more spacing between the paragraphs, and the layout breaks, that document is non-conformant.
fantasai: that seems reasonable
… in general, if you change the font size, line height, paragraph spacing, letter spacing, or any of these things
… if you translate it to German
… a well-constructed document will be able to accommodate some resonable amount of those changes
… CSSWG spent a very large proportion of the time as a WG to make such auto-sizing worked incorrectly
… fundamentally the web platform is designed to enable this
xfq: It's possible to do it this way, but authors don't always do it right.
MM: Since WCAG is referenced by regulations, needs to specify numbers.
Ruby Accessibility Note
MM: Latest ED is this, it covers a lot of cases.
https://
MM: This document says how documents containing ruby should be read aloud: ruby base, ruby annotation, or both
… Answer is "it depends"
… People want an answer! But the answer is "it depends".
… Or use AI. ;)
… Some analysis can detect whether a given annotation is for phonetics or not.
… In that case, you can tell by relying on some natural-language processing, whether it should be read aloud or not
… I woudl like to publish some version of this as a DNOTE in November.
… So I have asked for some reviews from experts.
… Biggest open issue is request for reliable mechanism
fantasai: That is outside the scope of a note, yes. :)
xfq: But some specification in the future could specify this.
florian: I agree. The solution is important, that's why we work on it. But this is a problem statement, you don't need a solution to publish a problem statement.
florian: Notes don't need to be finished to be published. So if you have imminent changes, you can make them first. but publish this month. it is already a useful document, and it's not good to refer to an editor's draft.
… so if we want to point people to it -- even if not finished -- it is best to be published.
… And then you can keep working on it and republish it.
xfq: You only need a resolution to publish within this group
florian: If we think anyone other than this group should look at it, then we should publish it.
… If it's so early that nobody outside this group should look at it, then it's too early.
… but otherwise we should publish it.
xfq: We should rename the shortname first, though.
Requirements for Japanese Text Layout
[bikeshedding]
<gb> Issue 66 rename repository and shortname into ruby-tts-reqs? (by himorin)
fantasai: so proposal is ruby-tts-reqs?
… alternatively ruby-speech-req?
Bobby: Maybe you can publish a Japanese version?
florian: I insist we don't wait for that. If someone wants to translate later that's fine.
Bert: -speech- is a good idea. TTS is also well-known but "speech" is easier to understand.
POLL: a) ruby-tts-reqs b) ruby-speech-reqs
POLL: a) ruby-tts-req(s) b) ruby-speech-req(s)
<florian> b
<Bert> b
b
a
<florian> murata: a
florian: Close. Let's defer to the editor.
fantasai: I don't care particularly but seems useful to follow example of other i18n specs?
xfq: Plural seems to be other WG documents.
RESOLUTION: Murata-san to pick a shortname in consideration of these points, though nobody cares too much which one.
xfq: Any objections to publishing this document as a First Draft Note?
… we can always publish later
RESOLUTION: Publish ruby-tts|speech-req(s) as FPDN
ACTION: xfq to rename the repo and shortname and publish this document as a first draft note
<gb> Created action #197
[thanks to Murata-san for writing this document!]
<Bert> I counted 87 W3C specs with a short name in *req and 34 with *reqs. But I didn't check how old or recent they are.
"Publish early, publish often!"
[css-text-decor] Control the line height / proximity of text containing emphasis marks
<gb> Issue 11257 [css-text-decor] Control the line height / proximity of text containing emphasis marks (by xfq) [css-text-decor-3] [css-text-decor-4] [i18n-needs-resolution] [i18n-jlreq] [i18n-clreq] [i18n-klreq] [i18n-mlreq]
https://
xfq: [introduces this issue]
Bobby: This happened in early stage of implementations
… similar issue in Chromium
… Only a few Japanese system fonts work well with emphasis marks to not expand the line height
<Bobby> https://
Bobby: Here I set the line height to 1.7
… but you can see that it's expanded to about 2
… I filed a bug, but couldn't find the problem
… I tried to see if it dpends on the codepoint
… Seems to depend on the font
<Zakim> fantasai, you wanted to comment on the spec
fantasai: for ruby, the impact of ruby on the text is supposed to be that half of the height of the ruby contributes to the line height
… half from the top line, half from the bottom line
… if the ruby fits within that space then it doesn't increase the height of the line
… if not, than it will @@4
… emphasis marks follow the same rule
… if you have a line height of 1.5 or higher there should be no issues
… I wonder if this implementation is making full height rather than half of it?
Bobby: or if the implementation is applying the line-height where it shouldn't?
<Bobby> https://
https://
fantasai: the dots are too far away from the characters
https://
fantasai: we should follow up on this
… I think we should treat this as an impl bug
<Bobby> https://
<Bobby> Same book on Firefox 144.02