Meeting minutes
<Rachael> zakim start meeeting
<hdv> Laura++
Introductions, announcements and new topics
Rachael: Is there anyone here who is new or in a new role?
… February 10th, at this meeting, ACT is going to be going over how to write ACT rules for WCAG 3 requirements.
… we will record ir but attend it you can.
WCAG 2.x WCAG 2 proposed changes (review by 9 February) https://lists.w3.org/Archives/Public/w3c-wai-gl/2026JanMar/0061.html
Rachael: we are working towards a pre-CFC step.
on the draft, uh, starting next Monday should get an email on it.
<alastairc> I would note that this issue w3c/
pl: gentle reminder the email went out pointing proposed changes. so now we're at the halfway point, you've got one more week to have a look at the issues and comment
Internationalization https://docs.google.com/presentation/d/1qeMPo8a9bQ9yBvk0Ph4YJ15hjyYD3wE61KHcMHtkUJA/edit?slide=id.p#slide=id.p
Slideset: https://
pl: where ideally looking for thumbs up. These will be, as merged next Monday, uh, after the meeting with AC for the, coordination.
kevin: What we are talking about is when WCAG 2 went to publication, about SCs 1.4.8 and 1.4.12, largely around text presentation metrics and Latin-based scripts. There is potentially a gap in terms of how we are supporting people with disabilities using languages like Arabic, CJK languages, etc.
kevin: In WCAG 3 the requirements are more broad; we have more requirements covering presentation of text and how text is adjusted.
… The solution in this case is slightly different. We've included a set of guardrail languages that seek to capture features from a range of different scripts, and then authors can follow metrics for those specific scripts.
… May be more accurate, but not as comprehensive
kevin: Guardrail languages were chosen based on 6 official UN languages, removed French and Spanish, then adding Hindi
kevin: If we learn more and find out more, then we would need to republish WCAG. There are a lot of challenges with republishing, not necessarily from the W3C Process perspective, but because WCAG is referenced directly or indirectly within many regulations, and may not get picked up there, thus losing the benefit
… second challenge is we don't necessarily know about metrics for other scripts. There's a lot of knowledge around general layout principles for different scripts, but they don't necessarily capture the needs of people with reading disabilities
… there may be additional provisions that they might require to be able to read effectively
… that is something this doesn't cover, this isn't looking to solve that problem, but what we're looking to explore is whether there's a way to add more information as we learn more, without the republication overhead
kevin: Requirements:
… Core REC track document that does not want to be republished,
… Ensure that language metrics are normative and therefore not easy to ignore
… Ensure required metrics are flexible enough to suit needs of specific languages/scripts
… Ideally maintain backward compatibility
kevin: Possible soilution: there is an approach within W3C Process that allows for registries - collections of values or other data
… collection of values doesn't help, because the set of metrics might actually vary between scripts
… however, you can also have a collection of references to other REC-track documents. So the registry could be a list of links to other documents.
kevin: Examples of what data entries must have to be included
kevin: Example of the registry itself, listing its entries, each including a reference to another public specification
kevin: Create a registry of links to REC track documents specifying text presentation requirements for specific scripts/languages (e.g. text presentation metrics for Latin script, or Japanese text)
alastairc: You're calling out REC-track docs, but presumably it doesn't have to be from W3C, it could be from other orgs?
kevin: Correct, so your entry requirements could specify whether it needs to be a W3C spec or is left open to other specifications
<alastairc> Presumably it doesn't have to be a W3C rec-track doc, it could be from other orgs?
kevin: What changes would you end up with?
… within WCAG 2, for 1.4.8 and 1.4.12, "specified in [REGISTRY]" is added
… creates a SC that does not require being chnaged, but references a registry which will provide the list of available languages, pointing to other REC-track documents or other standards documents
GreggVan: If we want these to be picked up in regulation/etc., other standards/regulations typically have something that you can't have a requirement that refers normatively to another document that is not also of the same stature.
… i.e. you can't say that you must do this according to this application note that someone wrote up themselves. They would have to submit it and it would have to go through review and standardization in order to be referenced normatively.
… So I love where you're going with this, but we can't overlook this.
kevin: What you can do is require in the registry document that it requires a normative document. We can specify that up-front.
Kevin: We want the metrics to be normative, because otherwise they won't be adopted in the same way, or can't be adopted in the same way.
kevin: Within WCAG 3, there are 2 levels to readable blocks of text, so what I've tried to do is have a registry entry requirement that 2 levels are defined, where one is enhanced
<kirkwood> +1 to Gregg
kevin: What you've got within the registry, is you've got to define what is required for referenced REC-track documents.
… you don't need to define it at a detailed level; can step back a little bit, e.g. rather than specifying that the document includes a value for inline margin, only that there are minimum and enhanced readability requirements.
GreggVan: You can't have anything in a standard or regulation that requires the use of a proprietary technology.
… You could use a registry to point to non-normative continuously-updated documents, but only if you use it only for best practices.
kevin: That might be solving a slightly different problem; I agree that you could use registries in that way equally if it's informative material
<GreggVan> NOTE: for Best Practice or Recommendations-- you COULD reference non-normative docs -- so that might be a great way to include that information in a standard - in a way that allows continual updating to current best practice.
<kirkwood> proprietary (or equivalent) … can be done
kevin: Started to think about the requirements and whether this addresses those. This is my thinking and is up for discussion.
… Core REC track document does not need to be republished as we learn more, as long as we're referencing the registry. The only thing we need to republish are the documents referenced by the registry, and the registry itself.
… Republishing the registry itself should be straightforward; republishing other documents would follow the standard W3C Process, but detaches this from the core specification.
… Ensure that language metrics are normative: achieved by requiring that the reference documents are also normative
… Flexibility of required metrics: specific metrics need not be specified, allowing for different metrics depending on script/language
… Backward compatibility: Sort of... If we are able to develop metrics for e.g. Japanese content, and that is added to the registry, then content that was previously exempt would now potentially fail?
<GN015> How can the author technically realize different metrics for different languages?
<CarrieH> does REC stand for Record?
<Rachael> Recommendation (normative W3C content)
<Zakim> alastairc, you wanted to comment on backwards compatibility, and likelihood of other orgs having something useful, and using informative docs (methods) per language/orthography
<julierawe> CarrieH In other words, this solution would mean we do *not* need to publish a new version of WCAG 3 every time specs for a new language are added to the registry that Kevin is proposing
<CarrieH> Thanks julierawe
alastairc: RE backwards compatibility, if it's for a language that hasn't been included yet, it might depend on the framing? I think the key would be not changing values in RECs that are already there.
… I would love it if organizations already have something useful that we could directly reference. I suspect it would be up to us to gather various things together and go through a process to add these documents.
… We could add either methods or some form of informative docs to say that rather than having to go off to another specification and work out which bits you actually need, you could have a method that grabs the values and puts them into an easy-to-read technique within our informative docs.
… I find that the registry approach kind of abstracts away the information I would need to implement it.
fantasai: I agree with this approach, I think it's very scalable. I think what I would recommend is in the place you are referencing the registry, to not simply reference the registry, but put a qualitative statement of what the requirement actually is: the registry would then be the specific implementation of that requirement for a particular language + script combination
… This improves your coverage and helps illustrate to authors of the referenced specs what you are trying to accomplish / what's needed.
kevin: I suppose one of the things I'm shying away from a little bit, and maybe this is not what you're suggesting, is specifying which parts need to be covered, as that may be dependent on the language or script. I was thinking maybe we could move that part into the registry-linked documents.
fantasai: I think there is enough commonality that you can write some kind of description. e.g. all scripts involve lines of text. They could be called out as examples of metrics.
<Ben_Tillyer> +1 to this
<Patrick_H_Lauke> +1
kevin: Sure, and that could be something worth exploring. I agree it would be really beneficial, I don't want to discount it, but also want to make sure the approach is realistic.
<Zakim> Makoto_U, you wanted to mention importance of normative text
<GN015> Currently, web pages are requested to still show the text if the user changes the spacing. Do we know request that the web page offers all spacing options?
<r12a> Some things are not generic: eg. ruby handling in Japanese/Chinese, word spacing in Thai, etc.
<Ben_Tillyer> +1
Makoto_U: Thank you so much for this consideration and discussion.
… I understand that it is very difficult to cover all languages in WCAG 3.
… In Japan, ISO standards must be adopted directly as Japanese national standards without any changes or any additional requirements.
… To address language-specific issues, it is essential to explicitly state something in the normative text, e.g. when WCAG 3 is adopted as a national standard, the standardization body can independently define values or additional criteria, or something like that.
… Even if something is written in a note or similar section, it is just informative. If it is informative, it is difficult for national standards to add something independently, or to add language-specific criteria.
<alastairc> This is part of the conundrum: the way WCAG gets used internationally. E.g. ISO strips out informative notes. I'm not sure if they would include the registry links?
<fantasai> registry links should be normative, for this purpose
Makoto_U: If the normative text explicitly permits defining unique numerical values or additional criteria, then the standardization body can address this as needed.
… I would like to have normative text which explicitly says any language can have language-specific criteria, or script-related requirements. It would leave flexibility for wider adoption of WCAG 3. So it is very important to have normative text in this point.
kevin: I think this approach allows for what Makoto is describing; maybe a topic for further discussion with Makoto.
<Zakim> GN, you wanted to ask how language dependent metrics are technically realized
<Patrick_H_Lauke> also, registry *content* may change in time. how would that gel with normative requirements
<alastairc> No, "mechanism" can be user-agent end, in which case the author requirement was to check it doesn't break
GN015: RE 1.4.8 wording, does this mean the web page needs to provide the possibility to change the spacing? In the past, if the user adjusted the spacing it would be readable, but the website did not provide means for doing this
kevin: I think 1.4.12 is what you're referring to, I think, which is, if the text is altered to meet any of these criteria, then there's no loss of functionality. 1.4.8 says the mechanism is available; 1.4.12 ensures that no loss of content or functionality occurs.
kevin: it doesn't specify who provides that mechanism, it's just saying, there's a mechanism available.
… The provision would be for the default script or language on the web page, so if you were working on e.g. a German website, you would follow the Latin script requirements. If you were an evaluator of a Chinese site, you would follow the requirements for the Chinese script. The burden is no greater.
<Patrick_H_Lauke> 1.4.12 always had an odd hand-wave ... it wasn't requiring mechanisms, but also never said how a user would achieve setting the spacing criteria, and what a failure would really look like ...
GN015: I'm thinking in terms of a representative of a software company that delivers software in more than 30 languages; this increases the test burden.
kevin: Sure, but the alternative is we have no provisions for anyone outside of Latin languages in how to make websites accessible
<Zakim> AWK, you wanted to ask if we've considered adding this sort of information into approved translations of the standard?
<alastairc> The testing wouldn't be per language, but per script/category. E.g. most european languages would come under one set of metrics.
AWK: Have we thought about adding this sort of information into WCAG-approved translations? There's clearly a process there, would that be an opportunity to visit that information. Maybe that would just provide a good time for the linked spec to get updated.
<jsahleen> If you support multiple languages, then you would need to examine every translation, right/
kevin: If the metrics are still embedded in WCAG though, an authorized translation wouldn't be referenced necessarily from the regulation. It would be the standard REC-track document, and the authorized translation isn't the same thing
AWK: Right, and certainly there won't be an ISO version of every translation. So that's where Makoto's comment sort of overcomes my thought. Just throwing it out there, even if there's a registry, maybe that is a checkbox that we make sure is checked before an authorized translation is approved, i.e. is the registry for the respective language updated before that authorized translation is processed?
kevin: Yes, that's an interesting consideration.
<alastairc> Plus the translations tend to take a while, and would probably translate whatever values were present?
Ben_Tillyer: Maybe I missed it, but have you put any thought into what languages can go into the registry, and what the approval process would look like? e.g. I know you brought up the WCAG 3 guardrail languages; in university settings there are even fictional languages like Klingon, for which various fonts exist and would need to be able to be made accessible.
kevin: Any languages could exist. Need to know what's your evidential basis for these readability metrics, and that may be a stumbling block for many of these languages.
<kirkwood> What about Urdu? https://
<Zakim> alastairc, you wanted to comment on multilingual readability people needed
alastairc: We really do need contacts of people who know about readability in different languages and scripts. As an only-English speaker, I really struggle trying to find readability criteria in other languages, because it's in other languages.
… It's this very small Venn diagram of people who understand readability and usability, and people who understand the intricacies about their own language.
Rachael: I expect if we decide to move forward with this approach, we would write a process document that would include any requirements for a document to be included in the registry.
Rachael: we would include the evidence-based info and any other additional information.
<Zakim> Rachael, you wanted to say we would want to specify a process for getting onto the registry
<kevin> +1 to needing more people with this knowledge
<jsahleen> +1 for process document
<Patrick_H_Lauke> (randomly ... do we need to always fall back on / mention "klingon" etc? there's enough non-fictional languages that we can discuss...)
<jsahleen> Urdu and Hindi
<Zakim> bbailey, you wanted to mention that Hindi has two common written forms
bbailey: An interesting example from Section 508: mentions that India and Pakistan have one spoken language, but two written forms -- and which to use is very politically sensitive. The state department used that as a reason to not provide captioning on their broadcasts.
fantasai: There are a number of languages for which scripts and languages are not 1:1; multiple scripts may be applicable to a single language or vice versa
kirkwood: We ran into issues with accessibility and Urdu, especially, in relation to non-ASCII characters
<bbailey> WCAG 2.0 translations: https://
r12a: +1 to what fantasai said, I think you need to be thinking in terms of locale descriptions rather than just plain language. That will get you around the problems with Hindustani, as you will have e.g. different codes for Hindi, Urdu, etc.
… You will probably need a process for engaging people to provide expert advice. The process might be something like, if you're providing advice to go into these registries, you need to give adequate information about your background, but then as part of the process, WCAG will need people who look into and verify the information. There are a lot of people out there with strong opnions that are not necessarily factually correct.
… Another aspect should be that if there are in-country government guidelines on readability, then those should come first, and should be reported on wherever possible.
… Need to think about how to engage these people, not just invite anyone who puts their hand up, need to understand what their expertise is and how we bring that expertise into the registry.
… I know it's hard enough to find people in the first place, and putting extra requirements on top is even more daunting. But verification is going to be really important to ensure factual information in the referenced specs.
Ben_Tillyer: When I worked at a large multinational bank, there was a big dicsussion on the lang attribute. We found it may be useful to form some kind of language and script combinations.
Ben_Tillyer: we found it very useful to learn a lot about BCP47.
kevin: I think the discussion's really good; need to find some way of going forward to better support different languages/scripts within WCAG; I think that's one of the key things we can get out of this
<alastairc> r12a - that sounds reasonable, also, we'd be asking for references to research or gov guidelines, which should help
<Ben_Tillyer> https://
<jsahleen> https://
<r12a> w3c has articles about how to use BCP47 language tags https://
<jsahleen> +1 for the registry approach. This seems like a reasonable path.
<jsahleen> ja-Latn vs. ja-Japn
<Ben_Tillyer> BCP47 covers language AND script
GN015: info shared for how to identify language, for language of page, and for screen reader support. We don't need to identify just the language, but also the script. We need clear guidance on how to identify the script
<alastairc> If we have the resources to get to that level, that would be a good problem to have
<shadi> +1 to AWK
AWK: We need to separate out what we are doing for WCAG 2 and WCAG 3 because it may impact the work that we need to do to get WCAG 3 out. The two criteria mentioned in the presentation. Maybe it's better to get it right in 3.0 and get it out sooner, rather than trying to update 2.x for that.
<alastairc> This should work for both I think? It's not duplicate work
Kevin: We have had formal objections regarding WCAG 2.2. lack of support for internationalization. Those are something that we need to address. When WCAG 2.2 was first published that was the decision that was progressed with. It was something we needed to move forward with. It does translated to WCAG 3.0, and for requirements for entry on the registry. So that's the background.
<GN015> Even is the script identified via BCP47, how are the metrics applied then? Currently, the user applies the metrics in CSS.
AWK: Did we make a commitment in addressing those formal recommendations that we would do a WCAG 2.3 to fix those?
<bbailey> 1.4.12 Text Spacing 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.
Kevin: We made a commitment that we would address the issue, and didn't specify a WCAG 2.3 or after, just that it would be addressed.
AWK: To clarify, we're going to address it in the future?
Rachael: We have to address it in WCAG 3.0
AWK: Where is it documented that we have to address it?
Kevin: Suspect it is somewhere, will dig into it.
<r12a> Should everyone on the call vote, or just WCAG members?
Rachael: Straw poll, start with WCAG3: Do you support defining internationalization in WCAG 3.0.
<alastairc> keep it specific for now
<janina> Is the registry independent of version? 2.3? 3? 4?
GreggVan: Consider saying non-Latin scripts and other topics and issues.
<janina> So a registry spec?
Rachael: Is the registry independent of version 2.3, 3, or 4 (for Janina)
<janina> Thinking that could be useful
Kevin: Depending on how you frame it , we handed text presentation and adjustability in two is different from the way we are handling it in 3. Do it would need some thinking around that. Yes, it could be written in a way to allow it to work the same in WCAG 2 or 3.
Rachael: Should be more specific for other areas.
<Ben_Tillyer> Was what I was going to say!
Rachael: Point is valid.
<bbailey> Closely related issue on WCAG2x GitHub repo: w3c/
<shadi> +1
<julierawe> +1
<ShawnT> +1
<Azlan> +1
<janina> +1
<Rachael> Do you support exploring the registry approach as a solution to diverse script support in WCAG 3? +1 if yes, -1 if no, 0 if neutral
<Bryan_Trogdon> +1
<Jennie_Delisi> +1
<fantasai> strong +1
<r12a> +1
<Makoto_U> +1
<BrianE> +1
Consider languages like Vietnamese that have complex diacritics. Asked about who should vote.
<Charu> +1
<GN015> -1
<jkatherman> +1
<alastairc> +1
<JeroenH> +1
<GreggVan> +1 to explore -- but carefully - keeping in mind what works legally in using registries (here and in other countries) for NORMATIVE (requirements) and for INFORMATIVE (recommendations and best practice)
<tayef> +1
<bbailey> +1
<julierawe> +1
<scott> +1
<jsahleen> +1
<giacomo-petri> +1
<AWK> +1
<laura> +1
<Ben_Tillyer> +1
<jtoles> +1
<maryjom> +1
<janina> +1
<Claire> +1
<Gez> +1
<joryc> +1
<LoriO> +1
Rachael: Started straw poll
<Detlev> +1
<Heather> +1
<Adam_Page> +1
<kirkwood> +1
<filippo-zorzi> +1
<LenB> +1
<stevef> +1
<alastairc> Is there an alternative?
<jsahleen> Must drop. Thank you all for addressing this, from i18n WG.
<janina> q: Is script same as font?
GN015: -1 vote due to test burden, script of ports, need some kind of script of page, script of part. And the user relying on it to be realized in the software. Where the requirement says up to a specific values, and we need only the maximum. For your script, the user can then set what they need. I do not see a solution, and it might cost more to execute.
Rachael: Wants to ensure that GN015's comments are captured.
RESOLUTION: We will explore the registry approach as a solution to diverse script support in WCAG 3 but will keep in mind potential test burden and concerns around open questions as we explore this option
Rachael: Passing, because it has support, but capturing the concerns.
<alastairc> janina - no, script as it latin text, japanese characters. I think it's acheived with unicode, but not related to fonts per-se.
<Rachael> Straw Poll: Do you support exploring the registry approach as a solution to diverse script support in WCAG 2? +1 if yes, -1 if no, 0 if neutral
<shadi> -1
<AWK> -1 as doing so will surely distract from the WG's ability to move WCAG 3.0 forward in a timely manner.
<Ben_Tillyer> +1
<julierawe> +1
<alastairc> +1, it's the same solution for both.
<stevef> +1
<LoriO> -1
<bbailey> 0
<GN015> -1
<janina> +1 if same solution
<Gez> 0
<Detlev> 0
<Heather> 0
<JeroenH> 0
<Claire> 0
<scott> 0
<ShawnT> 0
<hdv> 0
<LenB> +1
<Charu> 0
<Makoto_U> -1 focus on WCAG3
<tayef> +1
<jkatherman> 0
<r12a> 0
<laura> 0
<kevin> +1
<Azlan> 0
<giacomo-petri> +1
<jtoles> 0
<bbailey> 0 , +1 if same solution fits
<Rachael> +1
julierawe: Wants to understand GN015 comment. Wonder if he's helpful if there's a separate requirement if there's a language of the page. Would the testing burden seem a lot bigger with this proposal than it did in the past?
<Ben_Tillyer> GN015 - but what if, for one script, it is not line height at all?
GN015: If we have different metrics for different scripts it might be larger for other scripts. We don't know. I don't know if in Japanese it might be larger, and it needs to be tested for one language with one set of metrics. With different metrics for each language, each language would need to best tested independently.
<LoriO> +1 Shadi
shadi: GN015's comments are excellent, and as we explore WCAG 3, we need to think about the guardrails and possibilities of how to address it. Concerned about the rabbit hold of trying to shoehorn this solution in, and maybe creating problems elsewhere. Caution getting distracted from moving forward with WCAG 3. Seems to be over simplifying to think it's the same solution that will work for both.
<Zakim> alastairc, you wanted to comment on testing
Kenneth: Thinks that if there was a one-size-fits-all solution, we probably wouldn't have started down this road. Understanding is that this is coming from people who understand non-Latin language see this as a real problem.
alastairc: Consider those that have international language sites need to have testing. This definition would add on to that body of work with specific testing criteria.
<Zakim> Rachael, you wanted to say next steps on wcag 2
r12a: If you're going to continue to specify the requirement in terms of a maximum amount, is that maximum amount going to be sufficient for Thai and Tibetan? Because it's been set using Latin so far, and if we have a maximum that covers all languages, that would be possible, depending on the maximum definition.
<alastairc> r12a - it would be very helpful to have a set of languages/scripts we could consider MVP, we can't start with everything, but what would be reasonable coverage of different scripts.
Rachael: Going to try to pull it together on WCAG 2, we have to do something to address internationalization in WCAG 2 as part of the agreement. Understanding is that we can't handle it informative only for the internationalization portion.
<alastairc> We need an alternative, otherwise this is the option...
Rachael: If we must do something in WCAG 2, is this the right way forward or not? Wants to ask that question in a different way.
<r12a> alastaric, i think that if you go down the registry route the language-related information will probably grow organically, as information becomes available
<r12a> ie. as people contribute data
kevin: I can find the reference to the discussions around the WCAG 2.2 Formal Objection discussions. The FOs themselves are captured in https://
shadi: We have a commitment to work on WCAG 3. Mentions that it's not only the concern that have been raised. There's a direction, but not a solution that is ready to go. Constantly having to think back to WCAG 2 seems like a burden to getting a solution defined rather than move forward.
<bbailey> r12a -- do you happen to have a link to BCP47 (if that's the right reference) ?
stevef: Is there a requirement to fit internationalization in WCAG2? And what are the objections to doing what we have to?
<alastairc> We have a commitment to do *something*. The question is the something
<shadi> fully support doing something in WCAG 3
<kevin> w3c/
Kevin: Requirement to do it is TBD. Do we have a commitment? Yes. The formal objects when WCAG 2.2 was translated were centered around the support for non-Latin languages from a number of organizations who use non-Latin scripts that would benefit from accessibility.
<GN015> bbailey -- I only have this unofficial BCP47 language subtag lookup tool for searching the IANA registry: https://
<r12a> bbailey, try https://
Kevin: ...needs to search for the language of the commitment. How we do it to address WCAG 2 to try to think of a way forward.
<stevef> so if the WG made a commitment to fix in WCAG 2, there is no argument
Rachael: Regrouping: Kevin has an action to find all the references back to the commitment for this group. Asks for those with concerns to come up with alternative approaches. Thanks to Internationalization for attending today's meeting.
<r12a> thanks for the discussion ! bye
Rachael: Last call before shifting to next topic.
WCAG 3.0 Blockers to Developing https://docs.google.com/presentation/d/1JpwkA6dQJS2z5nbpGeVxH9lkWA9jiRNznyQUd_KpQt8/edit?usp=sharing
Rachael: Next topic is about the survey results for provisions that people were not comfortable with moving from exploratory to developing.
<Rachael> https://
Rachael: ... Sharing slides, links are included in the slides, posted separately.
<Rachael> survey results: https://
Rachael: [Slide 2]: Core and supplemental labels may be off. Current list of requirements are marked as exploratory and developing.
<Rachael> maturity label: https://
Rachael: Not all survey results answered the question at hand. Slide only include applicable comments. Three levels are exploratory, developing, and refining. Reviewed the definitions for each level specified on slide 2.
Rachael: Looking to move things from exploratory to developing. Reviewed discussion guidance on slide 3.
<alastairc> Speaker language identified (Developing): When more than one language is spoken in audio content, the language spoken by each speaker is identified in all media alternatives.
Rachael: What are the reasons for removing the provisions listed on slide 4.
<alastairc> Sounds identified (Developing): Sounds needed to understand the media are identified or described in captions and transcripts.
LoriO: Suggests for an explanation from those that opposed the provision.
<kirkwood> accessbile tooling may be language determinite
GreggVan: Seems like the list includes topics that are automatically detected. Provided thoughts on specific provisions concluding that the user should have tools that can be used on sites. Trying to figure out how these things are. Doesn't object to these, he's offering ideas that other people might have for them.
Rachael: Showed provision language on screen.
<Zakim> alastairc, you wanted to say that being automatable isn't a reason to remove. If authors don't need to do anything, great, but it is still a requirement.
AWK: Doesn't support removing them right now, as the subgroups may be working on them. Once the conformance model and what they mean, there's a deep level of detail that may be difficult to implement. But as long as we can establish a need for a benefit the experience for users, I don't think it's a reason to take them out.
<Makoto_U> +1 to AWK
<JeroenH> +1 to AWK and alastairc
alastairc: Don't think that if something being automatable, it doesn't mean it's a reason to take it out. It's still useful to have the provision.
Rachael: Will circle back with people to called these out to remove them.
<shadi> -1 to aggregating requirements
GreggVan: +1 to Alastair's call out. Also, every time we add another requirement to the guidelines we decrease the probability that people are going to follow them because they are going to get overwhelmed. We need to consolidate the requirements into less provisions.
<LoriO> +1 Rachael circle back idea
<alastairc> GreggVan - I'd like to follow up with you about that separately
<CarrieH> My two cents on nested clauses, I realize that this would be difficult to implement because we're assuming everyone can hire writers. But as someone that's autistic nested clauses does add to cognitive load
Rachael: Gregg's point of having less provisions has had many public discussions, and will need to circle back on that.
<CarrieH> I would have to stop, scroll around the sentence and then try to understand what the point it's trying to make here.
<AWK> Share Shadi's concerns with Gregg's "don't break SC into smaller items" approach.
Rachael: [Slide 5] Suggestions for removal reasons. Content of slide verbalized.
<alastairc> "A summary is available for long-form text content and: is identifiable visually and programmatically, uses concise sentences, and provides access to explanations of any uncommon words that are used in the summary."
Rachael: ...For 'Summaries available' asked the group if we needed to remove it.
<CarrieH> +1 to what John just sayd
jtoles: All for moving it to supplemental, but doesn't think it should be removed.
<kirkwood> Concerns about removal. Tool summaries are not a legal way to summarize
GreggVan: Keep it.
<kirkwood> keep it
GreggVan: Make a note of the definition of the term 'available'
Francis_Storr: Keep it, but move it to supplemental.
<Rachael> ac alastairc
<jtoles> +1 to better describing what "available" means in this context
<kirkwood> should be “author” summaries
<Zakim> alastairc, you wanted to comment on level chanfges and to comment on level changes
alastairc: Just on levels, it's good to go in at the level that the people who put this together. If people do have big concerns, they are more likely to voice them.
<CarrieH> Nested clauses: I struggle with that..
<janina> Uncommon words concerns me. Seems unnecessarily restricted--why not look up any word?
<CarrieH> I understand that non-native English speakers do this a lot
kirkwood: Concern about the summaries aspect. there's a big difference between author-approved summaries or summaries by the author of the technology. There's a big difference between the two.
<CarrieH> I think we shouldn't remove
Rachael: For 'No nested clauses,' does anyone think we need to remove it back to exploratory.
<janina> Agree with GV.
GreggVan: Thinks we need to move it back.
<scott> +1 gregg's comments
<hdv> +1 to Gregg, both on important idea and on best not a requirement in WCAG
<giacomo-petri> we do have best practices
<bbailey> I am all for keeping "summaries available" (because it is open ended). I have strongly preference that No Nested Clauses be Exploratory or Best Practice.
<alastairc> I think it could be adjusted, to something like "content can be read without nested clauses". It is currently supplemental, could be best-practice.
CarrieH: Personally struggles with nested clauses trying to figure out the meaning of sentences. Maybe people that are not native English speakers also struggle with this. Wanted to give voice to the purpose of this provision.
<GreggVan> +1 to this as best practice. Maybe also as supplemental if they are not in base - but problem if in base conformance
<laura> +1 to julie
julierawe: Notes this is a supplemental requirement (not core). Meant for organizations that have the resources to do this.
<GreggVan> +1 to rachael's statement - summary
Rachael: Recognizes that this provision is really important to COGA. Two options: keeping it supplemental opens up public comment. Exploratory hides it from public comment.
<janina> Would strongly support best practice. That would always make sense.
<alastairc> +1 to keep as supplemental, ok with best practice.
<CarrieH> +1 to keeping it where it is so we can receive more feedback but open to best practice
<Rachael> No nested clauses: exploratory, best practice, keep as supplemental
<giacomo-petri> best practice
<julierawe> +1
<Detlev> 0 not sure
<laura> +1 to keep as supplemental
<Heather> +1 keep for public comment
<julierawe> +1 to keeping as supplemental
<jtoles> +1 keep as supplemental
<LoriO> 0
<GreggVan> +1 to best and ok with supplemental - if supplementat not in base
<ShawnT> 0
<janina> +1 to best practice. Everyone can write better
<Adam_Page_> +1 to supplemental
<bbailey> soft +1 to keeping as is
<tayef> 0
<LenB> +1 supplemental
<Azlan> 0
<hdv> +1 to best practice, also ok with supplemental
<Charu> 0
<Claire> +1 to supplemental
<kirkwood> supplemental
<Ben_Tillyer> +1 supplemental
<Francis_Storr> +1 to supplemental
<CarrieH> +1 keeping it as supplemental (so we receive feedback) but open to best practice (restating)
<Gez> +1 supplemental
<scott> 0
<Makoto_U> 0
<jkatherman> +1 to supplemental
<tiffanyburtin> +1 supplemental
Rachael: Keep as supplemental, but will open an issue to consider for best practice.
Rachael: 'Captions consistent' - asked for group thoughts.
Makoto_U: Last three provisions are at early stages. Suggest keep last three as exploratory.
GreggVan: Supports
<Zakim> bbailey, you wanted to keep audio description available
<Francis_Storr> thoughts on "related productions" : w3c/
<alastairc> +1, would be good to get feedback on the eternal question of no-gaps!
Rachael: Captions consistent and Audio description volume adjustable to keep as exploratory
<kirkwood> we did live audio descriptions
<janina> Audio described opera has descriptions even sung content
<alastairc> Sounds like Gregg's concept of audio-desc is too narrow, or we need another term for this requirement
<alastairc> q/
<janina> AD not always in time slots with no dialog. That's not the only use case.
<GN015> I would like to point to the fact that nested clauses are sometimes a widespread and often convenient style in some languages. For example, German does kind of not work out without nested clauses.
<GN015> So, again, we need to be careful with internationalization considerations here.
<janina> GV is fixed on a gap, not always a req
<alastairc> It's one of those ones which is sometimes possible... thus supplemental or best-practice
<giacomo-petri> i was in queue :P
<bbailey> +1 to AWK point about sporting events and radio announcers !
<bbailey> I agree that scripted events (plays) are easier for AD
Discussion: Some difference of opinion about what live and audio descriptions mean. General consensus to keep as supplemental and continue to discuss