<alastairc> scribe:Glenda
Alastair: if going to TPAC, book hotel ASAP to get a good rate.
<alastairc> https://www.w3.org/2002/09/wbs/35422/Techniques-issues-July-2019/results
<patrick_h_lauke> changing to "activate" will then mean rewriting the procedure bullets (see https://raw.githack.com/w3c/wcag/patrickhlauke-issue372/techniques/failures/failure-downevent-not-upevent-no-mitigating-circumstances.html)
AC: reviewing Jake’s comments
Jake: confusing sentence. and there is no #4
AC: reviewing Gower’s comments
<patrick_h_lauke> "If #1 is true, and #3 and #4 are false then the content fails the Success Criterion."
Gower: Do all 4 bullets need to be true (in the objective)?
PL: They all need to be true.
Jake: this sentence needs work: “No further mechanism to abort or undo is available;”
<JF> +1 to Jake
Jake: If failure is due to activating on the down-event, there is no way to abort, it already occured on the down event.
AC: remove complete.
PL: I’ll review on github and ping you when it is done.
Gower: change to ordered
list.
... procedure seems really manual. Using an auto tester to
sniff for certain funtions. You could inspect those. You
wouldn’t need to run them.
AC: If there is an automatic way of discovering downevents, that could be used to assist in making this more efficient to test.
Gower: only certainty you can have is on a failure technique.
AC: If you follow this test procedure it must be a failure
Detlev: numbering in testing needs correction
AC: pending those updates - changing title, fix numbering, change test procedures, tweaking sentence, adding a note about auto testing. Does anyone object to passing this for publication.
<mbgower> as a mouse button is pressed
<alastairc> make: a control is activated
<JF> +1 to Mike
Gower: “this” is so generic in
the paragraph after the bullets.
... ignore my comment
AC: we are being fairly quick to publish, and quick to update. These are not normative.
RESOLUTION: Publish PR 815 as ammended
ACL reading summary “Neither SCs 2.4.6 or 3.3.2 require a visible label, so the procedure appears to be asking too much. The last part of the proposed response includes an update to the test procedure for G131.”
Rachael’s comment “I am unsure if we reached consensus last week about whether a technique can go beyond an SC.”
AC: It is permitted for techniques to go beyond an SC
<alastairc> https://www.w3.org/WAI/WCAG21/Techniques/general/G131
<alastairc> Rachael's question: I am unsure if we reached consensus last week about whether a technique can go beyond an SC.
<patrick_h_lauke> my impression/understanding was that 2.4.6 / 3.3.2 were "visual" in the sense that it refers to "labels" and "headings" that are in the page, but not necessarily marked up as such (which would be 1.3.1 and 4.1.2 issues otherwise)
<alastairc> https://github.com/w3c/wcag/issues/339#issuecomment-514129238
AC: new proposal for test
procedure (see above link)
... Patrick is correct
... example Bruce added, I’m not sure part 2 is needed. These
two SC are not about markup.
Bruce: I concur.
Gower: is the word “associated” good to use, or not? Associated often gets interpreted to be programmatically. So..maybe we should change that word. I can live with it for the time being and think about it some more.
<patrick_h_lauke> the technique can also associate programmatically, but note in prose that this aspect is to satisfy 1.3.1 / 4.1.2
<mbgower> the programmatic associatoin is covered by 1.3.1
<Detlev> @JF sure but that is 4.1.2 / 1.3.1
<mbgower> you don't need to cover it here
JF: I’m going to push back on “doesn’t need to be programmatically associated” because the non-sighted user needs that programmatic association (as important as the visual association).
AC: I don’t disagree about that need, but that is part of 1.3.1 (not these two SC that are focused on visual and do not required programmatic association)
JF: what do we mean by “associated”?
Gower: why don’t we remove the word associated?
JF: I agree
<patrick_h_lauke> +1 to remove "associated"
<alastairc> "For each interface component with a label:"
+1 to remove “associated"
<JakeAbma> +1 to remove "associated"
<Detlev> +1
<stevelee_> +1
AC: any objections?
<Chuck> +1 remove
<MarcJohlic> +1
<laura> +1
<JF> +1
RESOLUTION: Accept Jake’s suggestion as amended and create a pull request
AC: everyone agreed. Proposed
answer: Generally not, except for variations of the page, so
generally you should test across SCs for different
breakpoints.
... does everyone agree?
Gower: a little concerned with “variations of the page” is prone to misinterpretation
AC: that is what we use in conformance requirements
Gower: when I see that, I wonder, what does “variation” mean?
<alastairc> From the conformance criteria: "A full page includes each variation of the page that is automatically presented by the page for various screen sizes..." https://www.w3.org/TR/WCAG21/#cc2
Gower: if you change text spacing, is that a variation? Versus breakpoints, which are design changes. I think the intent is design changes.
PL: I remember that the variations is automatically presented
<mbgower> maybe "each designed variation"?
PL: we are not talking about variations based on user settings
+1 agree to this topic as surveyed
AC: is proposed response reasonable?
<patrick_h_lauke> noting normative text already says that variations are based on screen size https://www.w3.org/TR/WCAG21/#h-note-32
<patrick_h_lauke> point people to the above when we talk about variation?
Gower: can we add “design” variation?
<alastairc> https://github.com/w3c/wcag/issues/391#issuecomment-485991399
Gower: that works
AC: last call
RESOLUTION: Accept the proposed response to 391
Laura: using “at least” is correct and is setting a baseline. “Up to” is confusing. Suggest adding something such as the following after that sentence to help clarify:
"The specified metrics set a minimum baseline. Anything over the metrics passes and anything under the metrics fails."
PL: suggested “up to at least”
AC: but that may create more confusion
Jake’s comment: I think for this SC "up to" serves the intent and is reasonable when adjusting text. Up to must serve "all variation up to and including" Beyond that threshold is not usual or do we have data showing users really use higher number?
<JakeAbma> see also Wayne's comment: https://github.com/w3c/wcag/issues/635#issuecomment-513362895
AC: I wonder if something needs changing in the SC? Or if something in the Understanding document can help (addressing what we mean)?
<patrick_h_lauke> i think the intent is ideally that we want to make sure that for both values above AND below things should work. that it should just work from the default up to those defined hard values, and then beyond as well
AC: suggest solving with errata
<laura> Wayne was referring to 2.2.
AC: and use understanding to clarify it even more
<patrick_h_lauke> for testing purposes, for "at least" people are simply going to test those values and be done. for "up to" they'll need to test from default to set values
<laura> I'm struggling to see a way you could create something that would work at the default but not in between.
PL: I might draft an example
Laura: should we wait and see what Patrick comes up with?
AC: I think it would be useful to run this by the LVTF.
<patrick_h_lauke> i'll admit it's not a hill i definitely want to die on if we can make it clear in understanding that we mean above and below that value depending on where the starting value is...
<patrick_h_lauke> but it comes down to how hard people read the normative word and look for loopholes
<mbgower> +1 to Patrick's comment. Just tackle in understanding
+1 solve in understanding
<patrick_h_lauke> understanding though can be a bit "well, that's just your opinion"
<laura> +1 to tackling in understanding.
Gower: between understanding and a failure technique, we should have the clarity we need
<patrick_h_lauke> i mean it could also be interpreted that the "to" in "to at least" means a sliding "up to" ...
AC: proposed next actions - review from LVTF. Want to double check. Then propose update to understanding that we will then agree on. Any other suggestions?
RESOLUTION: leave open
<alastairc> https://github.com/w3c/wcag/pull/698
“Summary: Reflow (1.4.10) mandates no-scrolling at 320px, but you could pass it and have an unusable site between 320px and (for example) 1024px. THe SC could be updated to say 'down to', e.g. "Vertical scrolling content down to a width equivalent to 320 CSS pixels;””
<patrick_h_lauke> the edge case demo: https://codepen.io/patrickhlauke/live/ZZqzaB
AC: this would make it a higher requirement
JF: in 2.2 requiring more than 2.1, that is not a problem.
AC: interesting case, it would be a 2 word change to an SC (between 2.2 and 2.1). Same SC number.
<Chuck> scribe: Chuck
JF: ...let's get group think on this. I don't want to make decision independent.
<patrick_h_lauke> wasn't the survey we're looking at just now the straw poll?
JF: Everyone should weigh in.
Alastair: I don't want to....
survey was straw poll. Only 3 answered. This case is such a
subtle change it makes a good test case.
... Can we actually update an SC? This is an excellent test
case.
... Anybody else who thinks it would create difficulties or any
negatives?
Chuck: If we can't change this one we'll never change any one.
Mike: What's q?
Alastair: Can anyone... this would be the most subtle change we could ever make to an SC. Are there any negatives? Is this not the right approach?
MG: Not getting q. This is a normative change right?
Alastair: Yes. Normative to sc, done in 2.2, not changing 2.1.
MG: No problem changing in new itiration.
Glenda: From human perspective on
subtle change that is changing requirement, I think we are very
likely not notice change.
... If they learned it one way in 2.1, they won't pick it up in
2.2. Is prone to misunderstanding.
Alastair: There are ways to deal
with that. For most people it won't make difference. If they
met it before the approach they took will continue to
work.
... It's a legacy thing. We have a client that has separate
mobile site you click to through. That site passes 1.4.10 and
main site does not.
<mbgower> But that's not to say that I've scrutinized this change adequately and agree to it :) But if the intent is to clarify and close a possible loop hole, I'm not opposed to such changes.
Alastair: There are nich cases where you could pass the old and not the new.
Glenda: Guess I'm ok. I thought it breaks backwards compatibility, but it doesn't.
<Glenda> I’m neutral
Alastair: As Chuck said, if we can't change this we'll never be able to change one.
Patrick: You mentioned your client has a mobile site. The mobile site is an accessible alternative?
MG: Conforming alternative version.
Patrick: What happens if mobile site opens up on desktop agent?
<mbgower> s/MG: Conforming/Bruce: Conforming
Alastair: Very narrow!
Patrick: As long as testing that
satisfies requirement, it might stay small when you open it up
on desktop, as long as there isn't 2d scrolling...
... Exploits another loophole, but the intent of sc is met.
JF: Well played!
Patrick: You owe me $600
Alastair: It's still trying to meet 2.0 rather than 2.1.
<Zakim> bruce_bailey, you wanted to ask about mobile site as CAV
Alastair: Seems like we have agreement... Bruce?
Bruce: I was following right up
to last moment, except when you mentioned person could use
mobile as alternative.
... But that's no longer true. I'm anxious now.
Alastair: You can still use that
as an alternative conforming version. What wouldn't pass is
that if you had a version that suddenly jumped
... down from desktop top mobile... if you are completely
relying on an alternative version you could pass.
Bruce: Very subtle.
<patrick_h_lauke> if you start off on the "desktop" site, and try to make the viewport smaller, and you reach the point where it leads to double (hor/vert scrolling), then the client could argue that at that point the user should go to the "mobile" site, provided that site then doesn't lead to double scroll
JF: Stink bomb: We want a subtle
yet impactful change to an SC. Chuck said if we can't change
this we can't change any.
... I want to stick with mantra that if it's published it's
published. Perhaps an alternative is that we do a 1.4.10.1. Add
as a part of 2.2
... It kind of deprecates 1.4.10, further clarifies.
<bruce_bailey> lol, i would love to have 1.3.1.1, 1.3.1.2, etc
JF: I don't know if it's something we want to entertain, but it is another way to move forward. And offers us an alternative.
Alastair: <noting meltdowns>. Will go through queue.
<Zakim> mbgower, you wanted to say i have seen good reflow where horizontal scrollbars appear at various points BUT no information is truncated
MG: <silence> headset
failure.
... I feel like this conversation has 2 different directions.
One is the minutia of the change. I do have concerns. I've seen
implementations...
... I'm concerned with unintended consequences. My assumption
is that a change that doesn't really alter, really does
improve...
... I would prefer that be the same SC rather than make it a
new SC which would be muddy.
Alastair: This would be in 2.2 as we did with focus styles.
<patrick_h_lauke> noting that the requirement for 1.4.10 is not just "no truncation" but "no two-dimensional scroll" as well
Alastair: Kind of general "do we
want this to be a new sc" and a minimal case to test "can we
update an sc in this way".
... Not particularly with idea of 1.4.10.1.
JF: One of the things that leads
me to think about that is moving forward, while we create
testable statements, at some point this rolls into
Silver.
... Where the number will be less critical.
... There's short term and long term. If we think about sc as
being components of larger thing, does number have that much of
impact?
<patrick_h_lauke> if numbers are used, then scoping it to the version of WCAG would also make sense rather than the additive "only ever add, never change" makes less sense...
Alastair: Hope not.
<patrick_h_lauke> 1.4.10 (Mark 2)
Alastair: Hope silver doesn't use numbers.
<Zakim> bruce_bailey, you wanted to say keep “at” but update Understanding with intent and best practice
Bruce: I'm 180 degrees now. More
comfortable keeping as "at".
... This SC is a compromise and we settled for small size and
not sizes between default and small.
Alastair: Are we are on text
sizing? That's "up to vs. at least" And now we are looking at
reflow.
... I bring that up because one would have been an erata, where
as this reflow we would intentionally change the meaning to
everything in between.
... Just want to check which one you are speaking to.
Bruce: Reflow. This one is more a change in what we meant. Testing a single small size is easier than various sizes. I thought it's ok, but convinced otherwise.
Alastair: It was a compromise intentionally in 2.1.
Bruce: We should stick to that.
Alastair: 2 q in mind. If we thought changing an sc was a good idea, would we do it this way? 2nd question is we would write up new sc in 2.2 and discuss if good idea.
Bruce: Good idea, should be new/separate SC.
Patrick: What was the option....? Is there an option of a new sc and deprecate the previous one? So you don't have to test?
Alastair: Similar can of worms.
That was one of the options of focus styles. In that case we
kept current and add new requirement as separate sc.
... We could take that approach. Gets into how people use
numbering and SC.
... I like this one as the test case.
... Sounds like we need to expand our thing and write up a
couple of options similar to focus styles. Taking this as
another case.
<bruce_bailey> agree that this is a good test case!
Alastair: If it's a new sc, we might as well update 2.2 requirements and say we won't update, we will only add.
Chuck: That is the conclusion we are making.
JF: You raised big question. Are
we only doing new and not updating?
... We started on a cow path.... seems to me that asside from
this topic, there is a much larger question we haven't
resolved.
<patrick_h_lauke> taking the "always add, never change" approach will end up leading to lots of overlap/redundant old SCs
Alastair: That's why I wanted to use this as a mechanism to discuss that.
<patrick_h_lauke> if it ever goes beyond 2.2
JF: So what's our plan?
Alastair: Balance between lots of overlap and redudant sc. Either deprecating or replacing. Similar to focus styles.
<patrick_h_lauke> and automated tools should have versioned their numbering schemes...
Alastair: With focus styles you could see how they could be separated. Whereas with this it's very much overlapping.
JF: But again. What is the
practical outcome of that? If people are adhering to 2.2 they
will be making subtle changes, otherwise there's 2.1.
... Point scoring in silver, meeting 2.1 gives you X points,
meeting 2.2 gives you x+ points (hypothetically).
<patrick_h_lauke> developers/designers already think there's a lot of fluff and needlessly prescriptive stuff in WCAG 2.0 / 2.1. danger is just adding even more won't help that perception
JF: Are we going additive or are
we making changes?
... In 2.1 we decided to not make changes to 2.0. 2.2 can be
different. It's a good question, I don't know the right answer.
But we haven't made a decision today.
<bruce_bailey> https://github.com/w3c/wcag/issues/796
Alastair: Partly why I wanted to
raise this up. CFC we had last week had one negative comment
from Katie. I knew this one was coming up, I waited to
answer.
... Our requirements say we can do this. Bruce can speak to
that. But if in practice we aren't going to, then req doc will
be easier to get through.
... Almost needs to be re-presenting... we need a few more
people to comment on the survey or comment here.
<Zakim> bruce_bailey, you wanted to say that inconsistant phrasing from 1.2.1, 1.2.3, 1.2.4 is demonstration that normative changes are needed
Bruce: I think this one might be
between 2.2 and 2.1 might be a change, might be new, could be
AAA to be smooth.
... The idea of John's larger point, can we make normative
changes to text? That answer is clearly yes.
ack Chuck.
Bruce: That's a black and white editorial fix that is normative.
Alastair: There's a pull request to update 1.2.1 but Bruce remind me, is that changing requirements or moving text around?
Bruce: We haven't settled final
language. But on issue thread we agreed it wasn't consistent.
Never got back on sign language.
... The way 1.2.3 is phrased is not the same as 1.2.1 and no
reason to not be identical.
Alastair: MG on the survey you said needs more discussion. Is that to do with sc as proposed or the method of updating sc?
MG: I'm satisfied with discussion. I'm not sure we have resolution, but I'm satisfied with that too.
Alastair: Is anyone who's against the update approach assuming it's a good update to add?
JF: Update how?
Alastair: so that the 1.4.10 is adjusted as said in survey.
Bruce: I disagree with adjusting 1.4.10. It should be additional.
Alastair: Needs to go to whole
group officially.
... Need survey on update options.
... We didn't get enough participation in prior survey. I'll
rephrase and show options more clearly.
Bruce: I would have answered differently. This discussion has been very helpful.
Alastair: I'll refer to those excellent minutes.
RESOLUTION: Leave open pending survey.
Alastair: Maybe we don't need
next topic. For survey q 6 and 7...
... Looks like everyone agreed with response as proposed. Any
objections?
RESOLUTION: Accept q 6 and 7 as proposed.
<alastairc> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=2133852864
Alastair: I mean the spreadsheet
(link above)
... Before call I ran through and emailed the list. Looks like
we've only got one sufficient technique missing.
... In terms of lack of draft, we are missing character key
shortcuts as a technique.
... Anyone who can take on making a draft technique for that?
There's a few options in the tab.
... Can anyone volunteer to take on draft?
Mike: I may already have a draft. Looking.
Alastair: No one is against this
one. We do have a published failure technique. No success
technique yet.
... <manually lists/reads>
<alastairc> Identify Input Purpose, e.g. “Using incorrect autocomplete values for user input fields”.
<alastairc> Reflow, e.g. “Using fixed sized containers or fixed position content that is larger than 320px”.
<alastairc> Text-spacing, e.g. “Using fixes size containers that cause text to overlap when text spacing is applied”.
<alastairc> Content on hover/focus, e.g. “Failure of content on hover or focus due to content not being dismissible”.
JF: I heard "input purpose"...
Alastair: Looking for failure.
JF: I owe that.
... What happens when you are booking flight for family. How
should that be handled?
... Answer is just for person purchasing ticket.
... Tools which help known technique are storing data for user
and not for whole family.
Alastair: That was one of
them.
... This is a reminder. Feel free to deliver however you see
fit.
... The other failure there was using incorrect autocomplete
values.
... Or not using them when needed.
JF: Yes. I see it... feels like
in the techniques the answer is "here's some sample code to
illustrate it".
... That's the way forward. Show sample code.
... Not tech agnostic, but you can show how to do it in HTML.
HTML is the only one that supports req.
Alastair: I'm assuming any of these would be HTML or ARIA based later.
JF: Traveling a lot, but will try and get something written up.
<Detlev> @JF: Are you saying that *not* conveying purpose on fitting inputs would not be a failure?
Alastair: Anybody else want to
take one one? We have 8.
... If we get this done, we'll have one for a, aa and
aaa.
... Feel feel to reply directly to me if you want to take one
on, or even if you aren't sure and have q.
... <reads unresolved ones>
... Also let me know if you are assigned but cannot
address.
... Any q on techniques?
... We'll conclude...
JF: Kind of new business open q.
There's an internal conversation about adding a sc to
2.2.
... Other q for which there is no answer. Do we have a cutoff
deadline for 2.2 sc?
Alastair: No set deadline. We
have an initial set. We've had some drop out. We are trying to
treat as backlog.
... 6 that we evaluated.
... Prefectly happy to add to backlog, but no promises.
... There is no cutoff point yet.
... There will be, but hasn't been set yet. Not there yet.
JF: Wasn't me specifically, but
came from engineering team. Related to deprecation of
4.1.1
... Looking at what will we do with SC. There was a
proposal.
... More of a process q.
... The better written it is for backlog, the more likely to
make 2.2.
... We won't stop working on sc.
... I've heard that we do not yet have a cutoff point. But will
see one at some point.
... As far is introducing, how should we do that? Github? Other
way? Best way?
Alastair: An issue in github would be good. If written up, use 2.2 template.
JF: Yep, done already.
detlev: Still time to make new sc
in 2.2, related to scope of 2.5.11 pointer gestures. Long
debate on scoping pointer to path based gestures.
... Maybe another sc for dragging actions. If they don't count
as path based gestures.
... Provide alternative for that action. MG mentioned he had
worked on something on that. Or open to seeing such an
sc.
... Is this the right time to bring up and draft for dragging?
Did Mike already do this?
Mike: I have a technique drafted
that uses no form of dragging to meet pointer gesture. That
could become a basis for a new sc.
... That technique ... the logical thing is to get attention on
that technique. Once that technique is done it's possible to
pull sc from it.
detlev: Close to pointer
gestures. Does the group think it's a good idea to target
dragging actions? Or should be combined with pointer gestures
in future?
... where older sc would be changed or augmented.
Alastair: Many views. I suggest following process with focus styles. Write up approximate sc language, an overview section.
<mbgower> If we focus on the ST I've drafted, Detlev, we'll get some discussion on the topic as part of that process.
Alastair: Template we've been
using. Good point at which we can get through an initial
review. Give us a direction.
... Lot's of options, but finding it hard to give a general
direction, applying case by case.
... Once we have decision on reflow, will be clearer.
Mike: If we get technique
reviewed for pointer gestures (doesn't use dragging), people
will understand and approve or disapprove...
... Will guage groups understanding.
detlev: If door closes on 2.2, I
want to establish that as a new sc.
... More than meets the sc. It's a difficult thing to
understand as we've seen. I'll follow Alastair's
suggestion.
Mike: with some effort we can have the technique in front of everyone next week.
Alastair: How that translates to new sc is a different topic.
detlev: Can you include link to template?
Alastair: the 2.2 template.
... Any other q or comments?
ack Chuck.
<alastairc> trackbot end meeting
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) FAILED: s/MG: Conforming/Bruce: Conforming/ Succeeded: s/passline/baseline/ Default Present: alastairc, MichaelC, Rachael, patrick_h_lauke, Glenda, Raf, Detlev, stevelee_, Chuck, JF, SteveRepsher, johnkirkwood, Laura, mbgower Present: alastairc MichaelC Rachael patrick_h_lauke Glenda Raf Detlev stevelee_ Chuck JF SteveRepsher johnkirkwood Laura mbgower WARNING: Replacing previous Regrets list. (Old list: Justine{) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ JustineP Regrets: JustineP Found Scribe: Glenda Inferring ScribeNick: Glenda Found Scribe: Chuck Inferring ScribeNick: Chuck Scribes: Glenda, Chuck ScribeNicks: Glenda, Chuck Found Date: 23 Jul 2019 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]