<laura> Scribe List: https://www.w3.org/WAI/GL/wiki/Scribe_List

<laura> Scribing Commands and Related Info: https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info

<scribe> scribe: dan_bjorge

Introductions and future topics

alastairc: Let's get started. Any new introductions, shifts of company, etc?

Announcements

<alastairc> https://www.w3.org/events/meetings/6e0d77c5-06a4-47c5-a282-b44bdf1d7849/

alastairc: A couple of announcements.
... There is a W3C Europe meeting for W3C participants in Europe to better understand what work is involved/present in EU
... 2 hour meeting with mix of meetings and breakouts if anyone in Europe is interested.

<TheoHale_> +TheoHale

<alastairc> https://lists.w3.org/Archives/Public/public-wcag2-issues/2024Jan/0003.html

alastairc: We also have another set of WCAG 2 updates available, we're looking for any discussions about those to happen next week.

mbgower: Those aren't quite out yet, but they'll be appearing today. Will be 9 changes coming in, watch your inboxes. Usual 2 week review cycle.
... Also closing out last week's review cycle, will get those in today as well!

alastairc: We'll be discussing those next week as part of the usual review cycle

Writing testable outcomes https://github.com/w3c/wcag3/issues/47

alastairc: This is a document that was written some time ago, before our maturity level work.
... Next step is to update that document. It's an internal doc, not something we need a big approval process for.
... Just our shared understanding of how to do this work.
... Team did some updates and requested folks to review the document. Feel free to leave comments either in the google doc or in the issue.
... A few folks have already given reviews already

<Jennie_Delisi> * I missed the deadline for this - can you repeat it?

Rachael: Not going to go through the initial feedback today, but encourage folks to continue to give more and we'll go through at a later date!

<Jennie_Delisi> * Thank you

alastairc: Don't think there's a specific deadline for that feedback, but it's not a huge document, would be useful to look at, say, within next couple of weeks.

John Kirkwood: Can we get an overview of what the doc is revising?

<alastairc> https://docs.google.com/document/d/1sugAtqie_x1XqHDZo1Im7ftDNllWeRV_ty4PULeoTV0/edit?pli=1#heading=h.q6kvhdps0qv4

Rachel: This is the process to take the work we've done, where we've produced a list of potential outcomes, and to really dive down into them.
... We've started that process over the fall, but haven't yet gotten into the depth and quality we want for testability, thinking about scope carefully, etc
... There was a team including (I think) Daniel, Wilco, Jeanne on what it looks like to look like a really testable statement, we wanted to incorporate that into our docs.
... Now we want to incorporate that into our staged writing process, but we need to iterate on it a bit to get it to fit into our maturity model, decide which aspects belong at which maturity level.
... This document breaks that out into a step by step process by maturity level, with requirements to get to each step.
... There were enough changes that it didn't make sense to do a "track changes" view, recommend just rereading through the document.

Introduction to Outcome Format https://docs.google.com/document/d/1uNJ2riUQjP1FOei5HJvZmIlIXbYYQZaTQJ01hb4zFtk/edit#heading=h.p0vw6nnp7d6p

Rachael: One of the questions on outcomes from last fall are "How do we want to write them"
... How do we want to write them, what level do we want to write them at
... This is trying to explore the format
... We need help and encourage volunteers to help work through examples so we can talk about it as a group
... We've pulled out a few options - user needs statements ("I need..."), requirements statements ("You shall..."), passive voice (like WCAG 2), active voice, etc
... We pulled out some examples and would like folks to sign up to pick one and flesh it out
... To help, put your name down for a section; it'll have a link to a part of the document to fill out
... There are still different ways to write each bit within the format type, but these are examples to get us started
... We want to come back in a few weeks, look over these "exemplars", and discuss which we think works well across a breadth of subject areas
... We can change our mind later, but we'd like to have folks start writing using a consistent voice ...Gregg: So we haven't decided between passive/active voice, and we want examples to decide which way works best?

alastairc: More that passive vs active voice, also the "type" of statement

Gregg: So we're trying the combination of voice and form together in these examples?

alastairc: Yes
... If our last agenda item doesn't take very long, we might go into some breakout groups and start working on this today in small groups, time permitting.

Gregg: Looking at conversation support, as it relates to other work we're doing. I want to understand what "provide conversational support" means

alastair: See the scratchpad for that outcome

Jennie_Delisi: Is it really just a single line needed in the instructions ("Come for this purpose"?) to help scope what people are thinking about?

alastairc: Possibly? Unsure. I think the example in cognitive tests would be the most helpful, at least for me, in going through exercise.

<TheoHale_> I am happy to take on conversational support

Guidance modules https://github.com/w3c/wcag3/discussions/46

<Jennie_Delisi> * Rachael - like that?

alastairc: This is building on recent conversations about publication approach for WCAG 3
... Based on previous conversation, we're going to continue starting from WCAG 3 outcomes.
... Today we want to discuss more how to break it down, to try to address how many years it might take to publish.
... One of the options was breaking down into "modules"
... The proposal, if we want to go down that route, would be to break down WCAG 3 into groups of related guidance ("keyboard", "motion", etc)
... When ready, we'd copy those parts of WCAG 3 out of the working draft as a module, just copying from the working draft but as a standalone document

WCAG 3 draft would be all of that guidance, plus conformance details

scribe: WCAG 3 draft would be all of that guidance, plus conformance details
... We've had so far 7 upvotes, 1 downvote, and 1 :eyes:

<Jennie_Delisi> * Rachael - I added the definition from the WCAG 3 page. Not sure if that scopes it for people. But for those who forget what each term means, that may help jog memory. Not sure if that helps or not.

scribe: Main idea in the comments is wondering "what would we gain" from this approach

<Jennie_Delisi> * I may have made it too wordy :)

scribe: If we publish separately, some concerns about keeping them synchronized with the main draft
... One comment from roberto wanted to go even further than this structure (include informative, not just normative)
... Alastair's main comment is wondering what the practical difference is between publishing draft with guidance vs strictly informative docs
... Rachael's not sure that publishing separate documents is enough benefit to warrant the extra work to publish more things
... as we've been talking, the votes are now 5 thumbs up, 4 thumbs down

<ShawnT> I think you can use that to sort the comments by most popular

scribe: There's some confusion here about "up arrow" vs "thumbs up" for github votes - try to use thumbs up to indicate support

mbgower: One clarification - do you want this discussion just about "publishing informative modules", or generally for "publishing modules"?

alastairc: Let's keep this to "should we lift *guidance* from the draft to publish as modules", and not "should we structure the final publication as modules"

mbgower: In that case, I think realistically, WCAG 2 will remain the adopted standard for years and I don't think there's a lot to be gained by regurgitating WCAG 2 stuff in a new format.
... I like the idea of a modular approach enabling us to publish "net new" stuff (things not published in WCAG 2)
... If we did have "net new" modules, I think we could use that to get feedback from the community for stuff like how we can structure those and make them testable, in going with our "expanded guidance" philosophy
... Once we have those, then we can think about stuff that expands on existing WCAG 2 SCs, to the point where the module could include a mix of new stuff and fuller considerations
... Thinking about being able to say "if you meet this module, you *also* meet WCAG 2.2 SCs X, Y, and Z"
... That acknowledges that there's not much to be gained short term by replicating WCAG 2, but I think that helps work towards something long-term that lets us slowly adopt "WCAG 2 with improvements" until we have a version of 3 that both covers all the existing 2 stuff and also adds new stuff

Gregg: Similar comments to Mike's. Want to take a sampling of 2.0, give an idea of the spectrum of content. Don't want to bring *all* of them, but want enough to see the breadth of coverage.
... We've talked about a synergy between requirements and assertions. We can leverage the "hard" requirements alongside the things we want to get in for 3.0 that we haven't been able to fit into the "hard requirement" model.
... Want to incorporate *some* of them, but not all of them as a first step.

alastairc: To clarify, you're not talking about a set of modules divided by topic so much as the process of developing WCAG 3, where we migrate some content from WCAG 2, add some things we couldn't fit, and then progress wiht WCAG 3?

Gregg: Think modular approach is a good approach; we'd want to pick modules that specifically allow us to do that incremental process.
... Not so sure about extra effort of publishing them beyond an editor's draft. More interested in using modules to organize our work, don't think there's a lot of extra value in publishing them separately.
... Think our time would be better spent by not publishing the modules separately.

<kevin> qq+ to comment on patent policy

<Zakim> alastairc, you wanted to comment on technology specific modules

alastairc: I'm taking that as a vote *against* publishing modules separately, yes?

<Zakim> kevin, you wanted to react to GreggVan to comment on patent policy

Gregg: Yes

<alastairc> qq+ alastairc

kevin: There is one notable difference here between publishing "on rec track" vs "an informative module/note". If it's published on rec track, there's much more exploration/review process than the informative track.

<Zakim> alastairc, you wanted to react to kevin

alastairc: Want to discuss technology-specific modules. When Michael was discussing "new stuff", new technology comes to mind as something we might want to apply to WCAG 2.
... I think that creates difficulties. For example, with VR, it creates a mix of cases where some of WCAG 2 *might* be applicable, but some stuff (eg, on motion side) won't be applicable
... That particular slice might actually go across what we want to work on as modules, so I think that creates some extra complications.
... If we want to focus on new stuff not covered by WCAG 2, I think that makes it tricky to work on if we use a cross-cutting technology

Wilco: I felt pretty deflated after last week's conversation. The thing that I didn't appreciate about how that meeting turned out was that we voted against something that would give us a timeline on when to expect a WCAG 3 recommendation, a time-boxed approach.
... What feels like an unstated part of this question is that this would mean "no normative modules", "no recommendations" for however long it takes for us to decide "yes, now we're done, now this is a recommendation"
... That's really the question I'm desperate to get an answer on.
... What does that path actually look like? How long will we spend on WCAG 3 before we think this will be done?
... I think 4 years is extremely optimistic and probably not realistic unless we cut corners or drop some requirements.
... I don't like this idea of modules, but I also don't like not having any path to say "this is when we'll have a recommendation"

ljoakley: I like the idea of using modules to piece out the work.
... But from the user end of things, how would folks adopt this?
... Let's say we have a module, we have outcomes, tests, etc. How do we get folks to actually adopt that? How does it not become "just another email from the W3C"?
... Don't want to do the work and then not have users particularly care about it

dan_bjorge: Don't think there's much value in publishing stuff that's purely informative.

Gregg: Where do patents fall into this, in terms of patent policy?
... Agree on technology points brought up by Alastair, think it's appropriate to keep modules technology-agnostic.
... Regarding time, quality, speed, cost, pick 2. If we can't budge on quality and can't get more folks to work more hours on it, we need to compromise on speed. If we want less than 5 years, we'd need everyone on the committee to spend 20-30 hours a week on it. People don't have that much time they can spend.

<Wilco> +1, and that worries me

Gregg: We should get it into our heads that this is going to take a long time to do. No WCAG group has been able to address the topics we're trying to address in 3.0 - it'll take some time.

<Zakim> alastairc, you wanted to talk to the previous decision, the alternative didn't provide a timeline to a (similar) WCAG3

alastairc: To ljoakley's point: If there's a particular topic we felt was a gap in WCAG 2 that we could provide essentially-supplemental guidance for that some regulator was particularly asking for, I think then we could maybe do something more targetted, but other than that, I agree with Dan/others that there doesn't seem to be much value in separately publishing things. For non-regulators, folks can just look at the editor's draft anyway.
... On Wilco's topic for restructuring: I don't want to revisit the "do we restructure" discussion, we've already done that several times. But I don't think that doing it iteratively from WCAG 2 would get us to our desired end state any quicker than starting from outcomes.
... Personal opinion: I think it's quicker to get to the end state by restructuring. It doesn't mean we're throwing away WCAG 2.2 stuff, it means we're reforming it.
... On Gregg's point about how long it's going to take: I think the collaborative tools are a lot better now than they were in the WCAG 2 timeline. I think we're not starting from scratch, we have pieces from earlier versions we can use to help rebuild with. And I think if we keep scope to "the proven bits of WCAG 2, plus say 20% new stuff", that keeps the scope manageable, and I think that's part of what's in the project plan.

<Rachael> https://www.w3.org/WAI/GL/wiki/WCAG_3_Timeline#Publication_Plan

Rachael: Our current proposed timeline for the next 2 years is linked in the chat. We've gone through step by step why/how we think we can do it. We've shifted our subgroup model to allow us to bring in extra experts and resources. We don't really know what our velocity is, which I think makes this conversation hard. We have folks making assumptions about how fast we can work, but we don't really have information about how fast we can work.
... We really won't have a great insight into that question until we do our first retrospective at TPAC. At that point, we'll have had 8-9 months of actual work with that structure in place.
... Then we can say "this is how much we got done" and make a more informed estimate.
... Something else to keep in mind is that we have a ton of work we're already building on. We know the structure we want to be working towards. We know the idea of "outcomes" from silver, about "tests" vs "assertions" and qualitative vs quantitative outcomes.
... We haven't put that together yet because we wanted to have the guidance available about how to do it.
... Happy to answer questions about the timeline/plan, but suggest just reading through it as a first step.

<alastairc> Poll: Assuming we work in a modular way (tackling a set of outcomes at a time), should we try to publish informative documents? Yes / No

<Wilco> No

No

<Bri> No

<TheoHale_> No

<Detlev> no

<alastairc> no

<jeanne> no

<giacomo-petri> No

<Glenda> No (because we need to focus on being super productive)

<Francis_Storr> no

<GreggVan> no

<ljoakley> 0

<bruce_bailey> yes

<Rachael> no

<Wilco> *** No, not informative modules

<Frankie> No

<Azlan> No

<mikeGower> No, normative

<GreggVan> No - confusing as to what they are

<Jennie_Delisi> Sometimes

<Zakim> Jennie_Delisi, you wanted to ask clarifying question

alastairc: Seems like low support for informative module publishing, but maybe some suggestions for normative. Anyone have a proposal for that?

Jennie_Delisi: Clarifying: When we say "not publishing", we're excluding the stuff that related groups make, or not?

alastairc: The discussion in github is talking about "as we work on rec track WCAG 3 document, do we pull out some of the informative guidance on certain topics and publish them separately?"
... Not related to what task forces are doing

<Jennie_Delisi> No, as long as task forces can continue to publish their informative documents.

Jennie_Delisi: Thanks, I'm comfortable changing my vote so long as it's not considering task force documents in scope

<Rachael> Regarding timeline, this is the github thread on different perspectives on timelines https://github.com/w3c/wcag3/discussions/33#discussioncomment-7512622

Gregg: If we publish something normative, it means "we're done with this, we won't change it without compelling reason"
... Don't think we can realisitically do that, too likely we'll want to change stuff as we further develop the document as a whole
... Also don't think it'd be tremendously valuable, more likely to cause confusion than to help

mbgower: My concern with just having one big editor's draft is... imagine you have a rec document goal where you start out with, say, 3.1.1, which contains 1 module. Has a module that is net-new, nothing to do with WCAG 2. You work through that module until you have some testable things, some things that exceed what we can do testably, we can declare the process for it and for showing "done" in some repeatable way.
... At the end of that process, it gets published as 3.1.1. Say we put in 2 modules next year as part of 3.1.2, and we continue in that way.
... To Gregg's comment that you can't change anything normative once it's published: I don't think that's entirely true, just that if you do make changes, there needs to be a clear migration path. But even then, say you decide you're modifying the formula in 3.1.1. Then the formula just changes in 3.1.2 and you report against that. We want to minimize changes like that, but at some point in time, if we say we've released 5 modules, we can decide
... "okay, this is now 3.2", it's more stable than we we did earlier.
... I think if we can cajole an org to adopt it at 3.2, or even 3.1.x, then we've added additional ways (not just the equivalent of AAA) that give some way of being adopted by jurisdictions

<Wilco> scribe+

<Zakim> alastairc, you wanted to comment on keeping things malleable and to comment on scribe change

<Wilco> Alastair: I struggle with that, trying to put aside the effort it takes to get on rec track.

<Wilco> ... One of the keys to getting a WCAG 2 replacement is maliability. Making sure we can change anything across the whole

<Wilco> ... Say if we publish a module of some set, and then do three more. By the time we get to the fourth one, how the details of conformance work would probably have changed.

<Wilco> ... How we keep that coherent? It'll be quite important to keep things on time.

<Wilco> ... It's a big information organisation piece. Anyone who's gone through large scale updates knows that pain.

<Wilco> Alastair: It didn't look like we had enough support. There would need to be enough people interested to make that happen.

<Wilco> ... I'm struggling to see a full enough proposal to consider normative modules. If anyone wants to write it we could come back to that.

<Wilco> Mike: That's going to be the case no matter what. We're not going to get it right at first.

<Wilco> ... It might be a long time before you realize it doesn't work. Imagine 4 draft documents, get a lot of feedback, and at some point of time we could say 3.1, by the time you'll have enough modules that can handle different considerations.

<kirkwood> +1 to MG approach

<Wilco> ... The alternative, developing a crap load of stuff, we'll push along in draft, and after all that time it will have to magically be robust and work out the gate.

<Wilco> ... I think the smaller number, tweaked incrementally will be much more likely.

<Zakim> Rachael, you wanted to ask what is the benefit of publishing a final normative document over keeping a public draft

<Wilco> Rachael: Trying to understand, assuming that when we declare done we have sufficient overlap with WCAG 2.1 / 2.2

<Wilco> ... What would you see as the benefit of putting out a final rec track document earlier, vs putting out mature guidance but not published as a single rec

<Wilco> Mike: Ultimately noone will adopt it until it's published. People will look at it, but what's the motivation to move to it?

<Wilco> ... it's also a bit of a nightmare of people getting into legal issues for not following 3.0 drafts

<Wilco> ... I think if there is a 3.1 published, 5 new considerations that are net new to 2.0, there is an ability for people to adopt that and also follow 2.x

<Wilco> ... Eventually 3.x would completely replace 2.x, but that will not happen for 7 years minimum.

<Wilco> ... So the question is do we want to spend 7 years replacing 2.x, or do we want to get people improving on the current state sooner?

<Wilco> Gregg: If we only work on 3, and only adopt things into normative 3 that are not in 2 at all, that will be really hard.

<Wilco> ... So we would specifically not work on anything that overlaps 2 because if it did you can't adopt both?

<Wilco> ... If it were possible to use 2.2 as a base, and have 3.0 as a suplement, then we could adopt things into 3, and you could do 2.0 + 3

<Wilco> ... I thought one of our ways of getting stuff into 3 was to combine it with the 2.2 provisions and leverage that to get people working on stuff beyond 2.2

<Zakim> jeanne, you wanted to point out the interest in color contrast changes where it was already being implemented. It was needed, so they were enthusiastic about implementing it.

<Wilco> Jeanne: We don't control what people implement. When we published FPWD of 3 there was a great deal of excitement, companies immediately started to implement color contrast.

<Wilco> ... People needed and wanted an updated contrast, so they started implemented it

<Wilco> ... We have no control over when people will implement that. Its not a good idea to pretend we do

<Wilco> ... If people want to use it, they'll start implementing it

<Wilco> Mike: What I suggested was starting with net new. Once we have some modules of new we can start to subsume parts of WCAG 3.

<Wilco> ... Lets say we do contrast minimum, it gets adopted, and people who adopt it can report 3.2.1 as met.

<Wilco> ... We need to start somewhere, and it seems a lot easier to start with something new.

<Wilco> ... I think of WCAG 3 as suplemental to 2.x until we can use it by itself.

<alastairc> qv?

<Wilco> ... I think it's doable, the devil is in the details, but once we have a few modules we'll discover these

<Zakim> alastairc, you wanted to suggest we proceed with the project plan, but look for sets of guidance that are useful and supplement WCAG 2.x

<Wilco> ... The fastest way is to get started on it.

<Wilco> Alastair: It is hypothetical what would make a good module. It's probably best if it would fill a gap

<Rachael> Prioritizing outcome github threa https://github.com/w3c/wcag3/discussions/43

<Wilco> ... My suggestion would be we go through outcomes as planned, and as we go along we can look at things that are additive, or could replace parts of 2.2

<Wilco> ... then we set up a sub-group to look at how to publish that as a supplement to WCAG 2.2. We can have a discussion then whether that needs to be normative.

<Wilco> Gregg: I think Jeanne's correct. It shows the power of putting things out. Industry saw the value of it and implemented it.

<Wilco> ... If we find good material we can put it out. COGA did this, and it helps with rec track. I wouldn't try to push it into 2.0. We would lose some of the good bits we're getting into 3.0. We'd shave off a lot of good stuff if we tried to put it in a 2.x format.

<Wilco> ... We could have a technology specific note. Not a requirement or a regulation. We can release a lot of good stuff where we don't have to be detailed.

<Wilco> ... Rec track is for things we want to put into regulation, that takes long.

<Wilco> Rachael: Gentle reminder to avoid analogies. It can cause confusion.

<Wilco> Alastair: If anyone has a proposal please add it to the discussion

<alastairc> https://github.com/w3c/wcag3/discussions/46

<alastairc> Wilco: Clarification question, are we looking at the other topics.

<Wilco> Alastair: The chairs went back to that and didn't think the others were useful questions to answer, or if they were they'd need reformulating

<Wilco> ... If we need to bring one back to the table it'd need reformulating

<Wilco> Rachael: We felt we needed very detailed proposals. There are other detailed proposals that can have that kind of conversation.

<Wilco> ... The GitHub conversation informs the conversation, but we don't necessarily go through every item.

<Wilco> Alastair: I would suggest we go through the outcome format exploration.

<Wilco> ... We could spend some time working on them. We'll close the meeting and work on this particular item.

This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Dan/Daniel/
Default Present: dj, Laura_Carlson, shadi, ShawnT, Rachael, JustineP, mike_beganyi, Francis_Storr, jeanne, DanielHE, alastairc, julierawe, ashleyfirth, Frankie, Wolf, Bri, mbgower, dan_bjorge, AWK, kirkwood, Jennie, Jen_G, tburtin, jeanne_e_c, JakeAbma, wendyreid, Jaunita_George, Glenda, ToddL, Graham, jon_avila, GreggVan, scotto, Detlev, ljoakley, jtoles, Poornima, rscano, Roberto_Scano, bruce_bailey, Wilco, kevin, Azlan, Jennie_Delisi, TheoHale, TheoHale_, giacomo-petri, Ben_Tillyer
Present: dj, Laura_Carlson, shadi, ShawnT, Rachael, JustineP, mike_beganyi, Francis_Storr, jeanne, DanielHE, alastairc, julierawe, ashleyfirth, Frankie, Wolf, Bri, mbgower, dan_bjorge, AWK, kirkwood, Jennie, Jen_G, tburtin, jeanne_e_c, JakeAbma, wendyreid, Jaunita_George, Glenda, ToddL, Graham, jon_avila, GreggVan, scotto, Detlev, ljoakley, jtoles, Poornima, rscano, Roberto_Scano, bruce_bailey, Wilco, kevin, Azlan, Jennie_Delisi, TheoHale, TheoHale_, giacomo-petri, Ben_Tillyer, Frankie Wolf, maryjom
Found Scribe: dan_bjorge
Inferring ScribeNick: dan_bjorge

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)