– DRAFT –
AGWG Teleconference

<shadi> present

<kevin> https://w3c.github.io/scribe2/scribedoc.html

Announcements & Introductions

Internationalization approach https://docs.google.com/presentation/d/1qeMPo8a9bQ9yBvk0Ph4YJ15hjyYD3wE61KHcMHtkUJA/edit?slide=id.p#slide=id.p alastairc]

alastairc: Next week we'll be hosting an onboarding session for new members and those who would like a refresher. It will happen on this call 30 minutes before meeting start.

Slideset: https://docs.google.com/presentation/d/1qeMPo8a9bQ9yBvk0Ph4YJ15hjyYD3wE61KHcMHtkUJA/edit?slide=id.p#slide=id.p and archived PDF copy

alastairc: Kevin will walk us through these slides starting on slide 17.

[Slide 17]

<MURATA> I would like to make a brief statement. It will take about three minutes.

<alastairc> MURATA - we can do that and the end of this fairly short pressentation, please use q+

[Slide 19]

kevin: little background - existing draft is showing 5 gaurdrail languages and we've gotten feedback that this approach needs to change.

[Slide 20]

<wendyreid> s/alastairc /alastairc: /g

<wendyreid> s/kevin /kevin:/g

kevin: [slide 21]

<MURATA> I suggested following the +Lreq family of specs from I18N

kevin: possible solutions slide

kevin: separate publications, we don't have to republish WCAG3 every time a language spec is updated.

kevin: republish when more is know slide

kevin: next steps slide

MURATA: +Lreq family of specs from I18N could be a source for WCAG 3, I don't trust the registry approach

GreggVan: which appraoch was preferred by MURATA?

<MURATA> Separate specs: One for Latin.

GreggVan: one standard could refer to another standard if they exist when you make the reference.

<Patrick_H_Lauke> multi-language sites ...

GreggVan: if we put them all in WCAG does it mean that WCAG would then need to match / meet all the standards for all the languages (even if my site is published only in English)?
… if we republish new version numbers are added. Which means everyone will have to work on meeting each new langauge requirement for each version
… how many provisions deal with layout?

<Patrick_H_Lauke> i sense a "can you make a list of these problems" (reminded of the same request about WCAG 2.x)

<MURATA> Question for curiosity: have people had a look at *Lreq specs from I18N?

<Zakim> Patrick_H_Lauke, you wanted to talk about the 'makes it difficult for ISO' aspect

stevef: Kevin mentioned publishing a document for each language. Instead of having multiple documents why not have one document that is referenced by the main WCAG document?

<nattarnoff> If we do additional releases to 2.x, we should do them in bulk batches and limit the number of possible releases before WCAG 3.

<alastairc> nattarnoff - this is a WCAG 3 topic only

<MURATA> It is extremely important.

Patrick_H_Lauke: how important or curcial is this? we're having problems with WCAG 2.2 being copied / included in ISO. ISO is good for technical specs but breaks down a bit when you have something that is more of an 'it depends' scenario.

<kevin> Short answer Patrick, is yes

<nattarnoff> Thanks for the clarity alastairc. might be mixing working groups.

<Charles> answering MURATA, i was not familiar with Lreq specs

<Zakim> alastairc, you wanted to comment on scoping the requirements to the language that the site publishes in. and to comment on the provisions that would be affected

<MURATA> JLreq, CLreq, KLreq, ILreq, HLreq, ..... There are many.

alastairc: re: passing all the language requirements - the language used to create the site would be the one that should pass. If the user is using a translation tool that is beyond the ability of the author.

<Patrick_H_Lauke> (incidentally, Murata-san ... I'd be interested to know if there's more specific things in 2.x - that are not PDF-related - that we should be looking at in the backlog)

<MURATA> True.

kevin: re: ISO - incredibly important since there are some countries cannot reference any standards beyond ISO.

<MURATA> BTW, I am the chair elect of SC34.

kevin: re: can we publish all in one document? This would still be a lot of work and effectively forcing someone to meet WCAG and all the text metrics.

<Patrick_H_Lauke> assuming that for a multi-language site/product you'd then need to conform to more than one language module

<MURATA> *Lreq

kevin: re: relative CSS learning - <missed Kevin's point here>

<MURATA> But they are about requirements.

kevin: re: is someone know how we could do this, we'd like to hear how you can reference two documents effective.
… - Lreq doesn't have a relationship to another document. So, we'd need to work out how we'd relate multiple documents with a conformance or relationship approach

<Patrick_H_Lauke> Gregg text direction, text spacing metrics (e.g. some languages don't rely on things like line height, paragraph spacing...), etc

GreggVan: I'm not sure how important are the language requirements? can we take our language provisions and make separate standards and have countries figure out which combinations make sense for them?

<Patrick_H_Lauke> how critical they are: simplest case, you have normative requirements that are simply irrelevant for a particular script/language. worst case you end up with normatively requiring things that are effectively counterproductive / make things worse for a particular script/language

<alastairc> I think Gregg meant: If the provision isn't critical, drop it.

<Patrick_H_Lauke> LVTF

<alastairc> Low vision and some cognitive

kevin: example - letter spacing and word spacing differs by language and we'd need them to adapt based on the language. People with reading related disabilities could be severaly impacted by not delivering provisions addressing this.
… this is largely about script use and not 'language'. Just being specific to call this out.

<bbailey> If anyone hasn't looked: https://www.w3.org/WAI/standards-guidelines/wcag/translations/

<kevin> That then means that the metric to be tested against wouldn't be normative

<Patrick_H_Lauke> having normative part that then relies on non-normative makes it a constantly moving target

Matt_King: wondering if there's a third option; have a core WCAG provision that references an informative doc that is structured like our ARIA document so that we don't need to update WCAG as often as we think. If someone meets the requirements of the informative doc then someone could meet the provision.

alastairc: we would need the informative doc to have the same rigor and diligence as the normative doc.

Matt_King: we had the same conversation and worked through a method to do that.

<Patrick_H_Lauke> think (correct me if i'm wrong) ARIA is able to do it because it's not trying/isn't (?) ISO standard /referenced directly by legislation/insist on a compliance model

<Patrick_H_Lauke> that is the corner that WCAG paints itself into

MURATA: requirement documents can be written using multiple documents. It might be possible to learn from the CSS and I18N group's works.

<MURATA> Don't understand.

alastairc: not sure what we can learn there - because we are focused on readability metrics.

<MURATA> Characters, words, sentences.... They are language-dependent.

<HaTheo> FWIW, I owned fonts and text rendering as part of Office for a few years. I also have a strong background in reading and legibility, as I frequently worked with a research team focused on these areas. I am happy to be in these conversations and work with folks/point people to the right researchers.

<HaTheo> Also what Gregg is saying is correct...

<Charles> metrics = properties? or metrics = usage?

<MURATA> Why is WCAG sometimes very abstract (and non-testable) and sometimes very specific (and not languge-neutral)?

GreggVan: there isn't a standard spacing metric and then there are a variety of needs for users (some preferring x metric vs another wanting y metric). We can't in advance have a page that controls every detail users want, these are user agent functions. We should write this so that the the agent isn't prevented from meeting the users need by an
… author's coding technique.

GreggVan: I think we should ensure that pages can be adapted by their agents based on their preferences and needs.

Ben_Tillyer: do we have examples of how other standards have solved this I18n challenge? have we explored complimenting provisions with assertions? if the group came to the concusion that the providion is non-critical but we have other provisions that are critical (and closely related) - would we remove some of them and only have a latin-based
… document?

<kevin> https://www.w3.org/TR/WCAG22/#text-spacing

kevin: this provision specifies latin language metrics. how do we provide metrics for non-latin scripts?

<MURATA> Metrics are not the only.

kevin: I am not aware of specifications that reference other specifications. WOuld like to hear of them if we have them?

<Zakim> alastairc, you wanted to comment on user-agent aspect, and how we came to metrics on WCAG 2.1

kevin: could we shift to an assertion? I am not sure how we'd do that.

<Patrick_H_Lauke> the provisions are wayne dick rooted :)

<MURATA> 0q

alastairc: in WCAG 2.1 this came from research around font type faces, working out a normal distribution based on a certain range. This assumpton is currently not valid anymore, partially because of how Shadow DOM and because we no longer want to assume there's a user agent

<Jon_Avila> WCAG to non-web ICT addresses no stylesheet technology for 1.4.12

GreggVan: we're talking about stylesheets here, but because we want to be more generic than web pages, the internationalisation aspect is more tricky

<Patrick_H_Lauke> style ... visual layout ...

<alastairc> Jon_Avila - what was the approach, ignore that?

GreggVan: should we remove the ones we have, if we can't figure out how to internationalise?

<Patrick_H_Lauke> bbailey possibly 1.410 reflow , 1.4.4 resize text ...

GreggVan: we need to be equal to the extent we possibly can, never mind languages we or linguists don't know about, but otherwise, we need to make sure it works with all languages

GreggVan: lastly, if things are based on font spacing… people need to be able to space the letters out, more than any font is going to create as a natural font spacing

GreggVan: we need to think about the general problem of spacing out words and letters independently

GreggVan: though that's a UA thing

<Patrick_H_Lauke> Gregg letter-spacing is already part of 1.4.12

<Jon_Avila> but up to what values?

<Zakim> Rachael, you wanted to say framework for other languages so we can extend but we need research

<Patrick_H_Lauke> and letter-spacing is what causes some problems for scripts

<Jon_Avila> Currently 1.4.12 does cover spacing for characters, words, paragraphs, etc. and not fonts

<Patrick_H_Lauke> where introducing/forcing spacing can change meaning/remove meaning

Rachael: following up on what Gregg said… chair hat off… we should build a framework for other languages than English, but cannot possibly cover every single language out there. There are community dependencies, we're putting out a call for help / research

alastairc: if folks have other ideas, please reach out to kevin and/or chairs

GreggVan: you don't have to be a member of this community to contribute, we often include experts from outside. If you know of people who have nothing to do with WCAG but are great linguists… and have them contribute (without forcing them to also contribute to WCAG or politics)

<Rachael> +1 to inviting experts for specific contributions but we can't invent research out of nowhere

GreggVan: there exist scientists who really know this stuff well. If you know of such folks, find them and we can increase our understanding immensely.

alastairc: to some extent we have already

alastairc: and we're specifically interested in readability metrics for people with disabilities

kevin: yes we really want to talk to folks if we can find them

kevin: we have some leads in the Arabic speaking world… also hoping Murata-san can provide us with info re Japanese readability metrics

<MURATA> spacing between ruby base characters and ruby base charcters

alastairc: to wrap this up; Murata-san did you want to say a few words?

<MURATA> I will not repeat the detailed comments I submitted during the previous charter review. Instead, I would like to make a few brief points.

<MURATA> First, I would like to mention one thing related to the current ISO ballot on WCAG 2.2. I cannot discuss Japan's position before the ballot closes. However, I can say that there has been a very serious discussion in Japan about internationalization of WCAG 2.2.

<MURATA> Second, regarding the proposed AG WG charter, my company's position is unchanged. We will vote against the charter, and we intend to file a Formal Objection. Please do not ask me not to file a Formal Objection, or possibly an Appeal. Both are legitimate parts of the W3C Process.

<MURATA> Third, I would like to clarify one point about the role of the Internationalization Working Group.

<MURATA> Speaking as a member of the I18N WG, I would like to make clear that the role of the I18N WG is to review specifications and provide internationalization expertise. The charter of the I18N WG does not include drafting or maintaining the normative text of WCAG 3. That responsibility belongs to the AG WG. This is simply the division of

<MURATA> responsibilities between the two Working Groups.

<MURATA> Finally, speaking in my personal capacity, I believe the current approach is not working.

<MURATA> The AG WG cannot expect the I18N WG to solve the internationalization problems of WCAG 3 while retaining complete discretion over whether to accept the results.

<MURATA> When the I18N WG reviews WCAG 3, its findings should receive serious technical consideration. If internationalization findings are rejected, there should be a throughly documented technical rationale. Simply asserting that a concept such as “character” works for all writing systems is not a sufficient technical explanation.

<MURATA> Finally, speaking in my personal capacity, I believe the current approach is not working.

<MURATA> The AG WG cannot expect the I18N WG to solve the internationalization problems of WCAG 3 while retaining complete discretion over whether to accept the results.

<MURATA> When the I18N WG reviews WCAG 3, its findings should receive serious technical consideration. If internationalization findings are rejected, there should be a throughly documented technical rationale. Simply asserting that a concept such as “character” works for all writing systems is not a sufficient technical explanation.

WCAG 2 errata and updates survey https://www.w3.org/wbs/35422/wcag2-updates-2026/

alastairc: this is about our errata and updates approach

<Patrick_H_Lauke> again, WCAG 2.x backlog TF would welcome a list of pain points of internationalisation in WCAG 2 to see if we can at least mitigate problems in 2.2, OR see if 2.3 can help

<alastairc> https://docs.google.com/document/d/1kvek0bdY_qwzvD9BeoyfYejTyNxgCkJbHbJvu2Y1WcU/edit?tab=t.0

alastairc: [shares screen]

<bbailey> https://www.w3.org/wbs/35422/wcag2-updates-2026/results/

alastairc: we set up a survey based on feedback we got on the pre-CFC

alastairc: we got a number of positives, negatives and neutrals

alastairc: [reads from shared Google document]

<MURATA> What I should have typed before: To be clear, I am not committing the I18N WG to additional work. I am only saying that, when I18N review findings are provided, they should be handled with appropriate technical accountability.

<MURATA> Finally, I encourage the AG WG to ask itself one question.

<MURATA> Why has internationalization in WCAG made so little progress after all these years?

<Charles> i don’t understand the concern of taking away from WCAG3. the current charter of AG includes WCAG 2 maintenance.

alastairc: I see no-one on queue

<alastairc> draft RESOLUTION: The WCAG 2 task force will continue to produce editorial errata for WCAG 2.1 and 2.2

alastairc: I'll prep a resolution

MURATA: I would like to get rid of the word 'editorial'

<Jon_Avila> I would object to removing it.

alastairc: would anyone object to removing the word?

kevin: could you explain why, MURATA ?

MURATA: I'd like to introduce some technical changes

<Patrick_H_Lauke> reword "editorial" to class 1 / 2 ?

<kevin> Class 1/2 wouldn't cover what Murata-san highlighted though

<alastairc> draft RESOLUTION: The WCAG 2 task force will continue to produce editorial errata for WCAG 2.1 and 2.2

<Adam> +1

<Rachael> +1

<Heather> +1

alastairc: for this resolution, could you +1/-1/0 ?

<MURATA> -1

<nattarnoff> +1

<kirkwood> +1

<GreggVan> +1

<GN015> +1

<Patrick_H_Lauke> +1 (though suggest changing "editorial" to class 1 / 2)

<Francis_Storr> +1

<bbailey> 0

<HaTheo> +1

<Jon_Avila> +1

<bbailey> +1 to PL

<laura> +1

<giacomo-petri> +1

<Ben_Tillyer> 0

<Matt_King> 0

<stevef> 0

<filippo-zorzi> +1

<ShawnT> 0

<Detlev> +1

<MURATA> Should allow technical changes

<LoriO> +1

<wendyreid> 0

<Makoto_U> 0

<jkatherman> 0

<hdv> +1 , would also +1 Murata's suggestion to remove 'editorial'

<bbailey> https://www.w3.org/policies/process/#correction-classes

<SydneyColeman> -1

<CClaire> 0

<AshleeF> 0

<Dirk> 0

<Charles> +1 if also another draft resolution for technical, or if this resolution does not disallow non-editorial

<Patrick_H_Lauke> true editorial - no true scotsman

GreggVan: if the concern here is with 'editorial', we could do another resolution for other types of changes?

<nattarnoff> I will say, I'm not sure MURATA defining line length for a different script or language does "change meaning" and would fall under this.

<Charles> +1 to GreggVan point. it does not say ‘only editorial’ and does not disallow ‘non-editorial’

<bbailey> +1 to "not disallow non-editorial"

GreggVan: if we have something about number of chars on a line, we could make a change, or make it clear something is not for all languages

<Patrick_H_Lauke> to gregg's point: when it's an issue of "deciding whether it means A or B" those were exactly the things we set aside NOT for errata, but for the list for potential 2.3

alastairc: gregg is correct, we're not precluding other things

<Jon_Avila> I agree with Gregg that other things could be addressed if the wider-group was thoughtfully involved.

<Patrick_H_Lauke> again, i refer to the WCAG 2.x backlog TF board where we have two columns: "Errata" and "Future version updates" https://github.com/orgs/w3c/projects/56/views/1

<bbailey> We characterize the deprecation of 4.1.1 as “editorial”

<GreggVan> +1 TO Wendy

<Patrick_H_Lauke> 4.1.1 was an outlier

wendyreid: what might help… like Patrick_H_Lauke commented… we should be clear about what we mean. Especially since W3C has clear levels for types of changes. If we want to draw a line in the sand for kinds of changes, it might be easier to discuss if we specifically say things like 'class 1, class 2, etc would go into errata, others go into future version'. I voted 0, but leaning to -1, because editorial means a lot of things to a lot of

people

classes of changes: https://www.w3.org/policies/process/#correction-classes

alastairc: when we say 'editorial' it's class 1 or 2 changes, but everyone understands it to mean 'no changes to the interpretation'

<bbailey> https://www.w3.org/WAI/GL/wiki/Decisions

<Patrick_H_Lauke> alastc https://github.com/w3c/wcag/wiki/WCAG-2-Task-Force-process

alastairc: matt, it would be mostly normative, or we would not worry about this

alastairc: the link Patrick_H_Lauke shared is what we've been using so far around changes

<Zakim> alastairc, you wanted to comment on further changes

Patrick_H_Lauke: to reinforce… if you look up the WCAG 2.x project board, we have separate columns for Errata and Future Versions of WCAG. This is where we try to do exactly as suggested, errata is just errata, interpretation and ambiguous wording would be in @@@

<MURATA> Yes, 2.3.

Patrick_H_Lauke: Future Versions column is potentially what could end up in a possible WCAG 2.3

GreggVan: changes in supporting docs would not be seen as class 1 / 2, but it could change interpretation, we should be careful that changes to the Understanding doc, that are 'interpreting normative', should fall in the same category as changing language in the normative, to remove ambiguity

<alastairc> Draft resolution: The WCAG 2 task force will continue to produce class 1 and class 2 errata for WCAG 2.1 and 2.2 per https://www.w3.org/policies/process/#correction-classes. This does not prevent work on class 3-5 as that will be addressed in separate discussion(s).

<MURATA> I can agree on this draft resolution.

Patrick_H_Lauke: to pick on Gregg's last comment… Gregg does what you told us at last meeting, as a reason for don't need Errata, and put a note in Understanding when things need interpreting

Patrick_H_Lauke: that's the line we tried to dance on, when we said X and meant Y

Patrick_H_Lauke: sometimes we've been told it can be changed with a change in Understanding

Patrick_H_Lauke: changing Understanding can sometimes lead to different interpretation of the normative

Patrick_H_Lauke: this is why we send the items to the wider group

Patrick_H_Lauke: unless we're just changing commas

GreggVan: litmus test is: is there controversy

GreggVan: if there's no controversy and the whole WGs, we can change it in the Understanding doc; if there's dispute, we should not retroactively make changes

<Patrick_H_Lauke> "if there's no controversy" sorry that made me chuckle... in this group?

<alastairc> Draft resolution: The WCAG 2 task force will continue to produce class 1 and class 2 errata for WCAG 2.1 and 2.2 per https://www.w3.org/policies/process/#correction-classes. This does not prevent work on class 3-5 as that will be addressed in separate discussion(s).

<Adam> +1

<ShawnT> +1

<Rachael> +1

<giacomo-petri> +1

<Patrick_H_Lauke> +1

<stevef> +1

<GreggVan> +1

<HaTheo> +1

<Heather> +1

<wendyreid> +1

<Francis_Storr> +1

<laura> +1

<nattarnoff> +1

<Makoto_U> +1

<Ben_Tillyer> +1

<SydneyColeman> +1

<hdv> +1

<kirkwood> +1

<filippo-zorzi> +1

<Charles> +1

<bbailey> +1

<alastairc> +1 from Murata-san

<CClaire> +1

<Dirk> +1

<Jon_Avila> +1

<jkatherman> +1

Murata: got disconnected, would like to support resolution

RESOLUTION: The WCAG 2 task force will continue to produce class 1 and class 2 errata for WCAG 2.1 and 2.2 per https://www.w3.org/policies/process/#correction-classes. This does not prevent work on class 3-5 as that will be addressed in separate discussion(s).

<GN015> +1

<Atya> +1

alastairc: second question is: should we create a list of updates?

<Charles> aren’t the majority of github issues about interpretation? it seems improbable to not affect interpretation.

alastairc: the easiest way of doing that is to go through the issues

alastairc: as the group hasn't touched those

alastairc: we had some examples in the survey

<bbailey> https://www.w3.org/wbs/35422/wcag2-updates-2026/results/#xq3

alastairc: such as updating the normative wording of 4.1.3 due to ariaNotify shipping, which offers a non markup way of sending info on updates to users

alastairc: none of these are trying to add new features

alastairc: some comments said rather than these being updates for the future, some of these could be errata

<Jon_Avila> Would 2.3 be backward compatible to 2.x?

alastairc: [reads comments from document]

alastairc: we don't have to have the whole group look at WCAG 2 changes, there's quite a bit of non-overlap

<bbailey> https://docs.google.com/document/d/1kvek0bdY_qwzvD9BeoyfYejTyNxgCkJbHbJvu2Y1WcU/edit?tab=t.0#heading=h.w3zjfsnaz4fz

<MURATA> My upcoming FO will mention 2.3.

GreggVan: putting together the list is a necessary first step to making any decision… is it five things or many more? does the entire working group agree the change is what was meant originally?

<Patrick_H_Lauke> "does the entire working group agree the change is what was meant originally?" is not the relevant question for potential 2.3

GreggVan: re your answer to Andrew… I disagree with your response… a task force has no standing of any kind unless we as a WG say you are authorised to make normative changs… TF has no standing but to go back to the main group

<Patrick_H_Lauke> we're not trying to make "errata plus". we're trying to patch problems in 2.2 / 2.1 / 2.0

<MURATA> Disagrere

<Patrick_H_Lauke> taking the example that alastc had: for 4.1.3 the group did not originally mean to include ariaNotify because that did not exist at the time

shadi: creating a list as a first step is a good idea

shadi: without a list, I don't have a position for or against 2.3

<bbailey> All class 2 changes are in the emails Patrick lists every two weeks.

<wendyreid> +1 Shadi

shadi: re the point of overlap… from my position… my focus right now is WCAG 3, because the TF is focused on class 1 and 2 changes. If that changes and they'll start doing class 3 or above, I will need to pay more attention

shadi: for me that's a factor that decides whether I have to attend and focus on it

wendyreid: the process the TF has been undertaking has been fantastic

<hdv> +1 wendyreid

<Patrick_H_Lauke> (we've been caretakers ;) )

wendyreid: I appreciate the work they do to undertake these editorial/sometimes exploratory work, and constantly sending us updates, that provide all the necessary links and context, and they're communicating regularly.

<Heather> +1 to wendyreid

<bbailey> Thanks Wendy!

<Zakim> alastairc, you wanted to comment on Task force, and how whole group reviews and to also say the process after that and to comment on naming of 2.3 and no new features

<Patrick_H_Lauke> wendyreid making me blush (on behalf of the whole TF)

wendyreid: the work they do it completely fine. Not sure if we need to spend so much time reviewing their work. I understand it takes time to keep up but if people care they should.

alastairc: it's not that the TF is doing things independently. The members of the TF are members of AGWG, anything normative gets escalated.

<Ben_Tillyer> +1 to wendy

alastairc: in the background, this is building up a list for WCAG 2.3

alastairc: once the next charter comes into force, the next step in the process would be to create the updated changes, and I suspect we could get agreement and know what we're doing for the next charter

alastairc: TF is just asking for people who are interested to keep an eye out

<Zakim> Patrick_H_Lauke, you wanted to talk about cross-pollination

Patrick_H_Lauke: some people are on the TF and also active in the WCAG 3 subgroups

Patrick_H_Lauke: my focus is on 2.x stuff, but others are taking some of the issues from the TF to their groups in WCAG 3 work

<Adam> +1 to Patrick_H_Lauke on cross-pollination from 2.x to 3

<alastairc> Draft RESOLUTION: The taskforce will continue to work on class 3+ changes in order to create a list for consideration at the next charter period. These changes will get additional review during/post the charter period but is needed to make an informed decision about WCAG 2.3

<Patrick_H_Lauke> +1

<wendyreid> +1

<Adam> +1

<bbailey> +1

<giacomo-petri> +1

<Matt_King> +1

<nattarnoff> +1

<Rachael> +1

<Charles> +1

<Heather> +1

<Ben_Tillyer> +1

<MURATA> 0

<filippo-zorzi> +1

<hdv> +1

<alastairc> +1

<ShawnT> +1

<Makoto_U> +1

<jkatherman> +1

<LoriO> +1

<HaTheo> +1

<Francis_Storr> +1

<laura> +1

<Patrick_H_Lauke> we'd welcome issues being filed Murata-san and flagged for WCAG 2.x

<Jon_Avila> +1

<Patrick_H_Lauke> (i'm afraid i have to drop now)

<Zakim> bbailey, you wanted to reply to shadi

alastairc: Murata, I remember there was something you wanted addressed?

murata: some issues are covered, some are not

<MURATA> Please wait for the close of the WCAG 2.2 ballot in iSO.

bbailey: re the emails, if you can't find the time to look at everything, please look at the ones labelled potential errata

<Zakim> shadi, you wanted to ask what "work on class 3+ changes" means

shadi: what does work on class 3+ changs actually mean?

alastairc: these are PRs people have worked on

alastairc: we're not talking about publishing these

GreggVan: do you have PRs for them?

alastairc: not for all of them, but did send them in email recently. That was the first batch of things worked on

Rachael: chair hat on… when we went through charter convo, class 3 changes list was not detailed enough at that point to understand

GreggVan: I am grateful for the work and appreciate the amount of work they have been doing deeply.

GreggVan: you said some of the class 3 and 4 changs were in something that was sent around and said there was not much feedback

<Rachael> I do not believe we are considering class 4 which are new features.

GreggVan: if people commented, would like to know if they were on type 3 or 4 or 1 and 2

<bbailey> We are NOT doing class 4

<Zakim> bbailey, you wanted to mention “2.3” label is a bit of misnomer

bbailey: we're not doing class 4

bbailey: class 3 is 'anything people are raising questions about'

<kevin> If anyone is interested in the classes of changes: https://www.w3.org/policies/process/#correction-classes

<alastairc> I wonder if some of the i18n changes might be class 4? That's why I said 3+

bbailey: I got on queue to say the labels in the project board may not be representative

Jon_Avila: I agree with wendyreid that the task force emails are very helpful

Jon_Avila: sometimes in the threads in GH it's a little unclear what we're agreeing to

Jon_Avila: for substantial things in class 3 or higher, would be good to have more of a description of what's changing

Jon_Avila: wanted to ask if WCAG 2.3 would be backwards compatible with 2.2?

<Zakim> shadi, you wanted to suggest "process class 3+ issues" as alternate wording

<Zakim> alastairc, you wanted to comment on backwards compat

<bbailey> Backward compatibility historically is meeting 2.2 means meeting 2.1 means meeting 2.0

shadi: the resolution sounded a bit different than what we are talking about now

alastairc: class 4 would be adding something new… but I said class 3+ because some issues in internatonalisation may have been in the class 4 bucket

alastairc: [reads Rachael's resolution fix idea]

Rachael: it adds the word proposed before changes

<alastairc> Draft RESOLUTION: The taskforce will continue to work on class 3+ 'proposed' 'changes' in order to create a list for consideration at the next charter period. These changes will get additional review during/post the charter period but is needed to make an informed decision about WCAG 2.3

<MURATA> Defining what is a character would be class 4. Changing spacing depending on scripts, languages, or writing styles would be class 3.

<hdv> +1

<bbailey> +1

<Heather> +1

<MURATA> +

<Adam> +1

<ShawnT> +1

<MURATA> +1

<CClaire> +1

<Rachael> +1

<Francis_Storr> +1

<giacomo-petri> +1

<Ben_Tillyer> 0

<jkatherman> +1

<GreggVan> +1

<Jon_Avila> +1 but I would prefer to say something other than "work on"

<LoriO> +1

GreggVan: if group can't decide, would still be good to bring to wider group

<alastairc> draft RESOLUTION: The taskforce will continue to work on class 3+ proposed changes in order to create a list for consideration at the next charter period. These changes will get additional review during/post the charter period but is needed to make an informed decision about WCAG 2.3

<ShawnT> +1

<laura> +1

<bbailey> +1

<HaTheo> +1

<Adam> +1

<Detlev> 0

<alastairc> [Disconnect so re-posted

RESOLUTION: The taskforce will continue to work on class 3+ proposed changes in order to create a list for consideration at the next charter period. These changes will get additional review during/post the charter period but is needed to make an informed decision about WCAG 2.3

<kirkwood> +1

alastairc: most of the feedback we get on the surveys, we iterate on… sometimes we have things that need wider group review. This is one of those.

alastairc: I opened this based on comment from Wilco on flashing

alastairc: Wilco commented this needs to take viewport into account

alastairc: I wasn't sure if this works

alastairc: this may be tricky… we also got some side topics. Core topic is: does that makes sense

GN015: I'd like to understand where 470 square comes from

alastairc: this is based on some research from Bern

GreggVan: I'm not sure if deaf is related

<Jon_Avila> Browser zoom is not assistive technology.

GreggVan: re zoom, there is no need for an author to know how much something has zoomed

<Jon_Avila> Author could check the scale in browser to determine if it is zoomed.

<alastairc> Jon_Avila - it sort of it, just a very popular one

<GN015> In other contexts it was stated that the various SC need to be fulfilled at the same time.

<Rachael> Thank you scribes!