Re: Internationalization Working Group Meeting Minutes - TPAC 2025

Here is a proposed rewrite of my comments in the XML errata session on Day
2.

Murata:

When the original XML WG created XML 1.0, the group attempted to define the
set of name characters completely and precisely. However, several Japanese
name characters were missing.

Later, similar requests came from speakers of other languages, and a more
systematic review was conducted. The problem is that it is extremely
difficult to examine every new character continuously added to Unicode and
to determine correctly which of them should be allowed as name characters.
ISO had a similar effort, but it was not successful. They were criticized:
“Why is this character included but not that one?”

After many twists and turns, the XML 1.0 Fifth Edition adopted a different
approach: as long as allowing a character would not cause a serious
problem, it should be permitted as a name character—even if it is not
strictly necessary.


Proposed changes for the WCAG 2.3 session on Day 2.


MM: When WCAG 2.2 was being developed, there was an outstanding issue
submitted by Kida-san, questioning whether a particular success
criterion applied only to Western languages. That issue remained
unresolved.

Nevertheless, the AG WG moved the specification forward toward
Proposed Recommendation (PR) without addressing that outstanding
issue.  As a result, DAISY filed a Formal Objection (FO).  The outcome
of that FO was the addition of some non-normative notes—essentially
ad-hoc remarks such as “this does not apply to non-Western
languages”—but the normative text remained unchanged.

WCAG 2.2 was then submitted to ISO, and Japan was interested in
obtaining an ISO standard. At that point, the AG WG leadership asked
to meet with me personally. They requested that I refrain from
opposing the DIS ballot, assuring me that the unresolved problem would
be addressed in WCAG 2.3.

Now that WCAG 2.2 has become an international standard, it is time to
resume the discussion.

MM: The first thing I learned recently is that WCAG applies not only to
HTML and EPUB, but also to PDF when it is 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 is always true for  HTML documents and EPUB publications. But it is
not always true
for PDF.  Many years ago, no PDF publications provided accessibility trees,
and 5(?) years ago Adobe started to create PDF documents contaning  ruby
roles in accessibility trees; and now MSFT has also started to create
similar PDF.
… 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 the proposed SC should be Level A.

Regards,

Makoto

2025年11月17日(月) 15:50 Fuqiao Xue <xfq@w3.org>:

> We don't have the Zoom summary for TPAC 2025, but we do have the meeting
> minutes, which are here:
>
> * https://www.w3.org/2025/11/09-i18n-minutes.html (Day 1)
> * https://www.w3.org/2025/11/11-i18n-minutes.html (Day 2)
> * https://www.w3.org/2025/11/14-apa-minutes.html (WHATWG, i18n, APA joint
> meeting)
>
>

-- 
Regards,
Makoto