<alastairc> scribe: Rain
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
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.
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.
alastairc: We have some WCAG 2.2 misc items to discuss
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
<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
<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.)[End of scribe.perl diagnostic output]