<Chuck> meeting: AGWG-2022-12-13
<Chuck> cool, got it.
<Chuck> forward slash topic <text>
<Chuck> NO COLON
<ChrisLoiselle> scribe: ChrisLoiselle
Rachael: New member introductions and any topics for next year?
Rachael: Last meeting of year, no meeting next week. Next meeting is 10th of January
If attending CSUN, plan for Monday so we can get together.
<Zakim> bruce_bailey, you wanted to ask about MIT urls?
Bruce: Zoom urls may be changing?
Michael C: MIT zoom accounts will be extended. Will change over time .
<alastairc> We'll include zoom links on the W3C site info pages anyway...
Rachael: Outcomes as user needs sub group report update.
<jeanne> Writing Outcomes as User Needs https://docs.google.com/presentation/d/1UpBHL1DBezcFu-IuExakvEYJkWzZwFniE0gelPkDDkI/
Shawn L: presents updates with Jeanne, places url in IRC
Jeanne: References TPAC discussion and talks toward user needs for conformance and sub group follow up within Silver. We've met for 8 weeks.
Talks to goals and approaches then built prototypes . Looked at two guidelines , captions and text alternatives for WCAG 3 FPWD , looked for commonality and special purpose
Makoto: Talks to alt text
example. Citing concrete examples.
... Organized flows in to categories based on WAI tutorials
<Makoto> WAI’s Image Tutorials : https://www.w3.org/WAI/tutorials/images/
7 types of images in regard to categorization
Category of other was put in to bucket for scare or intense images, musical scores, etc.
built out user needs for functional images. Talks to what users need to perceive and understand for 7 types of images.
allows us to write outcomes and methods based on user needs.
We tried to write outcome and method for alt text. Used the method reference for alt decision tree for determining which type the image falls under and use one of methods from list for each type
<Makoto> An Alt Decision Tree : https://www.w3.org/WAI/tutorials/images/decision-tree/
decision tree can be used as a gateway vs. WCAG technique list out .
Makoto: talks to methods for alt text and appropriate methods per decision tree.
It may be possible for some ,not all guidelines to follow this type of structure. It has been hard for content authors to meet when reviewing understanding WCAG document.
decision tree may help it become easier to find useful and finding methods easier.
Jeanne: Captions is the next example. We took a different approach.
Suzanne took a different approach.
Suzanne: Group guidelines, methods, user needs. How can different layers have different advantages. Addressing user roles in those layers based on conformance model proposed.
Which user roles would apply. Left shift , i.e. well before accessibility testing. Owning accessibility, our content or our website placeholder content was generated.
Outcomes present the design or research challenge by product feature, geared toward the product owner. Outcome was based on product allows user to get info through speech or auditory hints through another method. Rather than talking to captions and what you need to address. Product feature specific.
For narration or captions, you can have user needs as next layer. Functional need and solution pairs , i.e. user can't hear the audio, will get same information at same time through captions.
for WCAG 3, combined functional needs would be surfaced so it isn't hidden within methods or functional need in a deeper level.
May not require all of it, but at least address based on audience or end users.
<scribe> New unique solutions are listed in outcomes and talks to the "why"
Methods (Techniques) , are specific how to , coding, visual design
Jeanne: We couldn't eliminate outcomes altogether. Both examples had a type of decision tree regarding badges proposal.
talks to target audience and project then method recommendations or advisory techniques
Shawn L : Conclusions - identified advantages , using known materials and decision tree. For audio, left shifting and the ownership and relatability .
Challenges - need more types of images , probably more than 7 types of categories and graphical examples would be useful.
general - non trivial amount of work , should be done in small groups on different parts asynchronously . Checkins with stakeholders are important.
outcomes and user needs should be present where approach is still result oriented . Support assistive technology the user is using rather than just programmatically association
Question 1 - do we agree we should agree we should develop other guidelines per this process?
Question 2 - do how does this align with the activities of other subgroups?
Gundula: One alternative was a comic, if comic has speech bubbles, does it represent graphic or part of speech?
<Fazio_> I think being able to use existing 2.0 guidance will make it easier to adopt
Mike G: Two polar opposite ends . Image guideline vs. time based media , kitchen sink vs. separate structure . Makoto's decision tree presents how diverse this is on images alt text. Functional images may be its own . Decision tree can be paired down.
Mike G: Time based media starts with text equivalent , then dives deeper. If just for speech, captions supplied, most are transformational , author shouldn't have to do other things related to plug ins. Author problems vs. transformation problems. Maybe we should look at it from content owner or author problem.
?
<Fazio_> +1 MG
Gregg: One catch all , is due to the list . Always this must be true and then examples , where as with captions , there are different types , thus different requirements.
Lists have problems. Try to avoid lists. Overall has to be there first then list as second layer.
Perhaps in application doc that can be updated vs. a standard . Techniques or methods in support document we can continually update.
<Lauriat> +1 to keeping things like lists where we can update them easily, absolutely!
<SuzanneTaylor> that's an interesting point, if we DO have a list-generating sentence structure, we'd need a final catch-all at the end (surfacing the list though, makes it easier to understand helps the product team remember
<Fazio_> US supreme court interprets shall as mandatory
Image types is related to list out problem, regarding do this and examples. The examples, were do this, provide or commands, thus are recommendations vs. having "shall" so wording matters . Great that there is more guidance around these. Needs are good for understanding. Methods tend to be like techniques, which should be in separate doc.
My website phrasing talks to insertions , thus is it there website or someone else's?
<Zakim> jeanne, you wanted to answer MG
Jeanne: MG, user need oriented was talk, not author related, so stuck with that throughout.
Gregg, we didn't recommend removing outcomes , user needs would be informative . User needs move to methods.
<SuzanneTaylor> (I took some notes in the Audio doc based on Gregg's comments)
Rachael: Please feel free to reach out to Silver Task Force with additional information or comments
<Fazio_> more examples are needed
<GreggVan> thank you - makes sense
<SuzanneTaylor> https://docs.google.com/document/d/1YFLroVspFQSEqUgAcI8qPS2CI6EboZcHA43FQNWpt-8/edit?usp=sharing
Rachael: ACT topic is next ,
Rachael: Automatic testing only or human testing needed?
<Zakim> Wilco, you wanted to say "no"
Wilco, no. ACT rules are broadly applicable. Can and are used in Trusted Tester. Stayed away from automated vs. manual, as technology changes.
Wilco: Most implementers are from automated space, so most of what has come out thus far was related to automation , it relates to both.
Rachael: Any questions on that ?
<GreggVan> +1 to testable line keeps moving
Rachael: To Gregg, you approved with adjustments. Talks to the "" be removed within comments on survey.
Gregg: Perhaps in API or code markup that you could put something vs. not putting something there. I.e. alt text of "" which it is null vs. decorative
Wilco: We have about a dozen rules that have this structure, we'd need to update it elsewhere as well. Talks to whitespace example . We are happy to remove it if group agrees.
Gregg: I think that is a good idea. Or completely empty, no whitespace. I leave it to you . I wanted to raise as people might do it.
Wilco: I will bring to task force to update.
<GreggVan> +1
Gregg: Thank you.
<Zakim> bruce_bailey, you wanted to ask if this it: https://www.w3.org/WAI/standards-guidelines/act/rules/m6b1q3/proposed/
<Rachael> draft RESOLUTION: Accept New Rule Menu item has non-empty accessible name, Wilco to bring back “” question to group
Wilco: you can see an example in expectation , Bruce.
<Rachael> draft RESOLUTION: Accept New Rule Menu item has non-empty accessible name, Wilco to bring back “” question to ACT for review and decision
Gregg: And then can decide it, doesn't have to come back to AG for review again.
Wilco: We will have to comeback either way.
<alastairc> +1
<Chuck> +1
<GreggVan> +1
<Wilco> +1
<ShawnT> +1
<joweismantel> +1
<bruce_bailey> I agree that null and empty and quote space quote are three different things
<bruce_bailey> +1
<Ben_Tillyer> +1
<Detlev> +1
<GN015> +1
<kirkwood> +1
<Ryladog> +1
<jon_avila> +1 I support the use of the quotes in the example
<jaunita_george> +1
<laura> +1
<Jennie> +1
<bruce_bailey> oh, and missing different than null
<Makoto> +1
<ToddL> +1
<Raf> +1
Bruce: Plus one to make it clear. Missing alt , vs. null alt .
RESOLUTION: Accept New Rule Menu item has non-empty accessible name, Wilco to bring back “” question to ACT for review and decision
<Ben_Tillyer> @Bruce - Although it looks like there is a space on the URL posted, that's down to the font, there is no space between the quotes
<Chuck> https://www.w3.org/2002/09/wbs/35422/act-dec-2022/results#xq9
<alastairc> Scrollable element rule: https://www.w3.org/WAI/standards-guidelines/act/rules/0ssw9k/proposed/
<bruce_bailey> @chuck and I think "missing" is another rule -- so these variations may already all be covered
Rachael: One person did not approve. Talks to Gregg's comment around keyboard accessible. Talks to Gundula's comments as well. Revolves around full rule of partial rule.
Wilco: On focusable question, if an element is focus, arrow keys can move the scroll bar.
On second point, ACT rules don't tell you when it passed, tells you failure states.
<Wilco> +1 can do
<Zakim> Rachael, you wanted to ask question
Gregg: I think under assumptions, adding that into scroll bar example, that would solve issue.
<Zakim> mbgower, you wanted to say it would be good to publish the decision tree
Rachael: Is the intent that a second rule be present?
Mike G: In assumptions, more defining decision tree then rules talk to the decision tree. Parsing the rule first vs. make decision tree explicit regarding logic flow and potential flaws
Gregg: I think that it needs to be in expectation vs. assumptions, based on conversation on this topic.
Alastair: These are finding fail states, vs. passing a success criteria .
Failure techniques for tests rather than passing.
<Ben_Tillyer> Just removed myself
Wilco: Yes to Alastair . If component isn't focusable, we know there is an issue. We can have another rule that talks to other issue. We try to keep rules atomic and don't build up a complex tree of decision. Rules maintenance and understanding is main reason behind that .
<Wilco> there isn't today, but there can be
Gregg: Plus 1 to keeping things flat regarding structure.
<GreggVan> great
Jon A: I agree that should atomic. The description or name may need to be clarified to include focus order so it can be scrolled.
<Wilco> +1 can do
<Zakim> mbgower, you wanted to say maybe 'decision tree' is the wrong word, but a list of failure points might allow for better categorization
<alastairc> Suggested resolution: Publish now, update later.
Mike G: A list of failure points that may better categorize would be beneficial. Checking because of X, Y, Z or this or that.
Wilco: I appreciate those comments. Meta level is on to do list to overview of where and why the rules fit.
<Rachael> draft RESOLUTION: Accept New Rule Scrollable element is keyboard accessible with an update to the description to clarify the scope
<mbgower> Thanks, Wilco! Really impressed with all this.
<Chuck> +1 tangent alert
Mike G: I have been working within dialogue boxes, I don't think you'd want body of dialogue box gain focus if it isn't scrollable. Is there any way to split the question , i.e. if it doesn't need focus and gets focus? Efficiency of keyboard user.
<jon_avila> Mike I think that could be another example
Rachael: running out of time, but would like to capture that topic.
<Jennie> mbgower: that quiestion could lead into the much needed test for when there are multiple scroll bars within the same page.
<Wilco> Answer is yes, its part of the rule, see https://www.w3.org/WAI/standards-guidelines/act/rules/0ssw9k/proposed/#scrollable-element
Gregg: Agree on rename , but want to capture other half on tabbing to keyboard scrollable.
<Rachael> draft RESOLUTION: Accept New Rule Scrollable element is keyboard accessible with an update to the description to clarify the scope and plan for a complimentary rule about being scrollable
If scrollable and tab to it.
<Zakim> Chuck, you wanted to ask for scribe change
+1 to new scribe :)
<Chuck> +1 to draft resolution
<Rachael> GreggVan: Send back to fix the structure, name and expectation.
<Jennie> Wilco - love your comment about working towards a flow. I would be interested in chatting about this in the future
<jon_avila> I can scribe
Gregg: We need new name and other work,
<Rachael> scribe: jon_avila
<Chuck> Thanks Jon Avila!
<Wilco> +1 to resolution, disagree with updating the expectation.
Gregg: do think they need to be combined.
<Rachael> draft RESOLUTION: Accept New Rule Scrollable element is keyboard accessible with an update to the description to clarify the scope and plan for a complimentary rule about being scrollable
<Jay_Mullen> +1 to resolution
<Chuck> +1
<Detlev> +1
<mbgower> 0
<Ben_Tillyer> 0
<ShawnT> 0
<jaunita_george> +1
Rachel: would like to vote if this go forward 0 if you are in between
<Ryladog> +1 with fixes
<GreggVan> -1 should be "if scrollable then gets focus and can have arrowkey scrool
<laura> 0
+1
<joweismantel> +1
<Zakim> GreggVan, you wanted to say we should send it back since it needs new name and new structure - description is not good enough
<GreggVan> q_
<alastairc> +1, so long as the described fails are accurate, it is informative and can be updated
<Chuck> 4 +1's, 4 0's, 1 -1's
<GreggVan> Ok
Wilco: What Gregg is asking for is not allowed for rules format - the format says we need to create atomic rules.
Rachel: we have decent consensus to go forward. Gregg I see you are objecting.
<Raf> +1
<Chuck> 5 +1's
Gregg: It doesn't make sense to
go forward if it needs to be retitled and described. Come back
with a pair.
... Does need to be cleaned up. If accept it goes in this way.
Not sure what it means to accept if we have to rewrite.
Rachel: pretty minimal rewriting the 2nd rule is not required to pass the first. All rules are independent - this just a scope change in one sense.
Wilco: This work goes to the task force so the group doesn't have to spend an hour every week
Gregg: Has to be rename as it's not accurate. Description has to change. The background and assumption - it's not just a simple thing.
<Chuck> no
Rachel: I feel like we are working on different understandings. Does Gregg's comment changes anyone's vote?
<bruce_bailey> yes
Bruce: Changing to a -1
<Chuck> 4 +1's, 4 0's, 2 -1's
Rachel: sending it back. Worth conversations outside. We can't move forward as we as a group want to if we can approach over time.
<Chuck> https://www.w3.org/2002/09/wbs/35422/act-dec-2022/results#xq8
<Rachael> draft RESOLUTION: TOPIC: New Rule: Iframe with interactive elements is not excluded from tab-order
Rachel: Briefly talk about number 8. Everyone passed without object. iFrame is not excluded from tab order. Does any one have concerns with accepting?
<Rachael> draft RESOLUTION: accept New Rule: Iframe with interactive elements is not excluded from tab-order
MikeG: Make observation of why 7 and 8 are clearner as people didn't get down to them. One to speed up but that care about this - could sign up for a bi-weekly check and do a more check and stamp at working group level. Possible change of process.
Rachel: Good suggestions to talk in planning call. Email chairs with other options.
<Wilco> +1
<GreggVan> +1
<Chuck> +1
<Ryladog> +1
<laura> +1
<alastairc> +1, no concerns
<bruce_bailey> +1
<joweismantel> +1
<Detlev> +1
<kirkwood> +1
<Makoto> +1
Rachel: Do have draft resolution to accept new rule. +1 if conformtable - if not or 0
<ToddL> +1
+1
<mbgower> 0 haven't looked at it, sorry
<jaunita_george> +1
Gregg: Lots of questionnaires where people don't respond. I think a lot of people do respond. Just because one out of 3 had a problem - not sure there is a problem.
<Ben_Tillyer> 0 not sure why iFrames with interactive elements have to be called out
Wilco: I'll need to look at this more closely. Not sure if we can publish rules if we don't have rules updated. That will create inconsistencies between versions of ARIA we are used in question 9.
Gregg: 9 has no objections.
RESOLUTION: accept New Rule: Iframe with interactive elements is not excluded from tab-order
<Rachael> TOPIC :Update rules approved today
Rachel: Topic is updating rules we have approved today since we didn't get through them.
<GreggVan> +1
<Chuck> +1
<laura> +1
<ToddL> +1
<kirkwood> +1
<Wilco> +1
<joweismantel> +1
<Makoto> +1
Rachel: Can everyone +1 if you are conformable making those updates.
<Jennie> +1
<bruce_bailey> +1
<ShawnT> +1
<Ryladog> +1
+1
<Rachael> RESOLUTION :Update rules approved today
RESOLUTION: Update rules approved today
<jaunita_george> +1
Rachel: First topic is removing 4.1.1 or marking obsolete.
Alastair: Proposal was to keep
heading 4.1.1 parsing and remove SC text and add note and link
to understanding - that is what was agreed several weeks
ago.
... Wilco had then recommending marking obsolete. We as a group
had not wanted people to test or report on it in 2.2 We agreed
it's backward compatibility from a user requirement point of
view.
<Jay_Mullen_> (forgive - having connectivity issues)
Alastair: Question is then to keep the SC text. We have a spread of answers.
Rachel: 2 people would like to
keep 2 and mark as obsolete. 3 want to remove and mark obsolete
and so forth.
... Wilco - not ok removing text as not removing backward
compatible promise.
<Detlev> Wilco: Would it be possible to re-open the ACT rules survey?
Rachel: Todd also voted that way but did not leave comment.
<AWK> +AWK
Rachel: Gregg had said removed as
it's clear that we are not recommended and note the purpose of
AT parsing HTML originally. Note would go in standard.
... Makoto also marked this way - could also leave text - but
only if it has a note.
... 3 people voted to remove SC text - either is fine - we
should pursue recommendations to get address in 2.0 and
2.1.
Awk: addressing 2.0 and 2.1 address backward compatibility issues.
Rachel: Bruce says I would rather remove and keep 4.1.1 without text to show that is was removed.
<Zakim> alastairc, you wanted to comment on removal vs styling
Rachel: A couple of themes - do we need to address 2.0 and 2.1
Alastair: Chair hat off - I think it's a lot clearly to remove the SC text from the spec - keeping the heading and number with note why it was removed and keeping understanding document for historical purposes - it will be clearer.
<Zakim> bruce_bailey, you wanted to ask if what we do for 2.0 , 2.1 impact choice for 2.2 ?
Bruce: Understandable we need to figure out 2.0 and 2.1 but we need to figure out 2.2. I don't think 2.2 impacts 2.0
<alastairc> +1, can decide 2.0/2.1 separately.
Rachel: does anyone want to speak to why we need to talk about 2.0 and 2.1?
<Wilco> +1
MikeG: It's where you have an organization that needs to report on different standards. If you do a test and there are new things there. It is a consideration.
<Rachael> strawpoll: a) Decide about 2.2 and address 2.0 and 2.1 separately b) Decide all three at once
<mbgower> b
<Chuck> a
<ShawnT> a
<joweismantel> a
<Wilco> B, strong concern about A
<Rachael> a
<alastairc> a
<Detlev> I am fine with anything here
b
<AWK> b is better but happy with a
<Jay_Mullen_> b
<bruce_bailey> a
<GreggVan> b but can live with a to keep it moving
<jaunita_george> b
<alastairc> (b would be fine if it was a quick decision.
<Makoto> a
<GN015> b
<Ryladog> c
<Chuck> I count 7 a and 8 b
<ToddL> b
<Chuck> and 1 c
<Ryladog> sorry
<Chuck> 7 a 9 b
Rachel: pretty even split. Katie, What is C?
<Ryladog> b
<Wilco> no
<bruce_bailey> i am okay with b -- i dont think it will be fast
<Chuck> Yes
<ShawnT> yes
Rachel: For the people who voted for A - are you ok if we try to make a quick decision on B?
<GreggVan> ok with either
<ShawnT> +1 to bruce_bailey
<joweismantel> +1 to Bruce
<Rachael> ackwil
Wilco: What concerns me is that we will end up with different results with 2.2 and 2.0/2.1
<bruce_bailey> +1 that implications for 2.0 and 2.1 might not be the same
<Rachael> Lets go ahead and discuss all three and see how far we get
<bruce_bailey> +1 to AWK for republishing 2.0 with errata
<mbgower> +1
awk: A - our CFC process would hopefully address. This is something we have wanted to do for years. To republish the specifications with the errata included. This would also remove confusion. What is printed on the website is not actually what the errata includes. We would have change to make it nice again.
<AWK> +1 to gregg
Gregg: 2 things, removing something that does not make the document weaker does not break - if you pass the old one then you pass the new one. The reason I am favor of all 3 - everyone would be relived as no one has identified a problem.
<GreggVan> +1
Alastair: could remove across all 3 - that would create consistency across all 3 - would be a strong and bold move update and make on all and republish so it's on the face of the spec. If we could support that would decide all 3.
<Rachael> proposal: Remove the text, mark as ?, add Note explaining why
<Wilco> -1
<Zakim> bruce_bailey, you wanted to mention 2.2 and republishing 2.0 puts pressure on U.S. Federal government to update 508
Bruce: I'm going to note - 2.2 is pressure on Access Board - I think it's still the right think to do.
Ryladog: you could add a note - but don't you should remove things in an existing standard - I don't think it's a good idea.
David: Governments do this type of things all of the time - ADAGAA - when you modify something after this date you must now comply with new version of the standard. As of the date we would like you to do this now. That's pretty common
<Zakim> GreggVan, you wanted to say they are not previous standards -- they are all current and active and according to standards work -- a change to a new version is retroactive
<AWK> +1 gregg
Gregg: Everyone is missing important thing here - that may be true for regulation - we do not have authority to say you use 2.2 because we don't regulate. In our case - all 3 standards are all current active standards and required by different government bodies. The proper thing is to mark it obsolete in all active standards. So people don't do something that is not proper.
<kirkwood> +1 to marking obsolete
Fazio: explain this is our guidance because time changes - changing something in backend could be problematic. I know we are not a regulatory body. As people do use it for regulation.
<Fazio_> I'm speaking in general terms
Gregg: Other people do require the standard. Doubt there is any litigation over 4.1.1. No benefit to users and no benefit to users and a lot of work for evaluators. You can't test it as there is no benefit. Not clear why it would be obsolete.
<Zakim> mbgower, you wanted to say we have to explain what obsolete means
<Fazio_> other countries still use 1.o
<Chuck> +1 mg
<bruce_bailey> USAB does hear anecdotal stories about 4.1.1 causing problems -- Overlay vendors
MikeG: I just wanted to pause and note that we seem to be on same page in terms of 4.1.1 being needed and confusion that it causes. Whatever we do we need to explain what it is and what is our intention. HTML uses obsolete in a different way. We might want to focus on wording.
<Zakim> bruce_bailey, you wanted to disagree about litigation
<GN015> Fazio, which countries ares still on version 1.0?
Bruce: I want to disagree with Gregg - we do hear at Access - we hear people to be pressured over 4.1.1 from overlay vendor on why people should buy their products.
<ToddL> +1 to Bruce
Wilco: 4.1.1 is one of the most failed success criteria in terms monitoring. Instead of removing can we hide it behind a button?
<Ryladog> No Wilco, we have to explain why
<Zakim> alastairc, you wanted to comment on middle ground
Gregg: I would ask Bruce - you are speaking in favor of it being removed as it's causing issues and people are getting wrapped around something we don't need.
<Wilco> @Ryladog, for sure! It needs to be explained regardless.
Alastair: On Wilco's point on the middle ground - I guess it would be possible - but why have it there if we are not asking people on it. The middle ground would be a note saying it would be removed and linked to the understanding document and we have the SC in the understanding document.
<alastairc> +1, it should be out!
<Zakim> GreggVan, you wanted to say -- there is a link a the top of the std that will give you the old version
<Chuck> +1, it should be out
Wilco: What you are suggesting - it removes normative language out of the standards. It's about whether it's in the standard or not. If it's obsolete it's still in the standard.
<Wilco> yes
Gregg: If it's obsolete but we leave it in then we could use cross out line - but we could put a link where the text is. To leave it there leaves people to still argue to say it's still there.
<bruce_bailey> to summarize, I agree that 4.1.1 is not causing litigation -- but it is causing THREATS of litigation
<alastairc> +1, we really want to prevent that confusion, by removing
<Zakim> Rachael, you wanted to speak to button
<GreggVan> +1 to no buttons
<Chuck> +1 no buttons
<ShawnT> +1 to no button
Rachel: Chair hat off - strongly object to adding a button as it makes a static spec interactive.
<bruce_bailey> +1 to no button
<Rachael> Strawpoll: a) update 2.2 with note and add a note only to 2.0 and 2.2 b) update all 3 consistently
Rachel: Chair hat on -
<mbgower> "Requirement 4.1.1 is obsolete. It does not need to be reported in WCAG 2.2. For WCAG 2.1 and 2.0 we are recommending that it not be tested and marked as passing on all reporting. For explanation, see updated Understanding document"
<Rachael> Strawpoll: a) update 2.2 with note and add a note only to 2.0 and 2.1 b) update all 3 consistently
<Rachael> Strawpoll: a) update 2.2 with note and add a note only to 2.0 and 2.1 b) update all 3 consistently c) something else
<mbgower> a
<ShawnT> a
<bruce_bailey> -1 , c
<Chuck> a, can live with b
<alastairc> b, ok with a.
<Makoto> a
<GN015> b
<Ryladog> a
<Francis_Storr> a
<GreggVan> b
<jaunita_george> a
<Wilco> b
B
<joweismantel> a
<ToddL> b
<Detlev> happy with any option that gets us past this place
Bruce: Saying it's obsolete doesn't go far enough - seems like weak work.
<Chuck> 8 a, 6 b
<laura> b
Rachel: Not saying how we update it - just talking about handling it all at once.
Bruce: Not ok with obsolete for 2.2 - but ok for 2.0 and 2.1
Rachel: Straw poll was confusing.
<Ryladog> yes
Rachel: Seems like we have slight preference for 2.2 than 2.1 and 2.0. Is the correct?
<Chuck> 9 a, 6 b
<GreggVan> bq+
<mbgower> Requirement 4.1.1 has been removed in 2.2. It does not need to be reported in WCAG 2.2. For WCAG 2.1 and 2.0 we are recommending that it not be tested and marked as passing on all reporting. For explanation, see updated Understanding document"
<ChrisLoiselle> don't need to be on queue, but wanted to add for reference , a change log , https://section508coordinators.github.io/TrustedTester/appendixb.html. For example, On https://www.w3.org/TR/WCAG22/#comparison-with-wcag-2-1, you'd highlight with a note that it would fall off . Wouldn't that be a place to talk to what has changed and why?
<bruce_bailey> +1 to doing something different for 2.2 maybe from 2.1 and 2.0
MikeG: Have put into 2 rough drafts - there is guidance on not reporting in 2.2 and wording on what we recommend for testing and passing in 2.0 and 2.1 and then all the understanding documents get updated. Whether we feel we need to back to 2.0 and 2.1. Preamble might not be normative.
<Zakim> mbgower, you wanted to say rationale goes in the pre-amble of 2.2 and others?
Gregg: Updating in 2.2 will have no practical effect for years as 2.0 used.
<Zakim> alastairc, you wanted to comment on migration
Wilco: Option D - leave as is and punt to after we have 2.2 to recommend. It's something we all approved when we let it get dropped from the agenda.
Alastair: this came back on the agenda as people including the group had been misinterpreting SC 4.1.1
<Ryladog> Suggest for 2.0 and 2.1: "Note: In a more recent version of this standard WCAG 2.2 this SC has been removed as the browsers have addressed this problem"
Alastair: There are migrations paths if we remove from 2.2 and put notes in 2.1 and 2.0 there will be a migration path. That is our first decision. Can we agree to remove text and add the note and then decide what we do with 2.1 and 2.0
<Zakim> GreggVan, you wanted to say that will not stop venders from
Gregg: The big problem from overlay vendors and others who make a problem for people who don't know or 2.2 and who use older standards such as older tools that have 2.0. So we need to change the other standards.
<mbgower> Understanding document change for 2.0/2.1. "Nothing should fail under 4.1.1. As such, it does not need to be tested, and can be reported as passing on all pages. Where improperly coded content causes accessibility failures, the failure should be reported against other criteria than 4.1.1"
<Rachael> draft RESOLUTION: Remove 4.1.1 in 2.2 and add note
<Wilco> -1
<Chuck> +1
<bruce_bailey> +1
<alastairc> +1
<Ryladog> +1
<mbgower> +1
<Rachael> +1
<GreggVan> -1
<Makoto> +1
<joweismantel> +1
<ChrisLoiselle> +1
<GN015> +1
<laura> +1
+0 only be I want to make sure it aligns with 2.0 and 2.1
<Chuck> 11 +1's, 2 -1's, 1 vote of zero
<GreggVan> -1 because you can't say that in understanding if the std doesnt also sayit
<Raf> +1
<Detlev> 0
<ToddL> 0
<Francis_Storr> +1
<bruce_bailey> @mbgower: > It does not *need* to be reported in WCAG 2.2 -- I do not think that part is strong enough
<Chuck> 14 +1's, 1 -1's, 2 votes of zero
Gregg: +1 it as I read wrong line.
Wilco: We committed to no breaking changing and removing it outright is a problem.
Rachel: Recommend we accept as we have strong support and then move to 2.1 and 2.0
<Ryladog> Suggest for 2.0 and 2.1: "Note: In a more recent version of this standard WCAG 2.2 this SC has been removed as the browsers have addressed this problem"
RESOLUTION: Remove 4.1.1 in 2.2 and add note
Rachel: Do people want to remove 4.1.1 in 2.0 and 2.1 and add note or strike out and add note?
<Rachael> strawypoll: a) Remove 4.1.1 in 2.0 and 2.1 and add note, b) Strike out the text and add anote c) leave the text in and add a note
Wilco: do we know if we can do something like this to remove something?
<Zakim> alastairc, you wanted to comment on process
<Ryladog> b
<GN015> d) what is the effect of striking out?
Alastair: Can you speak to process? As long as we as a group agree and republish a spec we can do that. A bit of management change - I think that is no longer a blocker.
<Chuck> +1 current management expressed support
<alastairc> scribe+ alastairc
<alastairc> jon_avila: Some standards list a date, if we don't do an errata, it woudn't include this change?
<Zakim> GreggVan, you wanted to explain
<bruce_bailey> +1 to doing both things
<Rachael> strawpoll: a) Remove 4.1.1 in 2.0 and 2.1 and add note, b) Strike out the text, mark as obsolete and add anote c) leave the text in, mark as obsolete and add a note
<Chuck> jon_avila: Gregg answered.
Gregg: You often cite a standard and date in case it's revised. 2 stage process. They also publish date but not sure it matters.
<alastairc> a, b
<GreggVan> a or b prefer a
<Ryladog> c
Bruce: Just talking about 2.0 and 2.1 with assumption we remove from 2.2
<GN015> d) remove and explain why it was removed
<Rachael> a
<Francis_Storr> a
<Chuck> a, can tolerate b
<joweismantel> a
<bruce_bailey> c -- but any okay
<Detlev> take any
<kirkwood> assuming note will have date of removal.
<GN015> a
<mbgower> okay with any; the wording and guidance is what I care about
<alastairc> sorry, a, c is ok.
<Rachael> ack
<Wilco> abstain, because of my objection to removing the SC
<Makoto> b or c
<Zakim> GreggVan, you wanted to say all are equiv
<laura> a, b
Gregg: All the same - but C is dangerous because it's still there.
A or B
<bruce_bailey> gregg just changed my vote to a
<Chuck> 8 a, 2 b,
<Plansmash> a
<ShawnT> a
<joweismantel> A note, strikethrough is not announced consistently by screen readers
<Chuck> a has very strong support
<alastairc> Suggested resolution: Remove 4.1.1 in 2.0 and 2.1 and add note (same as WCAG 2.2)
Rachel: for those of you who support leaving or striking out and marking obsolete - can you speak to your concern. Can you tolerate it.
<kirkwood> agree with Katie about link issue
Ryladog: There are many links to the SC - we want to leave a target to a link - but in the latest version it is removed as it's no longer a version.
<Zakim> alastairc, you wanted to say there's no breaking URLs going on here.
Rachel: My understanding we leave the heading and link so it's anchor and won't break the link.
Ryladog: that is good and important.
Alastair: May or may not say obsolete and the anchor and understanding document would still be there and would say what it is was in 2.0 and 2.1 and we will say it's no longer recommended. There is no breaking urls. Not sure how it is easy to update 2.0 document. will need to check with Michael.
<Rachael> draft RESOLUTION: Leave the SC number and short name, remove the text, add an explanatory note
<ChrisLoiselle> c , leave in for 2 or 2.1 and add note , unless you are publishing a new W3C recommendation. C is pointing people to most recent recommendation. +1 to Katie H. I.e. referenceable . Defer to group on decision .
<bruce_bailey> +1
<Chuck> +1
<Ryladog> +1
<Ryladog> +1
<alastairc> Suggested resolution: Remove 4.1.1 in 2.0 and 2.1 and add note (same as WCAG 2.2)
Wilco: This is going a little to fast - are we saying this an errata or republishing?
<ShawnT> +1
Rachel: We are proposing an errata and then republishing spec.
<Rachael> draft RESOLUTION: Leave the SC number and short name, remove the SC text, add an explanatory note, publish as an errata and republish spec
<Rachael> draft RESOLUTION: Leave the SC number and short name, remove the SC text, add an explanatory note, publish as an errata and republish spec for 2.0 and 2.1
<Chuck> +1
<Ryladog> Suggest for 2.0 and 2.1: "Note: In a more recent version of this standard WCAG 2.2 this SC has been removed as the browsers have addressed this problem"
<Rachael> draft RESOLUTION: Leave the SC number and short name, mark as obsolete, remove the SC text, add an explanatory note, publish as an errata and republish spec for 2.0 and 2.1
Gregg: forgot to say mark as obsolete and removed.
<Chuck> +1
<bruce_bailey> +1
Wilco: skimming w3c process - we would need to do last call and send out for public review if we do that. Do we know what we are committing to.
<alastairc> +1
<Rachael> draft RESOLUTION: Leave the SC number and short name, mark as obsolete, remove the SC text, add an explanatory note, publish as an errata and republish spec for 2.0 and 2.1
<GN015> I see a difference between obsolete and removed, I do not agree to obsolete, I agree to remove
MikeG: would like to understand what Wilco's see as best path forward here. I'd rather us be very clear and all be aligned.
<bruce_bailey> +1
<GreggVan> +1
<Ryladog> +1
<joweismantel> +1
Rachel: Would like people's vote to know where we are.
<ShawnT> +1
<Wilco> -1 until I know what we're actually signing up for
<Makoto> +1
<kirkwood> +1
Alastair: We did not get to target spacing - we will set up a Friday meeting and get through those on email to group on where we get to.
+1
<mbgower> 0 this looks okay overall, but I want to go back to the team and get reaction
<GN015> -1, obsolete implies the full text has to be kept; we discussed to remove, which is something else
Rachel: Feels like we are close to resolution.
Alastair: will do some suggests with updates from survey.
Rachel: Thank you - have a good holiday - see you in January.
<mbgower> lol
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) Default Present: Ben_Tillyer, Lauriat, mikayla, alastairc, JustineP, Jason_Khurdan, bruce_bailey, ShawnT, Rachael, Makoto, tzviya, jaunita_george, Wilco, sarahhorton, wendyreid, JenStrickland_, mbgower, Poornima, cwilso, jeanne, Laura_Carlson, Katie_Haritos-Shea, GreggVan, kirkwood, JStrickland, Detlev, GN, janina, Chuck, ToddL, ChrisLoiselle, Jennie, Jay_Mullen, I, remember, jake, putting, together, spreadsheet, for, something, like, that, 2, years, ago, was, pretty, good, jon_avila, Francis_Storr, AWK, SuzanneTaylor, joweismantel, Raf Present: Ben_Tillyer, Lauriat, mikayla, alastairc, JustineP, Jason_Khurdan, bruce_bailey, ShawnT, Rachael, Makoto, tzviya, jaunita_george, Wilco, sarahhorton, wendyreid, JenStrickland_, mbgower, Poornima, cwilso, jeanne, Laura_Carlson, Katie_Haritos-Shea, GreggVan, kirkwood, JStrickland, Detlev, GN, janina, Chuck, ToddL, ChrisLoiselle, Jennie, Jay_Mullen, I, remember, jake, putting, together, spreadsheet, for, something, like, that, 2, years, ago, was, pretty, good, jon_avila, Francis_Storr, AWK, SuzanneTaylor, joweismantel, Raf, I remember jake putting together a spreadsheet for something like that 2 years ago that was pretty good, GN015 Regrets: Rain, Todd, tzviya Found Scribe: ChrisLoiselle Inferring ScribeNick: ChrisLoiselle Found Scribe: jon_avila Inferring ScribeNick: jon_avila Scribes: ChrisLoiselle, jon_avila ScribeNicks: ChrisLoiselle, jon_avila 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: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]