<alastairc> scribe: Rain

EO WCAG videos intro (15 min) https://github.com/w3c/wai-wcag-videos#readme

alastairc: guests to talk about WAI WCAG videos

<shadi> https://www.w3.org/2002/09/wbs/1/WCAGvideos_batch1thorough/

brentb: co-chair of Education Reach working group, launched WCAG Videos project a while ago
... trying to use personas to pull together succinct 30 second to 1 minute videos
... to give examples of success criteria
... these will be examples without calling out a specific number or name because want to be able to use the videos as a topic so that they can be used more widely and have more longevity

<AWK> +AWK

<Rain_> scribe: Rain_

<ChrisLoiselle> Rain, if you have issues again I can take over, just let me know. Happy to help. I've been there with IRC issues!

brentb: work on 5 minute scenes, then work together with a larger group to edit and revise
... working to bring this to a wider group for broader review,
... currently working with a batch of 10 scripts, and have representatives from COGA, AG, Silver and other groups to give input
... the AG group is being offered the chance to take a look and give feedback
... would be good to look at prior work that has been done so that we aren't repeating previous feedback
... putting together a survey for the review
... surveys that they put up will give us information on what needs to be reviewed. Comments can be in the survey, in github, or however makes sense
... anyone interested is welcome to provide feedback

<shadi> https://www.w3.org/2002/09/wbs/1/WCAGvideos_batch1thorough/

shadi: perspectives videos are already on the home page,
... these videos will have a similar tone
... they are not meant to describe the benefits of accessibility, but rather explain the criteria
... and make it possible for these to be reused
... primary use case is to help people who are going through the criteria and trying to understand what they mean,
... and by being personal, it makes it easier to understand

brentb: the survey will begin with a list of things to review, and not to review
... please pay attention to this information so that not spending time on something not needed

shadi: will still be moving some personas around, and deciding which ones to produce and which ones not to
... also looking to have as much diversity as possible in situations and people

<Zakim> sajkaj, you wanted to ask about using multiple environments and devices across all the videos

Janina: really glad this is happening

<Zakim> JF, you wanted to ask about audio descriptions

Janina: hoping that diversity is clearly represented, and that natural language, and visual language are also represented

JF: congratulations, this is really cool.
... when looking at the page, looking at the column for audio and visual, but not seeing an audio description column yet

shadi: one of the things to review is whether or not the visual description is sufficient

brentb: this is also one of the things that the small group is reviewing. What is being said? Is it enough to describe what is happening visually? Or is there enough in that audio so that audio descriptions aren't needed? If not, we would like to tweak the audio so that separate audio descriptions aren't needed

shadi: responding to Janina, yes, we are trying to represent different levels of skills with ATs, computer skills, etc

<shadi> https://www.w3.org/WAI/perspective-videos/

JF: also asking about transcripts, would like to know what the transcripts look like. Would like to see transcripts on the script page so that it is clear what support elements will be available with the video

shadi: we will have transcripts, but since the video scripts are still changing, we haven't created them yet, because maintianing the transcripts would be high maintenence

JF: please include a note that transcripts are still to come so that we know that it is a work in progress. Reiterating that absolutely loves this, and this is not criticism

bruce_bailey: also noting that the screenplay themselves are the current representation of the transcript

<JF> +1 to Janina

Janina: some general public also prefers to read a transcript rather than watch a video, even while the primary audience is for deaf blind

<AWK> Although 1.2.5 requires audio description rather than a transcript, which is sufficient for 1.2.3...

brentb: survey is currently open until today, but aware that we are just hearing this on the meeting today. Will consider extending the deadline if we ask, but need to know how long need to extend for

alastairc: asking if anyone who would like to look at it will put a note into IRC

david-macdonald: also reinforced that this is great work even if the feedback is dour

alastairc: asking to keep it open until next week in order to give people time

brentb: asking if midnight Boston time on Friday would be reasonable, and individuals can ask for additional time if necessary

alastairc: encourage people to look at at least one or two, find out how it's working, what the approach is, and better understand what this is

bruce_bailey: where do we go to look for the announcement? Would like to invite some other people in

brentb: we generally post this information on our Wiki, but will start sending newly opened surveys to the chairs of AG
... these are also announced on the EO listserve

<shadi> https://lists.w3.org/Archives/Public/w3c-wai-eo/

alastairc: will look for future announcements to forward onto the main group

<bruce_bailey> looking here for archives:

<bruce_bailey> https://lists.w3.org/Archives/Public/public-eo-archive/2021JanMar/

shadi: asking if we would prefer to send the emails directly to the group, which Alastair confirmed is sufficient

<bruce_bailey> video review request does NOT seem to be on that listserve

WCAG 3.0 issues (30 min Survey TBC) https://www.w3.org/2002/09/wbs/35422/30_weekly_21_April_21/

alastairc: moving on to WCAG 3.0 weekly responses survey

<alastairc> https://github.com/w3c/silver/issues?q=is%3Aissue+is%3Aopen+label%3A%22status%3A+in+weekly+survey%22

alastairc: This week we had 3 issues in Silver
... 5 agree with the responses, 3 suggest something else.

264

alastairc: 264 is consider wording that introduces some lists

Rachael: from reading Gundula's comment, need to get the list to read correctly with semicolons

alastairc: Michael added print down the final bullets

<alastairc> https://github.com/w3c/silver/pull/515/files

Jeanne: believes put the responses into the pull request

alastairc: if mbgower and Gundula are on the list, please take a look at the pull request

mbgower: I think this does address

<alastairc> https://github.com/w3c/silver/issues/289

alastairc: 289, will make an appropriate comment later, and that will be the resolution
... hoping that outcomes and measures will be put together in multiple languages. Our draft is thanking them, and we agree, and we are working on tools to work in all languages (in progress)
... 313, consistency of wording and phrasing is also important. Our draft response is that yes, we agree. We need to have a definition of consistency, which is challenging across languages. We will continue to explore, tagging to review further later
... mbgower also had a comment, that being clear is different from consistency
... can we change the response to say that consistent isn't the same as clear?

<Zakim> JF, you wanted to get clarification around clear words, common words, and plain language

mbgower: they are not the same. Easy to demonstrate that clear and consistent are two different concepts. The response doesn't tackle that

<ChrisLoiselle> +1 to JF on wording.

<ChrisLoiselle> +1 to MG.

JF: in the past week, as an activity in a subgroup, did a deep dive on the first draft of the existing public working draft. We are mixing our terms, clear, common, plain language. Since we aren't consistent about what we are talking about, this is something to look at.

<JustineP> +1 to that

JF: Clear words are different in context

alastairc: Fair point. We need to update the document, but this will be tackled as we integrate more content.

JF: the simple writer tool is looking at common words, not clear words.
... As part of the exercise, I took a paragraph of text and put it into the tool, and it rejected words like "site," which is very common. Common words don't necessarily lead to better accessibility.

alastairc: This may need to be raised as a new issue specific to this guideline.

mbgower: Checking if his comments were added into the PR. Not sure that they are there yet, but has full faith in Jeanne to consider and incorporate responses, so that is fine for me
... I'm fine posting a suggested response into that one, if you want me to do that

<alastairc> https://github.com/w3c/silver/issues/313#issuecomment-827704760

alastairc: yes, I was just going to put together something based on the discussion (link posted above)
... edited top of the draft response to say that yes, we agree that consistency is important, and we will be looking into it further. Will tag this to come back to later

<JF> +1 to MG

<JF> what is a "clear word"?

mbgower: want to make sure it is clear that we will not be incorporating consistency into clear words, because these are different.

alastairc: it is there now

Jeanne: the subgroup agrees with that

mbgower: thanks Jeanne

alastairc: We have updated the responses, is there any objection to approving?
... if not, then we can resolve

RESOLUTION: Accept the updated responses & PR

alastairc: excellent. In this section of the meeting, tackling the easiest ones to tackle, but worth noting that we've got the meetings on Thursday.
... These will be a much deeper dive then, and will tackle the bigger issues then.

WCAG 2.2 issues https://www.w3.org/2002/09/wbs/35422/WCAG22-Misc-items/

alastairc: We have some WCAG 2.2 misc items to discuss

New technique for new contrast formula (threshold value) #1213

alastairc: Reading out what is in the survey. See survey.

<alastairc> https://raw.githack.com/w3c/wcag/bruce-usab-wcag22-contrast-technique/techniques/general/G221.html

alastairc: read out Gundula's comments on luminance

bruce_bailey: suggestion to mark out the exact value. If you want to use the final published number, that is fine.
... looking to find out if there are any values where using the correct number is fine, but finding that four digits of accuracy isn't necessary

alastairc: essentially, this doesn't negate using the previous published number
... This is basically an answer to why doesn't WCAG use the same value from the final RGB spec
... Sarah spotted a typo to correct. Wilco doesn't feel that the technique should be published
... repeated the response above for the sake of addressing Wilco's comment to see if it addresses the concern

Wilco_: but it might make a difference?

<Zakim> AWK, you wanted to suggest adding the new formula as an "or" in the existing technique

<AWK> sorry

<AWK> i sec

AWK: why might it make a difference?

Wilco_: the numbers are different

AWK: Bruce investigated to see if they make a difference, and found they don't

Wilco_: if it generally doesn't make a difference, we can do an errata, that way it will be consistent everywhere

AWK: believes this was discussed before and the group decided not to do an errata, which is why we are looking at adding a technique. But I think it might make sense to not add a new technique, but to update this technique. Step 1 is to evaluate using the old values, and step 2 is to evaluate using the new values from this updated version.
... If you pass with either (or both) of them, that you meet the technique.
... This might be better than having two techniques that appear different.
... If we have two techniques, we have to explain why because people will ask the question.

<bruce_bailey> link to g18 https://www.w3.org/TR/WCAG20-TECHS/G18.html

Wilco_: if we don't want an errata, can we put a note somewhere that says that we know they are slightly different, but in practice this won't make a difference.

alastairc: We could do that. That is an option to look at.

mbgower: If this is only going as a technique change, then it is not effecting the normative text. In this case, we are talking about an alteration to the understanding or technique, neither of which are normative, so doesn't make sence to be an errata

AWK: the ratio calculation is normative
... the reference to the version of the document is normative
... the issue is that the working group erroneously referred to a version that is out of date.

<bruce_bailey> fwiw, i am not sure we discussed erratum last

AWK: So it is not outrageous to add an errata because the working group erred, but the result is apparently insignificant.

alastairc: I thought we had discussed a change, but not sure if we discussed as an erratum or not. It would be a fairly quick change to make and announce, and get feedback on.

Wilco_: where can we find the research that it doesn't make any difference?

bruce_bailey: Recollection is that we decided not to make a normative change, but now we have had more discussion about the errata, so may make sense to consider. To answer Wilco, asked colleagues who are experts. Don't have the maths or other information in writing right now.

<alastairc> https://github.com/w3c/wcag/issues/360

alastairc: The deep dive into this history (linked above)
... This includes the equations
... Options include this technique, which we thought was the least controversial, for acknowledging the updated value
... We could change it for 2.2, but then it would be an erratum.

<ChrisLoiselle> If talking to this on errata, would need to declare whether it is Editorial Errata or Substantive Errata. I was trying to understand glossary term of each of these but couldn't find it.

alastairc: Changing it in 2.2 would also mean changing the normative document.

<ChrisLoiselle> Substantive corrections are proposed by the Accessibility Guidelines Working Group, which has consensus that they are appropriate; they are not to be considered normative until a new Recommendation is published following the process to revise a Recommendation.

<Zakim> mbgower, you wanted to say do erratum and modify technique to match

<ChrisLoiselle> https://www.w3.org/WAI/WCAG21/errata/#substantive reference point

alastairc: will want to talk with Michael Cooper about doing an erratum

mbgower: propose that we do an erratum and modify the technique to match

<ben> What are the downsides to adding an erratum?

alastairc: is anyone on this call opposed to doing this?
... Downsides, if we do it now, it will have to go into 2.2 and be visible there. Wouldn't immediately be visible in 2.0 and 2.1, as it would be in the errata. Downside is that it shouldn't make any practical difference, but it would be unfortunate if people found it did.

AWK: part of what we discussed before is that if there is no actual difference for the range of colors, the question is what is the value of doing this?
... If it is not changing anything for any end users, is it that we feel better that everything is aligned? Or is there something more to it?
... Doesn't seem harmful to make a change, but maybe we are weighing the difference of people looking at WCAG as referencing something outdated, or is WCAG a document that can change, which might make people nervous.

david-macdonald: historical perspective, we want to be results based, and want the end user experience to be different. Trying to filter this through that perspective. As soon as you change something, even if it is small, it makes you wonder. I would just change it on 2.2. Am fine with an errata, but concerned that people would get nervous if changed in 2.0 and 2.1

<Zakim> bruce_bailey, you wanted to say it feels like we have two bad choices

<Zakim> alastairc, you wanted to suggest we try it now, opportunity to get feedback

bruce_bailey: We have two bad choices. We make people nervous by making a change that makes no practical difference, or we don't make the update.

alastairc: chair hat off, potential of people noticing it and worrying more than we think they need to. Now might be good timing, as we are about to put 2.2 out for wide review, to adjust, and include a note about the adjustment. Add a line to the existing note that the former was from sRGB spec, and has been updated, but should make no practical difference.

<david-macdonald> +1

alastairc: This might be a reasonable approach.

<bruce_bailey> +1

<bruce_bailey> i don't spreadsheets, etc

AWK: the one concern I have that is greater when we are talking about this as an erratum vs. a technique, is the working group getting positive verification that this absolutely makes no difference. Asking if Bruce is able to pull together that data and verification.
... It would be good for us to see that information.

<ChrisLoiselle> I could be wrong on issue, would need to review further.

<Rachael> Could we say we expect no change but let us know if you find one, as part of the wide review

alastairc: Would it be sufficient if we found a comment in github from an expert saying that this has been validated and they've done the math?

AWK: sure

<bruce_bailey> bottom of this comment: https://github.com/w3c/wcag/issues/360#issuecomment-498615230

<jon_avila> We'd want to ask how they calculated it. I did some random testing of values and I found no issue but I didn't do an exhaustive test.

<bruce_bailey> svgeesus confirms here: https://github.com/w3c/wcag/issues/360#issuecomment-606721654

<bruce_bailey> my understanding is svgeesus is the lead for svg spec

ChrisLoiselle: adding context to the question that AWK proposed, 360, if in 2.1 it is a current technique, but in 2.2 we want to reference the new formula, at least 2.2 would have the formula in a technique that aligns. Then for 3 this will have the reference to the luminance value and the work.

alastairc: We then wouldn't have a technique that uses the same numbers as the actual notes. Either we take an errata approach, or we have two techniques, one with each value.

Wilco_: Would still like to see the calculation. There was clearly a reason to change it, so I imagine it does make a difference.

alastairc: Suggest looking at the comment in the issue. Thinking about hex values and the level of granularity you get from a four digit decimal place in the formula. Possible that the colors seen on screen are not sufficient to differentiate.

Wilco_: But it matters on the edges, where something might be 4.5 but it would fall on 4.4.

<jon_avila> I disagree with Wilco.

<AWK> https://github.com/w3c/wcag/issues/360#issuecomment-498615230

bruce_bailey: as I understand the maths, you cannot find examples of any two colors at 8bit color where you get a different result

<bruce_bailey> svgeesus is Chris Lilley from https://www.w3.org/TR/SVG2/

alastairc: the granularity of 8bit color isn't sufficient. Math for this is above in issue comment

AWK: The comment above is a summary from Andrew Summers
... for 8bit color, there is no variation that was found
... in issue above, Andrew Summers speaks to the concern. This is a problem more of optics rather than of impacting this narrow use case.

<JF> +1, if it has no change impact, why change?

AWK: This doesn't have an effect on the calculation used for WCAG. Clearly it must have an effect on someone who needs a more precise number

<Zakim> JF, you wanted to note "deprecate" the technique, not "remove it"

<ChrisLoiselle> +1 , don't want to remove it

JF: +1 to Andrew. If there is no change, why are we changing it? But want to look at something pedantic. Are we deprecating or removing? Object to removing. Okay with deprecating.

<ChrisLoiselle> deprecating per version of wcag in reference to what the change took place in the formula.

JF: For historical reasons, we should keep it preserved

alastairc: either we have it as a sufficient advisory technique or we don't. Doesn't effect 2.1. We still need a technique for color contrast overall.

<AWK> I don't care if we make the change as an errata, and I don't care if we don't make the change. We do have justification to make the change as an errata, as there was an error. We also have a justification to ignore this, as there is no user impact.

JF: my concern is the choice of the the words we are using

<alastairc> Poll: Option 1 - Errata with note. Option 2 - Technique addition.

<mbgower> option 1

<ben> 1

1

<JF> Option X: defer a decision until we get actual confirmation on the maths

<Rachael> 1 ideally with pre-review

<ben> ...cannot live with 3

<david-macdonald> 1 Errata with note (but we should have reference to the assurance that there is no effect) OR 3

<Wilco_> 3, can live with 1, disagree with 2

<KarenHerr> 1

alastairc: Option 3 is not doing anything

<sarahhorton> 1

alastairc: we have as good of confirmation on maths as we'll get

<bruce_bailey> preference for 1

<JF> 3 (or merge 1 & 2 together)

<bruce_bailey> can live with 2 or 3

<laura> 1

<Sukriti> I can do it until 12:45

<morr4> 1

<Sukriti> scribe:Sukriti

<ChrisLoiselle> I'll take up Sukriti's last 15 minutes if it is helpful.

<JustineP> 1

<ChrisLoiselle> 1 if fine with me

<Jennie_> 1

Chuck: want to deprecate G18 and add G19

Alastair: For legacy reporting, why not go to 2.1?

Chuck: if we're going to change the requirement, the technique should change as well

Alastair: we're not removing 2.1 techniques

<jon_avila> For those interested in the math the sRGB values are the R, G, or B /255. If you calc 10/255 you get 0.0392156862745098 if you calc 11/255 you get get 0.0431372549019608 - the original number and updated number are both within that range so it would not impact a value of 10 or 11 - just a number between 10 and 11 which is more granular than 8-bit color

<alastairc> https://www.w3.org/WAI/WCAG21/Techniques/general/G18

<alastairc> https://www.w3.org/WAI/WCAG22/Techniques/general/G18

Chuck: need backwards compatibility

awk: no actual difference in the calculations. Different math, but it's coming out the same

<ChrisLoiselle> new technique for wcag 2.2 would be a clearer transition and that we can add a note that talks to math update and reference wcag 2.1 , explaining the they are one in the same and we are doing so to update math / formula .

<jon_avila> I don't think it will even make a difference in the calculated contrast as the algorithm is if it's <= x then do this or > x do this.

JF: has the old procedure become invalid? Or is there a better one now
... don't want to lose the old procedure if still valid

<ChrisLoiselle> I think JF's point is that an errata is not a spelling update and doesn't want to lose that.

Alastair: We won't lose it. 2.1 will still have it

<JF> it could be G18(rev)

<JF> exactly Chris

awk: if we do an errata, it will change in 2.0
... we will need to change the understanding document

Chuck: don't want to lose what we've relied on for 13 years

alastair: actual spec doesn't change in case of an errata. Do we still need to change the technique documents that refer to that value?

<AWK> "Please check the errata for any errors or issues reported since publication."

awk: there is a line that mentions errata since publication
... the first part of the technique is the same, where we make a change is in the test and resources section. Where we replace the test procedure and resources on the same document. Note adjacent to the test procedure that says

<alastairc> Proposed resolution: Create (proposed) errata that updates value, update G18 to include new value (for WCAG 2.0/1/2) with note that says "Prior to May 2021 there was a different value..."

awk: prior to this date, this is what was used. We wouldn't be duplicating the procedure. Providing transparency

<jon_avila> if R sRGB <= 0.03928 then R = R sRGB /12.92 else R = ((R sRGB +0.055)/1.055) ^ 2.4

JonA: if it's not going to change the calculated value at all

<JF> G18 would have: Resources (old algorithm), Resources (new algorithm). Test (Old procedure) Test (new procedure)

Alastair: Any objections to Andew's suggestion?

awk: need to make clear it is an editorial errata because no impact on end users

<bruce_bailey> +1 to characterizing as edditorial errata

<ChrisLoiselle> +1 to Editorial in that formula does not impact end users

<mbgower> +1

<ben> +1

<AWK> +1

<JF> +.75

+1

<sarahhorton> +1

<Wilco_> 0

RESOLUTION: Create (proposed) editorial errata that updates value, update G18 to include new value (for WCAG 2.0/1/2) with note that says "Prior to May 2021 there was a different value..."

<Detlev_> +1

<david-macdonald> +1

<jon_avila> +1

<Rachael> +1

Understanding 1.4.3 and 1.4.6 should refer to 1.4.11 #1261

<alastairc> https://github.com/w3c/wcag/pull/1764

<Rain_> +1

RESOLUTION: Accept PR and close issue

Alastair: If anyone has a chance to look at 2.2 issues on github, would be very helpful

<alastairc> https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%22WCAG+2.2%22

WCAG 2.3 / Next steps discussion, see https://lists.w3.org/Archives/Public/w3c-wai-gl/2021AprJun/0113.html

<alastairc> Option 1: Focus on 3.0, no 2.3.

<alastairc> Option 2: Focus on 2.3, light 3.0 (current approach)

<alastairc> Option 3: Focus on 3.0, taskforce/subgroup on 2.3

<alastairc> Results

<alastairc> Option 1 7 (primary) 1

<alastairc> Option 2 3 1

<alastairc> Option 3 12 6

Alastair: we do need to have a concrete idea of what we're working on for a year, gather requirements etc. for 2.3
... need to decide if we go ahead with the task force and who'd want to be on it

<Zakim> AWK, you wanted to suggest that we should do a poll to ask what individuals in the WG will work on, 3.0, 2.3, or both.

awk: it's very easy to say let's focus on 3.0 and keep 2.3 subgroup going. Some people might be able to do both but time commitment will vary

Rachael: want to encourage to think of this as a subgroup and not a task force
... subgroup has more of a limited scope

Juanita: standards in 3.0 are more subjective. Moving away resources from the 2.0 series...it's going to take a long time for governments to move to 3.0

<ChrisLoiselle> Sukriti, do you want me to take over scribing for you?

<JF> +1 to Wilco

wilco: some type of long term support for 2.x is needed

Alastair: discussed doing that last week

<Jaunita> +1 to wilco

katie: if 3.0 is not our primary focus, will not happen

<jon_avila> I am with Katie on this!

katie: have to have a task force for 2.x as well

<Zakim> JF, you wanted to counter Rachael

JF: want to see an actual task force instead of subgroup

<ChrisLoiselle> scribe: ChrisLoiselle

<AWK> I agree with Katie about 3.0 needing attention in order to progress.

<AWK> Also agree that task forces can be short term

<Wilco_> +1 to TF

JF: I believe a task force is best for efforts needed.

Alastair: For the next year, group could contribute. Difference between task force or subgroup can be discussed.

<Ryladog> Let me re-iterate, please please no 2.3, just move to 3.0. Have a task force to address 2.x issues and techniques

Alastair: On whether governments are ready for WCAG 3 , and if they are ready to uptake vs. WCAG 2.2 or WCAG 2.3 is the question. Focus is important. WCAG 3 has gotten to a point where we can at least start parallel work.

DavidMcD: Question on starting on WCAG 3 and whether we are introducing WCAG 3 into our method or if we are jumping into WCAG 3's methodology.

Alastair: We'd be bringing our expertise to their efforts. Review and catching up and making changes would be work in progress on merging and making it AGWG primary focus.
... Thursday will be a great conversation area for all of this.

Rachael: I feel this is the time for AG to get involved in Silver.
... FPWD is a starting point for structure and conversation and not an end point.

DavidMcD: Thank you.

<JF> https://lists.w3.org/Archives/Public/public-silver/2021Apr/0104.html

JF: We aren't specifically working on a WCAG 2.3 . Right now a sub group of silver is working on XR. My concern is working with working draft and testable statements. I think the work on testable statements should be worked on within this group (AGWG).
... Testable statements in XR should be made and published sooner rather than 3 to 5 year timeframe.

<Ryladog> *me says from "when we start fully focusing on WCAG 3"

JF: I don't know if that adds clarity , but talking to WCAG 2.3 would be logical to an extent.

Alastair: What would go in to WCAG 2.3 and what would groups focus be?

Michael: On clarity on resources available , what would a survey show on who is available for what work?

Michael, hope I caught what you were saying , clarify if you need to , sorry!

Alastair: If 2.3 doesn't happen , perhaps efforts are moved into WCAG 3 .

<michael> And 2.2

<david-macdonald> 3.0

<jon_avila> 3.0

<Rachael> 3.0

<Ryladog> * says we need EVERYBODY primarily focused on 3.0 - whether it is comfortable or not.

<ben> 3.0

<Rain_> 3.0

<johnkirkwood> 3.0

<sarahhorton> 3.0

<Jennie_> 3.0

<AWK> 3.0

<Wilco_> 3.0

<bruce_bailey> 2.3, have to drop 3.0

<Ryladog> 3.0

<michael> 2.2 to finish line, then split

<JustineP> 3.0

<JF> @ Bruce - not a 2.3 TF, a "testable statements" TF

BruceB: I would say if we to a task force for 2.3, I'd drop off the WCAG 3.0 related activity.

<Rachael> Jf, I do not think that is what we are discussing

<morr4> 3.0

<michael> Split effort between

<Zakim> sarahhorton, you wanted to say that the 3.0 content development process uncovers new requirements

For me, ChrisLoiselle I'd be in both AGWG and Silver due to my interest in Visual Contrast and Low Vision Task Force etc. until they merge and become one. So I think I'm technically already splitting my efforts at moment.

<Ryladog> *says WCAG 3 was originally Web 2010

<Jaunita> I have to drop too, but I would like to join the 2.3 group. I can split my time

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/brentb: will still/shadi: will still/
Succeeded: s/shouldn't/should/
Succeeded: s/svg spe/svg spec/
Succeeded: s/testabel/testable/
Succeeded: s/scribe: Rain/scribe: Rain_/
Default Present: ChrisLoiselle, AlastairC, jeanne, shadi, Laura_Carlson, Jennie_, ben, Sukriti, JF, Nicaise, morr, sarahhorton, Detlev_, KarenHerr, Katie_Haritos-Shea, johnkirkwood, sajkaj, AWK, Rain_, bruce_bailey, mbgower, JustineP, juliette_alexandria, MelanieP, jon_avila, david-macdonald, .75
Present: ChrisLoiselle, AlastairC, jeanne, shadi, Laura_Carlson, Jennie_, ben, Sukriti, JF, Nicaise, morr4, sarahhorton, Detlev_, KarenHerr, Katie_Haritos-Shea, johnkirkwood, sajkaj, Rain_, bruce_bailey, mbgower, JustineP, juliette_alexandria, MelanieP, jon_avila, david-macdonald
Found Scribe: Rain
Inferring ScribeNick: Rain
Found Scribe: Rain_
Inferring ScribeNick: Rain_
Found Scribe: Sukriti
Inferring ScribeNick: Sukriti
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Scribes: Rain, Rain_, Sukriti, ChrisLoiselle
ScribeNicks: Rain, Rain_, Sukriti, ChrisLoiselle

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.)