Meeting minutes
<Jemma> Jemma - University of Illinois Chicago - Editor and co facilitator of ARIA Authoring Practice Guide Taskforce
<alastairc> Retro document https://
Retrospective
alastairc: Last retro: onboarding meetings just before the first meeting of each month, and a lot of subgroup work
<Rachael> +1 to subgroup work going well
alastairc: There is an optimal group size for getting through that type of work, 2 is not enough, 8 is too many, and somewhere in the middle depending on the people in the group
GreggVan: 2.1 and 2.2 took less time but we were just adding a few things, not restructuring. In WCAG 3 we're trying to do things in a new structure than before and expectation is you can do it in a third of the time and it's unrealistic and I worry it will push us to push something out that won't be what needs to be
<AWK> +1 to GV comments. That said, the expectation is that we figure out a way to go faster.
GreggVan: I think that AI is going to change a lot of things and we need to be paying more attention to what it is that can be done
GreggVan: Do things as thoroughly as we need to do.
Rachael: One of our goals is to get more outside participation in subgroups with outside expertise and haven't managed to do it as successfully as we'd like
Jaunita_Flessas: Meetings have been in the middle of the night, is there a way to move some meetings for Asia Pacific timezones?
Makoto_U: Facilitating a subgroup that has 6 members and I think smaller groups is better to have good conversations, but due to time differences, it has been difficult to have more than 2 or 3 people in our weekly subgroup meetings — we need to pick up the pace but need a better solution
Ben_Tillyer: Some people who are not vocal are contributing more
<Zakim> JJ, you wanted to comment on timezones
JJ: A11y Task Force, tried to find time that works for most people, very challenging because of different timezones
JJ: Try to do some async work but sometimes rotate meetings to accommodate different times
alastairc: Definite topic for where we can improve
shadi: Things that went well: in a recent period there has been focus on conformance (not conformance model), having that broader discussion is very useful and important of WCAG 3 project (not guidelines)
LenB: Good to see the notes in documents and spreadsheets, challenge was also in timezones
LenB: How can we do thing async, how do we communicate better, and try to increase visibility and transparency
<mgifford2> Setting alternating time zones is one approach I've tried, but it hasn't yet resulted in many new folks joining. Ultimately, we are all using electronic calendars, so if there is a critical mass of users it should be possible.
<Zakim> mbgower, you wanted to say some things that went well
mbgower: Found it useful in jumping around the different groups, it was easier to get oneself up to speed and get idea of progress of groups
mbgower: Keeping scratchpads and documents is really handy
shadi: Amazing work on closing issues in WCAG 2
alastairc: Summary: Accommodate meetings for those in Asia-Pacific timezone, difficult to work async but not able to get a lot done because it's difficult to build momentum, enthusiasm and motivation to do things. Splitting things up in areas for each person to work on but easy for it to slip out of mind especially if there's no regular contact with other people.
alastairc: Looking for ideas on how to make this timezone aspect easier?
Rachael: Trying to have subgroups of people in those particular timezones, e.g. Australia, Japan, China, in those areas
alastairc: Historically tried running Australian timed alternative AG meeting, but you end up not being able to make decisions if you're trying to cover the same ground in the same meetings
alastairc: Some people will not agree with the previous meetings, and there's no central place for decision making
alastairc: Believe subgroups would have that same problem
alastairc: With subgroups, if you're in a particular timezone there's a restriction of topics that you could be joining in, and if we had a group of people in Australia/Japan (roughly same timezones), your interests might be specific or restricted to what topics can be tackeld
Jaunita_Flessas: Thinking about maybe AG meetings could be done once a month in a different timezone? Not regularly, but if there are more folks joining from those timezones to get more participants in those areas
Jaunita_Flessas: Pacific timezones work well, anything past 12:00pm is 5:00am and Melbourne is 2 hours ahead of Japan —if we plan around 3pm Pacific/6pm Eastern, should be good for those timezones but might not get Europe
kevin: What time is that in Europe?
JJ: 11, 12, or 1am in the evening
Jaunita_Flessas: Maybe just once a month so European colleagues can have the majority of the meetings and once a month for Asia-Pacific
<AWK> When we were attempting to do periodic APACtime-zone meetings it was very hard to have many attendees. I think that unless it is really regular it is hard to get it into people's schedules.
mgifford2: If we take a bit more time to rehash issues to make sure there's enough overlap for people participating, shouldn't we be making better decisions even if it takes longer?
Ben_Tillyer: Cycling through timezones would be beneficial, but some can't do 9-5 that interacts with their work of employment during the day.
kevin: One of the challenges is that if there is a split in meetings, there's a split in decision making but it might be worth a try
mgifford2: Longers meetings aren't necessarily as effective
<Zakim> alastairc, you wanted to comment on regulatity
alastairc: Noticed over the years that if you have irregular meetings you tend to lose participation
alastairc: Partially because consistency of schedule works for participation of people
<AWK> +1 to Alastair's point about regularity=attendance. Doesn't solve the problem globally though
mbgower: Regional basis subgroups don't need to be restricted in topics
mbgower: Could have subgroups that have multiple topics that smaller groups of people can tackle
mbgower: Choose 2-3 topics of interest in that region — could be valuable in terms of work
<kevin> +1 to the value of having groups in different TZs
<Ben_Tillyer> Cycling through 2-3 options for the meeting time can definitely be done and kept "regular" and predictable for people. Having the .ics file kept up to date with that should solve some of the challenges (found here: https://
<Zakim> Rachael, you wanted to explore a 2nd meeting
Rachael: Enough work for a second meeting for next few years, what if we did a second meeting that was topic-specific?
Rachael: Focus on one for conformance, one for WCAG 3, one focused on guidelines or 2.x
Rachael: Decision-making meetings but more narrow to let people have 5 days to review and comment back on decisions made
Jaunita_Flessas: I like both ideas, having a timezone-specific subgroup because all the work is user-dependent on some ways and would be good to have that expertise on some calls
Jaunita_Flessas: If you're working on images/pointers, and have issues that overlap, could be good to have a group that is diverse but same timezone to discuss it
<Zakim> alastairc, you wanted to comment on keeping up, and the "I missed this but..."
alastairc: Some people come for a few weeks, then come back, and would have missed some bits and need to repeat things a lot and there's a synchronisation problem for those who had been there and will have to go back over things —reasonable that those who were previously not present have questions and want to discuss things again
<Ben_Tillyer> +1 to the comments of alastairc. It does feel like I've gone back in time by a year or three sometimes
GreggVan: For a lot of our topics, we have a lot of people with expertise in them, any conversations without them on the call would raise discussions that don't get done
GreggVan: Tried to groups at 2 different times and people can't get into discussions and back and forth but what might work —we used to have a working session on Tuesday and another one later in the week
GreggVan: You have a group where you always have a core that is always present in both meetings — someone working on special topic who won't be there in the main meeting might be a problem but if we can shift them to later in the day so that they can participate in the second of those 2 groups to keep threads going
<kevin> +1 to the value of a good core part of groups
mbgower: I found in WCAG 2 you'll have a long issue and we've tried to make a synopsis of that issue and added to the thread but there is a summary of what's going on in this topic so that someone can go back and see the basic decisions and background discussion on these topics
mbgower: Don't know how we solved moving from discussion to issue, don't know if GitHub can handle that but it's a way to handle repetitiveness
<Zakim> mbgower, you wanted to say I think good documentation of decisions and rationales can make a real difference
mbgower: There's a reasonable ask for a person to do the homework and look at what's been done in between meetings
mbgower: On the responsibility of the person coming back in and establish where to go for the context of where we are
<Fazio> we've been discussing how to leverage AI with our git issues
<Zakim> alastairc, you wanted to comment on 2 types of work - formative and refining.
<mgifford2> Could we use AI to occasionally summarize the threads? It is also possible to edit the initial post (there is track changes) and provide a link to a comment with the AI summary.
<shadi> +1 to mbgower
<mgifford2> Fazio GitHub right? Not git.
alastairc: Might work in some cases but harder for others — we've got 2 kinds of work, e.g. formative work (writing up new things/things that are different) and requires a lot of decisions to happen and you get an assertion or conformance model, but those are difficult to explain/summarise for every single decision; we also have refining work
where topics are restrictive, almost self-documenting with the summary in GitHub
alastairc: Harder to summarise bigger topics
Jaunita_Flessas: Heard from new folks that there's a lot of information to go through, maybe we could use AI to help summarise to help people onboarded quicker or into discussions quicker
Ben_Tillyer: Used Gemini on the minutes to tell me what happened in those calls
Ben_Tillyer: Personally AI could be used to help keep on top of topics
Ben_Tillyer: Can be explored to help get people stay on top of past/current topics
Fazio: Some type of collab bet. Microsoft/Copilot and W3C to work with copilot
Fazio: Would help with documentation, comments, issues
<Zakim> kevin, you wanted to be the AI naysayer
<mgifford2> This issue of long issues isn't specific to the W3C. We've got the same issues with Drupal Issues. There are going to be a lot others looking at this. Trust, but Verify, always.
kevin: When there are subtleties in the arguments being presented which is often the case in the work we do, and we need to be careful if we're making a summary, we'll need to manually check it. Discussions that we've had so far, chairs took actions to summarise up to the point of the discussion and then bring back to the meeting for people to pick up.
kevin: They are labour intensive but necessary because it gives the perspective of the whole argument. There's an argument for how to integrate better with AI but I don't think it's a collaboration with a particular partner because we use a number of different tools.
kevin: It's not a straightforward yes/no answer towards using AI
Jaunita_Flessas: There's nuance in arguments, and if we check before they're sent to the group, even if there are humans scribing, you're not getting that nuance if you're not in the meeting but also we might want to use AI for more accurate transcription of meetings
Jaunita_Flessas: Might be because people are hestitant to have their information exposed to AI, if this information is already in public on the internet, the models have gotten better over the past few years and copilot is using OpenAI LLM so might be good to revisit
<Fazio> Nothing is perfect, not even human memory or discussions
<Fazio> I think theres more positive than negative to incorporating an AI assistant
<mgifford2> +1 Fazio
GreggVan: We're all talking as if the current minutes are accurate, and I've watched them but a lot of times there are different hallucinations — we should be comparing what AI does to what we have and which is better, not necessarily AI is infallible but what we're currently using is already full of inaccuracies
GreggVan: When you're done talking, we can see what the AI wrote and if it's wrong, show people how to make a correction
GreggVan: Wouldn't do that to a minute writer
GreggVan: We should try it with AI and correct if we want to and see which is better
<Jaunita_Flessas> Would be super cool to have a running summary of IRC convos too
GreggVan: Sometimes people say amazing things and you can't capture them all the time
Ben: To Kevin, I've been doing work in my day job, demonstrating how much better agentic AI can be than something off the shelf.
… General tools can be pretty good at a lot of things. When you make a tool more precise, it can benefit you in a particular environment.
<Zakim> alastairc, you wanted to say verification has to be live, people don't look at it afterwards.
Alastair: Kevin, may know more about what the w3c is doing with minute taking. We need a summarization of documents, minutes, threads, emails...
<Fazio> *robust*
Alastair: Then the IRC side is different. I haven't seen a live-scribe, editable tool.
… I suggest we leave scribing along for now. Kevin can talk to it. Chairs try to summarize, but other tools would be great. Please get in touch.
Ken: Some of these threads have been wrapped up. Minute-taking is collaborative. People should feel empowered to correct, and scribes should understand not to take that personally.
<alastairc> Forgot to say - changes need to be within the meeting, otherwise people don't check them.
Ken: Trying to correct LLM output is more time intensive. It could take more cycles, especially a transcript.
Kevin: I'm not aware of everything going on. Some groups have tried automatic scribing through Zoom. It didn't quite work. Anytime we try something, we encounter etiquette situations where a human would understand not to record something.
… Havent' done anything on integration with IRC.
… Using AI tools for scribing is not there yet. AI as transcription service is solid.
<Zakim> kevin, you wanted to talk about W3C minute taking
Kevin: The third challenge is summarizing the vast quantity of input.
<mgifford2> Is the history of the IRC for #ag available somewhere? Especially during meetings. It would be interesting to see what comes from that - especially over time.
Kevin: We should be thinking of how to get the most useful AI in each context.
Alastair: For other challenges we could try to improve, how about subgroup participation or asynchronous work.
Jaunita_Flessas: What helps a little bit is detailed documentation.
… Instructions help make the task less daunting.
… That can help veterans as well as new people.
Alastair: How would we go about creating that?
Jaunita_Flessas: Let's say we're writing a guideline. If there is a structure we need to follow for a technique or failure, it would be handy to see an example.
<mgifford2> I also assume that other W3C groups are dealing with similar challenges with time-zones and use of AI. It would be interesting to learn from them as well. Side-rant - I understand the advatages of IRC, but there are lots of disadvantages too. It isn't my messaging platform of choice.
Jaunita_Flessas: Or if the task is an update, a template can be useful. Something that is easily accessible.
Alastair: I thought we had those. Apparently not enough.
… It's a shame Giacomo isn't here. Apparently his group worked effectively.
mbgower: The WCAG2 task force is async, the meetings is just to get agreement on things. Need to increase the culture of bringing work to the group. The sub-group is the first place people bring work to review.
… perhaps it could be issue tracking in a sub-group?
Alastair: Potentially we could have a big github board of requirements. There are over 200 including assertions.
… We're potentially getting to the point where that could work soon. Until now things were changing too much.
mbgower: Is there a way to make it more granular and have sub-issues.
shawn: Yes, can have sub-issues. I find them useful. There are some quirks.
Alastair: So we have a couple of ideas, and about 10 minutes to the break.
<mgifford2> If folks want to see the sub-sub issue in GitHub mgifford/
Alastair: The central spreadsheet worked well for some people.
<mgifford2> I just set that up as I had seen it but not played with it. Feel free to add/edit if you want to play with it.
Alastair: Most of the difficult things were getting people involved, and the time zones.
mbgower: If we could create culture for more experienced people to shut up, and less experienced feel they can jump in more.
<mgifford2> Talking sticks?
Alastair: Before I do continue with the queue, I want to encourage people to get on queue to contribute something more.
… +1s are really helpful to help us understand support.
… We do have to make some progress.
Gregg: We need to stop people from getting in line to restate things.
… But we want to encourage anyone to speak again if they have something new to say.
… But I do like the idea of establishing pauses; moments of silence. maybe there's a way of having people being able to move to the front of the line, if they don't often get in queue.
<Fazio> It's the art of meeting management
<Fazio> Janina does something similar
Gregg: Some people are not interesting in commenting. So they find other channels. We can help create those.
<Zakim> Rachael, you wanted to ask if github helps
Rachael: We had a similar conversation in another retro.
… I'm curious whether the githubs threads were successful.
alastairc: To expand on that, we have less surveys. Have the github discussions helped?
Ben_Tillyer: Silence is good sometimes. It's easy to say things that are at the front of your mind. Sometimes, after a bit of reflection, you get into more nuanced thoughts that need to be had.
… Maybe we should have some designated ponderance time.
GreggVan: Two quick comments. Surveys are a great tool. Everybody gets a chance to talk. But some may comment and some may observe. But it's more of a level playing feild.
alastairc: The question for the wider groups is whether github discussions and issues were helpful or noisier. Did people appreciate that ability to reply to other's comments?
… It didn't help the chairs understand what the consensus might be.
AWK: The discussions are great, but they never end.
… It starts to be like a marathon you never signed up for.
… If you don't pay attention at the right time, things get resolved.
… Those are things that are nice about the surveys, CFCs and meetings, where there is a deadline.
kevin: The break is from 10:30 to 11. It's half an hour. Lunch is today at 12:30 until 1:45.
… There is an afternoon break from 3 to 3:30. It is currently 10:30 JST.
alastairc: I'm not sure what the external reaction has been, to respond to Ben's question.
Rachael: There seems to be the most excitement around having user centred processes.
… So I would say the assertion space. After the December time period, it will be more useful, as Alastair said. We are doing one for Knowbility.
kevin: We have the potential to piggyback WCAG 3 on a few CSUN topics.
<shawn> [ Shawn is doing a session at CSUN and plans to include some on WCAG 3 ]
kevin: I can't think of another specification that is comparable to this.
… We are seeing areas like security and privacy approaching similar questions.
alastairc: To summarize, we will look at scheduling meetings at different times.
… We will try to use surveys or other mechanisms to draw topics to a close.
… We will investiate AI tools for summarizing, separate from minute taking.
<Zakim> Rachael, you wanted to say an action to set deadlines on github discussions
<Patrick_H_Lauke> re project boards, issues can live in multiple boards (if we're talking github), so you can have best of both worlds to an extent
alastairc: We will consider the best way of organizing across project boards.
shadi: Do the chairs and leadership have reflections on what went well and not so well.
Rachael: I think some of them came up. At least for me, us creating summaries that people can find. We create them. We need to make them more discoverable.
… That will allow people to come back in with the background.
… We try new things fairly regularly. I think the maturity level approached helped.
alastairc: The parallel subgroups worked quite well.
… It's hard to start a new structure. Hopefully we've got more things in place.
… The editors' week worked well. We haven't covered that, but dedicated time to try to draw everything together was very useful.
kevin: I would +1 everything said. I think what everyone can do to support the work is for everyone to participate. The collaboration is so important. Make sure your input is in one of those layers.
<Rachael> +1 to wanting to hear everyone's voice
kevin: Make sure you respond to surveys. Even if it just to say +1. It helps us understand what the group is thinking. Where the consensus is.
alastairc: To add something else. When we have subgroup work, making it clear what the output should be. We can't be everywhere, so sessions in the main meeting are the best place to tackle questions that have come up -- especially where they surround how to progress.
Rachael: We didn't slip anything more than 45 days. We made our targets.
alastairc: We have an old agenda...
Kevin: Are you just going to do topics?
Schedule and future work
Rachael: We are going to start by going over the next 4 years' schedule.
[shares deck]
[slide 2]
Rachael: We have three key deliverables.
… WCAG 3 normative, the larger set of supporting documentation, and some kind of update to WCAG 2 covering normative updates, but no additional requirements.
<Patrick_H_Lauke> +1 for wcag 2.x backlog inclusion
<Patrick_H_Lauke> 2.2.1 ;)
Rachael: WCAG 2.?is just to indicate we do not know what to call this right now.
[Assumptions slide]
Rachael: We continue 2-week charters. The WCAG 2 TF continues, outside the main work.
Rachael: We continue to have enough participants to have 5 subgroups
Gregg: I suggest WCAG 2.2.1 for naming. EN is going up for a vote soon. It would be better to get something out before the vote was done, so the revised version has a chance of adoption.
… You mentioned you wanted to get one out, but also continue. I encourage you not to do that. Do not continue to do normative changes in waves.
… That's going to be disruptive and difficult to adopt.
alastairc: We have scoping changes tomorrow for WCAG 2. Let's not talk about the name yet, please.
<Patrick_H_Lauke> 2.2 Alpha Zero Black edition
Rachael: The intent is to do one normative update. We will talk in more detail tomorrow.
[Terminology slide]
[Key Takeaways slide]
Rachael: We plan to publish second half of year of 2029.
… The candidate rec would come out two years before that, end of 2027
… WCAG 2 update would be 2026 for comment, publish second half 2027.
[Detailed schedule]
Rachael: This table is a 4x5 table, with the three items in columns and the first column providing row headings for each quarter of 2026.
[Detailed schedule 2027 slide]
[Detailed schedule 2028 slide]
Rachael: WCAG 3 would be getting a lot of comments.
[Detailed schedule 2029 slide]
Rachael: We have scheduled in some slip in the second half of the year.
[Detailed schedule 2030]
Rachael: We would be working on backlog work and the supplemental documentation.
<Jaunita_Flessas> Looks reasonable to get there within 5 years
GreggVan: I thought CR just happens before publishing.
… Maybe I don't understand what Candidate Recommendation means.
… I worry about the ambition of the schedule
… I'd rather it be scheduled by the maturity, not the date.
… I don't people realize how far we have to go. We are not as far along as perceived.
… We found that the understanding and techniques work informed the normative language.
<Patrick_H_Lauke> regarding Candidate Recommendation definition https://
GreggVan: We should not be thinking about publishing if we haven't written up what we understand it to me, or the methods to do it.
… I like the plan overall. Those are just the two main considerations.
alastairc: getting to refining stage, assuming the content will be mature
shadi: Timeline is ambitious, what are the maturity levels and what is the full WCAG 3 package?
… in multi year development, how to sync all materials
<alastairc> Supplimental docs = informative docs, how-to, methods, tests
shadi: for evaluation, how can we go beyond WCAG-EM
… evaluation can impact the criteria
… we have learned from WCAG 2 and ACT that we things are tested in practice the requirements can be ambiguous
<Zakim> AWK, you wanted to speak to the group's ability to focus on two specs which are potentially adopted into regulation.
shadi: I would like to see definition of supplemental guidance
AWK: speaking from experience working on silver, WCAG 3 and 2.1 and 2.2…
… people are going to focus on the standard that is closest to what supports their organisation best
<Patrick_H_Lauke> agree, but ... pragmatically, can't blame organisations for concentrating on the here and now
AWK: the longer development takes the
<Zakim> Rachael, you wanted to speak to the methods
<mgifford2> To build on shadi point about ACT rules - the ARRM community group has also found the implementations of WCAG 2 being difficult to understand per role that has some responsibilities for delivering it.
AWK: larger the risk of it not being adopted
Rachael: tests and methods are critical but we should not forget role based guidance eg for designers
… they can feed into requirements
… we will do async reviews
Patrick_H_Lauke: commenting on non-normative work, the term “normative” is often not understood by target audience
… first normative and then understanding is not an option, should be a full package at publication
<shadi> +1 to defining the "WCAG3 package"
<Zakim> kevin, you wanted to mention prior and background work on supplemental materials and to comment on making things more atomic
kevin: The “WCAG3 package” definition has been worked on, but not finished.
… in WCAG 2 there are a
… lot of understanding documents
<Patrick_H_Lauke> expanding on the minuted part: from our experience in WCAG 2.x backlog TF, we saw that a lot of the normative wording is actually opaque/unclear to developers. only once the understanding documents are written do developers actually understand what the normative part of the requirements even means
kevin: one of the steps that helps is to break things down, e.g. one atomic requirement at a time
<Patrick_H_Lauke> so even when asking developers/the community for review, if the understanding part isn't finished by that point, they may not have the full picture to even be able to comment on it
<shadi> +1 to granular requirements
<Zakim> alastairc, you wanted to comment on tests being part of it from the start
alastairc: informative/supplemental documentation - understanding and techniques are being pulled to the top
<Zakim> AWK, you wanted to respond to Rachael which is that the reason that the WCAG 2.x backlog task force has been able to function independently is because it isn't making normative changes.
AWK: backlog tf has been working so smoothly due to non-normative changes
<shawn> [ shawn notes potential confusion between "WCAG 2 Supplemental Guidance" https://
shadi: we need to draw the line, and define what is at the core of the necessary documentation
<Patrick_H_Lauke> (backlog TF would love to make actual normative changes...our hands have been tied on trying to explain things that, on closer inspection, were very difficult to rationalise without logic pretzels)
shadi: moving away from supplemental as that could be seen as addendum
alastairc: it takes 6 weeks to 6 months to create and then much longer to actually publish
<Zakim> shawn, you wanted to say https://
<Patrick_H_Lauke> (6 weeks to 6 months ... "string length measurement task force")
shawn: avoid using “supplemental guidance” in WCAG 3 as it has a very specific meaning in WCAG 2
alastairc: we can bring tests and user needs into the requirements
… a lot of iteration is needed after reaching the base maturity
shadi: still lost, is there a definition for WCAG 3 package
Rachael: this term is new to me but will be working on defining it
shawn: do you have an initial list to share now to get to shared understanding? ?
shadi: we need to map out in more detail what these informative documentations will include and how they relate
<Zakim> GreggVan, you wanted to say Understanding, Methods, Tests are the key ones. Where to start and such can follow later.
shadi: for example what will they achieve
GreggVan: understanding and tests are key
… other things can come later even though they are important
alastairc: these things have been prototyped before. You have informative documents and notes. We explored tagging and filtering.
… we got methods. Tests. User needs. Brief rationales to go with requirements
<Zakim> Rachael, you wanted to transition us to the next conversation
Rachael: Shadi first
<Zakim> shadi, you wanted to disagree with Gregg
shadi: we have discussed what is part of core, eg reporting, measuring how well a website performs.
… this would influence how requirements are structured
… when working on WCAG-EM we found a lot of issues but were unable to make changes to WCAG
… Therefore these need to be developed together, staggered or sequenced
alastairc: transitioning to task forces for next charter slide
Rachael: acknowledging the topic, will get back to it later
… mentioning the task forces listed on slide
… coga, act, mobile, WCAG backlog, wcag2ict…
… policy, usability testing and assertions, low vision, something else?
… I’m asking which need to be part of next chapter
charter
shadi: can this be driven by its need and not by names or structures
… how can WCAG 3 be addressed more broadly?
… a (new) group could address this in various forms
… first define needs then structures
<mbgower> +1
GreggVan: WCAG2ICT might not be needed, they are very busy already working on AAA guidance (WCAG 2.2)
<shawn> +1 for topics first (rather than TFs)
GreggVan: WCAG3ICT, do research where it falls shorts on non web
… re special interest groups VS task force
<Patrick_H_Lauke> +1 COGA more of a special interest group atm.
GreggVan: coga has been in the middle of everything
… a tf should do a task and then dissolve
<shadi> +1 to scoped TFs
<GreggVan> +1
<shawn> [ Shawn has specific input on Low Vision TF and contrast algorithm, though I think not worth taking time now ]
jeroen_: positive about policy task forces listed
Rachael: special interest topics can be important without needing to be a task force
<Zakim> alastairc, you wanted to comment on TFs (generally) having their own deliverables, and needing own email list etc.
alastairc: TFs work best when they have a clear deliverable
… I would like MATF to check next WCAG 3 release to identify gaps
… we are building in the “non web” part, wcag3ict might not be needed
<Patrick_H_Lauke> (as a side note ... i always read the "2" in WCAG2ICT as meaning "to", as in "how to apply WCAG to ICT". so wouldn't need to be called WCAG3ICT)
<Patrick_H_Lauke> 2Fast2ICT
alastairc: notes can be created by groups to be referenced in WCAG 3
kevin: tf is artificial in terms of processes. No technical reports can be published.
<Patrick_H_Lauke> kevin: TF is confined to the charter of its parent WG
<shadi> +1 to Kevin
kevin: define what outcomes are and then figure out vehicle for delivering
GreggVan: re COGA not intended to downplay but to make more mainstream
shawn: with low vision hat on, different issues with internationalization, contrast, and other guidance. Based on past experience, we might not want one TF to take all of these.
shadi: figure out topics for WCAG 2 and 3.
… AI should also be considered
… what are the lessons learned
<Patrick_H_Lauke> AI is such a vague term, that means all sorts of things to people... this would need to be very specifically defined first
shadi: it might not be tf or subgroup, but some way of people getting together to focus on specific topics like AI
<shadi> +1 to Patrick_H_Lauke
<kevin> +1 to Patrick_H_Lauke
mbgower: can we touch base with all task forces and let them give feedback
… what are lessons learned to bring us to the next stage
<mbgower> ACT-rules
Rachael: before we move on, can you speak more about testing shadi
shadi: I meant what are the take aways and can we formalise the lessons learned
<Zakim> kevin, you wanted to mention ARIA testing discussion... although probably later
<mbgower> +1 to the aria discussion. There's a session on it this week, right?
kevin: there is ongoing discussion in ARIA about testing, can learn from this. Friday joint meeting
Rachael: [ ending with summary, lunch break starts ]
Kevin: [ helps everyone not to miss lunch location ]
Rachael: we talked about policy guidance, brief mention of AI, talked normative + support docs, mobile/epub/kiosks/tv/vr
<GreggVan> let me know when you would like the Brief AI explanation
Rachael: reporting. Anything else that popped up during lunch/powernaps?
Gregg: did you want me to explain what AI was about? using AI to create smart browsers (agentic) that can automatically identify headers, tables, etc even if content didn't mark them up properly
Gregg: will also allow progressive descriptions
Gregg: interrogating browser interactively about images
Gregg: simplifying language, removing idioms, explaining idioms, etc
<Patrick_H_Lauke> so ... magic ...
Gregg: same with contrast - modifying things dynamically
Rachael: think that was not only context for AI
Shadi: agree with you Gregg that a11y features in browser, including those with AI, are important. but wonder if that's level higher - WAI mission, or W3C priorities, maybe separate WG other than AGWG
Shadi: think that's beyond the scope of guidelines. the more browsers can do, the less others need to do. understand relationship, but think it's sepaate/beyond scope here
Shadi: when I raised AI i meant more in authoring sense - writing requirements so that they can be machine-readable. AI for testing purposes.
Shadi: back in the day we had lots of problems with captions for instance. nowadays, it's much more feasible to use "AI" (machine learning) to autogenerate things like captions
Hidde: think future where browser magically fixes things with "AI", sounds like an "accessibility dongle". we need to be careful that we can't rely on it, particularly if working in areas like specification/verification
Hidde: "accessibility dongle"
Lisa: if AI comes in to do author's job... when AT can work directly with a11y API great, but for cognitive we have a lot of tools that need to do scraping...
Lisa: when tools get it wrong (such as getting words wrong in autogenerated captions/content), this can be annoying for most users, but these mistakes can be really problematic for people with cognitive issues
Lisa: "AI" has potential to be trained for testing for things that are easy to test for
Lisa: what already works well today is reading text in images, pretty reliably
Lisa: do we then say "don't use text in images", but rather "make sure to test in all current AIs/UAs"
<Patrick_H_Lauke> making a requirement "make sure that users can access the text if embedded in an image" and then allowing one sufficient technique/way to pass is to demonstrate that all current (for whatever definition of the word) can reliably find/expose text in image
Gregg: +1 to all things mentioned by Shadi/Hidde/Lisa. need to make sure that we don't write guidelines that are out of step with tools/UAs
<Zakim> alastairc, you wanted to comment on it being about ensuring that AI (/user-agents) can do something without us having to change the normative guidance. I.e. a review pass of the guidelines.
Ken: something Hidde said last time spurred common phrase: "remember to prioritise human-first output"
Ken: core concept/tenet - it's about people. don't want to make mistake to optimise for machines instead of people. keeping that in mind
<Zakim> hdv, you wanted to note it will benefit our work if disambiguate specific types of AI
Hidde: we also need to disambiguate "AI". LLMs, machine-learning... they are different, do different things, different consequences
Shadi: sounds simplistic to say "we can just write guidelines carefully ... then AI does it, and we're done". like, can we obsolete 1.1.1? in a few year's time, we can just remove concept of headings if browsers recognise them automagically. more here to unpack
Rachael: we covered some of this before. technology-neutral. neutral from person solving them.
Rachael: still a requirement. and. we can't always assume there is going to BE a browser. the core point of the requirement still needs to exist, even IF some UAs may already meet them automagically
<Lisa> +1 to rachael
Rachael: making sure that even if a requirement seems "obsolete" because it's fulfilled automatically. but the requirement still exists for new technologies that may not do that
<alastairc> +1, we don't know how widely available things will be in advance, or across platforms. Therefore we have to /allow/ for UAs to acheive things, but still include them.
Lisa: COGA has document on risks to users FROM AI
Lisa: including mental health and safety
Lisa: need to scope out what's included in COGA group, in AT, ...
Jaunita: getting back to point about getting specs out faster, not just tech agnostic, but fast-tracking updates if technology updates
Jaunita: without having to go through lengthy w3c process, to keep up with technology
<hdv> +1 to spending some time on user agents and authoring tools
<shadi> +1
Rachael: stepping away from AI and back to what topics we need to focus on. do we need to think about user agents and authoring tools. do we need time talking about them?
Alastair: essentially a seaparate topic...
Jaunita: i think yes. could also ask UAs to do more
<Zakim> JJ, you wanted to reply about user agents
Jaunita: same for authoring tools, requiring them not to create inaccessible content
<Patrick_H_Lauke> good luck with that. we've seen low-to-no traction for UAAG and ATAG in the past
JJ: going beyond user agent, possible to talk about other deeper aspects (available in say native mobile development, like detecting is AT is running)
Kevin: we can write standards, nobody forces people to follow them...
Kevin: Patrick mentioned that UAAG and ATAG got no traction at the time. there was no engagement with organisations that these specs applied to. engaging them more, working with them...
Kevin: there is work on authoring tools guidelines, working with accessibility standards canada
Kevin: within that there will be much more engagement with authoring tool vendors
<Zakim> hdv, you wanted to say we don't require but can inspire
<shawn> Authoring Tool Accessibility Guidelines Community Group (ATAG CG) https://
Hidde: user agents are in good position to make positive changes...if they engaged. worked on authoring tool engagement with Shadi at the time
Hidde: would love to see more of that
Shadi: from what i'm hearing the answer is yes, more discussion on this topic. also because this group also has authoring guidelines, or rather this is the one monolythic accessibility group - might need to be unpacked
Shadi: if i had to pick, i'd say user agent work would get us more mileage, so not sure about prioritisation on authors
<Zakim> alastairc, you wanted to comment on accessibility supported complexity
Alastair: accessibility support set is where things like "images in text" comes in as a user-agent method might work on one platform but not another..
Alastair: also, if you're testing contrast, should you assume that "increase contrast" is enabled on the platform the user is on
Kevin: coming back to Shadi's points - think you said authoring tools when you meant user agents...
Shadi: sorry, i meant user agents - i.e. on previous point, resource allocation should prioritise user agents where most impact could happen
Mike: note that this works really well, until it doesn't work... (relying on user agents to magically fix things)
Mike: (gives example of on mobile, resize text and reflow being almost mutually exclusive - resize means zooming, which leads to bidirectional scrolling failing reflow)
Alastair: reflow and resize text ... think there are options there
Patrick_H_Lauke: I agree with idea of UAs doing everything, but worry that that error-correction might not work properly. Agree that if we write guidance to focus on the outcome, e.g. glean heading structure, how it's achieved (author or UA), that should work.
<Zakim> Rachael, you wanted to say can we transition to the next topic
Rachael: we dove a little deeper in these topics than others. are there other topics?
<Zakim> mbgower, you wanted to say do we ahve a source of truth for correct behaviour?
Mike: do we have established sources of truth? is the accessibility tree the source of truth? is how a UA/AT exposes things the truth? (references our current WCAG 2.x backlog issue about "are empty headings a failure")
<JJ> +1
Mike: when we talk about accessibility supported, what does that mean? one browser? two browsers? current AT? what is "current"?
<Zakim> JJ, you wanted to comment on source of truth for non web
JJ: it's also something we notice in non-web, when you don't have an a11y tree or source code. only source of truth is how things are output by actual AT, but there can be differences (devices, OS versions). same applies for ACT rules
<Zakim> shawn, you wanted to ask about the WCAG i18n issues, and separating "Low Vision (Color Contrast Algorithm)
JJ: but also, the more agnostic you make it, the more "vague" it becomes
Shawn: i advocate for fixes happening early instead of late. e.g. authoring tool, rather than leaving it up to browser
<hdv> +1 to Shawns point of earlier = better, so authoring tool helping get it right at the start rather than user agent fixing afterwards
Shawn: previous slide had possible low vision TF, and contrast algorithm. maybe we can put those as separate issues? do we need WCAG 2 i18n issues?
<Zakim> alastairc, you wanted to say that should be under the requirement level, e.g. methods.
Shawn: known issue, there for a while, but not sure if it fits on your list of topics/concerns
Alastair: in general we can't use accessibility tree, as some platforms don't have it. but if you cast mind back to accessibility support set, we agreed that we would have default accessibility support set, which would include the "typical" ones
Alastair: SR, voice input, fairly limited set. other regions/regulators/organisations could create their own sets
Alastair: to say whether something IS available in that particular region's set. game-able, but should be ok...
Alastair: some requirements may be satisfied by just one - user agent, authoring tool, etc - and others may be satisfied by multiples
Shadi: there are cases where offloading to user agent is only realistic option as there are no author methods available
Rachael: other ideas, let me know. moving to next topic, Accessibility testing working group
Kevin: short topic ...
Kevin: there are variety of efforts for testing - ARIA-AT, ACT, WCAG-EM, accessibility compat... should that all be coordinated/pulled into a working group? doesn't have to be a working group as such?
Kevin: ARIA WG are looking at this as well, see if we coordinate
Kevin: AGWG and ARIA are meeting to discuss this on friday
Rachael: pro on having separate group - maybe we don't have the time to think about testing; but curious to have folks think about it before friday
<Zakim> shawn, you wanted to ask about two different things?
<JJ> I can see that also working well for non-web testing techniques.
Shawn: hearing different things, would be good to be clear. one is interoperability - is this thing supported in browsers and AT. the other is testing: ACT rules, WCAG-EM methodologies...
Kevin: can I respond? ... yes
<shadi> +1 to shawn
Shawn: request to use better terminology, two buckets, not lumping together
<Zakim> mbgower, you wanted to say yes, i htink so
Kevin: this also relates to WPT. the point of this was to try to define buckets, where the boundaries actually are. conformance models etc. only exploratory at this stage. how could it solve problems
Mike: agree with Kevin. to me interop is different issue. source of truth for me is how to verify
Mike: at IBM, we have "if you test it in one place and it passes, that's enough. don't need to test in other places". if we start getting interop/compat issues is that you then have to test again on all possible platforms/UAs
<alastairc> Remembering that testing contrast with an eye-dropper compared to the source code can be different.
Mike: ... proprietary systems, maybe Apple need to say what THEIR source of truth is on their platform...
Shadi: separating out the aspects/overlaps is useful
<Zakim> shawn, you wanted to say which?
Shawn: would be good to do before next meeting
Alastair: responding to Mike, knowing from platforms what THEIR source of truth is. at requirement level, we need to be agnostic - what does the USER get. but underneath that, we can be more specific "here's a method to achieving this, to test this, on that platform"
<Zakim> shawn, you wanted to ask where things fit
<JJ> Using automation frameworks you are able to retrieve the accessibility tree on most platforms. Also on web, web drivers go beyond what can be accessed from the normal web sandbox
Shawn: when doing WCAG3, some people said one approach is "write the test first". where would this approach fit?
Alastair: Kevin, what was motivation from other groups?
Kevin: part of motivation is that there are a lot of different threads around a11y testing, and it suggests there overlap/relationship. question over whether or not they should be brought more closely together. exploratory
Shawn: were they talking about interoperability, or more ACT?
Kevin: both. this is exploratory, just looking at all different testing efforts
Kevin: does this fit together in some way, to help us reach a better testing model
<shawn> "testing of content meeting success critieria"
Kevin: are we repeating work? should we bring things together?
Jaunita: when we talk about testing, a lot of people talk about functional testing...
Jaunita: a lot of testing places seem to rely on SR testing, contrast testing, nobody looking at code anymore
<Zakim> JJ, you wanted to have leverage over vendors to expose accessibility properties
JJ: can we do anything about making sure a11y attributes are exposed from shadow dom etc? (sorry, paraphrasing)
Mike: going back to source of truth. page as presented to user? a11y tree? code underneath?
Mike: for end user, it's a failure. who's responsible? more of an issue from compliance perspective
<JJ> Not require, but at the least, we can suggest?
<JJ> +1 to Mike
Mike: [references the WCAG 2.x backlog heading issue again] an empty heading ... does that fail descriptive headings? even if most AT (apart from VO) don't expose empty headings based on heuristics
Kevin: on JJ's point ... that highlights "who should be doing that". our remit, ARIA's remit, (WHATWG?)
We will need to acknowledge where platforms don't provide something, or don't provide good access to test something. However, we can't tell platforms what to do, we can only say what the accessibility outcome is.
Kevin: same with Mike's point ... should AGWG feed into the discussion on how a11y tree is constructed? is it ARIA, or other working group?
Alastair: coffee
W3C Process Discussion
hdv: What we're about to do, I'm about to introduce - we intentionally do not ascribe feedback to specific people, we want it to be anonymous
<hdv> https://
hdv: taking feedback from as wide a group as possible. We're covering this across WGs at TPAC this year; I'm doing it for this group. Thanks to the chairs for making some time.
… I will be taking notes and bringing it back to the AB, our goal is to make parts of the process better for everyone.
hdv: If you think of more ideas, you can find and talk to an AB member this week (or thereafter). If you're an advisory rep, you can file issues in the ab-memberonly (w3c/
Functional Needs
Rachael: one suggestion that was made was EN 301 549, the editors group tried to use EN 301 549 without privacy
… we found there were requirements that concern mental health, complexity of cognitition and motion
… there were things we were marking that did not have a EN 301 549 functional need associated
… there is also a functional needs framework that is slightly different from the Digital Accessibility Framework
… when we look at a larger classification, what we run into is we're used to groups being broken up into several categories, at a slightly different level than cognition that is usually one top level. So there are basically differnet levels of hierarchy
… if we lose the top level, we lose some of the subtleties
… if we use sub category level we also lose a lot of nuance. So my question to you all, are there other classification systems that we can lean on?
… so what kind of grouping do we want?
Jaunita_Flessas: aren't there other cognitive accessibility categories not related to executive function?
Rachael: yes we could have a longer list of some of these
Lisa: there years ago when we did user research for COGA… looking at different sources of time we tried to merge them into a single thing, so we had vocab for the different cognitive functions as we talk about cognitive functions rather than disability groups at COGA
… when the W3C made a first stab to functional needs and we had more
<Jaunita_Flessas> Maybe we need to include occupational therapists and assisitve technology specialists and such in the discussion?
<Jaunita_Flessas> *assisitve
Lisa: it could be that all problems are from auditory discrimination. It'd be strange to group together people with contrasting skills
GreggVan: I'd like to suggest we don't do any kind of grouping
… we should be thinking about tagging. Each requirement can apply to a variety of different groups
<JJ> +1 for one to many tagging.
<Patrick_H_Lauke> I'd be careful that "tagging" will also then need a clearly defined taxonomy/set of tags/labels
GreggVan: we should highlight the many ways in which each of these things helps
<Patrick_H_Lauke> otherwise it'll just end up a confusing mess
<JJ> Aligns with setup for testing to only test one requirement at once
<Patrick_H_Lauke> and looking at efforts like https://
Rachael: with the grouping we're talking about here, we aren't talking about 1:1 relationships. What we're talking about is we need a classification system
<Patrick_H_Lauke> +1 ken
kenneth: to chime in on what Patrick_H_Lauke said… that's on my mind too. The build system will validate against a specified list of tags
GreggVan: instead of tagging with some scheme, should we attach user needs to this instead?
<Patrick_H_Lauke> "user needs" are a classification/tag, no? not sure what the difference is here
Lisa: for the Gold level conformance some things address additional user needs for different functional needs. The issue there is when you increase the amount of tags, the notion of 'helps many different kinds of users' is not as helpful as we might think
… when you say x is useful for cognitive accessibility, or 'it doesn't hurt to…' that's not always true in practical sense
… we want to make sure this is about making it practically useful
… it's very nuanced, we need a strong policy
JJ: wanted to comment on the presentation of categories… I noticed WCAG is now available as JSON, really like that, this allows for different views of the standard. Having clearly defined categories like this will open up a lot of possibilities
Rachael: there's a lot of details that have to be worked out
GreggVan: Lisa makes a good point, we need to look at what's practical. We want to build for the future
… the other one is, we want to figure out what the big barriers are
… some things are helpful, some things are showstoppers
<shadi> +1 to kevin
kevin: I think there's two ways to look at this… “if you fail to meet a requirement, who is that going to have an impact on”, vs “if you meet a requirement, who is it going to benefit”
<Patrick_H_Lauke> +1 to Kevin's distinction
<Patrick_H_Lauke> to me, that underlines the difference here between WCAG being a set of requirements, rather than it being a "manual" of sorts
kevin: so when you do a report, it could include a profile of what impact are the requirements you meet / fail going to have
GreggVan: I'd suggest we do both
… both are important
<Lisa> sounds like rdf
<Patrick_H_Lauke> to me, those are two distinct aims
kevin: Patrick voiced those are two different things, I don't disagree that we could do both.
kevin: is there something different about the groups?
Lisa: we need to say functional need, not disability, as disability names keep changing, they're moving targets, people may not know they have a disability
<Patrick_H_Lauke> it'll start moving from "accessibility" to "usability" for many situations
<Patrick_H_Lauke> (the line is already blurry in many cases anyway)
Lisa: there's a language called RDF that allows you to make nuanced statements about something
… we did that with ARIA before, with OWL
… it will even allow folks to put together their own spec
<Patrick_H_Lauke> RDF is just ... a way to mark something up. like JSON or whatever
<GreggVan> q+ to say +1 to functional need or better yet user need. that is what needs to be met. and most people don't know how to translate "disabilities" into functional needs -- or into what they need to do.
shadi: +1
<JJ> +1 for idea of “forks”
<Patrick_H_Lauke> RDF or not doesn't answer the fundamental question of why/what exactly we're trying to add metadata for/about
shadi: I do want to emphasise how it helps to express severity of an issue, eg this is a blocker, showstopper
<Zakim> GreggVan, you wanted to say +1 to functional need. that is what needs to be met. and most people don't know how to translate "disabilities" into functional needs -- or into what they need to do.
<JJ> But there should also be a “main” spec
<Lisa> RDF is a form of metadata
GreggVan: +1 to point about functional needs… though 'user need' may be even better, they are more concrete and diverse
<Patrick_H_Lauke> it's a data model/syntax.
Rachael: DAF is a framework from Accessibility Community to help people make a mapping
… it's the closest thing I could find to what I believe we need
… would like to ask the group if others know of other frameworks we could potentially use
… but this one can be used for many to many relationships
<Patrick_H_Lauke> still need to decide on a specific ontology, categorisation, WHAT you're actually trying to capture in metadata
kevin: I'd love to translate to 'user need' but not sure how well it would go… would vaguely worry that 'user need' might be more broad and less well defined
<GreggVan> can you repost the link to the page you are showing?
kevin: regarding the idea of impact… we'd need to think about the impact of failing to meet the requirement vs rather than failing to meet specific occurrences
… I also worry we move too much to assessing the impact of the specific design
shadi: in principle I fully agree, shouldn't go down the occurences rabbit hole
kevin: that's the word
shadi: a nuance… we have a requirement on page title, it talks about describing the purpose or intent of the page
… could that give us another layer of how does it help
<kevin> +1 to exploring that idea of 'intent of the page'
shadi: I see all sorts of tools about scoring, could there be something more agreed upon
GreggVan: could a link be posted to the current slide?
Rachael: it will be in the slides after we're done, I'll add it there
Patrick_H_Lauke: the impact of any requirement on a real user is contextual
<Rachael> link to slides: https://
Patrick_H_Lauke: it's dangerous to try and define it too much.
shadi: re Patrick… site wide is almost a second dimension to this
<GreggVan> THX
Rachael: we'll pick it up again next week
Rachael: thanks everyone
… tomorrow we have a breakout session for internationalisation
<kenneth> https://
Rachael: at 8.30
<Rachael> https://
Rachael: it's important for WCAG 2 as well as WCAG 3
… here's the link to the event
Preparation for tomorrow
<Rachael> w3c/
<kenneth> if you needed the breakout issue, it's w3c/
shawn: the comments are in the breakout issue
Rachael: any other questions we want to cover before we wrap up?