23:41:58 RRSAgent has joined #ag 23:42:03 logging to https://www.w3.org/2025/11/09-ag-irc 23:42:03 RRSAgent, make logs Public 23:42:04 Meeting: AGWG Teleconference 23:42:20 agenda+ AGWG retro 23:48:42 wendyreid has joined #ag 23:52:59 Makoto_U has joined #ag 23:58:03 jeroen_ has joined #ag 23:59:18 Jemma has joined #AG 00:00:36 GreggVan has joined #ag 00:01:09 spectranaut_ has joined #ag 00:01:34 gpellegrino has joined #ag 00:02:03 elguerrero has joined #ag 00:02:06 shawn has joined #ag 00:02:34 present+ 00:02:51 AWK has joined #ag 00:03:07 present+ 00:03:10 present+ 00:03:19 present+ 00:03:34 RRSAgent, make minutes 00:03:35 I have made the request to generate https://www.w3.org/2025/11/09-ag-minutes.html alastairc 00:03:44 Jemma - University of Illinois Chicago - Editor and co facilitator of ARIA Authoring Practice Guide Taskforce 00:04:38 present+ 00:04:44 present+ 00:05:03 present+ JaeunJemmaKu 00:05:16 present+ 00:07:03 LenB has joined #ag 00:07:08 present+ 00:07:29 LenB has joined #ag 00:07:29 AWK has joined #ag 00:07:29 elguerrero has joined #ag 00:07:29 Jemma has joined #ag 00:07:29 Makoto_U has joined #ag 00:07:29 jcraig has joined #ag 00:08:39 jamesn has joined #ag 00:08:39 JJ has joined #ag 00:08:39 LenB has joined #ag 00:08:39 AWK has joined #ag 00:08:39 elguerrero has joined #ag 00:08:39 Jemma has joined #ag 00:08:39 Makoto_U has joined #ag 00:08:39 jcraig has joined #ag 00:08:50 present+ Shawn 00:09:42 Retro document https://docs.google.com/document/d/1DxCVBtsbxgOS0mLpoJ4Ur1nU0_MadKzE6q9PGg_MBzE/edit?tab=t.i1jh2ls9zb48 00:09:58 mgifford2 has joined #ag 00:09:58 jamesn has joined #ag 00:09:58 JJ has joined #ag 00:09:58 LenB has joined #ag 00:09:58 AWK has joined #ag 00:09:58 Jemma has joined #ag 00:09:58 Makoto_U has joined #ag 00:09:58 jcraig has joined #ag 00:11:08 Ben_Tillyer has joined #ag 00:11:08 elguerrero has joined #ag 00:11:08 mgifford2 has joined #ag 00:11:08 jamesn has joined #ag 00:11:08 JJ has joined #ag 00:11:08 LenB has joined #ag 00:11:08 AWK has joined #ag 00:11:08 Jemma has joined #ag 00:11:08 Makoto_U has joined #ag 00:11:08 jcraig has joined #ag 00:11:53 present+ AWK 00:12:11 shadi has joined #ag 00:12:11 Ben_Tillyer has joined #ag 00:12:11 elguerrero has joined #ag 00:12:11 mgifford2 has joined #ag 00:12:11 jamesn has joined #ag 00:12:11 LenB has joined #ag 00:12:11 AWK has joined #ag 00:12:11 Jemma has joined #ag 00:12:11 Makoto_U has joined #ag 00:12:11 jcraig has joined #ag 00:12:14 scribe+ 00:12:14 Topic: Retrospective 00:12:14 alastairc: Last retro: onboarding meetings just before the first meeting of each month, and a lot of subgroup work 00:12:24 present+ 00:13:12 q+ 00:13:20 ack GreggVan 00:13:32 shadi has joined #ag 00:13:32 Ben_Tillyer has joined #ag 00:13:32 elguerrero has joined #ag 00:13:32 mgifford2 has joined #ag 00:13:32 jamesn has joined #ag 00:13:32 LenB has joined #ag 00:13:32 AWK has joined #ag 00:13:32 Jemma has joined #ag 00:13:32 Makoto_U has joined #ag 00:13:32 jcraig has joined #ag 00:14:40 shadi has joined #ag 00:14:40 Ben_Tillyer has joined #ag 00:14:40 elguerrero has joined #ag 00:14:40 mgifford2 has joined #ag 00:14:40 jamesn has joined #ag 00:14:40 LenB has joined #ag 00:14:40 AWK has joined #ag 00:14:40 Jemma has joined #ag 00:14:40 Makoto_U has joined #ag 00:14:40 jcraig has joined #ag 00:14:58 q+ 00:15:02 q+ 00:15:05 ack me 00:15:14 q- 00:15:27 +1 to subgroup work going well 00:15:54 Jon_Avila has joined #ag 00:15:54 shadi has joined #ag 00:15:54 Ben_Tillyer has joined #ag 00:15:54 elguerrero has joined #ag 00:15:54 mgifford2 has joined #ag 00:15:54 jamesn has joined #ag 00:15:54 LenB has joined #ag 00:15:54 AWK has joined #ag 00:15:54 Jemma has joined #ag 00:15:54 Makoto_U has joined #ag 00:15:54 jcraig has joined #ag 00:15:55 JJ has joined #ag 00:17:22 JJ has joined #ag 00:17:22 Jon_Avila has joined #ag 00:17:22 shadi has joined #ag 00:17:22 Ben_Tillyer has joined #ag 00:17:22 elguerrero has joined #ag 00:17:22 mgifford2 has joined #ag 00:17:22 jamesn has joined #ag 00:17:22 LenB has joined #ag 00:17:22 AWK has joined #ag 00:17:22 Jemma has joined #ag 00:17:22 Makoto_U has joined #ag 00:17:22 jcraig has joined #ag 00:17:42 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 00:18:02 q+ 00:18:02 q+ 00:18:10 ack GreggVan 00:18:40 Adam_Page has joined #ag 00:19:04 LenB has joined #ag 00:19:04 Jaunita_Flessas has joined #ag 00:19:04 ReinaldoFerraz has joined #ag 00:19:04 JJ has joined #ag 00:19:04 Jon_Avila has joined #ag 00:19:04 shadi has joined #ag 00:19:04 elguerrero has joined #ag 00:19:04 mgifford2 has joined #ag 00:19:04 jamesn has joined #ag 00:19:04 AWK has joined #ag 00:19:04 Jemma has joined #ag 00:19:04 Makoto_U has joined #ag 00:19:04 jcraig has joined #ag 00:19:08 present+ 00:19:09 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 00:19:23 present+ 00:19:28 +1 to GV comments. That said, the expectation is that we figure out a way to go faster. 00:19:34 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 00:19:46 GreggVan: Do things as thoroughly as we need to do. 00:19:48 q? 00:19:52 ack Rachael 00:19:56 Ben_Tillyer has joined #ag 00:20:10 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 00:20:13 q? 00:20:24 q+ 00:20:41 ack Jaunita_Flessas 00:20:55 Jaunita_Flessas: Meetings have been in the middle of the night, is there a way to move some meetings for Asia Pacific timezones? 00:20:57 q+ 00:21:07 ack Makoto_U 00:21:47 mbgower has joined #ag 00:21:54 present+ 00:21:56 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 00:22:49 q+ to comment on timezones 00:23:40 Ben_Tillyer has joined #ag 00:23:47 Ben_Tillyer: Some people who are not vocal are contributing more 00:23:57 ack JJ 00:23:57 JJ, you wanted to comment on timezones 00:24:15 JJ: A11y Task Force, tried to find time that works for most people, very challenging because of different timezones 00:25:00 JJ: Try to do some async work but sometimes rotate meetings to accommodate different times 00:25:04 alastairc: Definite topic for where we can improve 00:25:12 q+ 00:25:21 q+ 00:25:23 ack shadi 00:25:47 rrsagent, make minutes 00:25:48 I have made the request to generate https://www.w3.org/2025/11/09-ag-minutes.html mbgower 00:26:16 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) 00:26:23 q+ to say some things that went well 00:26:27 ack LenB 00:26:58 LenB: Good to see the notes in documents and spreadsheets, challenge was also in timezones 00:27:09 mgifford2 has joined #ag 00:27:23 LenB: How can we do thing async, how do we communicate better, and try to increase visibility and transparency 00:27:24 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. 00:27:51 q? 00:27:59 ack mbgower 00:27:59 mbgower, you wanted to say some things that went well 00:28:16 q+ 00:28:30 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 00:28:49 mbgower: Keeping scratchpads and documents is really handy 00:28:59 q? 00:29:06 ack shadi 00:29:07 ack shadi 00:29:19 shadi: Amazing work on closing issues in WCAG 2 00:32:17 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. 00:32:26 alastairc: Looking for ideas on how to make this timezone aspect easier? 00:32:32 q? 00:32:34 q+ 00:32:42 ack Rachael 00:33:16 Rachael: Trying to have subgroups of people in those particular timezones, e.g. Australia, Japan, China, in those areas 00:33:20 q? 00:34:02 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 00:34:21 alastairc: Some people will not agree with the previous meetings, and there's no central place for decision making 00:34:23 alastairc: Believe subgroups would have that same problem 00:35:03 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 00:35:05 q? 00:35:54 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 00:36:39 Ben_Tillyer has joined #ag 00:37:04 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 00:37:15 kevin: What time is that in Europe? 00:37:23 JJ: 11, 12, or 1am in the evening 00:37:45 Jaunita_Flessas: Maybe just once a month so European colleagues can have the majority of the meetings and once a month for Asia-Pacific 00:38:31 q? 00:38:33 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. 00:38:47 q+ 00:38:48 q+ 00:38:53 q- later 00:39:02 ack Ben_Tillyer 00:39:03 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? 00:39:53 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. 00:40:07 q+ on regulatity 00:40:16 ack me 00:40:38 Fazio has joined #ag 00:40:48 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 00:40:52 present+ 00:40:57 mgifford2: Longers meetings aren't necessarily as effective 00:41:00 q+ 00:41:11 ack alastairc 00:41:11 alastairc, you wanted to comment on regulatity 00:41:22 alastairc: Noticed over the years that if you have irregular meetings you tend to lose participation 00:41:37 Ben_Tillyer has joined #ag 00:41:42 alastairc: Partially because consistency of schedule works for participation of people 00:41:53 +1 to Alastair's point about regularity=attendance. Doesn't solve the problem globally though 00:42:12 ack mbgower 00:42:15 q+ to explore a 2nd meeting 00:42:31 mbgower: Regional basis subgroups don't need to be restricted in topics 00:42:42 q+ 00:42:57 mbgower: Could have subgroups that have multiple topics that smaller groups of people can tackle 00:43:36 mbgower: Choose 2-3 topics of interest in that region — could be valuable in terms of work 00:43:44 +1 to the value of having groups in different TZs 00:43:50 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://www.w3.org/groups/wg/ag/calendar/?tz=UTC&tf=1&past=#export) 00:44:02 q? 00:44:09 ack Rachael 00:44:09 Rachael, you wanted to explore a 2nd meeting 00:44:31 Rachael: Enough work for a second meeting for next few years, what if we did a second meeting that was topic-specific? 00:44:43 Rachael: Focus on one for conformance, one for WCAG 3, one focused on guidelines or 2.x 00:45:06 Rachael: Decision-making meetings but more narrow to let people have 5 days to review and comment back on decisions made 00:45:14 ack Jaunita_Flessas 00:45:30 q+ on keeping up, and the "I missed this but..." 00:45:38 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 00:45:41 q+ 00:45:58 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 00:46:07 ack alastairc 00:46:07 alastairc, you wanted to comment on keeping up, and the "I missed this but..." 00:46:57 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 00:47:08 ack ack GreggVan 00:47:08 ack GreggVan 00:47:08 +1 to the comments of alastairc. It does feel like I've gone back in time by a year or three sometimes 00:47:31 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 00:48:01 q+ to say I think good documentation of decisions and rationales can make a real difference 00:48:10 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 00:49:13 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 00:49:14 q+ on 2 types of work - formative and refining. 00:49:22 +1 to the value of a good core part of groups 00:50:09 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 00:50:26 mgifford2 has joined #ag 00:50:27 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 00:50:28 ack mbgower 00:50:28 mbgower, you wanted to say I think good documentation of decisions and rationales can make a real difference 00:50:43 mbgower: There's a reasonable ask for a person to do the homework and look at what's been done in between meetings 00:50:59 q+ 00:51:04 q+ 00:51:04 mbgower: On the responsibility of the person coming back in and establish where to go for the context of where we are 00:51:05 we've been discussing how to leverage AI with our git issues 00:51:13 ack me 00:51:13 alastairc, you wanted to comment on 2 types of work - formative and refining. 00:51:13 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. 00:51:14 +1 to mbgower 00:52:03 Fazio GitHub right? Not git. 00:52:32 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 00:52:32 where topics are restrictive, almost self-documenting with the summary in GitHub 00:52:39 alastairc: Harder to summarise bigger topics 00:52:44 ack Jaunita_Flessas 00:52:44 ack Jaunita_Flessas 00:53:27 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 00:53:28 q+ to be the AI naysayer 00:54:06 Neha2 has joined #ag 00:54:15 Ben_Tillyer: Used Gemini on the minutes to tell me what happened in those calls 00:54:28 Ben_Tillyer: Personally AI could be used to help keep on top of topics 00:55:21 Ben_Tillyer: Can be explored to help get people stay on top of past/current topics 00:55:38 ack Fazio 00:55:44 ack ben_ 00:56:07 Ben_Tillyer has joined #ag 00:56:26 q+ 00:56:27 Fazio: Some type of collab bet. Microsoft/Copilot and W3C to work with copilot 00:56:44 Fazio: Would help with documentation, comments, issues 00:56:45 ack kevin 00:56:47 kevin, you wanted to be the AI naysayer 00:57:07 q+ 00:57:18 q+ 00:57:26 q- 00:57:34 q+ 00:57:42 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. 00:57:50 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. 00:58:09 present+ 00:58:29 mgifford2: 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. 00:58:55 q? 00:58:55 kevin: It's not a straightforward yes/no answer towards using AI 00:58:59 ack Jaunita_Flessas 00:59:11 s/mgifford2: They/kevin: They/ 00:59:46 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 00:59:50 q+ to say verification has to be live, people don't look at it afterwards. 01:00:32 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 01:00:37 Nothing is perfect, not even human memory or discussions 01:00:57 I think theres more positive than negative to incorporating an AI assistant 01:01:02 ack GreggVan 01:01:25 +1 Fazio 01:01:41 q+ to ask if live AI scribing to IRC has been tried? Gives option to correct during meeting 01:01:49 q+ 01:02:14 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 01:02:27 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 01:02:39 GreggVan: Wouldn't do that to a minute writer 01:03:12 GreggVan: We should try it with AI and correct if we want to and see which is better 01:03:12 Would be super cool to have a running summary of IRC convos too 01:03:26 GreggVan: Sometimes people say amazing things and you can't capture them all the time 01:03:39 scribe- 01:03:42 scribe+ mbgower 01:03:58 ack Ben_Tillyer 01:04:21 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. 01:04:48 q? 01:04:49 ... 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. 01:04:51 ack me 01:04:51 alastairc, you wanted to say verification has to be live, people don't look at it afterwards. 01:05:22 q+ to talk about W£C minute taking 01:05:38 q- 01:05:43 q+ to talk about W3C minute taking 01:05:44 Alastair: Kevin, may know more about what the w3c is doing with minute taking. We need a summarization of documents, minutes, threads, emails... 01:05:58 *robust* 01:06:01 ... Then the IRC side is different. I haven't seen a live-scribe, editable tool. 01:06:23 q- covered by Gregg and Alastair 01:06:34 q- 01:06:40 ... 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. 01:06:42 ack kenneth 01:06:45 ack kenneth 01:07:28 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. 01:07:34 Forgot to say - changes need to be within the meeting, otherwise people don't check them. 01:08:00 ... Trying to correct LLM output is more time intensive. It could take more cycles, especially a transcript. 01:09:12 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. 01:09:24 ... Havent' done anything on integration with IRC. 01:09:52 ... Using AI tools for scribing is not there yet. AI as transcription service is solid. 01:10:02 q? 01:10:06 ack kevin 01:10:06 kevin, you wanted to talk about W3C minute taking 01:10:24 ... The third challenge is summarizing the vast quantity of input. 01:10:38 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. 01:10:38 ... We should be thinking of how to get the most useful AI in each context. 01:11:14 Alastair: For other challenges we could try to improve, how about subgroup participation or asynchronous work. 01:11:15 q+ 01:11:30 ack Jaunita_Flessas 01:11:30 ack Jaunita_Flessas 01:11:40 Jaunita_Flessas: What helps a little bit is detailed documentation. 01:12:02 ... Instructions help make the task less daunting. 01:12:40 ... That can help veterans as well as new people. 01:12:59 Alastair: How would we go about creating that? 01:13:32 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. 01:13:33 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. 01:13:55 ... Or if the task is an update, a template can be useful. Something that is easily accessible. 01:14:10 q? 01:14:11 Alastair: I thought we had those. Apparently not enough. 01:14:36 ... It's a shame Giacomo isn't here. Apparently his group worked effectively. 01:14:42 q+ 01:15:02 scribe+ 01:16:03 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. 01:16:09 ... perhaps it could be issue tracking in a sub-group? 01:16:15 q? 01:16:18 ack mbgower 01:16:34 rrsagent, make minutes 01:16:35 I have made the request to generate https://www.w3.org/2025/11/09-ag-minutes.html kevin 01:17:21 Alastair: Potentially we could have a big github board of requirements. There are over 200 including assertions. 01:17:39 ... We're potentially getting to the point where that could work soon. Until now things were changing too much. 01:17:42 q+ 01:17:49 scribe+ 01:18:03 mbgower: Is there a way to make it more granular and have sub-issues. 01:18:25 shawn: Yes, can have sub-issues. There are some quirks. 01:19:22 rrsagent, make minutes 01:19:24 I have made the request to generate https://www.w3.org/2025/11/09-ag-minutes.html kevin 01:19:30 s/There are some quirks./I find them useful. There are some quirks. 01:20:06 Alastair: So we have a couple of ideas, and about 10 minutes to the break. 01:20:14 If folks want to see the sub-sub issue in GitHub https://github.com/mgifford/w3c-tpac-susty-breakout/issues/3 01:20:26 ... The central spreadsheet worked well for some people. 01:20:42 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. 01:20:59 ... Most of the difficult things were getting people involved, and the time zones. 01:21:04 q+ 01:21:22 ack mbgower 01:21:32 rrsagent, make minutes 01:21:33 I have made the request to generate https://www.w3.org/2025/11/09-ag-minutes.html kevin 01:22:06 q+ 01:22:11 mbgower: If we could create culture for more experienced people to shut up, and less experienced feel they can jump in more. 01:22:12 q+ to ask if github helps 01:22:23 Talking sticks? 01:23:00 Alastair: Before I do continue with the queue, I want to encourage people to get on queue to contribute something more. 01:23:11 ... +1s are really helpful to help us understand support. 01:23:16 denkeni has joined #ag 01:23:20 q+ 01:23:23 ... We do have to make some progress. 01:23:24 ack GreggVan 01:23:44 Gregg: We need to stop people from getting in line to restate things. 01:24:21 ... But we want to encourage anyone to speak again if they have something new to say. 01:25:01 ... 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. 01:25:09 It's the art of meeting management 01:25:32 Janina does something similar 01:25:35 ... Some people are not interesting in commenting. So they find other channels. We can help create those. 01:25:35 ack Rachael 01:25:36 Rachael, you wanted to ask if github helps 01:25:57 Rachael: We had a similar conversation in another retro. 01:26:08 ... I'm curious whether the githubs threads were successful. 01:26:26 ack Ben_Tillyer 01:26:40 alastairc: To expand on that, we have less surveys. Have the github discussions helped? 01:27:18 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. 01:27:30 q+ 01:27:31 ... Maybe we should have some designated ponderance time. 01:27:38 ack GreggVan 01:28:07 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. 01:28:47 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? 01:28:54 q+ 01:29:00 ack AWK 01:29:06 ... It didn't help the chairs understand what the consensus might be. 01:29:17 AWK: The discussions are great, but they never end. 01:29:28 ... It starts to be like a marathon you never signed up for. 01:29:47 ... If you don't pay attention at the right time, things get resolved. 01:30:32 ... Those are things that are nice about the surveys, CFCs and meetings, where there is a deadline. 01:31:07 kevin: The break is from 10:30 to 11. It's half an hour. Lunch is today at 12:30 until 1:45. 01:31:38 ... There is an afternoon break from 3 to 3:30. It is currently 10:30 JST. 01:32:04 Tamsin has joined #ag 01:32:50 RRSAgent, draft minutes 01:32:51 I have made the request to generate https://www.w3.org/2025/11/09-ag-minutes.html kenneth 02:03:49 q+ 02:04:58 Present+ 02:05:12 present+ 02:05:54 q+ 02:05:55 alastairc: I'm not sure what the external reaction has been, to respond to Ben's question. 02:05:59 ack Ben_Tillyer 02:06:01 ack Ben_Tillyer 02:06:24 Rachael: There seems to be the most excitement around having user centred processes. 02:07:02 ... 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. 02:07:03 ack kevin 02:07:24 kevin: We have the potential to piggyback WCAG 3 on a few CSUN topics. 02:07:49 [ Shawn is doing a session at CSUN and plans to include some on WCAG 3 ] 02:07:50 ... I can't think of another specification that is comparable to this. 02:08:26 ... We are seeing areas like security and privacy and approaching similar questions. 02:08:43 s/privacy and approaching/privacy approaching 02:09:08 alastairc: To summarize, we will look at scheduling meetings at different times. 02:09:28 ... We will try to use surveys or other mechanisms to draw topics to a close. 02:09:53 q+ to say an action to set deadlines on github discussions 02:09:56 ... We will investiate AI tools for summarizing, separate from minute taking. 02:10:00 ack Rachael 02:10:00 Rachael, you wanted to say an action to set deadlines on github discussions 02:10:12 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 02:10:16 ... We will consider the best way of organizing across project boards. 02:10:28 q+ 02:10:35 ack shadi 02:10:57 shadi: Do the chairs and leadership have reflections on what went well and not so well. 02:11:10 q+ 02:11:17 q+ 02:11:44 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. 02:12:19 ... That will allow people to come back in with the background. 02:12:25 q+ 02:12:32 q- later 02:12:50 ... We try new things fairly regularly. I think the maturity level approached helped. 02:13:11 alastairc: The parallel subgroups worked quite well. 02:13:45 ... It's hard to start a new structure. Hopefully we've got more things in place. 02:14:18 ... The editors' week worked well. We haven't covered that, but dedicated time to try to draw everything together was very useful. 02:14:25 ack Rachael 02:14:27 ack me 02:14:44 ack kevin 02:15:15 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. 02:15:35 +1 to wanting to hear everyone's voice 02:16:03 ... 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. 02:16:58 q+ 02:17:18 ack Rachael 02:17:21 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. 02:17:44 Rachael: We didn't slip anything more than 45 days. We made our targets. 02:18:04 q? 02:18:22 agenda? 02:18:38 alastairc: We have an old agenda... 02:18:47 clear agenda 02:18:49 Kevin: Are you just going to do topics? 02:19:02 TOPIC: Schedule and future work 02:20:06 Rachael: We are going to start by going over the next 4 years' schedule. 02:20:06 https://docs.google.com/presentation/d/1lrSm4JSt7vgmXdAJwO0cASqp11EGYoCCR6Ni2OkWBzk/edit?slide=id.p#slide=id.p 02:20:41 [shares deck] 02:20:51 [slide 2] 02:21:04 Rachael: We have three key deliverables. 02:21:42 ... WCAG 3 normative, the larger set of supporting documentation, and some kind of update to WCAG 2 covering normative updates, but no additional requirements. 02:21:47 +1 for wcag 2.x backlog inclusion 02:21:58 2.2.1 ;) 02:22:13 ... WCAG 2? is just to indicate we do not know what to call this right now. 02:22:43 [Assumptions slide] 02:23:52 Rachael: We continue 2-week charters. The WCAG 2 TF continues, outside the main work. 02:24:04 q+ 02:24:14 s/WCAG 2? /WCAG 2.? 02:24:29 Rachael: We continue to have enough participants to have 5 subgroups 02:25:25 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. 02:26:06 ... 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. 02:26:09 q+ 02:26:16 ack GreggVan 02:26:22 ... That's going to be disruptive and difficult to adopt. 02:26:45 alastairc: We have scoping changes tomorrow for WCAG 2. Let's not talk about the name yet, please. 02:26:47 q- 02:26:52 q? 02:27:07 2.2 Alpha Zero Black edition 02:27:19 Rachael: The intent is to do one normative update. We will talk in more detail tomorrow. 02:27:34 [Terminology slide] 02:28:15 [Key Takeaways slide] 02:28:29 Rachael: We plan to publish second half of year of 2029. 02:28:54 q+ 02:29:01 ... The candidate rec would come out two years before that, end of 2027 02:29:31 ... WCAG 2 update would be 2026 for comment, publish second half 2027. 02:29:38 [Detailed schedule] 02:30:43 Rachael: This table is a 4x4 table, with the three items in columns and the first column providing row headings for each quarter of 2026. 02:31:07 s/4x4/4x5 02:32:05 [Detailed schedule 2027 slide] 02:32:50 [Detailed schedule 2028 slide] 02:33:04 Rachael: WCAG 3 would be getting a lot of comments. 02:33:51 [Detailed schedule 2029 slide] 02:34:11 Rachael: We have scheduled in some slip in the second half of the year. 02:34:36 [Detailed schedule 2030] 02:35:00 Rachael: We would be working on backlog work and the supplemental documentation. 02:35:11 ack GreggVan 02:35:24 q+ 02:35:25 Looks reasonable to get there within 5 years 02:35:30 GreggVan: I thought CR just happens before publishing. 02:35:42 ... Maybe I don't understand what Candidate Recommendation mens. 02:35:47 q+ 02:35:54 s/mens/means/ 02:36:07 ... I worry about the ambition of the schedule 02:36:31 ... I'd rather it be scheduled by the maturity, not the date. 02:37:09 ... I don't people realize how far we have to go. We are not as far along as perceived. 02:37:30 ... We found that the understanding and techniques work informed the normative language. 02:37:41 regarding Candidate Recommendation definition https://www.w3.org/policies/process/#RecsCR 02:37:57 ... 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. 02:38:08 ack me 02:38:10 ... I like the plan overall. Those are just the two main considerations. 02:38:47 q+ to speak to the group's ability to focus on two specs which are potentially adopted into regulation. 02:38:49 scribe+ JJ 02:39:58 ack shadi 02:40:05 alastairc: getting to refining stage, assuming the content will be mature 02:40:10 q+ to speak to the methods 02:41:00 shadi: Timeline is ambitious, what are the maturity levels and what is the full WCAG 3 package? 02:41:02 q+ 02:41:34 … in multi year development, how to sync all materials 02:41:38 Supplimental docs = informative docs, how-to, methods, tests 02:42:17 … for evaluation, how can we go beyond WCAG-EM 02:42:32 q+ to mention prior and background work on supplemental materials 02:42:45 … evaluation can impact the criteria 02:43:28 … we have learned from WCAG 2 and ACT that we things are tested in practice the requirements can be ambiguous 02:43:57 q+ on tests being part of it from the start 02:44:02 ack AWK 02:44:02 AWK, you wanted to speak to the group's ability to focus on two specs which are potentially adopted into regulation. 02:44:05 … I would like to see definition of supplemental guidance 02:44:50 AWK: speaking from experience working on silver, WCAG 3 and 2.1 and 2.2… 02:45:18 … people are going to focus on the standard that is closest to what supports their organisation best 02:45:23 agree, but ... pragmatically, can't blame organisations for concentrating on the here and now 02:45:28 … the longer development takes the 02:45:32 q+ 02:45:36 ack Rachael 02:45:36 Rachael, you wanted to speak to the methods 02:45:39 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. 02:45:41 … larger the risk of it not being adopted 02:46:31 Rachael: tests and methods are critical but we should not forget role based guidance eg for designers 02:46:45 … they can feed into requirements 02:46:53 q+ 02:47:14 … we will do async reviews 02:47:22 ack Patrick_H_Lauke 02:48:10 q+ to comment on making things more atomic 02:48:30 Patrick_H_Lauke: commenting on non-normative work, the term “normative” is often not understood by target audience 02:48:31 q+ 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. 02:49:11 … first normative and then understanding is not an option, should be a full package at publication 02:49:18 +1 to defining the "WCAG3 package" 02:49:34 ack kevin 02:49:35 kevin, you wanted to mention prior and background work on supplemental materials and to comment on making things more atomic 02:49:39 q- 02:50:26 q+ 02:50:33 kevin: The “WCAG3 package” definition has been worked on, but not finished. 02:50:38 q+ 02:50:49 … in WCAG 2 there are a 02:51:01 … lot of understanding documents 02:51:05 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 02:51:50 … one of the steps that helps is to break things down, e.g. one atomic requirement at a time 02:51:55 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 02:51:55 +1 to granular requirements 02:51:58 ack me 02:51:58 alastairc, you wanted to comment on tests being part of it from the start 02:53:14 alastairc: informative/supplemental documentation - understanding and techniques are being pulled to the top 02:53:18 ack AWK 02:53:18 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 02:53:22 ... changes. 02:53:45 q+ on the normative changes 02:53:47 ack shadi 02:53:51 AWK: backlog tf has been working so smoothly due to non-normative changes 02:54:02 [ shawn notes potential confusion between "WCAG 2 Supplemental Guidance" https://www.w3.org/WAI/WCAG2/supplemental/ and WCAG 3 "supplemental content" 02:54:31 shadi: we need to draw the line, and define what is at the core of the necessary documentation 02:54:39 (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) 02:54:59 q+ 02:55:03 ack Rachael 02:55:07 … moving away from supplemental as that could be seen as addendum 02:57:06 alastairc: it takes 6 weeks to 6 months to create and then much longer to actually publish 02:57:17 q+ to say https://www.w3.org/TR/WCAG22/#background-on-wcag-2 "supplemental guidance" 02:57:26 ack shawn 02:57:26 shawn, you wanted to say https://www.w3.org/TR/WCAG22/#background-on-wcag-2 "supplemental guidance" 02:57:49 (6 weeks to 6 months ... "string length measurement task force") 02:58:04 shawn: avoid using “supplemental guidance” in WCAG 3 as it has a very specific meaning in WCAG 2 02:58:56 alastairc: we can bring tests and user needs into the requirements 02:59:20 q? 02:59:29 q+ 02:59:34 ack shadi 02:59:35 … a lot of iteration is needed after reaching the base maturity 03:00:04 shadi: still lost, is there a definition for WCAG 3 package 03:00:15 q+ 03:00:30 Rachael: this term is new to me but will be working on defining it 03:00:35 ack shawn 03:00:59 q+ 03:01:02 q+ 03:01:14 shawn: how can we get to shared understanding ? 03:01:48 q+ to say Understanding, Methods, Tests are the key ones. Where to start and such can follow later. 03:01:57 q+ to transition us to the next conversation 03:02:02 shadi: we need to map out in more detail what these informative documentations will include and how they relate 03:02:07 s/how can we get to shared understanding/do you have an initial list to share now to get to shared understanding? 03:02:28 ack GreggVan 03:02:28 GreggVan, you wanted to say Understanding, Methods, Tests are the key ones. Where to start and such can follow later. 03:02:34 … for example what will they achieve 03:03:00 q+ to disagree with Gregg 03:03:00 GreggVan: understanding and tests are key 03:03:24 … other things can come later even though they are important 03:03:30 ack me 03:04:46 alastairc: these things have been prototyped before. You have informative documents and notes. We explored tagging and filtering. 03:05:16 … we got methods. Tests. User needs. Brief rationales to go with requirements 03:05:16 ack Rachael 03:05:16 Rachael, you wanted to transition us to the next conversation 03:05:35 Rachael: Shadi first 03:05:38 ack shadi 03:05:38 shadi, you wanted to disagree with Gregg 03:05:41 q+ Rachael 03:06:15 shadi: we have discussed what is part of core, eg reporting, measuring how well a website performs. 03:06:32 … this would influence how requirements are structured 03:06:59 … when working on WCAG-EM we found a lot of issues but were unable to make changes to WCAG 03:07:37 … Therefore these need to be developed together, staggered or sequenced 03:08:03 alastairc: transitioning to task forces for next charter slide 03:08:36 Rachael: acknowledging the topic, will get back to it later 03:08:56 q+ 03:09:10 ack Rachael 03:09:37 … mentioning the task forces listed on slide 03:10:06 … coga, act, mobile, WCAG backlog, wcag2ict… 03:10:25 q? 03:10:35 ack shadi 03:10:40 … policy, usability testing and assertions, low vision, something else? 03:11:24 q+ 03:11:26 … I’m asking which need to be part of next chapter 03:11:33 charter 03:11:36 q+ positive on policy guidance task force 03:11:48 q+ jeroen_ 03:11:52 q- pos 03:11:55 q+ 03:12:02 shadi: can this be driven by its need and not by names or structures 03:12:23 … how can WCAG 3 be addressed more broadly? 03:12:45 … a (new) group could address this in various forms 03:13:03 … first define needs then structures 03:13:10 q+ on TFs (generally) having their own deliverables, and needing own email list etc. 03:13:34 q+ to say I don't think we need WCAG2ICT equivalent 03:13:40 ack GreggVan 03:14:03 q- 03:14:03 scribe- 03:14:05 +1 03:14:36 GreggVan: WCAG2ICT might not be needed, they are very busy already working on AAA guidance (WCAG 2.2) 03:15:00 +1 for topics first (rather than TFs) 03:15:20 … WCAG3ICT, do research where it falls shorts on non web 03:15:55 … re special interest groups VS task force 03:16:22 +1 COGA more of a special interest group atm. 03:16:28 … coga has been in the middle of everything 03:16:38 … a tf should do a task and then dissolve 03:16:44 +1 to scoped TFs 03:16:46 q? 03:16:50 ack jeroen_ 03:17:01 +1 03:17:06 [ Shawn has specific input on Low Vision TF and contrast algorithm, though I think not worth taking time now ] 03:17:17 jeroen_: positive about policy task forces listed 03:17:17 ack Rachael 03:17:54 q+ 03:18:24 Rachael: special interest topics can be important without needing to be a task force 03:18:26 ack alastairc 03:18:26 alastairc, you wanted to comment on TFs (generally) having their own deliverables, and needing own email list etc. 03:18:46 q+ 03:18:49 q+ 03:18:54 alastairc: TFs work best when they have a clear deliverable 03:19:11 q- 03:19:19 … I would like MATF to check next WCAG 3 release to identify gaps 03:19:56 … we are building in the “non web” part, wcag3ict might not be needed 03:20:00 q+ 03:20:08 (as a side note ... i always ready the "2" in WCAG2ICT as meaning "to", as in "how to apply WCAG to ICT". so wouldn't need to be called WCAG3ICT) 03:20:14 2Fast2ICT 03:20:23 s/ready/read 03:20:30 ack kevin 03:20:33 … notes can be created by groups to be referenced in WCAG 3 03:21:12 kevin: tf is artificial in terms of processes. No technical reports can be published. 03:21:32 kevin: TF is confined to the charter of its parent WG 03:21:36 ack GreggVan 03:21:39 +1 to Kevin 03:21:41 q+ 03:21:42 … define what outcomes are and then figure out vehicle for delivering 03:22:06 GreggVan: re COGS 03:22:17 ack shawn 03:22:28 GreggVan: re COGA not intended to downplay but to make more mainstream 03:22:40 s/GreggVan: re COGS// 03:23:13 shawn: contrast algorithm is still a big issue for low vision TF 03:23:35 ack shadi 03:23:52 … but that topic can derail the WG processes so we have to be careful how to incorporate 03:24:32 shadi: figure out topics for WCAG 2 and 3. 03:24:47 … AI should also be considered 03:25:02 … what are the lessons learned 03:25:16 q+ 03:25:38 AI is such a vague term, that means all sorts of things to people... this would need to be very specifically defined first 03:25:48 … it might not be tf or subgroup, but some way of people getting together to focus on specific topics like AI 03:25:51 +1 to Patrick_H_Lauke 03:25:57 ack mbgower 03:26:01 +1 to Patrick_H_Lauke 03:26:20 s/contrast algorithm is still a big issue for low vision TF/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. 03:26:31 mbgower: can we touch base with all task forces and let them give feedback 03:27:07 q? 03:27:13 … what are lessons learned to bring us to the next stage 03:27:25 q? 03:27:50 ACT-rules 03:27:55 Rachael: before we move on, can you speak more about testing shadi 03:28:10 q+ to mention ARIA testing discussion... although probably later 03:28:44 shadi: I meant what are the take aways and can we formalise the lessons learned 03:28:44 ack kevin 03:28:44 kevin, you wanted to mention ARIA testing discussion... although probably later 03:29:08 +1 to the aria discussion. There's a session on it this week, right? 03:29:37 kevin: there is ongoing discussion in ARIA about testing, can learn from this. Friday joint meeting 03:30:23 Rachael: [ ending with summary, lunch break starts ] 03:30:56 Kevin: [ helps everyone not to miss lunch location ] 04:28:47 s/… but that topic can derail the WG processes so we have to be careful how to incorporate// 04:52:24 scribe+ 04:53:23 present+ 04:54:17 Rachael: we talked about policy guidance, brief mention of AI, talked normative + support docs, mobile/epub/kiosks/tv/vr 04:54:22 present+ 04:54:25 present+ 04:54:41 let me know when you would like the Brief AI explanation 04:54:52 q+ 04:54:57 Rachael: reporting. Anything else that popped up during lunch/powernaps? 04:55:12 ack GreggVan 04:55:38 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 04:55:54 q+ 04:55:59 Gregg: will also allow progressive descriptions 04:56:05 q+ 04:56:09 Gregg: interrogating browser interactively about images 04:56:29 Gregg: simplifying language, removing idioms, explaining idioms, etc 04:56:36 so ... magic ... 04:57:00 Gregg: same with contrast - modifying things dynamically 04:57:02 Q+ 04:57:15 Rachael: think that was not only context for AI 04:58:12 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 04:58:23 q+ 04:58:42 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 04:58:44 Present+ 04:59:11 q+ 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. 04:59:11 Shadi: when I raised AI i meant more in authoring sense - writing requirements so that they can be machine-readable. AI for testing purposes. 04:59:40 ack shadi 04:59:48 ack hdv 04:59:50 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 05:00:34 q+ to say that the requirements don't change based on how they are met (ai vs author) 05:00:49 q+ 05:00:50 Hidde: think future where browser magically fixes things with "AI", sounds like an "accessibility toggle". we need to be careful that we can't rely on it, particularly if working in areas like specification/verification 05:01:01 ack Lisa 05:01:02 Hidde: "accessibility dongle" 05:01:02 s/toggle/dongle 05:02:15 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... 05:04:18 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 05:04:54 Lisa: "AI" has potential to be trained for testing for things that are easy to test for 05:05:39 Lisa: what already works well today is reading text in images, pretty reliably 05:06:24 ack GreggVan 05:06:27 Lisa: do we then say "don't use text in images", but rather "make sure to test in all current AIs/UAs" 05:06:36 present+ 05:07:20 q+ to note it will benefit our work if disambiguate specific types of AI 05:08:04 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 05:08:24 q- 05:08:43 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 05:08:53 ack me 05:08:53 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 05:08:57 ... guidelines. 05:09:17 ack kenneth 05:09:33 q+ 05:09:47 Ken: something Hidde said last time spurred common phrase: "remember to prioritise human-first output" 05:10:15 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 05:10:16 ack hdv 05:10:16 hdv, you wanted to note it will benefit our work if disambiguate specific types of AI 05:10:39 ack shadi 05:10:43 Hidde: we also need to disambiguate "AI". LLMs, machine-learning... they are different, do different things, different consequences 05:10:48 q+ 05:11:25 Q+ 05:11:54 q+ on how to meet aspect & accessibility supported 05:11:56 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 05:12:05 q+ 05:12:10 ack Rachael 05:12:34 Rachael: we covered some of this before. technology-neutral. neutral from person solving them. 05:13:09 q- 05:13:14 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 05:13:20 +1 to rachael 05:13:27 present+ 05:13:59 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 05:14:09 +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. 05:14:13 Lisa: COGA has document on risks to users FROM AI 05:14:33 Lisa: including mental health and safety 05:14:54 ack Jaunita_Flessas 05:14:56 Lisa: need to scope out what's included in COGA group, in AT, ... 05:14:59 ack Lisa 05:15:21 Jaunita: getting back to point about getting specs out faster, not just tech agnostic, but fast-tracking updates if technology updates 05:15:39 Jaunita: without having to go through lengthy w3c process, to keep up with technology 05:15:40 q+ 05:15:43 ack Rachael 05:16:16 +1 to spending some time on user agents and authoring tools 05:16:23 +1 05:16:24 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? 05:16:28 q+ 05:16:35 Alastair: essentially a seaparate topic... 05:16:39 ack Jaunita_Flessas 05:16:40 q+ to reply about user agents 05:17:22 Jaunita: i think yes. could also ask UAs to do more 05:17:39 q+ 05:17:48 ack JJ 05:17:48 JJ, you wanted to reply about user agents 05:18:01 q+ to say we don't require but can inspire 05:18:07 Jaunita: same for authoring tools, requiring them not to create inaccessible content 05:18:21 good luck with that. we've seen low-to-no traction for UAAG and ATAG in the past 05:19:00 ack kevin 05:19:51 JJ: going beyond user agent, possible to talk about other deeper aspects (available in say native mobile development, like detecting is AT is running) 05:19:51 q+ 05:20:12 Kevin: we can write standards, nobody forces people to follow them... 05:20:54 Keving: 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... 05:21:12 s/Keving: /Kevin: 05:21:24 Kevin: there is work on authoring tools guidelines, working with accessibility standards canada 05:21:49 Kevin: within that there will be much more engagement with authoring tool vendors 05:21:49 q? 05:21:52 ack hdv 05:21:52 hdv, you wanted to say we don't require but can inspire 05:22:36 Authoring Tool Accessibility Guidelines Community Group (ATAG CG) https://www.w3.org/community/atag/ 05:22:52 Could you please give me the slides URL 05:23:04 Hidde: user agents are in good position to make positive changes...if they engaged. worked on authoring tool engagement with Shadi at the time 05:23:11 s/Could you please give me the slides URL// 05:23:13 Hidde: would love to see more of that 05:23:15 q? 05:23:18 ack shawn 05:23:27 Thank you very much 05:23:38 s/Thank you very much// 05:24:05 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 05:24:42 q+ on accessibility supported complexity 05:24:46 ack shawn 05:24:47 Shadi: if i had to pick, i'd say authoring tool work would get us more mileage, so not sure about prioritisation on authors 05:24:51 ack shadi 05:24:53 ack me 05:24:58 ack alastairc 05:24:58 alastairc, you wanted to comment on accessibility supported complexity 05:25:49 s/authoring tool work would get us more mileage/user agent work would get us more mileage 05:25:56 Alastair: accessibility support set is where things like "images in text" comes in. 05:26:14 Alastair: also, if you're testing contrast, should you assume that "increase contrast" is enabled on the platform the user is on 05:26:16 q? 05:26:18 q+ 05:26:23 ack kevin 05:26:50 Kevin: coming back to Shadi's points - think you said authoring tools when you meant user agents... 05:27:06 s/where things like "images in text" comes in/where things like "images in text" comes in as a user-agent method might work on one platform but not another. 05:27:29 Shadi: sorry, i meant user agents - i.e. on previous point, resource allocation should prioritise user agents where most impact could happen 05:27:34 q+ 05:27:50 ack shadi 05:27:51 q+ to say can we wrap up this topic 05:28:09 q+ 05:28:14 q- 05:28:29 q+ 05:28:36 ack mbgower 05:28:47 q- 05:28:59 Mike: note that this works really well, until it doesn't work... (relying on user agents to magically fix things) 05:29:52 Mike: (gives example of on mobile, resize text and reflow being almost mutually exclusive - resize means zooming, which leads to bidirectional scrolling failing reflow) 05:30:44 q+ 05:31:05 Alastair: reflow and resize text ... think there are options there 05:31:12 ack Patrick_H_Lauke 05:31:19 scribe+ 05:31:41 q+ to say can we transition to the next topic 05:32:37 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. 05:32:49 ack Rachael 05:32:49 Rachael, you wanted to say can we transition to the next topic 05:32:59 q+ to say do we ahve a source of truth for correct behaviour? 05:33:05 q+ 05:33:09 Rachael: we dove a little deeper in these topics than others. are there other topics? 05:33:24 ack mbgower 05:33:24 mbgower, you wanted to say do we ahve a source of truth for correct behaviour? 05:34:08 q- 05:34:12 q+ to comment on source of truth for non web 05:34:29 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") 05:34:46 +1 05:34:47 q+ that should be under the requirement level, e.g. methods. 05:34:50 q+ to ask about the WCAG i18n issues, and separating "Low Vision (Color Contrast Algorithm) 05:34:54 q+ to say that should be under the requirement level, e.g. methods. 05:35:00 Mike: when we talk about accessibility supported, what does that mean? one browser? two browsers? current AT? what is "current"? 05:35:18 ack JJ 05:35:18 JJ, you wanted to comment on source of truth for non web 05:36:11 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 05:36:33 ack shawn 05:36:33 shawn, you wanted to ask about the WCAG i18n issues, and separating "Low Vision (Color Contrast Algorithm) 05:36:37 JJ: but also, the more agnostic you make it, the more "fake" it becomes 05:37:03 Shawn: i advocate for fixes happening early instead of late. e.g. authoring tool, rather than leaving it up to browser 05:37:36 +1 to Shawns point of earlier = better, so authoring tool helping get it right at the start rather than user agent fixing afterwards 05:37:40 q+ 05:37:50 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? 05:38:03 ack me 05:38:03 alastairc, you wanted to say that should be under the requirement level, e.g. methods. 05:38:04 s/fake/vague 05:38:04 Shawn: known issue, there for a while, but not sure if it fits on your list of topics/concerns 05:38:58 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 05:39:19 Alastair: SR, voice input, fairly limited set. other regions/regulators/organisations could create their own sets 05:39:57 Alastair: to say whether something IS available in that particular region's set. game-able, but should be ok... 05:40:03 q? 05:40:06 ack shadi 05:40:29 Alastair: some requirements may be satisfied by just one - user agent, authoring tool, etc - and others may be satisfied by multiples 05:40:58 q? 05:41:07 Shadi: there are cases where offloading to user agent is only realistic option as there are no author methods available 05:41:53 Rachael: other ideas, let me know. moving to next topic, Accessibility testing working group 05:42:04 Kevin: short topic ... 05:43:19 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? 05:43:30 q+ 05:43:35 Kevin: ARIA WG are looking at this as well, see if we coordinate 05:43:48 ack Rachael 05:43:49 Kevin: AGWG and ARIA are meeting to discuss this on friday 05:44:02 q+ to ask about two different things? 05:44:26 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 05:44:27 ack shawn 05:44:27 shawn, you wanted to ask about two different things? 05:44:36 scribe- 05:44:36 I can see that also working well non-web testing techniques. 05:45:01 s/well/well for 05:45:12 q+ 05:45:18 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... 05:45:21 q+ to say yes, i htink so 05:45:25 Kevin: can I respond? ... yes 05:45:34 q- 05:45:41 +1 to shawn 05:45:43 Shawn: request to use better terminology, two buckets, not lumping together 05:46:31 q+ to say which? 05:46:40 ack mbgower 05:46:40 mbgower, you wanted to say yes, i htink so 05:46:42 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 05:46:59 Mike: agree with Kevin. to me interop is different issue. source of truth for me is how to verify 05:47:02 q+ 05:47:53 q- later 05:48:02 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 05:48:08 Remembering that testing contrast with an eye-dropper compared to the source code can be different. 05:48:10 q? 05:48:41 (My name is Earl?) 05:49:13 q+ 05:49:17 ack shadi 05:49:28 Mike: ... proprietary systems, maybe Apple need to say what THEIR source of truth is on their platform... 05:49:36 s/(My name is Earl?)// 05:50:22 Shadi: separating out the aspects/overlaps is useful 05:50:27 ack shawn 05:50:27 shawn, you wanted to say which? 05:50:34 Shawn: would be good to do before next meeting 05:50:37 ack alastairc 05:51:21 q+ to ask where things fit 05:51:26 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" 05:51:27 ack shawn 05:51:27 shawn, you wanted to ask where things fit 05:52:00 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 05:52:07 Shawn: when doing WCAG3, some people said one approach is "write the test first". where would this approach fit? 05:52:32 Alastair: Kevin, what was motivation from other groups? 05:53:16 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 05:53:33 Shawn: were they talking about interoperability, or more ACT? 05:53:48 Kevin: both. this is exploratory, just looking at all different testing efforts 05:54:08 Kevin: does this fit together in some way, to help us reach a better testing model 05:54:23 "testing of content meeting success critieria" 05:54:36 q+ 05:54:45 ack shawn 05:54:45 Kevin: are we repeating work? should we bring things together? 05:54:59 q+ 05:55:09 q+ 05:55:13 q+ to have leverage over vendors to expose accessibility properties 05:55:22 ack Jaunita_Flessas 05:55:56 Jaunita: when we talk about testing, a lot of people talk about functional testing... 05:55:59 q- 05:56:32 Jaunita: a lot of testing places seem to rely on SR testing, contrast testing, nobody looking at code anymore 05:56:39 ack JJ 05:56:39 JJ, you wanted to have leverage over vendors to expose accessibility properties 05:57:31 q+ 05:57:44 ack mbgower 05:58:01 q+ 05:58:19 JJ: can we do anything about making sure a11y attributes are exposed from shadow dom etc? (sorry, paraphrasing) 05:58:37 Mike: going back to source of truth. page as presented to user? a11y tree? code underneath? 05:58:40 q+ on how we acknowledge platform difficulties, we can't dictate how platforms report or progress 05:59:32 Mike: for end user, it's a failure. who's responsible? more of an issue from compliance perspective 05:59:35 Not require, but at the least, we can suggest? 06:00:37 +1 to Mike 06:00:41 q- 06:00:46 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 06:01:33 Kevin: on JJ's point ... that highlights "who should be doing that". our remit, ARIA's remit, (WHATWG?) 06:01:49 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. 06:02:04 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? 06:02:24 Alastair: coffee 06:20:10 scribe- 06:34:25 present+ 06:34:35 present+ 06:34:50 scribe+ 06:35:09 TOPIC: WC3 Process Discussion 06:35:24 s/WC3/W3C 06:35:31 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 06:35:32 https://www.w3.org/policies/process/ 06:36:28 ... 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. 06:38:06 ... I will be taking notes and bringing it back to the AB, our goal is to make parts of the process better for everyone. 06:38:27 scribe- 06:53:04 scribe+ 06:53:42 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-@@ repo 06:53:52 scribe- 06:54:10 s/ab-@@/ab-memberonly (https://github.com/w3c/AB-memberonly/) 06:55:09 TOPIC: Functional Needs 06:55:41 scribe+ 06:56:11 Rachael: one suggestion that was made was EN 301 549, the editors group tried to use EN 301 549 without privacy 06:56:34 ... we found there were requirements that concern mental health, complexity of cognitition and motion 06:56:52 ... there were things we were marking that did not have a EN 301 549 functional need associated 06:57:17 ... there is also a functional needs framework that is slightly different from the Digital Accessibility Framework 06:58:16 ... 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 06:58:28 ... if we lose the top level, we lose some of the subtleties 06:59:08 ... 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? 07:00:52 ... so what kind of grouping do we want? 07:01:38 Jaunita_Flessas: aren't there other cognitive accessibility categories not related to executive function? 07:01:46 Rachael: yes we could have a longer list of some of these 07:02:33 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 07:02:56 ... when the W3C made a first stab to functional needs and we had more 07:02:57 q+ 07:03:05 Maybe we need to include occupational therapists and assisitve technology specialists and such in the discussion? 07:03:26 *assisitve 07:04:04 ack GreggVan 07:04:04 ... it could be that all problems are from auditory discrimination. It'd be strange to group together people with contrasting skills 07:04:29 GreggVan: I'd like to suggest we don't do any kind of grouping 07:04:51 ... we should be thinking about tagging. Each requirement can apply to a variety of different groups 07:04:57 q+ 07:05:01 +1 for one to many tagging. 07:05:19 I'd be careful that "tagging" will also then need a clearly defined taxonomy/set of tags/labels 07:05:25 ... we should highlight the many ways in which each of these things helps 07:05:27 otherwise it'll just end up a confusing mess 07:05:36 Aligns with setup for testing to only test one requirement at once 07:06:25 q+ 07:06:40 and looking at efforts like https://www.section508.gov/develop/mapping-wcag-to-fpc/ ... yes you'll end up with things that literally fall under/get tagged for EVERYTHING 07:06:43 ack Rachael 07:06:44 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 07:06:51 ack kenneth 07:07:10 +1 ken 07:07:15 q+ 07:07:17 kenneth: to chime in on what Patrick_H_Lauke said… that's on my mind too. We want to make sure we only tag with a specified list of tags 07:07:20 ack GreggVan 07:07:22 Q+ 07:07:52 GreggVan: instead of tagging with some scheme, should we attach user needs to this instead? 07:07:59 q+ structured tagging allows for multiple views (like WCAG JSON) 07:08:02 ack Lisa 07:08:10 "user needs" are a classification/tag, no? not sure what the difference is here 07:08:30 q+ 07:08:34 q+ to say user needs are great but challenge is they are not 'standardised' and not at requirement level... could be though 07:09:02 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 07:09:10 q+ 07:09:22 q- 07:10:21 ... when you say x is useful for cognitive accessibility, or 'it doesn't hurt to…' that's not always true in practical sense 07:10:39 s/We want to make sure we only tag with/The build system will validate against/ 07:11:10 ... we want to make sure this is about making it practically useful 07:11:25 q- 07:11:36 ... it's very nuanced, we need a strong policy 07:11:47 ack jj 07:11:59 q+ 07:12:50 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 07:13:04 ack GreggVan 07:13:04 Rachael: there's a lot of details that have to be worked out 07:13:24 GreggVan: Lisa makes a good point, we need to look at what's practical. We want to build for the future 07:13:59 ... the other one is, we want to figure out what the big barriers are 07:14:07 ... some things are helpful, some things are showstoppers 07:14:32 q+ 07:15:08 ack kevin 07:15:21 q+ 07:15:29 +1 to kevin 07:15:32 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” 07:15:41 +1 to Kevin's distinction 07:16:14 ack GreggVan 07:16:16 to me, that underlines the difference here between WCAG being a set of requirements, rather than it being a "manual" of sorts 07:16:16 ... so when you do a report, it could include a profile of what impact are the requirements you meet / fail going to have 07:16:24 GreggVan: I'd suggest we do both 07:16:42 ... both are important 07:17:12 q+ 07:17:25 sounds like rdf 07:17:34 Q+ 07:17:35 to me, those are two distinct aims 07:17:37 q+ 07:17:43 ack kevin 07:18:02 kevin: Patrick voiced those are two different things, I don't disagree that we could do both. 07:18:33 ack Lisa 07:18:36 kevin: is there something different about the groups? 07:19:23 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 07:19:24 it'll start moving from "accessibility" to "usability" for many situations 07:19:43 (the line is already blurry in many cases anyway) 07:19:45 ... there's a language called RDF that allows you to make nuanced statements about something 07:20:07 ... we did that with ARIA before, with OWL 07:20:11 q+ 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. 07:20:34 ... it will even allow folks to put together their own spec 07:20:44 q+ 07:20:48 ack shadi 07:20:50 RDF is just ... a way to mark something up. like JSON or whatever 07:20:51 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. 07:20:58 shadi: +1 07:21:08 +1 for idea of “forks” 07:21:23 q+ 07:21:25 RDF or not doesn't answer the fundamental question of why/what exactly we're trying to add metadata for/about 07:21:40 shadi: I do want to emphasise how it helps to express severity of an issue, eg this is a blocker, showstopper 07:21:44 ack GreggVan 07:21:44 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 07:21:47 ... what they need to do. 07:21:54 But there should also be a “main” spec 07:21:54 RDF is a form of metadata 07:22:17 GreggVan: +1 to point about functional needs… though 'user need' may be even better, they are more concrete and diverse 07:22:44 ack Rachael 07:22:44 it's a data model/syntax. 07:23:04 Rachael: DAF is a framework from Accessibility Community to help people make a mapping 07:23:13 ... it's the closest thing I could find to what I believe we need 07:23:36 ... would like to ask the group if others know of other frameworks we could potentially use 07:23:46 ... but this one can be used for many to many relationships 07:23:51 still need to decide on a specific ontology, categorisation, WHAT you're actually trying to capture in metadata 07:24:03 ack kevin 07:24:38 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 07:25:18 q+ 07:25:30 can you repost the link to the page you are showing? 07:25:33 kevin: regarding the idea of impact… we'd need to think about the impact of failing to meet the requirement vs @@@ 07:25:48 ack shadi 07:25:53 ... I also worry we move too much to assessing the impact of the specific design 07:26:03 shadi: in principle I fully agree, shouldn't go down the occurences rabbit hole 07:26:08 kevin: that's the word 07:26:30 s/@@@/rather than failing to meet specific occurrences/ 07:26:48 shadi: a nuance… we have a requirement on page title, it talks about describing the purpose or intent of the page 07:26:58 ... could that give us another layer of how does it help 07:27:00 q+ 07:27:25 +1 to exploring that idea of 'intent of the page' 07:27:39 ack GreggVan 07:27:40 q+ 07:27:43 ... I see all sorts of tools about scoring, could there be something more agreed upon 07:28:13 ack Patrick_H_Lauke 07:28:17 GreggVan: could a link be posted to the current slide? 07:28:25 Rachael: it will be in the slides after we're done, I'll add it there 07:28:49 Patrick_H_Lauke: the impact of any requirement on a real user is contextual 07:29:24 link to slides: https://docs.google.com/presentation/d/1lrSm4JSt7vgmXdAJwO0cASqp11EGYoCCR6Ni2OkWBzk/edit?slide=id.g3a1d2fc24ff_2_13#slide=id.g3a1d2fc24ff_2_13 07:29:37 Patrick_H_Lauke: it's dangerous to try and define it too much. 07:29:51 q? 07:29:53 q+ 07:29:57 ack shadi 07:30:20 shadi: re Patrick… side wide is almost a second dimension to this 07:30:35 s/side wide/site wide 07:30:42 THX 07:31:01 Rachael: we'll pick it up again next week 07:31:08 q? 07:31:10 Rachael: thanks everyone 07:31:31 ... tomorrow we have a breakout session for internationalisation 07:31:48 https://www.w3.org/2025/Talks/TPAC/wcag-non-latin/ 07:32:18 Rachael: at 8.30 07:32:33 https://www.w3.org/events/meetings/f4b8985a-2604-4cb0-a37a-1e189ac6fe19/ 07:32:33 ... it's important for WCAG 2 as well as WCAG 3 07:32:38 ... here's the link to the event 07:32:40 TOPIC: Preparation for tomorrow 07:33:04 https://github.com/w3c/wcag/issues/4263 07:33:22 if you needed the breakout issue, it's https://github.com/w3c/tpac2025-breakouts/issues/38 07:33:31 q? 07:33:32 https://github.com/w3c/tpac2025-breakouts/issues/38 07:33:44 s|https://github.com/w3c/tpac2025-breakouts/issues/38|| 07:33:47 shawn: the comments are in the breakout issue 07:36:17 Rachael: any other questions we want to cover before we wrap up?