<Chuck_> start meeting: AGWG-2020-06-09
<ChrisLoiselle> scribe:ChrisLoiselle
I can scribe first hour.
I'd rather scribe first hour, I'm good to go :)
Chuck: I wanted to give any new members to introduce themselves.
<Fazio_> nice photo
Omar Bonilla: I'm a digital accessibility member at Thompson Reuters. I introduced myself to the silver group earlier. Glad to meet everyone.
Francis Storr: I work for Intel. I was integral to building up their program and still work there. Looking forward to working with the group.
<laura_> Scribing Commands and Related Info https://www.w3.org/WAI/GL/wiki/Scribing_Commands_and_Related_Info
Chuck: Content usable discussion. Rachael, hand off to you.
<Rachael> https://docs.google.com/document/d/1c1tJFXxdKzfg96tMcGjpEonHjtll_nRlXiavLjAFPPE/edit#
RachaelM: We need to have a meeting to create the final language for CfC. We want to make sure AG, Coga and APA all make the meeting. Meeting length will be up to 2 hrs.
If you are interested, either enter your details into https://docs.google.com/document/d/1c1tJFXxdKzfg96tMcGjpEonHjtll_nRlXiavLjAFPPE/edit# or email me directly.
<Fazio_> For those concerned about Content Usable overstepping boundaries, here is an excerpt from the Air Carrier Access Act that necessitates its need
<Fazio_> Collectively, such individuals must be able to provide feedback on the usability of the Web site by individuals with visual, auditory, tactile, and cognitive disabilities.
Please add yourself to the document and we will send a poll for attendees and aim to have meeting next week.
<Zakim> bruce_bailey, you wanted to ask if this was document with lots of feedback from David McDonald
We will schedule meeting around the schedules of people who want to strongly attend. We don't want to get into an area where we can't finalize the language. We want all at the table that want to be at table.
Bruce: Is the the document that David M. wanted to talk to? Rachael: Yes. I'll reach out to David M.
DavidF: If we don't get consensus (from David) how does that impact the publishing of the document?
<JF_> @ DAvid F. please seee here: https://w3c.github.io/w3process/index.html#Consensus
AWK: I was on queue to talk to Rachael's question on whether we should be on meeting or not. I disagree with DavidF that it is not just David M. disagreeing with the document. I feel that the AG working group should stand behind it rather than to a closed group. I feel we don't have consensus yet. That takes work to overcome.
Rachael: I concur, this is more than David M.'s review. Many have reached out in various forms for feedback. To AWK, we aren't trying to AG, however talking to most invested members on topic to produce a working statement to agree on . This would not bypass AG or APA. No attempt to step around process.
<Zakim> mbgower, you wanted to say that would not be a good way of viewing either Davids feedback or others concern
Rachael: Intent was to bring everyone together on the topic. If we need to hold it at AG time and bring in COGA and lose time for WCAG 2.2 time, we can.
<AWK> +1 Mbgower - you said it better!
Mike G. : I try to speak up when I only oppose. I don't want to interpret other actions as negative.
<Chuck_> q/
<Zakim> bruce_bailey, you wanted to say it is not a vote
DavidF: Very few are involved in COGA. I didn't mean to state it as negative viewpoint, I was just stating where the objections are coming from.
<JF_> +1 to Bruce
<Fazio_> I was uI wasn't being negative, and all of the responses ar in response toThat's my point
BruceB: If one person is articulating a different standpoint, that may be same view as others without stating it publicly.
<Fazio_> One person can't represent the whole group
<Fazio_> so everyone needs to speak up
Chuck: Objective was to get group to consensus.
<JF_> https://w3c.github.io/w3process/index.html#Consensus
JF: I lost your voice.
<alastairc> DavidF - You'll find that DavidM was making the points, others agreed but don't feel the need to jump on comments. That wouldn't be effective use of time in meetings.
JF: Talks to W3C to consensus and provides link. It is a messy process, but it is present to members.
JF: We are moving to something everyone can live with.
<Chuck_> https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues2/results
Chuck: Shares his screen on ,
shows results of the focus visible results survey.
... Talks to changing the level 2.4.7 SC.
Chuck raises question to Pascal.
Pascal: I don't have anything to add off of comment.
Pascal's comment in survey: I don't agree with deprecating the existing SC 2.4.7, and would see the new SC 2.4.11 as AAA candidate.
Gundula: Comment in survey: The backwards compatibility is a high value, therefore 2.4.7 should remain on Level AA. It should not be deprecated, as it is not covered by 2.4.11, and deprecating an SC also feels incompatible. Next, the 2.4.11 Focus visible (enhanced) is rather prescriptive by nature and goes beyond 2.4.7 Focus visible. Therefore I see it as a Level AAA requirement. Compare 1.4.6 Contrast (enhanced), which is also level AAA.
Chuck reads this aloud as well.
<mbgower> CHuck, you should refresh your page
Gundula: I think we talked to this in a past meeting.
Alastair: In terms scope of question, we wanted to focus on if 2.4.7 moves level or not.
It wasn't on the new SC's level would be.
To Gundula's points. I'm not particularly fussy about moving 2.4.7 to A or leaving it at AA, selecting "current option" as it is the default (no-change) option. If we did leave leave 2.4.7 at AA but mark as deprecated: I'm not fussy about the term "deprecated", anything that says to people "don't look here, go to the new SC". Gundula - Moving 2.4.7 is backwards compatible, at least in the way we have agreed is critical: Anything passin[CUT]
Therefore increasing a requirement is the backwards compatible way of approaching it.
Regarding the new 2.4.11, it does go beyond 2.4.7, that is the point. 2.4.7 is not sufficient for the user need. I would also say it is not "overly" prescriptive as there are various ways to meet it. However, I would agree that to keep the language simple it is formed in a way that would lead people to an outline/background approach.
Chuck: Moving to "A" at 2.2. , at 2.0 it remained at "AA". That is how I read it in terms of backwards compatibility.
Alastair: Yes.
<JF_> +1 to chuck.. as long as when you are compliant in 2.2 you are *also* compliant in 2.1 then backward compt = true
BruceB: I'd like to hear from JF's stand on this issue.
<CharlesHall> the opposite is not true for backward compatibility. if i passed A at 2.1, i may no longer pass A at 2.2
JF: We had concerns (Wilco) on testing profiles and versioning. We (Deque) did sit down and we are good with proposal moving forward.
Mike G: I think Wilco should close it since he opened it.
<bruce_bailey> +1 to wilco closing
Alastair: We can review that moving forward with him.
<bruce_bailey> @thanks john
<Chuck_> Straw poll: Do you support moving 2.4.7 to A and adding the new SC? +1 Yes, -1 No.
<david-macdonald> +1
<mbgower> +1
<Detlev> +1
<Rachael> +1
<alastairc> +1
<bruce_bailey> +1
<CharlesHall> +1
<JF_> +1
<AWK> +1
<Francis_Storr> +1
<Nicaise> +1
<laura_> +1
<OmarBonilla__> +1
<JakeAbma> 0
<MarcJohlic> +1
RESOLUTION: Move 2.4.7 to A and add the new SC?
<CharlesHall> adding new SC at AA?
MikeG: Wouldn't resolution talk to Wilco to close ticket?
Alastair: Yes. that is what should be done.
Chuck: Talks to Errata/clarification of 2.2.1 Timing Adjustable extension github https://www.w3.org/2002/09/wbs/35422/2020-05-cwa/
<Chuck_> https://www.w3.org/2002/09/wbs/35422/2020-05-cwa/results
There were four choices: Update the extend bullet to mean 'time' rather than opportunities., Adjust the extend bullet to say 'opportunities' rather than time., Leave the SC text as it is, but update the understanding document (please comment about in what way) or Something else (please comment)
<alastairc> DavidM - which way to change though?
<bruce_bailey> fwiw, i have heard people confused on the sc face
DavidM: I haven't heard a lot of complaints. I think we may fix understanding documents and fixing that terminology would work.
Alastair: Patrick has read it as time, vs. number times you can do it.
If we updated understanding, I want to be forthright on what we are stating. Adding a note to extend bullet on time. We could be clear on understanding and would not talk to normative changes.
<Zakim> mbgower, you wanted to say, there is confusion, but can we even agree on what it means :)
BruceB: I think people have been confused by it vs. how we wrote it. I think the correct should be made.
Mike G: I don't think we could all agree as to how this should be written.
<JF_> +1 to Mike - changing normative language is a slippery slope
MikeG: Changing normative language would be worrisome.
<mbgower> My comment reflects what AWK is saying about redundancy
<bruce_bailey> +1 to AKW that pull request is no good
AWK: Changing the SC text is hard to do through errata. I tend to be conservative on changing normative text. If we take the adjust bullet and change that, then talk to extend the time limit some number of times. The concern is around longer duration. I propose we go with the understanding route and takes effect immediately.
<Zakim> alastairc, you wanted to say that I used the PR as one option, but thought it should go the other way!
<JF_> +1 to AWK for all those reasons
AWK, let me know if I summarized that correctly for you.
<KimD> +1 to AWK, although we've opened the door to changing Normative language by moving 2.4.7 to A
Alastair: I think it was getting more complicated than it needed to be. I think my comments in the survey talk to what can be done.
AWK: I'm in agreement with opportunities. The cost of changing one word for another word in the normative text vs. updating in understanding make it worthwhile to talk to in understanding vs. normative text change.
<alastairc> Would be something from "and the user is allowed to extend the time limit at least ten times; or" to "and the user has 10 opportunities to extend the time limit; or"
Gundula: The requirement can be understood in both ways, opportunities and time. If the real meaning is only stated in the understanding, then it makes it harder to apply the SC and techniques to meet.
<bruce_bailey> +1 to GN015 saying
<Zakim> bruce_bailey, you wanted to say we can have our cake and eat it too
BruceB: Agrees with Gundula's comments.
<bruce_bailey> okay to do *both* things
<mbgower> Chuck, correct, no longer meeting standard
Chuck: Thinking of backward compatibility , i..e. ten opportunities vs. ten times. Would it stop being compatible ?
<AWK> If someone misinterprets the standard they are already not in conformance
<alastairc> Wondering about a poll: Whether it is done in the SC text or understanding, can people live with adjusting it to "opportunities"?
<JF_> choice is good
<Jennie> +1 to John F
<alastairc> choice would be supporting the PR then, which explicitly allows for either.
DavidM: Originally, one
opportunity to change it ten times. We wanted flexibility of
time or opportunities. I.e. ten times the time to do so. If you
want to break it into opportunities, that is fine. If you want
to do it once , that is also fine.
... Let me know if that summarizes correctly.
<bruce_bailey> Q: Does changing times to opportunity change the meaning of the SC?
<CharlesHall> so 10 opportunities would fail if each opportunity was not identical to the original time?
<bruce_bailey> JF scenerio is conforming
<AWK> For the "extend" portion you would need to be able to extend 200 sec in 10 actions to meet that bullet
JF: Edge case. Task , ten seconds to complete. Click once. Ten to 20 seconds. Each time I execute the button, it extends, adding twenty seconds. I.e. 5 times gives me 100 seconds. DavidM: Yes.
<GN015> A: each opportuntity takes time, so it contradicts the intention. According to the current understanding, the aim is to give ten times the amount of time.
<alastairc> Gundula - but that is from the "adjust" bullet, not the extend bullet.
<bruce_bailey> i am sure we did not write it badly on purpose !
JF: Making flexibility was main
point, net result was ten times the amount of allotted time.
DavidM: I don't remember the exact conversation, but intent was
a simple action to extend time.
... So how we do that is based off of techniques. DavidM: Yes,
as long as it is a simple action.
<Zakim> bruce_bailey, you wanted to discuss straw poll suggestion
JF: I'm good with what DavidM was stating.
BruceB: I think both are ok for
backwards compatibility. I don't think clearing up phrasing
could be bad.
... Straw poll would be are these two sentences stating the
same thing?
<Zakim> alastairc, you wanted to say that is from the other bullet
Chuck and Alastair: That is what is in the survey.
<bruce_bailey> -1 as i disagree that is what the PR says
<bruce_bailey> i think the PR is requiring both
Alastair: The Pull Request seems ok per that interpretation. Changing to duration would be problematic from compatibility.
<mbgower> I also disagree that the PR doesn't say that
<bruce_bailey> 1) the user is allowed to extend the time limit at least ten times
AWK: I don't entirely agree with David on extend bullet. My recollection is about extending ten times. User can extend time limit ten times. Not extending time ten X. Second point: I think we can clarify it in the understanding. I think we need to think more about WCAG 2.2 and Silver.
<kirkwood> solved with a simple and/or ?
<bruce_bailey> 2) the user is allowed to extend the time limit at least ten opportunities
Chuck: You are more a proponent of changing understanding rather than normative? AWK: Yes.
<AWK> GN, that is the goal of the "adjust" bullet
Gundula: I think ten times vs. ten opportunities is confusing. The application who gave ten opportunities or ten times the amount of time would still satisfy the requirement.
DavidM: Alastair's comments on bullets. We have a bullet on ten times the length. These are OR statements. So ten opportunities of the default time. The "at least" requires that you have to increase the time each time you extend.
<Zakim> mbgower, you wanted to say adding a technique is another way to clarify
It is a lot of work about normative text vs. updating understanding. I agree with AWK. If we use third bullet, we need ten times the amount of time of default time.
<bruce_bailey> -1 in that SC is an *or* its not requiring *both*
<alastairc> Bruce, it's "one of the following", I think that's what they meant.
MikeG: I support the idea of not changing the normative text. I think providing a technique that is sufficient to accomplish this, provides clarity on the technique. Without updating the understanding documents.
<bruce_bailey> 1) the user is allowed to extend the time limit at least ten times
<bruce_bailey> 2) the user is allowed to extend the time limit at least ten opportunities
<AWK> +1 bruce
You could have a time out of a hour , that would have to be the example in understanding or technique. We need agreement on what is meant.
<Chuck_> +1 says same thing
<KimD> +1 - they say the same thing
<alastairc> -1 the first could be duration
<Rachael> +1 says the same thing
<CharlesHall> the math of either still has to result in a sum of 10x the {author defined time}
<laura_> +1 bruce they say the same thing
<david-macdonald> -1 our intention was that the user has 10 times the amount of time
<mbgower> 2 is less easy to misinterpret (but it's not elegant English)
<MarcJohlic> +1 to Bruce - I read those as saying the same thing
<david-macdonald> We didn't intent extend bullet to lower the amount of time
<AWK> +1
<kirkwood> +1
<Fazio_> +0
<OmarBonilla__> +1
<mbgower> -1
<JF_> =1 they are NOT the same
<Francis_Storr> +1
For reference: https://www.merriam-webster.com/dictionary/time
<Jennie> -1
<GN015> -1
<bruce_bailey> okay, i give up, we need to decide formally what we ment
<Chuck_> Straw Poll: Leave SC (Normative) text and adjust understanding document, +1 Supports, -1 Against
<david-macdonald> +1
<kirkwood> -1
<GN015> -1
<CharlesHall> +1
<AWK> +1
<laura_> +1
<MarcJohlic> +1
<bruce_bailey> -1 because i need to know which way you want to change Understanding
JF: Right now, the normative text is open to interpretation. We can't invalidate interpretation in understanding document.
<alastairc> Possible interpretations:
<alastairc> 1) ten times the original duration
<alastairc> 2) ten opportunities to extend
<alastairc> 3) either 10x duration or 10x opportunities
<alastairc> 4) any number of opportunities that add up to 10x duration
Bruce: Extend being interpreted as adjust does not make sense.
<Zakim> mbgower, you wanted to say in my comment I suggested a straw poll to determine if we AGREE on what it is supposed to mean
<david-macdonald> #4
<bruce_bailey> +1 to MG, i agree that one can meet extend withou meeting adjust
<bruce_bailey> -1 one to implying in understand they are they same
MikeG: If someone takes task of technique, this would be a sufficient technique, with ambiguity with the SC text.
<bruce_bailey> should have caught this sooner !!!
<Chuck_> Straw Poll: Leave SC and understanding document the same, and add a success technique, +1 supports, -1 against
<Chuck_> Straw Poll: Leave SC and understanding document the same, and add a success technique that meets extend, +1 supports, -1 against
<Chuck_> Straw Poll: Leave SC and understanding document the same, and add a success technique that meets "extend" and does not address "adjust", +1 supports, -1 against
<david-macdonald> I think we would need several techniques
<bruce_bailey> +1 to a having a technique that meets extend withou meeting adjust
<JF_> +1 to David M
<GN015> -1
<Chuck_> Straw Poll: Leave SC and understanding document the same, and add one or more success technique that meets "extend" and does not address "adjust", +1 supports, -1 against
<bruce_bailey> @MG i am happy to help draft that
<KimD> -1
<mbgower> +1
<Rachael> +1
<bruce_bailey> +1
<JakeAbma> +1
<david-macdonald> +1
<Jennie> +1
<laura> +1
<kirkwood> +1
<Nicaise> +1
<alastairc> +1 if we do also update the understanding doc to work with that.
<Francis_Storr> +1
<MarcJohlic> +1
<AWK> +.95
<Detlev> +1
<Fazio_> +0
<JF_> +1 (and another +1 to Mike and Bruce wood-shedding draft language)
<GN015> -1 ot still leaves the ambiguity of the SC and forces the user to read through the understaning in ´cluding techniques just to understand the SC
AWK: I agree with approach , but leaning toward to updating understanding as well.
Kim: I think the more we bury what we mean by something, the harder it gets to understand what we mean. Changing on language would be where we need to do this.
<bruce_bailey> we could also straw poll a failure technique where extend is met but adjust is not (and vice versa)
Gundula: It doesn't resolve the ambiguity.
<AWK> If we could eliminate ambiguity we wouldn't need the understanding documents
<bruce_bailey> @DavidM, could have hour time-out with 10 times to add five minutes each
<bruce_bailey> ... thats still a decent user experience
<AWK> David, where in the Extend bullet does it say that there is an expectation of a full 10x?
DavidM: We need to come to an agreement. It is called timing , not opportunities. If we limit to opportunities, it may miss what we are talking to about the SC.
<Rachael> scribe: Rachael
<ChrisLoiselle> No problem. Happy to help.
<mbgower> I can scribe if you want, Rachael
Chuck: I am feeling the sameconcern that we are not addressing the core. If we do work on the success/failure techniques it might help us craft a better understanding or what else needs to be changed.
<david-macdonald> the bullet really means 10x opportunities to reset the default time
Alastair: This survey question is based on a PR. I think we've explored the question well. As far as I can tell, its primarily David that is convinced that bullet means 10 times the duration. Others oppose. I suggest someone take responsibility for this and come back with something based on the survey results and minutes and come up with a proposal.
<bruce_bailey> @DavidM -- i respectfully disagree
chuck: How does the group feel about this approach? Volunteers?
<Zakim> alastairc, you wanted to suggest someone takes this away to make a better proposal
David: I can go back to the chairs from the time and get their opinions. Its an edge issue that hasn't caused trouble before this. I am just saying that we don't want it to be less than 10 times the default. The first bullet was the default. The second was to extend the default.
Bruce: I think we split it off. You have a scarce resource. People log into the card catalog for 2 hours but don't want to let them in for 20 hours. If the default time is generous, then you don't want them to get an unreasonably large amount of time. WE wanted to give them opportunities.
David: Then we came up with 20 hours because you have to sleep at least 20 hours. That's what I understand the bullet to mean.
Chuck: I think it is interesting what the original intent was but we have at least 4 different interpretations on this call alone.
<JF_> +1 to Mike
<Chuck_> +1 to Mike
<alastairc> Nope, never had a client use adjust or extend.
Mike: There are ways to game this SC but I do want to loop back to whether people are seeing it take place? A lot CAN be taken advantage of but this is over a decade old. Is anyone seeing people take advantage of extend to create an unreasonable situation for users?
<Fazio_> +1
GN: We had a nice example of a long time frame when 10 times is unreasonable. There are other examples of very short time frames and having to extend the time repeatedly adds stress and makes the task inaccessible.
<mbgower> Yep, I agree that the Extend technique could be VERY disruptive
Chuck: Can someone take this on?
Mike: I think Bruce and I could take this on.
<GN015> I would like to join, if you agree.
RESOLUTION: PR not accepted, leave open for new option
<kirkwood> I volunteer as well
<bruce_bailey> i will put something into the Github Issue today
<alastairc> For the volunteers - suggest go to: https://github.com/w3c/wcag/issues/1040
<kirkwood> citymnouse
<Chuck_> 1.2.1 Audio-only and Video-only, 1.2.2 Captions (Prerecorded), 1.2.3 Audio Description or Media Alternative (Prerecorded)
Chuck: Bruce had reported that exceptions in 2.2 do not follow the same verbiage pattern as 2.1. Suggests they be consistent. Prepared examples
<Chuck_> 1.2.1 Audio-only and Video-only, 1.2.2 Captions (Prerecorded), 1.2.3 Audio Description or Media Alternative (Prerecorded) — All three end with “except when the audio or video is a media alternative…”
<Chuck_> 1.4.12 Text Spacing — Ends with “Exception: Human languages and scripts that…”
Chuck: should we make an effort
to adjust the new SC text to be in the pattern of 2.0?
... so far there hasn't been much response but some support for
this. 3 alternative ideas.
AWK: Back when creating a survey meant you were the first to respond. I don't think this is worth our time. There are so many things we have to do - Silver conformance. These are exceptions. Unless we are getting notes from people saying we dont' understand, I don't think its worth it.
<bruce_bailey> I have all three rewrites in the Github issue
<bruce_bailey> https://github.com/w3c/wcag/issues/895#issuecomment-629385766
David: My sense is that 2.1 is better. Longer if in. I would go back and put the exceptions at the end.
GN: I looked at the new wording. I would differentiate between the text spacing. I think it was clear and consistent how it was in the past but for reflow, etc the exception is mentioned at the beginning. I think that makes it harder to understand. I would keep it at the end. Requirement, exception, bullet list. No mention exception at the beginning. HArder to parse.
Chuck: You are suggesting a
reformatting but make it easier to read.
... I am supportive of reformulating but I am concerned about
whether this is a priority. Has the world had trouble
interpretting it?
... Bruce what inspired you to bring this up?
Bruce: Unlike the previous suggestion, no. I don't get anyone understanding it wrong. When we wrote WCAG we tried for plain language. Having the word exception and then the exceptions - I don't think that's consistent with Plain language. One stuck out and then I noticed more.
<Zakim> alastairc, you wanted to comment on the prioritisation
<mbgower> I agree with Alastair. let's work forward
Alastair: I was talking to Andrew's point about prioritization. We have a window at the moment to tackle normative proposals at GITHUB. There will be more 2.2 coming up and we have a bottleneck our other SC to get in for wide review. So we have a bit of time.
<mbgower> Ha, maybe I don't agree with Alasatir :)
Chuck: We have a few weeks to address these.
mbgower: I think we put a lot of time into wordsmithing 2.1. I'd rather focus on 2.2 and moving forward. It seems unproductive to me to go back and change language when we haven't had complaints.
<laura> +1 to MG. Not to focus on formatting at this time.
Alastair: I think that's fair. Looking at some of the examples Bruce put it, I see Gundula's point about readability. It makes me wonder about David's point and apply the new structure to the old one. If someone wants to see what level of work it woudl be, it might be a good half hour exercise.
<Chuck_> aq?
Chuck: I am not opposed to someone trying. We are asking the group on how to use this short opportunity to work on normative task. My concern is that the window isn't big enough to reach consensus on revised text. I am not opposed to the task but I don't think the time availabe is sufficient.
<Detlev> +1 to Chuck
<mbgower> If folks want, they can take a look at the IBM checklist, where I stripped out the exceptions and shoved them into a consistent location inside the rationale we created.
Chuck: Alastair had the most actionable proposal.
Alastair: Take 30 minutes, how would we work the new pattern into the 2.0 SC? Then we can go to the group for prioritization.
<mbgower> https://www.ibm.com/able/guidelines/ci162/accessibility_checklist.html
Bruce: I spent 30 minutes and then half a day trying to do this. I don't think it is a trivial exercise. Maybe we just do 1.4.12.
mbgower: Put in link to IBM. I removed exceptions and created a more consistent approach. Not perfect but clearer.
Chuck: Did you refactor 2.0 or 2.1?
<bruce_bailey> wow, looks great !
mbgower: All of them. I'm not advocating it. We are just an org. Its a form of simplification.
<CharlesHall> there are many examples of refactoring / rewording WCAG. gathering many was done with Silver research. i know of others since that research.
Chuck: Suggestion to take a week and review this presentation.
Alastair: This list is way beyond the scope of what we are talking about here. It may be interesting to look at how its done. Overall, I am not hearing we should spend a lot of time on this.
Chuck: The next actionable thing I've heard is to focus on 1.4.12. Straw poll: Should we focus on 1.4.12 restructuring?
<AWK> -1, not seeing adjusting 1.4.12 as worth it.
<laura> -1, not seeing adjusting 1.4.12 as worth it.
Rachael: If we like 2.1 format better, why woudl we adjust 1.4.12 if that is already a 2.1 (unless I'm misremembering?)?
<alastairc> -1, not seeing consistent improvement from the new ones, and not worth the time to update just some
Chuck: Looks like others don't see 1.4.12 worth it. So then the last actionable suggestion was to focus elsehwere.
<GN015> +1, I like the new wording, while I can live with not changing it.
Chuck: we havent' had consensus on other suggestions os straw poll on the resultion of leaving this unresolved and address later?
<Chuck_> straw poll: Group has not attained consensus, and agrees to leave open. +1 to leave open, -1 continue to try and resolve.
+1
<david-macdonald> +1 to leave ooen and take up in Silver
<laura> +1
<bruce_bailey> -1 because i think it important to fix
<Nicaise> +1
<Brooks> +1
<KimD> +1
<mbgower> +1
<Francis_Storr> +1
<Detlev> +1
<AWK> +1
<OmarBonilla__> +1
<JF_> 0, not seeing adjusting 1.4.12 as worth it.
<AWK> We could also close the issue and not leave open
<Fazio_> +0
<mbgower> I agree with John.
<AWK> e.g., don't fix
<bruce_bailey> i can live with leaving it alone
I don't agree with closing the issue. I'd like to come back to this when more time.
<mbgower> 'Sorry, we arent' doing it' +1
AWK: We can say open, close, or talk about it later.
Chuck: I was not suggesting closing the issue.
<mbgower> +1 to closing
Alastair: From Github, we would close this issue until another proposal was put in.
<david-macdonald> +1 to close
Alastair: someone could reopen or add new issue.
<laura> maybe close and defer to silver?
Bruce: I am less enthusiastic about 2.1 wording than I want to be. We didn't get the chance to do the editorial review 2.1 needed.
AWK: We would typically close issues and then allow them to be reopened. No negative to closing in queue.
Bruce: I would like us to decide on a direction or not.
Chuck: I don't think its not worth spending time on just that it woudl take up free time.
<alastairc> Marked as "wcag.next" in github
Rachael: I woudl like to see this move forward but dont' have time to work on this now. Dont' want it to drop so want to make sure the process brings it back.
RESOLUTION: Close GitHub issue.
Alastair: I made adjustments in Git to make sure we get back to it.
Chuck: Ammendment.
Bruce: Inactive is too vague. It is poor word choice. If we used disabled it would be so much clearer.
<GN015> +1 to bruce
Chuck: Wilco was concerned that inactive was not clear. A more generic word would be preferable.
GN: I understand that inactive
and disabled are the same from the definition but it also
distinguishes between the two words so is unclear.
... I'd rather keep them as synonyms because its not clear
today or replace the word "inactive" with "disabled"
... The text is "not active" but needs to be accessible. A
filter or toggle button use "active" and "inactive" in a
different way.
Alastair: The next step was trying to get a direction. Do we agree that this needs the clariifcation. I appreciate Gundula's response. Its not as clear as it needs to be. Michael Cooper suggested making a new definition rather than adding yet another note to user controls. Its another call for someone to take this on. Take Inactive, disabled, read only, etc. and try to come up with a better defintion.
Chuck: Alastair is suggesting someone take on defining Inactive.
Alastair: Yes or simply make a better pull request. We have suggestions in the survey and responses. Patrick makes excellent suggestions and pull requests but can't attend meetings so we lose the feedback loop.
<AWK> Would this PR affect WCAG 2.2 or earlier?
Chuck: does someone want to take
this on?
... is the group OK with this?
Alastair: Does this affect 2.2? I think we need analysis on when we reference inactive user controls.
<Zakim> bruce_bailey, you wanted to say it does not solve the problem of having the wrong term
Bruce: I was OK with the
defintion I saw in the pull request. I don't think its solving
the problem of poor word choice in the SC.
... the term inactive in the SC is misleading. Its a broad term
but counterproductive.
Chuck: so you are against a defintion?
Bruce: I'm all for adding a
defintion but you'll be defining disabled for the word
inactive.
... but I agree that is the next step
<alastairc> anyone able to tackle this?
Chuck: We arestill looking at definition crafting as the next step. Any volunteers?
<AWK> I'll try
<CharlesHall> inactive having a definition requires active to have a definition, and there is more than 1 meaning because active is also a state.
RESOLUTION: Andrew to work on "inactive" definition.
<GN015> I also had an issue with the link
Chuck: The next question was redundant entry. The link was not working. I propose we fix the link and then resurvey with the correct link?
Alastair: It does now resolve.
There was an extra l at the end of htmll.
... This is the culmination of the email discussion and we need
to have a bit of discussion on it before CFC.
Chuck: Leave it open for next
week.
... Thank you everyone for joining.
<laura> bye
This is scribe.perl Revision of Date 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/i live with/i can live with/ Default Present: ShaneW, alastairc, Rachael, ChrisLoiselle, KimD, CharlesHall, MichaelC, JF_, PascalWentz, Detlev, JustineP, Fazio_, Nicaise, Francis_Storr, OmarBonilla__, Jennie, mbgower, Laura, kirkwood, JakeAbma, Brooks, .95, bruce_bailey, GN, MarcJohlic Present: ShaneW alastairc Rachael ChrisLoiselle KimD CharlesHall MichaelC JF_ PascalWentz Detlev JustineP Fazio_ Nicaise Francis_Storr OmarBonilla__ Jennie mbgower Laura kirkwood JakeAbma Brooks .95 bruce_bailey GN MarcJohlic GN015 Regrets: Rafal_Charlampowicz Steve_Lee Found Scribe: ChrisLoiselle Inferring ScribeNick: ChrisLoiselle Found Scribe: Rachael Inferring ScribeNick: Rachael Scribes: ChrisLoiselle, Rachael ScribeNicks: ChrisLoiselle, Rachael WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting 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]