Meeting minutes
Introductions
Rachael: introductions?
Announcements - WCAG2ICT reminder w3c/wcag2ict#912
alastairc: Please review the WCAG2ICT update
Rachael: CfC for WCAG 3 new draft has closed without objections
Introductions
Taskforce kickoff (Assertions & Guidance Document) https://www.w3.org/wbs/35422/2026-taskforce-setup
<julierawe> And we appreciate your leadership!
Rachael: Two new task forces: 1) assertions 2) guidance documents (testing reporting, policy guidance)
… policy subgroup will be transistioned to task force
Rachael: let us know if you are interested in participating
… please fill out the survey and even respond if you are not interested
Matt_King: guidance name for TF could be confusing
Rachael: TF will write goal statement to sort that out
alastairc: we were struggling to find a good name
bbailey: which subgroups will be closing?
<alastairc> The current policy one will wrap up soon, but the provisions ones will continue.
Rachael: subgroups working on rquirements will work longer, but we will try to get eight weeks check-ins more regularly
Rachael: other concerns?
Internationalization approach [20 minute] https://docs.google.com/presentation/d/1qeMPo8a9bQ9yBvk0Ph4YJ15hjyYD3wE61KHcMHtkUJA/edit?slide=id.g3fa5a187f93_0_5#slide=id.g3fa5a187f93_0_5
kevin: (shows presentation - please refer to contents there, link further up)
kevin: was talking to experts on readability and internationalization
Slideset: https://
kevin: showing slide 28
<MURATA> Here is an early draft of a11y-req-ja. It has been discussed in JLTF of the I18N WG, the Global Inclusion CG, and the Text and Wording subgroup
kevin: trying to define requirements that ca be applied universally (like language orinetation)
<MURATA> Disagree
<MURATA> Disagree
<MURATA> Disagree
<Zakim> bbailey, you wanted to inquire which subgroups are on another 8-week run
kevin: A task will be to look at different languages to see how universal requiremtns can be added to
<kevin> Preview of the example requirements
MURATA: Beginning with a universal approach will not work for japanese - there are different specific requirements - this is very different from what the internationalization WG has proposed. There were discussions with Kevin but no agreement
<MURATA> Here is an early draft of a11y-req-ja. It has been discussed in JLTF of the I18N WG, the Global Inclusion CG, and the Text and Wording subgroup
MURATA: I strongly disagree with this approach, I’m concerned beginning with a universal approach will ignore important aspects of language and culture, there is no consensus about this in the internationalization subgroup
<Zakim> Rachael, you wanted to ask for more details
Rachael: can we have more details, MURATA, why therei is such a strong conflict? This seems to provide a hook and allow to add specific things to adapt into different languages
julierawe: question for MURATA san: we had looked at the provision as a subgroup, thought it was headed in the right direction, some wording changes around writing direction - though it just needed some fine-tning - what happened?
MURATA: The requirement is fine - changing the writing mode horizontal to vertical and vice versa - but a universal approach was not discussed.
… without knowing the culture well, you cannot develop a universal approach
… without knowing things like segmentation on Japanese or compound words in German ,you cannot do it
wendyreid: MURATA san is the expert... what is problematic when you come from the epub context - how would we expect to work across other contexts, like websites?
<shadi> +1 to wendyreid
wendyreid: changing text annotations - epub has conventions for that, but is this generally applicable?
… we could recommendations that are familiar to epub like segmentation, but are difficult to apply to other contexts
<Zakim> alastairc, you wanted to comment on modular spec not working for accessibility
alastairc: one aspect MURATA has mentioned before is having modular aspects - but that doesn't work in a regulatory environment
<alastairc> Oh, also, if the issue is based from human perception, that is a better place to start for creating universal requirements than going from the script.
<Charles> i really appreciate the presence of experts on this topic – and defer to them. but i hear ‘universal approach’ as ‘universal intent’ and not as ‘universal method’. and agree with MURATA that anything universal must require an understanding of the differences within that universe.
kevin: The approach from thinking from a universal perspective, sound out if it was a good idea - we need to then work out what works for the languages we know about - for others, we can define features for those we don't currently have in view -
kevin: as to implementation challenges (Wendy): yes, true - there is a need to be able adust content (e.g. direction of reading) - but how it is done is still to be defined, may perhaps not be a core requirement
… we need to support the universality of WCAG
MURATA: Not sure if switching reading requirements like directionality I am not sure. Many requirements have never been implemented. First we need to define them, then see if they are doable and can be implemented in spec.
… there are strong requirements but these may not be necessarily be incorporated in spec - but we need to define requirements that work for particular cultures
Makoto_U: Comment on slide 28: web and mobile app person the example is confusing - do web pages need to have such mechanism? The Japanese web content would not need such a change of direction
<MURATA> Some Japanese cannot read vertical writing at all,.
<Zakim> Rachael, you wanted to clarify terms and scope of this conversation
Makoto_U: ned to understand more details and scope of text directionality
<CClaire> + 1 to Makoto that there should be no difference when we have different reading direction, same in Chinese character
Rachael: This slide deck was around how do we handle language-specific requirements - this is an example of an approach - instead of registries, we could take the approch "This applies when..." the word universal may be misunderstood here.
kevin: It is one of the ongoing challenges how to provide text presentation provisions to be as inclusive as possible of application contexts
kevin: one approach is republishing WCAG if we learn more - but that would be a maintenance issue
kevin: so the aim is to reduce the effort of maintance
<MURATA> ｑ＋
Rachael: The idea was to put the more language-specifi information into the additional info like recommended practice, or guidance
<Zakim> alastairc, you wanted to comment on what requirements would be included, and the basis in human perception rather than scripts
kevin: we cannot cover everything in requirements, needs layers in recommendations
alastairc: if working up from scripts and languages in the world, this would we a difficult task
… we can work from different requirements across PwD
<kevin> +1 to driving by the need not just the script/language
<Charles> note: there is also a tactile presentation of text.
alastairc: Anything in the core requirements to be used in regulation we have to be confident across languages and scripts - but there are different levels/tiers - like assertions: we worked on the readibility
<kevin> Vertical and horizontal text
<CClaire> To add some comments to what Alastair just mentioned, understandable that we are not able to develop for all languages, but the first step might be to define/find the common for certain languages or group it, i.e. Chinese and Japanese
kevin: Rational to include horizontal / vertical: came fro mthe work MURATA san did, but it may not become a strong requirement
MURATA: want to mention doc from Japanes Daisy consortium has the requirement for switching horizontal vertical directions
<bbailey> Slide 28 requirement (as written) possibly onerous for English.
MURATA: working on Japanese accessibility requirements - people in these groups have looked at my requirements, others are creating similar things for other languages
bbailey: Some requirements are also difficult for the English language - annotation requirement may not be realistic
<MURATA> Agreed. > Kevin
kevin: worth noting that CG can't publish normative materials
<CClaire> And I'm not sure if it is correct to say so, even though we have two directions to read Chinese, however, most of time when people create website or mobile app, horizontal reading is more popular nowaday. But you will see both Chinese character and English words are mixing in one sentence kind of thing so how to setup the size of font would be
<CClaire> interesting
kevin: it would not be appropriate - we need to follow a course appropriate from charter and procedure perspectives
Rachael: presnetation was mainly meant to offer an example - we will circle back with the group to that
What to do about the term "mobile" - https://github.com/w3c/wcag3/discussions/851
<MURATA> My biggest comment: begin with req documents for particular languages
<alastairc> MURATA - Any requirement coming from a particular language would need to be "universalised" to become a WCAG 3 core requirement. I.e. we'd need to establish (with support from i18n) that it works across languages/scripts.
Rachael: had conversation on email: concerns around the term "mobile". There is a github discussion on that - MATF will consider that. Please have a look and add points in the GitHub discussion - will be discussed in WG on Sept 22
Rachael: we want to go back to subgroup work after the break
… please stay to go in the breakout room
Francis: comment on quorum - how many do we need in the subgroups?
<alastairc> 3 for decisions, but 1 or 2 people can work on things!
Rachael: May be three - will come back with info
Kevin: it only concerns decisions, useful work can still be done
GreggVan: those working on sign language: Google has released a text to sign feature for his phones - seems to work surprisingly well - just a data point. If this is true, we're on the cusp of text-to-sign!
<AshleeF> It’s sign language to text — SL2T
Rachael: Please shere link!
Rachael: entering into eight minute break now
<MURATA> I will go to bed. Sorry!
<Dirk> that soundtrack is just getting better and better!
<AshleeF> GreggVan this is the link we've been reading in the SL subgroup, is it the same as yours? https://
<kirkwood> David McDonald did it
<GreggVan> Sorry I said it backwards. The one on Pixel Phone is sign to text. https://
<GreggVan> of the text output afterward."
<bbailey> Inputs subgroup working document: https://
<GreggVan> for Text to Sign -- see the following
<GreggVan> Signapse (UK) — Photorealistic AI signer. Their SignStream service handles both text-to-sign and sign-to-text, and they have Deaf staff in development, translation and leadership roles. BSL live in UK rail; DGS launch scheduled for September 2026, with ASL forthcoming.
<GreggVan> Site: https://
<GreggVan> Kara Technologies (NZ) — Hyper-realistic MetaHuman avatars. Each sign is performed by a native Deaf signer, motion-captured, then reviewed; their Kara Notation System trains the AI on facial expression, spatial direction, timing and role-shifting rather than word-for-word mapping. Building a 10,000+ sign NZSL library for real-time emergency/transit use. Notable for its published position statement respecting WFD/WASLI concerns.
<GreggVan> Site: https://
<GreggVan> Sign-Speak (US, Deaf-owned) — Not avatar-first, but the most complete bidirectional ASL system. Interprets ASL into spoken/written English and vice versa via a phone/tablet camera, no special hardware; piloted campus-wide at Syracuse in late 2025.
<GreggVan> Site: https://
<GreggVan> Then there are a bunch of Commercial and real but narrower in scope?
<GreggVan> https://
<GreggVan> https://
<GreggVan> https://
<GreggVan> https://
<GreggVan> Research to watch
<GreggVan> https://
<GreggVan> https://