02:00:53 RRSAgent has joined #wcag2-backlog 02:00:58 logging to https://www.w3.org/2025/11/13-wcag2-backlog-irc 02:00:58 RRSAgent, make logs Public 02:00:59 please title this meeting ("meeting: ..."), alastairc 02:02:00 Daniel has joined #wcag2-backlog 02:02:04 giacomo-petri has joined #wcag2-backlog 02:02:07 kenneth has joined #wcag2-backlog 02:02:17 LenB has joined #wcag2-backlog 02:02:21 shawn has joined #wcag2-backlog 02:02:23 mehm81281 has joined #wcag2-backlog 02:02:25 Makoto_U has joined #wcag2-backlog 02:02:33 agenda+ Internationalisation proposals 02:02:35 present+ 02:02:35 present+ 02:02:45 present+ 02:02:45 mehm8128 has joined #wcag2-backlog 02:02:52 agenda+ Other priority (normative) updates 02:03:02 agenda+ Reviewing WCAG 3 after the next publication (early new year?) 02:03:08 agenda+ Standard Backlog meeting agenda 02:03:14 agenda? 02:03:22 kevin has joined #wcag2-backlog 02:03:26 Patrick_H_Lauke has joined #wcag2-backlog 02:03:40 present+ 02:03:44 present+ 02:03:46 scribe+ 02:03:46 mbgower has joined #wcag2-backlog 02:03:52 present+ 02:03:55 present+ 02:04:01 present+ 02:04:07 alastairc: There's going to be overlap between what we discussed Tuesday and today, but this will also be about who's going to take on particular issues. 02:04:10 MURATA has joined #wcag2-backlog 02:04:16 present+ 02:04:32 zakim, take up next item 02:04:32 agendum 1 -- Internationalisation proposals -- taken up [from alastairc] 02:04:54 JeroenH has joined #wcag2-backlog 02:05:11 Adam_Page has joined #wcag2-backlog 02:05:12 nigel has joined #wcag2-backlog 02:05:21 present+ 02:05:22 present+ 02:05:25 present+ Nigel_Megitt 02:06:07 mbgower: Suggest a sub-item for WCAG 3 - how to feed back to WCAG 3 from WCAG 2 open issues; how to scrutinize and triage our 500 issues and however many open PRs 02:06:11 present+ 02:06:31 alastairc: On Tues we had some discussions RE internationalization proposals and some other normative things 02:06:46 ... there was some discussion about how to handle backwards compatibility, not much came out of that other than taking it on a case-by-case basis 02:07:13 ... wasn't entirely sure whether it requires new SCs or can be handled in e.g. new techniques 02:07:36 ... can things be done editorially, or via errata, or via informative docs, can automatically be picked up by EN 301 549 02:07:47 ... but some people are convinced normative change is needed 02:08:05 ... Non-normative work can continue as it currently does right now in the backlog TF 02:08:39 ... RE whether or not to allow normative changes in a new version, there was desire to see a list of the planned changes 02:08:54 ... I think there was enough impetus from the i18n changes that we will have enough justification for a new version 02:09:08 ... maybe we can include some kind of list not in the charter but to the side of it 02:09:58 q+ to say I think trying to summarize state of SC, not solve, as first step 02:10:02 ... Examples of updates: i18n, contrast algorithm, making descriptions RE audio description and/or timing adjustable, remedy missing essential exceptions 02:10:48 mbgower: RE avenues for changes, I've been thinking we tend to get stuck on trying to solve the problem as we're talking about it, i.e. craft the wording that will resolve this 02:10:56 ... in some cases, just describing the state of the SC can be useful 02:11:13 ... e.g. reflow, it's easy to describe some of the problems 02:11:21 ... not an avenue of change, but rather an avenue of identification 02:11:42 ... my interpretation of what's happening with WCAG 3 was it is attempting to identify then revamp 02:11:57 ... it wouldn't be bad if we could potentially identify some of those things and identify what's wrong with them between now and when 3 comes out 02:12:09 ... with WCAG 2 we've been largely chasing what the SC is, rather than what can be done with it 02:12:35 ... if we can get agreement on what we want to have covered, then we can work on crafting how to cover it in normative language 02:12:47 ack mbgower 02:12:47 mbgower, you wanted to say I think trying to summarize state of SC, not solve, as first step 02:13:00 alastairc: I think maybe we talk about that within the scope of the ones we wanted to dig into today 02:13:56 ... RE internationalization, there was a proposal from Murata-san, for ruby annotations (i.e. the blue smaller text next to the larger black text) 02:14:20 ... there can be varying levels of complexity, can configure whether it is on/off or how much 02:14:45 ... generally HTML would be able to pass the requirement. Historically PDF has not been able to pass it as of 10 years ago, but now it can be done 02:15:22 MURATA: A lot of people in Japan think that if a PDF document contains ruby, it is not accessible. But now some PDF documents which have correct accessibility trees and ruby roles can be used for text-to-speech. But most PDFs with ruby cannot. 02:15:38 ... goal of this SC is to encourage the usage of correct mechanisms, and move away from print-only PDF which is not accessible 02:15:52 q+ 02:15:54 alastairc: My question to the group is, what is the best way to approach this issue? 02:16:00 ack giacomo-petri 02:16:26 giacomo-petri: As you mentioned previously, I'm not sure why it can't be covered by 1.3.1/1.3.2, it's true that it is optional, but also basically popups are treated as optional 02:16:47 ... you have to ensure that the info & relationship is clear (1.3.1), and maybe we have a paragraph in the Understanding document to clarify 02:17:10 q+ to say add a new issue on this in github 02:17:15 ... in meaningful sequence (1.3.2) maybe we explain that ruby cannot be read by itself, but needs to be read in meaningful sequence in context of the associated words 02:17:16 ack mbgower 02:17:16 mbgower, you wanted to say add a new issue on this in github 02:17:33 q+ Murata-san 02:17:42 MURATA has joined #wcag2-backlog 02:17:49 mbgower: I'm not suggesting kicking the can down the road, but I think the most logical way to pursue this is to create a new issue with the proposal, and then it goes through the TF process. If we're going to do this live on the call, that's fine, but this can be considered a draft 02:18:05 q+ 02:18:14 q+ 02:18:17 s/MURATA:/Murata-san:/ 02:18:28 ack MURATA 02:18:39 ack Murata-san 02:18:39 ack MURATA-san 02:19:06 Murata-san: I attended @@1 IG this morning; they use @@2 which has exactly the same problem 02:19:40 q+ on advantage of doing a technique + understanding 02:19:41 q+ to say this seems closer to 3.1.6 Pronunciation and 3.1.4 Abbreviations 02:19:44 ... @@3 has the same problem, and appears free from restrictions of testable requirements. These can be concretely imposed and implemented by software. 02:20:05 ... If this is only in the informative document, then this is not in the requirement, and is not a regulatory issue - not enforceable. 02:20:19 ack kenneth 02:20:25 q+ to say that techniques can be used to indicate conformance failure 02:20:28 +1 requirements should never be just in understanding/non-normative 02:20:35 ack me 02:20:35 alastairc, you wanted to comment on advantage of doing a technique + understanding 02:21:18 alastairc: There is an advantage to doing it in the Understanding document, in that it applies probably from WCAG 2.0 onwards. It is coming under something general, but it would have the same force, just depending on level (A, AA, AAA) 02:21:20 q+ to say that IMO the requirement seems already covered. If the reading sequence of ruby doesn't make sense it's already violating 1.3.2 02:21:47 ... because it's something that WCAG in general hasn't spoken about very much, this is something that could be done with techniques if we hang it under a A/AA SC 02:21:50 Ben_Till1 has joined #wcag2-backlog 02:21:50 ack mbgower 02:21:50 mbgower, you wanted to say this seems closer to 3.1.6 Pronunciation and 3.1.4 Abbreviations 02:21:52 ... it would be as enforceable as anything else there 02:21:53 present+ 02:22:22 mbgower: I would like to try restating the problem, to make sure I'm understanding it. I'm thinking it may be pronunciation or abbreviations 02:22:25 +1 to Technique being enforceable conformance failure 02:22:31 q- 02:22:31 if the technique only shows how the normative wording of the SC also applies/emerges in situations that were not obvious, then yes "just" doing a technique would be ok 02:22:47 MURATA has joined #wcag2-backlog 02:22:52 q+ 02:22:55 shiestyle has joined #wcag2-backlog 02:23:08 present+ 02:23:12 mbgower: [ distinguishes kanji / kana, and how the small blue characters are phonetic descriptions ] 02:23:29 q 02:23:31 q+ 02:23:42 ... it's providing pronunciation, roughly equivalent to an acronym or abbreviation? 02:24:10 I think there was a point that sometimes these characters can be abused to say other things, but that would be another type of SC. 02:24:11 +1 that adding clarification and specifics in understanding and techniques to A or AA SC(s) then applies for WCAG 2.1 and 2.2 (rather then waiting for WCAG 2.3 for a new SC) 02:24:15 Murata-san: I'm trying to write a technical note about TTS and ruby, and the internationalization WG agreed on a technical note. That note discusses the taxonomy of ruby, and phonetics is just one aspect 02:24:40 ... e.g. "enemy" having "friend" as ruby 02:24:46 ... and now Chinese people are mimicking this 02:25:00 alastairc: That sounds like people are essentially misusing it to say other things? 02:25:14 Murata-san: Yes, it could be considered an abuse, but it is extremely common 02:25:28 alastairc: So there could be a distinction between it being provided and accurate? 02:25:36 q- 02:25:53 https://www.w3.org/WAI/WCAG22/Understanding/pronunciation.html 02:25:54 Murata-san: There has been discussion over whether HTML should have another attribute to distinguish phonetic vs. other uses of ruby, but there will be tons of documents that do not have the new attribute 02:26:04 https://www.w3.org/WAI/WCAG22/Understanding/abbreviations 02:26:13 The language of both of those SC seem highly relevant to me, here. 02:26:14 q/ 02:26:15 q? 02:26:17 ... I am reluctant to introduce a new attribute. I'd like to see it solved by AI, but people suggest that it is not currently feasible with AI 02:26:47 alastairc: This is reminding me that in COGA, some people with cognitive disabilities would have a browser plugin to convert icons to text to help them understand 02:26:55 kevin: WAI-Adapt symbols 02:27:16 q+ to say a major shortcoming of is that it has no attributes 02:27:19 alastairc: I think that was hanging under Input purpose and identify purpose 02:27:23 ack MURATA 02:27:25 ack mbgower 02:27:25 mbgower, you wanted to say a major shortcoming of is that it has no attributes 02:27:33 present+ 02:27:35 Adam_Page has joined #wcag2-backlog 02:27:46 mbgower: I pasted in the links to abbreviations and pronunciations, can we look at the language of those? 02:28:28 ... the mechanism provided through the ruby interface is a mechanism to expand the abbreviation 02:28:37 q+ 02:28:55 ... pronunciation is about avoiding ambiguity 02:29:04 ... there's no requirement of programmatic association 02:29:32 ... that's kind of how I'm seeing the problem with English, and then it's much more specific in Japanese 02:29:34 q? 02:29:50 alastairc: I'm not convinced either of those would apply - they're not necessarily expanded forms, they're not necessarily pronunciation 02:30:09 ... certainly the proposal was more along the lines of programmatically determinable relationship 02:30:20 ack kenneth 02:30:23 ... the only other thing might be the level A technique, can't remember the number, under 2.0 that would apply to ISO versions 02:30:24 q+ to ask if we don't already have this in H62 02:30:26 scribe+ 02:30:29 scribe+ 02:30:39 scribe- 02:30:59 +1 02:31:02 Ken: I think usage of ruby is to clarify, although it has a pronunciation aspect 02:31:13 ... I don't see abbreviation fitting in here 02:31:19 q+ 02:31:19 Japanese ruby provide no info about accent. 02:31:25 scribe- 02:31:26 ack kevin 02:31:26 kevin, you wanted to ask if we don't already have this in H62 02:31:39 https://www.w3.org/WAI/WCAG21/Techniques/html/H62 02:31:41 To clarify, I wasn't saying that 1.3.6 and 1.3.8 cover this. I'm saying that 1.3.1 doesn't entirely fit 02:32:07 kevin: we've got Technique H62, which discusses usage of ruby element in HTML. It's not the same as abbreviation; the structure is different and creates an appropriate association. That's under pronunciation, so it doesn't necessarily cover relationships 02:32:12 ... it also doesn't talk about PDF as a technique 02:32:48 ... Given you can make a technique a formal conformance failure, as Alastair was alluding to, would it not be an approach to create a technique that talks about the technical aspects of ruby presentation in PDF, and have that within 1.3.1 Info and relationships 02:32:58 ... and then have a failure point, that if you don't have the proper association, then it is a failure 02:33:03 FYI: https://w3c.github.io/ruby-t2s-req/ 02:33:08 https://www.w3.org/WAI/WCAG22/Techniques/html/H62 02:33:11 ... you could go further and have an HTML failure under Info and relationships as well 02:33:31 ... I wonder if that allows us to effectively use the SC we've got, create clear conformance failure points using techniques, and highlight how those need to be done properly 02:33:36 q? 02:33:47 +1 I'm all for seeing if a hybrid approach like kevin is mentioning has merit. that's where i was trying to go 02:33:50 ... There could be something wrong in my relatively simple thinking, but I'm wondering if we can use the tools we already have available to achieve what we want? 02:33:51 ack giacomo-petri 02:33:57 alastairc: It could be, just nobody has tried that before 02:34:14 giacomo-petri: Echoing what Kevin said, I understand Murata-san's thought that having a SC will make everything clear 02:34:38 q+ 02:34:42 ... it can already be covered / failed under existing SC 02:34:46 +1 to that reading 02:35:05 Murata-san: Are you saying the Understanding document can clarify what is normative? 02:35:09 q+ to say that this information is only exposed through the user agent, though, right? This is not visible in a browser 02:35:19 kevin: It's not the understanding document, you can create a very specific failure technique to outline what fails within the normative material. 02:35:28 q+ 02:35:37 ack Makoto_U 02:35:38 ... so RE what you said earlier, that it's not clear it would be a normative failure, this would be making that clear, so this is a powerful tool to promote that sort of thing. 02:35:43 Murata-san: I didn't know that, thanks. 02:36:16 Makoto_U: RE SC 1.3.1 and 1.3.2 covering this issue, and Mike mentioning 3.1.4 and 3.1.6 being similar 02:36:27 q? 02:36:55 ... as I mentioned at the breakout session about non-latin scripts, in WCAG 2.0, Watanabe-san, I, and others, were Japanese representatives, we tried to get ruby covered in WCAG 2.0 as a means to read complex kanji characters 02:37:07 ... we made a proposal 02:37:28 q+ 02:37:39 ... 3.1.4 and 3.1.6 are at level AAA. Concern is it won't be enforceable / won't change the situation, as many regulators target AA 02:37:44 q+ to say will the katakana appear in a user agent? Is the ruby reader a browser or AT? 02:37:52 Murata-san: Japanese publishers even said AA is too much, they only wanted to commit to A 02:38:04 kevin: 1.3.1 is A, and this fits in 1.3.1, so it fits in level A 02:38:18 ... namely the part of making it programmatically related 02:38:26 ... it doesn't solve the problems of people misusing it and the quality is incorrect 02:38:34 ... but certainly the programmatic relationship can be level A 02:38:52 Murata-san: And you are saying we can pose a conformance requirement via a failure technique and it will be honored by implementations? Sounds reasonable to me 02:38:53 q+ on enforcement 02:39:04 ack murata 02:39:09 kevin: The whole thing follows through the TF process; I don't want to hijack Mike, Bruce, and Alastair 02:39:18 ... it's not breaking anything, we know it fits with all of the information, it's just providing clarification 02:39:19 ack mbgower 02:39:19 mbgower, you wanted to say that this information is only exposed through the user agent, though, right? This is not visible in a browser and to and to say will the katakana appear 02:39:20 q+ 02:39:22 ... in a user agent? Is the ruby reader a browser or AT? 02:39:33 mbgower: I want to see if I understand the kind of circular problem. 02:39:39 q+ 02:39:56 ... I do not believe that web browsers will display anything but the Kanji. Is the ruby reader considered AT? 02:39:56 q+ 02:40:12 q- 02:40:14 qq+ 02:40:43 so as initial action: create a technique under 1.3.1 (A) for programmatic association - provided that the ruby annotation IS visible in browser/user agent 02:40:47 ack Ben_Till1 02:40:50 ... if we think it's always there, we can put it under 1.3.1 02:41:20 Ben_Till1: One thing I hadn't seen this week was a code example, so just during this meeting I looked at the HTML spec, and put something together. Tried to make a PDF as well but didn't have enough time 02:42:29 q+ to also say that just because it isn't shown by default, it is authored, so it's like a pop-up being associated with it's trigger. 02:42:31 ... so I followed the Ruby HTML notation where we have base characters and smaller symbols. Need to zoom in on this example to show it well. 02:42:52 ... what I wanted to do is look in the accessibility tree. You can see that each character is in a ruby tag 02:43:16 q- 02:43:31 ack Ben_Till 02:43:31 Ben_Till, you wanted to react to mbgower 02:43:45 ... wanted to show this because it helped me get my head around it in HTML. I'll try to use Adobe DC to convert to PDF from HTML, and put a document together 02:43:51 Thanks, so the katakana is in there by default, so it seems to fall under 1.3.1, then. 02:44:09 ack alastairc 02:44:09 alastairc, you wanted to comment on enforcement and to also say that just because it isn't shown by default, it is authored, so it's like a pop-up being associated with it's 02:44:12 ... trigger. 02:44:16 alastairc: On Tuesday, AWK put an example of doing it in PDF 02:44:52 ... RE content enforcement, I wanted to mention that if we added a new failure technique to fail improperly-associated ruby techniques, that becomes as enforceable as anything else, but we don't do the enforcement, that would be up to other organizations 02:44:54 q+ 02:45:13 Link 1: codepen editor view https://codepen.io/benja11y/pen/MYyaapX Link 2: 'fulscreen' codepen view https://codepen.io/benja11y/full/MYyaapX Link 3: whatwg ruby element spec https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-ruby-element 02:45:36 ... RE Mike's comment on it not appearing by default, I don't think that's a problem, there are other similar situations for other technologies 02:45:39 ack murata 02:45:57 Murata-san: By default ruby is displayed. I'm not aware of PDF viewers that allow them to be hidden. In HTML it's up to the stylesheet. 02:46:26 ... For some people with visual disabilities, ruby is problematic and they want to hide them. Different users may always want it displayed because they have trouble reading kanji. 02:46:34 q+ to say I'm satisfied we can cover as a failure of 1.3.1. The additional considerations are another thing 02:46:34 ack kenneth 02:46:43 scribe+ 02:46:49 think there's a lot of different, interrelated aspects here (even going into UAAG, HTML) 02:47:11 q+ 02:47:14 q+ 02:47:16 Ken: Are people keeping track of all techniques? Do they review their sites accordingly? 02:47:18 ack mbgower 02:47:18 mbgower, you wanted to say I'm satisfied we can cover as a failure of 1.3.1. The additional considerations are another thing 02:47:20 scribe- 02:47:30 s/all techniques/all new techniques as they are added/ 02:47:39 mbgower: We're not capable of stopping the presses for anyone :) 02:47:58 ... some of the things Murata-san is talking about go beyond the programmatic association. I'd like to identify what those things are and make sure that each of them can fit into some part of this 02:48:07 ... if they can't, that's definitely something we want to tackle in WCAG 3 02:48:18 programmatic association, "accuracy" of information in the ruby annotations, how user agents/readers actually expose these (by default, as an option, etc) 02:48:20 q+ to say we have ways to make it happen :) 02:48:23 ack giacomo-petri 02:48:24 ... e.g. abilities to manipulate, maybe that's controlled by things like reflow or text spacing, but I'm not convinced it is 02:48:45 q+ 02:48:48 giacomo-petri: RE how to notify people about changes, perhaps we can add something to the Understanding document. Maybe we can add something about CJK languages clarifying the purpose and referencing relevant techniques 02:48:49 q- 02:49:02 +1 02:49:06 ... I strongly feel that people involved in accessibility topics should be monitoring the informative docs, because otherwise we are wasting time. 02:49:15 q+ to say maybe we should surface failure techniques for obviously 02:49:22 ack shawn 02:49:22 shawn, you wanted to say we have ways to make it happen :) 02:49:27 ... I think it's fair to say that, hey, take a look at the informative docs if you have doubts or are unsure, while evaluating site accessibility 02:49:37 shawn: We do have ways that we can share information and promote/push information 02:49:41 maybe we should collate a list of "changes made to non-normative documents" based on git logs to periodically push 02:49:52 ... whether it's this or other substantial updates, it would be good to use WAI announcements and messaging to push updates to the community 02:49:53 ack kevin 02:50:19 ... piggybacking off of Shawn, I don't think we should go looking for problems and things for us to do, our main job is to create the standard and make the details of what passes/fails as clear as possible 02:50:31 ... making sure the community knows about it can be up to myriad other people 02:50:37 ack mbgower 02:50:38 mbgower, you wanted to say maybe we should surface failure techniques for obviously 02:50:44 education and outreach... ;) 02:50:45 ... making a good standard is already hard enough :) 02:51:12 mbgower: RE kenneth, maybe one thing we need to think on is the importance of failure techniques. They're still informative, but they have a lot more weight than anything else, because you are actually showing a failure. 02:51:25 [ that's what I was gonna say, Patrick -- even without a WG, that's part of WAI work ] 02:51:29 ... they can't go into our errata, but maybe it makes sense for us to have a clearer way of surfacing new failure techniques especially. 02:51:37 q/ 02:51:38 q? 02:51:41 ... for one thing, they have a knock-on effect to ACT which I don't think the sufficient techniques do as much 02:51:47 ... maybe the co-facilitators can work on that 02:52:20 alastairc: Failure techniques are quite rare; there's not nearly as many because it's rarer to be able to say that in every single case it's a failure. 02:52:26 ... this could be one of the new rare failure techniques. 02:52:35 ... I'm getting the sense that everyone's on board with this being a reasonable approach 02:52:44 q+ to ask scribe stand-in for a few minutes 02:52:48 q+ 02:52:52 https://docs.google.com/presentation/d/1x8JncN-V_a5HRxGIl6neVta9eYBskrVKOJjyKV6j1mU/edit?slide=id.g39946c6cb53_0_12#slide=id.g39946c6cb53_0_12 02:52:54 ... can someone volunteer to get this in, and the slide is available if that helps 02:53:25 scribe+ 02:53:25 ack kenneth 02:53:25 kenneth, you wanted to ask scribe stand-in for a few minutes 02:53:27 ack mbgower 02:53:38 Mike: I'll open the issue 02:53:51 ... I'll get your id Murata san I'll assign you to it 02:54:03 ... Ad these comments to the existing issue and we'll open additional ones 02:54:19 Murata: I'll have to check, but I'll add back if needed 02:54:26 [ Shawn points mbgower to https://github.com/w3c/tpac2025-breakouts/issues/38#issuecomment-3506486553 ] 02:55:15 Subtopic: Text spacing 02:55:28 Alastair: Discussion on Tuesday morning 02:55:39 ... Murata was proposing informative. But we may end up needing something normative 02:56:15 ... For same text spacing at the moment there have exception that if it doesn't apply to that script there is no reqiurement 02:56:16 https://www.w3.org/TR/WCAG22/#text-spacing 02:56:26 ... NOt optimal, because there might be different properties for which it applies 02:56:32 "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. 02:56:45 ... This is mainly to make it testable 02:57:03 ... We can't clarify the script type without inserting a big table 02:57:23 (this SC is a good example of a ... well-meaning, but badly written - arguably - SC) 02:57:38 ... In WCAG3 we break these out, we have five specific languges 02:58:12 I have created a brief issue to capture the ruby issue. I can add in additional information in the description https://github.com/w3c/wcag/issues/4746 02:58:21 ... The other question -- These shouldn't be just the baseline of how scripts should be laid out 02:58:31 ... It's also about how to specify boundaries 02:58:40 q+ to volunteer to pick scribing back up 02:58:50 q? 02:58:52 scribe- 02:58:52 ack kenneth 02:58:52 kenneth, you wanted to volunteer to pick scribing back up 02:58:55 +1 accessibility recommendations (the minimum that a user can modify things to) rather than baseline recommendations 02:59:20 alastairc: Is that a reasonable summary, that you were looking for some informative changes to expand on the SC? 02:59:41 Murata-san: Ideally in the main document, there should be a mechanism for introducing different requirements depending on the natural language used 03:00:08 changing this fundamentally to include different languages NORMATIVELY will be a big change 03:00:12 ... I tried to write down such a thing not using an external registry; but then of course the main document would have to include a lot of restrictions, each value for each language, and the result can become messy, but it is usable 03:00:34 though if for english/latin languages the values are the same as the current metrics, at least it'd be backwards-compatible 03:00:37 s/languges/languages/ 03:00:38 ... that is one possibility. Another possibility is to introduce an external registry, and from that we invoke different normative documents depending on the value 03:00:55 ... this in theory works nice, but in many cases, registries fail in certain standardization. People don't add so many entries in registries, and very often stop maintaining them. 03:01:15 q+ 03:01:27 ... so while in theory registries are good, in practice they don't work very well. I know W3C has their own strict procedure for creating registries; creating/maintaining is not easy 03:01:39 ... so registries come across as discouraged 03:02:23 kevin: I think on paper, a registry is a good mechanism to address this problem. I don't know enough about how they've been used in W3C in the past or now, to work out whether or not that is a good way, or may have the same problems as we've seen in ISO. 03:02:38 ... one advantage of a registry, is if we start populating a registry for WCAG 2, it's equally applicable for WCAG 3. 03:02:51 ack alastairc 03:02:52 ... I will look into it a bit more. 03:03:13 alastairc: I think there's 2 problems. One is this mechanism that we have a whole plethora of requirements depending on language/script 03:03:29 s/reqiurement/requirement/ 03:03:36 ... the second problem is actually having people to fill in the values. It's not only people who are experts in the language, it's that and knowing what values will be appropriate for accessibility purpose. 03:03:38 q+ 03:04:02 ack giacomo-petri 03:04:07 ... having the necessary research is very helpful; but appropriate values for each language are likely written _in_ that language 03:04:31 giacomo-petri: If we have that external registry, is the goal to link it from the normative document? Because if we link it from the Understanding, we still have the same problem 03:04:43 what happens if the registry changes? 03:04:48 alastairc: I think it will require a normative change. Could be "if these values don't apply, then check the registry" 03:05:17 ... RE what if the registry changes: I thought registries were essentially normative? So it should be the same as referencing another normative spec 03:05:19 q+ 03:05:19 q+ 03:05:30 ack nigel 03:05:55 [ info on W3C registry https://www.w3.org/standards/types/#x3-w3c-registry-track ] 03:06:11 nigel: I've done some work on registries. Registry content is not allowed to have normative @@1 03:06:24 Murata-san: Registry is flexible, but can be a backdoor 03:06:28 s/@@1/semantics/ 03:06:48 q+ 03:06:50 Murata-san: The whole point of introducing a registry would be to introduce normative semantics 03:06:55 ack kenneth 03:06:57 scribe+ 03:07:27 agree that a registry itself may not contain normative semantics, but if the normative spec points to the registry and "blesses" it by reference.... 03:07:30 ack Ben_Till 03:07:32 Ken: There seem to be a distinction between first and second class 03:07:35 scribe- 03:07:53 https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html#resources 03:07:57 Ben_Till1: McLeash study involving 480 languages and multiple scripts; I haven't read the study, but am wondering if anyone has, and knows what they say about CJK languages? 03:08:06 https://www.geonames.de/languages.html#j 03:08:09 MURATA has joined #wcag2-backlog 03:08:12 q+ 03:08:18 ack shawn 03:08:31 s/There seem to be a distinction between first and second class/Re-iterating a point from Murata-san during the breakout about having select "first-class" language values in spec creates a "second-class" distinction for others in the registry/ 03:08:33 "Testing the following pages with the maximum spacing adjustments allowed by 03:08:35 the SC showed no adverse effects for the roughly 480 languages and scripts 03:08:37 y 03:08:47 shawn: I seem to recall something in the low vision task force, that may be useful. I'll dig it up 03:09:13 alastairc: We've still got 2 issues - how to insert it, and how to get the information that would go into such an external link 03:09:14 The Process §6.5.5 and §6.5.6 https://www.w3.org/TR/ttml-imsc1.2/ make clear that: Registries document values, they do not define any architectural or interoperability requirements related to those values. 03:09:40 https://github.com/w3c/wcag/issues/4263 03:09:52 s|https://www.w3.org/TR/ttml-imsc1.2/|https://www.w3.org/policies/process/#reg-ref-specifications 03:10:10 ... If no one has any other ideas, I think we've got research to do on registries 03:10:22 and "and must not define any requirements on implementations." 03:10:23 q+ 03:10:25 ... Murata-san, if you or anyone knows where we can get the information on increased accessibility values, that would also be of interest 03:10:29 point of order: from my understanding, the mcleish study referenced did NOT cover the "480 different languages". at least the abstract for that study does not seem to suggest that 03:10:53 shawn: That seems like a bit of chicken-and-egg in a good way - if we provide the framework of how we provide the information, then it makes it clear what we're looking for, and may encourage people to help dig up the data we need 03:10:57 ack shawn 03:11:30 alastairc: We've got a few things that I could find for normative updates 03:12:15 ... I found 5 (in Slide 8) that definitely seem to need some kind of normative update, due to affecting interpratation, or relating to internationalization 03:12:25 ... can the group think of anything else? 03:12:28 q+ 03:12:43 scribe+ 03:12:58 Ken: This may require going through the remaining open issue to decide 03:13:00 scribe- 03:13:24 q+ 03:13:31 alastairc: I think there are very few that are labeled Normative, though we may have put some off and said we're not changing it. This may be an opportunity to re-tag some things as Normative, if it's something that could be improved or clarified 03:13:31 ack kenneth 03:13:38 Thanks Patrick_H_Lauke - study performed, then testing (by Jim Allan?) followed 03:13:42 ack Patrick_H_Lauke 03:13:46 ... we're not looking to add new requirements, that would go to WCAG 3. But if it's a clarification on existing, that's what we're looking for. 03:14:18 Patrick_H_Lauke: One of the more pervasive problems, there's a few instances where the SC hand-waves things, "something something clearly labeled as such", and never specifies what "clearly" actually means 03:14:35 q+ to say contrast minimum has some need for qualification (scrolling effect) 03:15:03