Meeting minutes
Kevin: I'll do a quick intro to the problem, then pass over to Murata-san. Goal is to have discussion about the problem as it is, potential solutions, and find a way forward.
Slideset: https://
Kevin: Access for all is a key pillar
Kevin: So is internationalization. Led by Internationalization Activity, works with W3C WGs
Kevin: The overlap with accessibility is there are considerations to support reading disabilities and low vision. Focus on SC 1.4.8 Visual Presentation and 1.4.12 Text Spacing
Kevin: For 1.4.8, this is about visual presentation for blocks of text, requires a mechanism to be available to change a number of characteristics about the block of text, e.g. color, width, spacing
Kevin: For 1.4.12 about text spacing, there is no loss of functionality if these features are set for the text
… doesn't require that these features be there, but if you change the features to those, there is no loss of functionality
Kevin: If the presentation feature is not used within the language: nothing
Kevin: For users of those languages, this means people with reading disabilities are not supported
Kevin: There are requirements in development for WCAG 3 to address this. One is the foundational requirement: Readable Blocks of Text
… for the specified language, you need to meet at least these characteristics
… since we can't cover every language, we have a series of guard-rail languages representing a number of different orthographies
… try to align with the language closest to the orthography of the language you want to present
Kevin: We currently only have data for 4 of these characteristics in one language; we don't know what we're missing
… reminder that this is for WCAG 3, we're not looking to bring this particular solution back to WCAG 2 for various reasons
Kevin: There are several questions we need to explore and answer
… what needs to change in 1.4.8 and 1.4.12, what features matter, what values need to be used
… are there other SC that impact non-Latin scripts
… and can we avoid breaking backward compatibility? This is important because WCAG 2 is embedded in legislations, so breaking backcompat has consequences; we need to be careful how to approach
… now I'll pass over to Murata-san who has a possible approach
MURATA: I'm Murata Makoto, my family name is Murata. Long time member. Was member of original XML WG in 1997.
… recently involved in EPUB3
<Siri> Can share link to slides?
MURATA: since then involved in Japanese DAISY consortium
… now involved in @@ group which is a member of W3C
… for those who can't see the logo: it's a logo of Don Quixote (windmill included)
… here is an example of Ruby layout. First of all, you see the color is different.
… secondly, the size of this Ruby is bigger than what is commonly available in printed books. Low-vision users require bigger Ruby annotations for obvious reasons
… Why a different color? Because some users cannot distinguish Ruby base characters and Ruby annotations, and will mistake it for a single character
… Provides even more features. For some users, the annotations are harmful, so it is possible to hide them
… For others, additional annotations are available, so you can show or hide for e.g. many characters, or only difficult characters
… however, I mistakenly didn't say anything about Ruby in the context of WCAG, because I mistakenly thought that PDF was outside the scope of WCAG 2. So I only recently learned Ruby is in scope.
… Proposed SC 1.3.XX Ruby Annotations. When ruby is used, the association between the ruby base and its annotation(s) must be programmatically determinable.
… Level A, because if the base-annotation association is lost, the intended meaning cannot be understood. This is critical.
… Fortunately, if you use HTML or EPUB, the relationship is preserved by default.
… PDF ~10 years ago would often export ruby as just a smaller font, losing the connection to parent text
… Adobe has since addressed this in the PDF standard. Structured tags can represent the relationship, if you author with software that supports it
… Unfortunately, quality still varies. A lot of people have been very pessimistic about e.g. TTS in PDF documents containing ruby
… We have to make a difference
… Second proposal: reformulation of notes in two SCs, that were created in response to CJK feedback. They are non-normative, ad-hoc, and do not fix the underlying issues. They function as an alibi, not a solution.
… Intent: Some accessibility needs depend on the writing system. The goal (accessibility) is the same across languages.
… Details e.g. appropriate line length and spacing may differ.
… Need a way to express shared intent with distinct language-specific values.
… Proposal: Natural-Language-Dependent Requirements (1.3.x)
… SC stays unified; only specific parts vary by language. WCAG may reference external layout specs e.g. JLReq
… this makes WCAG work for all writing systems without splitting WCAG into pieces.
… I have written down complete proposals for each of these changes in the GitHub repository, for the purpose of this breakout session.
<shawn> proposals w3c/
MURATA: I don't think there's time to go into the full details in this session, but I wanted to cover the basic principles here. Thank you.
Kevin: Thank you Murata-san.
mbgower: Kevin, you had a slide earlier about other potential SCs with non-Latin languages. There are a couple I'd like to suggest: Reflow, and I wonder if any text alternative language is dependent
… Potentially goes all the way up to Page title. Wondering if anyone has considered/verified
… The other things in terms of that excellent presentation, there've been a few things on my mind.
… We have 4.1.2 Name, Role, Value, specific for UI components (operable things). I've been wondering if we should have that attribute for non-control components.
… That could get a little messy, but maybe something more refined than what's in 1.3.1 Information and Relationships.
<JJ> +1 to 4.1.2 variant for non-controls
mbgower: 1.3.1 is kind of the "kitchen sink" (everything gets put in there that isn't somewhere else), but I could see where you could have a situation for Ruby technology
… I hate how 3.1.4 Abbreviations is set up right now, it's this really prescriptive thing that says if you have an abbreviation, have a way of expanding the form or meaning
… related/overlap with 3.1.6 Pronunciation. Both are AAA. Wondering if this is getting close to the situation with kanji/kana
… There's a few things I'd like to hook these things on, I don't think they work in the AAA situation, but I think what Murata-san presented can work for more than just Japanese
<Zakim> mbgower, you wanted to say what about Reflow? Also, do any of the text alternative guidelines factor in? 1.1.1, 1.2.1-1.2.8?
addison: I'm the current co-chair of the Internationalization WG
… This is not the first time we've talked about this, either within Internationalization or with WCAG
… In our group we've discussed the approach Kevin showed, and we feel uncomfortable as not covering enough different languages and not providing a framework for further languages to be added in as we discover more needs
… maybe some values will work just as well across certain languages for a specific item but not all
… we want to push for having a sufficient framework in place, and then be able to connect the framework to things as we learn them
… like what Murata-san suggested in his presentation
… would not affect backwards compatibility, as the existing things don't know about it
… I don't have a solution baked, but I think the shape of the problem and how we approach it is important
<Zakim> JJ, you wanted to ask about ruby support on non-web ict / mobile apps
JJ: I'd like to ask about the support, if you know, for Ruby in non-web technologies, maybe also in mobile apps - how is that support? Would they be able to achieve the same things?
<Makoto> We already have a sufficient technique H62: Using the ruby element to meet SC 3.1.6 Pronunciation which is close to Murata-san's proposal.
JJ: would we be able to add new or update existing SCs to add any nuance?
Murata: I am writing a document about TTS support of Ruby, and major companies are interested in what I am writing
… On mobile devices, the characters are too small.
… There may be other ways of presenting, e.g. different colors, parenthesized notes
Bobby: [ Discusses character sets in Japanese and Chinese ]
… Ruby has been supported in HTML for decades; some details were only finalized as of HTML 5, so it's an ongoing system
… We've just started to see how to use assistive technology
<Zakim> alastairc, you wanted to ask about the difference between what works in a language system, and what is accessible.
<Bobby> Bopomofo Layout by HTML ruby sample https://
Murata: I know that Florian and fantasai are still trying to improve support of Ruby annotations
alastairc: When Kevin showed we had a table of languages with the ability to provide different values, one of the things we have generally held to is that the spec on its face needs to be testable.
… someone needs to be able to adjust the corresponding browsers in their browser
… each time we try to add something, it will require republications. We don't want to have to go 2.3, 2.4, ...
<addison> >> we might have per-language or per-script standards, e.g. 3.2-JP
alastairc: In WCAG 3 we wanted to get some baseline with reasonable coverage, and provide more specific documentation within informative docs
… that's one of the difficult things I see for integrating this both in WCAG 2 and 3
… We found a lot of information provided by the Internationalization TF in terms of what works in what writing systems, but not what's accessible across different writing systems, e.g. for people with low vision and other disabilities
… the values we established, at least on the English side of things, were intended to provide a reasonable amount of flexibility so that even if people adjust things, it's enough to work with Latin languages
… We haven't been able to do that for other languages, partly due to us not knowing where to look, so we have quite a bit of a gap there.
… Are there further accessibility issues with the visual aspect of Ruby? e.g. you mentioned they're quite hard to read on small screens. Are there equivalent accessibility features that it would be useful to have in the future for the visual display?
giacomo-petri: When we were talking about other criteria impacted, one of our clients in Japan were interested in using Contrast (Enhanced) because they feel that Japanese characters are more difficult to be read
… maybe that's something to think about
… Is it because of the reading level, or is it because symbols are difficult to perceive? Is it perceivable or understandable?
janina0: APA has been working to bring Augmentative and Alternative communication (AAC) that may be applicable to Ruby. We have no idea, whether it would be destructive in a CJK environment, is it testable, etc.?
r12a: We're worried about the guard-rail approach partly because it doesn't cover nearly the full range of types of languages we'd like to cover, partly because it covers certain types basically the same
… I think there are 2 things going on that we need to keep separate
… You have some guidelines that say you need to be able to increase the size of the font without breaking anything
… but there's another aspect that there are particular features which are important for readability of the text, e.g. justification
… in the Internationalization WG we are mostly concerned about how to capture that information. We don't think the current approach is sufficient
… what we've suggested before and would like to suggest again, is to have something similar to what Alastair was saying, and have some kind of non-normative registry or additional documentation with values for spacing, etc.
… also e.g. whether to require diacritics in Arabic
… that information would grow over time
… that might be a mechanism to move forward, as Alastair was saying
… We talked a lot about Ruby today. In Internationalization there are concerns that Ruby is sometimes over-adopted in cases it isn't designed for
… Ruby is designed specifically for CJK and perhaps Mongolian, and the features that are specified for the use of Ruby are specific to those languages
… so your question was whether Ruby can be used for other languages; well the first question is what do you want to use it for?
… e.g. there are other alternatives for e.g. pronunciation
… Ruby is not a linguistic glossing device
<alastairc> what's "glossing"?
r12a: there is no markup specifically for glossing at the moment. Ruby kind of does a kind of glossing, but it's very minimal and specifically designed for CJK
… So please don't assume that Ruby is the panacea for all of your problems
… Glossing = you will often see a piece of original text, with the phonetic transcription on another line, perhaps some semantic information on yet another line
<mbgower> Sounds like the same problem as trying to use ARIA to solve other problems such as OpenAI
r12a: Be clear about what you want to achieve by using Ruby
… Recap: we would like to suggest you develop this additional language/script-specific documentation that grows over time, and be careful jumping on the Ruby bandwagon (don't overuse)
<Zakim> Makoto, you wanted to say that SC 3.1.6 was added based on inputs from JIS
Makoto: On Japanese websites, we don't use vertical writing in general, but we do have vertical writing in ebooks.
… 3.1.6 in WCAG 2: the first version of the Japanese standard published in 2004, there was a section about how to use Ruby for kanji characters when needed
… I got involved in WCAG in 2005 to make sure it was included in 2.0
… at that time, it was looked at as a Japanese-specific issue, but there was concensus that if we could look at it in a wider scope, it could be used further for internationalization
… Also got sufficient technique H62, using ruby element to meet SC
… I think this is very close to the SC proposed by Murata-san in this meeting
… I'm also curious to know if other languages such as Chinese, Korean, Taiwanese, have the same or similar language-specific issues
MURATA: RE class of Ruby: is it only for phonetics? The short answer is no.
… e.g. Enemy having friend as ruby. There are extreme cases in manga, but also lots of examples in textbooks of describing background information.
… This is arguably an abuse, but this is the way it has been for a long time
… so it is hard to tell the common use of Ruby.
… for textbooks in high school it's not necessarily so cut and dry, and in manga/novels who knows
<addison> sometimes it has multiple uses at the same time, cf. double-sided ruby
MURATA: I have some motivation to separate language-dependent requirements into other documents. However, I can't live with first-class and second-class citizen languages
… where first-class is covered in normative document while second-class is relegated to informative. This is discrimination.
<Zakim> kevin, you wanted to distinguish between WCAG 3 approach and WCAG 2 needs
Kevin: We talked about the WCAG 3 approach, and I confess I introduced the first case. I was mostly hoping to focus on WCAG 2 in this conversation today.
… There's still room to tweak the WCAG 3 approach.
… I don't think we're looking to overuse/abuse Ruby for things it wasn't intended for
… The initial goal from Murata-san is how to resolve Ruby in PDF, since it's already part of the specification
<Zakim> alastairc, you wanted to ask whether the info is for readability for everyone, or for people with disabilities?
alastairc: There was talk about the readability aspect. My original question: is that readability for everyone, or specific values for people with disabilities?
… Kind of a joke in the WG: if it's rubbish for everyone, that's not our remit, our remit is improving things for people with disabilities
… so I really want to be clear about that question
… RE Murata-san's comments, if we didn't have this approach of including a few languages normatively (very happy to discuss which ones and adjust), we can't then include everything normatively, so then everything would be informative
… this would lead to a very generic normative requirement, which then leads to problems with testability
Bobby: About the complexity of han characters, it's more about the complexity of the font. In Japan, an article is composed by han characters and some kana. In other Asian languages the optical size is even smaller.
… I want to know if the optical size of the font is discussed in WCAG. We can adjust optical size in variable fonts now
addison: Alastair, I hear what you're saying, I think testability is important, and I think just having a big informative soup is not as helpful as we'd like.
… at the same time I think we struggle with looking at things, and thinking there could be requirements that might seem reasonable for Western European languages, that might be unreasonable for others.
… we would want a way to clearly state that those values do not apply to those other languages.
… we should also be able to denote which values do apply across the board
… and then there may be some requirements that only make sense for some languages, and may be completely inapplicable to Western European languages
… you could consider separate documents to collect this information. Unicode has CLDR to collect information about different locales; maybe we could use their inheritance model?
r12a: In internationalization we share the concern Murata-san has about first-class languages in the normative document. I guess we envisage that all of such information would be kept in separate documents
… you can still test for some things, even if they're not described in the normative document. Or do you only test things that are normatively described?
alastairc: Generally, yes
kevin: From a regulatory perspective, the normative text is all that the regulation references
r12a: You're always going to have that problem that you can only be normative for a small number of languages, and that starts to be problematic
<Zakim> mbgower, you wanted to say that WCAG currently does not prescribe font size; just ability to resize and manipulate
mbgower: Responding to Bobby's question, there are no requirements to specify text size, closest we get is assessment of size in context of contrast
… only other thing close to that is in 1.4.8 Visual Presentation
… In most conventions, there is an assumption of 20/20 vision that things are based on, e.g. traffic signals
… if the font size is so small that nobody can read it, it's not an accessibility problem
… figure out what size is good enough, then require it to be transformed by size and spacing
MURATA: There are lots of rendering techniques for Ruby for accessibility, e.g. widening the gap between base and annotations
<Zakim> alastairc, you wanted to comment on optical sizing and to also say that it would be fine to have requirement that doesn't apply to all
MURATA: these are not required in WCAG. What is required is the underying representation and rendering. This is what my SC entails.
alastairc: RE sizing, as Mike covered, there is an assumption that the default is readable, but people with disabilities will need to increase it
… RE addison, it's fine if we can do exclusions, it's when you get to large lists of differing attributes where it can get unwieldy
… we do have mechanisms for WCAG 3, e.g. assertions relying on third-party resources
… we don't have those options available in WCAG 2
<Zakim> shawn, you wanted to say there are approaches. and WCAG 2.
shawn: It's good to look at what some thoughts were on WCAG 3 and to get some guidance for that.
… I also want to help us, as we move forward, to keep in mind that we are eager to see what we can do in WCAG 2.
… Someone had said if it's not in the normative part of WCAG 3 then it's not in regulation, and that's not necessarily true. We're thinking of writing a policy document which can be more explicit about referencing additional resources
alastairc: to wrap up, this isn't the end of our conversation. The next chunk of time for AGWG at TPAC is looking at upcoming changes to WCAG 2
… we're going to try to take on board what Murata-san has presented. It would be helpful Kevin if you could grab a couple of people during the next break, as we do have some gaps
addison: Let's keep the conversation going, let's find ways to keep talking about it
alastairc: And we've got some movement on the WCAG side now, which we didn't before