<AWK> Zakim clear agenda
<jon_avila> I could scribe
<jon_avila> scribe: jon_avila
awk: 2 days in TPAC in Japan in September - 4 days if you want to do Silver as well. Registration just opened.
<Fazio> what's the speaker question protocol
<Fazio> I have QUESTION
MichaelC: June 21st early bird pricing ends. 102 euros a day for early then up to 151 and 200 for late or onsite Sign up if you are coming -- that will help us plan
awk: you can put yourself on queue by typing q+
DavidFazio: question about invited expert fund -- hangs in limbo -- what are the next steps?
MichaelC: In theory you shouldn't be prompted for payment -- not able to test myself -- Michael will ask what the procedure and he will get back to him.
awk: Any other TPAC related
questions?
... Silver is Monday and Tuesday, Wednesday in Planery and AG
is Thursday and Friday
davidMacD: do we need to register if we are going to be on phone?
awk: No
<AWK> https://docs.google.com/spreadsheets/d/11IKqjRFvkRd2dAfUiyc5whhB3yIYXvSiirWct7KQIB0/edit#gid=0
awk: as a reminder here is the Google doc of the 2.2 SCs we have. Checking in to see how these are going... Any updates?
<david-macdonald2> I've updated the Up-Event one https://raw.githack.com/w3c/wcag/tech-up-event/techniques/general/G211.html
alastairc: focus visible has initial draft. Need to setup meeting with Jake. Sent email to list yesterday with list of each one with names. Not sure if it appeared for others.
detlev: didn't see it.
AlastairC: Regarding authentication - -John R has been sheparding it -- had a call but have not made further progress
DavidMacD: just dropped in a technique for 2.1 into IRC
awk: David were you heading up deprecation of 4.1.1?
davidMacD: Wilco had been lead -
momentum in it's favor -- so resistance -- primarily from one
team of aXe at Deque -- fair amount of momentum to remove if we
can change backward compatability that is attractive.
... Huge fight over validation some time ago -- compromise was
for 4.1.1 -- for most part that has subsided. Primary technique
was to validate -- we won't have that techniques to somewhere
else to 1.3.1 or 4.1.2 -- we might lose that techniques but
that might have cause some distress to some people who want to
see good form.
... Could move technique to 1.3.1 or 4.1.2 because it's already
covered under the language of those criteria.
awk: Last discussion on github was in April.
DavidMacD: No further movement then what is on github in April although Wilco did take an action item to go through and see if there isn't something that would be an issue that would not fit under 1.3.1 or 4.1.2
<alastairc> In summary, waiting for Wilco?
awk: pinged Wilco in Github issue
DavidMacD: Can update on Epub. One is basically saying that when someone is following along in epub with AT in classroom -- the page numbers can be different when text is enlarged and page numbers change.
<alastairc> Primary names per WCAG 2.2 SC is listed here: https://lists.w3.org/Archives/Public/w3c-wai-gl/2019AprJun/0096.html
<AWK> (David updating about "Meaningful set" an EPUB-focused SC proposal)
DavidMacD: Some proposed language
-- the numbering of pages in default mode can be determined
both visually and programmatically if the view changes. If
there is a default most you could still identify if the flow
has changed.
... may be able to create some langauge that is consistent with
success criteria.
... related to in a set - technologies that have page numbers
-- the default layout -- both visible and programmatic can be
determined -- rough wording. Along the same lines like a set of
webpages.
awk: Alastair's email of proposals and who has signed up as lead on them and what the current status -- right now is still thin in terms of status. Alastair -- how should people let you know if there is an update?
AlastairC: People can either email me or edit spreadsheet if you have access to edit. I can corodinate. Email just went out due to email issue.
detlev: wondering -- there are 2 items -- proximity of related information and location of labels and at some point was called label gap. I think we had agreed to make it one activity. Not sure what status is. Was quite difficult to measure initially -- not sure if it is suitable for 2.2. On other hand I'm not aware of row 8 related to change in mobile view. Should these be lumpted together and should we persue label gaps?
<alastairc> Noting that Andrew & Detlev are down for each of those...
awk: group needs to determine how
this shakes up -- 1 or broken out into different items. We
might not know until we see proposals for each of those to
address the user needs that both of those lines refer to.
... Detlev, if we arranged a call -- would that be something
you would be involed in?
<alastairc> https://docs.google.com/spreadsheets/d/1yjrfIP9KLqTn_Jlq6-T1JvsqY924R_5z1WI2YLv3obc/edit#gid=0
<alastairc> People down for those: Jake, Andrew, Detlev, JonA, David McD
awk: would others be interested if we arranged a call around labels and proximity that isn't jsut about labels?
MikeG: would like to be involved.
detlev: will make sure I am
primary on label gaps/placement.
... seems to be useful to have them together.
DavidMacD: agrees that they should be together
awk: will put out request for call on list for proximity
detlev: do you want to me to send out doodle with dates and times to the list.
I am interested as well.
awk: Any other questions or
barriers that they need help getting past?
... We need to start having wg reviewing SC as soon as
possible.
AlastairC: have it listed as June 4th for review
awk: Looking at a two week period
-- accessible authentication is closest. Not sure if others
like deprecating 4.1.1 is easier as we are not writing new SC
but there is content regarding understanding and techniques. We
have a few that are possible ready - -but would feel better if
we had queue built up of SCs that are ready.
... watch the list for things to participate -- look at list
and see who the contact is -- get in contact with people who
are lead for SC and help you find a project to work on
awk: this spreadsheet has
techniques for each of the WCAG 2.1 SC. Still quite a bit to
do. We have improved on this in the past couple weeks. Label in
Name we now have 3 approved techniques
... We mark as done as far as tracking. If people have another
technique we can add that -- but as far as metrics of having 3
sufficient and 1 failure we could say done or completed. Any
objection to makring as complete?
MikeG: has technique but it doesn't have to be there for this to be marked complete. I'm ok with that.
awk: We will try to proriotize
medium and high category other than done category - -using this
as a prioritization.
... Looking at orientiation -- is high -- no techniques for it.
There is one from Kathy - -using a control to access content in
other orientations that are restricted. Does anyone from the
mobile task force know if this one is set to go?
... don't have any other sufficient techniques for orientation
that are planned.
MikeG: is that sufficient or adivsory?
awk: seems like it could be sufficient.
I would agree with Andrew that it sounds sufficient to me.
<AWK> Using CSS to set the orientation to allow both landscape and portrait.
<AWK> Use of show/hide controls to allow access to content in different orientations.
awk: In understanding doc there
are 2 sufficient techniques are listed. This second one is the
one that Kathy has described.
... Another possible technique is just not do anything that
restricts it. Actively not restricting the display. That seems
like a general technique around that.
<alastairc> Yes, it is an odd one, do nothing to pass!#
I agree it could be a general technique.
MikeG: Failures seem to be more important than sufficient techniques
awk: Failures can be harder to get written
MikeG: Main thrust is to allow orientation to change. It's more likely to be caught on a failure than on a suffiicient. We can put those into automated engines.
<AWK> Need to check the aXe library for orientation tests
awk: Charcter key shortcuts -- 1 each drafted -- but none published.
detlev: in absence of others we
could discuss this in survey to see if it's feasible.
... bookmarklet has been written to press keys. Happy to see
what others propose
awk: put on survey for additional
feedback.
... is that 2.1.4?
... Native controls for up event -- for pointer cancelation SC.
2.5.2
<david-macdonald2> https://raw.githack.com/w3c/wcag/tech-up-event/techniques/general/G211.html
awk: David MacDonald can you put
yourself down for that
... 2.5.1 pointer gestures. Some techniques drafted but not
accepted.
... we need people to review the 4 that are drafted and we have
a couple more as well. Do people know which ones are ready to
go for survey? Or if something is needed?
detlev: might be worth having general technique. No fancy things such as touchstart/end or pointer events and then you meet it. Not sure if it's too broad.
<AWK> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=0
detlev: depending on whether
sliders are in scope or not may determine whether this is
adivsory or not.
... providing controls is similar to content sliders that can
be moved by swipe gestures that have a clear direction.
Pasting in Orientation ACT Rule that address a tiny aspect of orientation https://github.com/act-rules/act-rules.github.io/pull/408
detlev: Could remove anything
that could smell like dragging.
... Failure technique might need resolution of dispute over
control sliders whether it path based gestures or not.
awk: Failure to relying on path based or multipoint alone. Is that different?
detlev: Can't recall if that is different - Rachel had put that in. She is not on call
awk: Single point activate for spacial positioning and manipulation.
detlev: focuses on multipoint
gestures like pinch gesture in map where many have plus and
minus to zoom in and out. Many don't have arrows to move left
and right. Would that fail unless you can tap on some other
point of map.
... Failure might discuss a map with plus min but the map does
not respond to taps but you can't move sideways -- determien if
dragging is in or out of scope. They are tied up on this open
debate about dragging.
MikeG: Just to back that up - if you restricted to pinch to zoom that is multipoint. If it fails plus and minus that would be enough.
awk: A sufficient techniques
would be to have plus and minus buttons for map
... Seems like it's straight forward to write. Nice to have
example -- but if it's common enough we could point to a common
example of where it is done.
detlev: We'd want it to meet other criteria as well.
awk: that's the challenge because
public examples narrowly meet a SC but then we will find it's
not meeting another such as buttons not labeled
... last high one is motion actuation.
... 3 techniques for Rachael. What is status?
<Detlev> @Rachael wondering if you are still on 2.5.1 - Failure due to relying on path-based gestures or on multi-point gestures alone?
Rachael: Alastair had made some
chagnes and I thought they were coming back to the group for
review.
... Once the sufficients are done then I can write the failure
as it will be very similar -- just opposite.
Alastair: It's in the queue for me to review next week.
AlastairC: will look at it to get it in the survey.
awk: not a full review of all the
2.1 techniques and failures that we are thinking about. David
just put one in that we can all take a look at for pointer
cancellation.
... If you are interested in helping please let us know. We
have a bunch to get on survey. If you see something that is
listed but doesn't have someone assign yourself. You can let us
knwo if you want to add one that is not listed.
<Zakim> mbgower, you wanted to say do we have a target for having techniques for all?
MikeG: Wondering if we have a target timeline to have techniques for all 2.1 A and AA.
awk: don't have a specific target timeline. Our approach is to make sure we talk about it each week and keep focus on it so we can make progress.
MikeG: would like to target end of June personally. Would like it to be sooner than later. We are about a year past and yes we now have techniques for 2.1
awk: not sure a month and half from now is realistic.
MikeG: if we have date is more
likely to slip.
... maybe done by TPAC is more realistic.
awk: I could go along to saying
yes to by TPAC as it's far enough out to be achievable
... I would hope to not talk about WCAG 2.1 techniques at TPAC.
Focusing on Silver and 2.2 is more important
... we feel they are important enough for 2.2 that we have
these in place to support the sentiment to change the process
for 2.2
Rachael: I am also in support of saying they are done in TPAC. And if we have not completed them by TPAC we should talk about them.
DavidMacD: I agree TPAC is September -- that is doable -- mid-August is reasonable. I have 3 -- do one a week
awk: Any objections to say they
are done by TPAC?
... Less than TPAC date equation -- before TPAC fine.
... would rather have by June but I don't think that is
achievable. Hopefully we can crush deadline so it's not even a
question.
Alastair: for people who are spread across 2.1 techniques and 2.2 SC it's fine to prioritize the techniques over the next few weeks and we have enough SC for the chater. As a suggestion.
<Rachael> scribe: Rachael
RESOLUTION: Complete 2.1 techniques before TPAC
AWK: MGower, you suggest that means one technique for A and AA? I was thinking that was 2 for each A and AA.
Mbgower: I think that's fine but we may get in a situation where we may only have one technique but I think its a good goal.
AWK: Nothing unanimous.
<alastairc> https://raw.githack.com/w3c/wcag/f016542fa6d0c135224ad9a573c95e3ef5d383c8/techniques/failures/F97.html
AWK: 8 people proposed, 3
suggestions. Patrick made an update but not sure he made it to
mbgower's suggestions.
... the version sent out was different from Jake's most recent
version.
Alaistar: Unsure whether all comments have caught up with new version.
AWK: You will follow up with Patrick? Alastair your comments?
<mbgower> I will follow up with Patrick
Alastair: Mine were minor.
AWK: Sounds like your main concern is that the mouse failure may not be a failure.
mbgower: I would be happy if we came up with a failure where it doesn't fail another SC. If it always fails keyboard and pointer, its a redundant SC. I Think the revision addresses this. I am pretty comfortable with it but I'll circle back with Patrick.
RESOLUTION: Leave open pending Mike Gower and Patrick working on comments
AWK: David, were you working on this?
David: The only one that hasn't been addressed is Jake's comment about rewriting it. That would be good to talk about. I've tried to address the other comments.
AWK: Do you have the current URL?
<david-macdonald> https://raw.githack.com/w3c/wcag/tech-up-event/techniques/general/G211.html
AWK: Based on what I'm seeing, I don't see the procedure changed to address the comments.
David: If the back button works, then the action is reversible.
AWK: Jake, are your comments addressed?
Jake: I think yes.
<Chuck> ack Chuck: "Abort or Undo" addresses my concern.
David: Ability to abort function before completion or undo the function after completion.
Chuck: I think my concern was addressed. My concern was that reverse is a stronger word. You can correct a search but it never goes away.
David: I agree with that and can amend it as we talk.
Detlev: I wasn't sure if the link example was a good one for reversal. My main point was that you can test all controls without triggering something. You could go from control to control and see which triggers something. I just think its the wrong way around.
David: I think what you are saying is that you can find all controls that are abort or undo but its easier to test every control on the page. Is that right?
Detlev: I find it difficult to wrap my mind around it. I would like an example.
<AWK> For each clickable control: 1) Activate the down-event then move the pointer outside the target before triggering the up-event, and then release the pointer to trigger the up-event. 2) Check if the action is reversible if the action is triggered. 3) Confirm that the action was not triggered when the pointer is released outside of the hit area for the target.
Detlev: First step to test if something happens on the down event.
David: I think that's better.
<jon_avila> I think Detlev is saying the order of testing should be changed to be more efficient. Click and drag out of control and then check other aspects of SC.
<Zakim> AWK, you wanted to suggest edits
AWK: I have a suggestion above but would reverse 2 and 3.
David: adding the new text to template.
Detlev: The only complication is that we may have down events that are touch so may only be testable on a mobile device.
<alastairc> David - could you put the note in the last example below the actual example?
Detlev: if you have a down event
on a touch screen, you want to move your finger and you may
scroll the page so you can't move your finger away from the
control. This may need a note on testing.
... may be limited in scope to desktop scenario or you may need
to include a touch device.
Unless you've doubled up on events, then you may have an event that would only be touch that you couldn't catch on a desktop. We should check with Patrick
David: I've captured Patrick's comment.
Detlev: Patrick would know but I am raising the flag.
David: I've added a note based on his comments.
AWK: People will test based on
the configurations they will base their conformance claims
on.
... Does the procedure check what it needs to check if testing
on mobile?
David: I need to do some digging around to determine.
Alastair: Are we making this more
difficult than needed?
... if you are using a native html button, use example 1. Then
the test procedure doesn't need to address whether its on touch
down or pointer. I think the test procedure is fine but the
example for a sufficient technique doesn't need to cover
everything.
... is it sufficient to cover the native on click event?
David: The native controls do
pass. We are basically saying don't do dumb stuff.
... so what additional changes are needed or is it where it
needs to be?
Alastair: I'm wondering if the note on the 2nd example goes into too much detail.
David: The note is from Patrick's comments
Alastair: I'm not sure we should have to inspect the code to see if its onclick. A tester would have difficulty. Do we need a cocheck there?
<Detlev> afk
David: This is a test for the SC
itself and also happens to work for the technique. We have
always tried to focus on functional testing before code
inspection but we have both.
... I'm comfortable with where this is. Its a simple test. The
only complexity is captured in the note.
Alastair: I would end the note after the word Handlers...
David: I have it selected and can delete if you want.
AWK: I had a couple questions.
The title says using native controls and then it says generic.
Can we make it all native?
... I was also struggling with the first example where it
repeats. If it says, in JavaScript native click events are
triggered on the up event by default...
... that is kinda saying the same thing.
David: Captured those.
AWK: I suggested swapping 2 and
3.
... another important change is in expected results needs to
say 2 or 3 are true.
David: Got it.
AWK: Is there an external resource to link to for this? Something from HTML?
David: The html language doesn't have it but we could link to Javascript.
<alastairc> David, try this for a resources link: https://developer.mozilla.org/en-US/docs/Web/API/Element/click_event
AWK: I think we've addressed
everything. Are there any objections to accepting this as
ammended?
... Alastair suggested a resource. It seems relevant.
RESOLUTION: Accept PR 726 as amended
AWK: This is the sliders debate.
<Zakim> alastairc, you wanted to talk about the options
Alastair: We did a little bit
last week. I put it into my comment but we moved sliders out of
scope but there were concerns. You could have click events
without dragging unless you define it as drawing. There are 3
options: Sliders out, some sliders in, all sliders in
... I don't feel strongly but I think it could impact sortable
lists, resizing boxes
mbgower: Is dragging a gesture? how are we going to define dragging so its understandable to everyone? I went through the entire archive to dig up the discussion of this.
In the original one, we had no dragging. We had time based and multipoint.
scribe: But we decided to go with
path based instead due to complexity with time based. We only
have one definition of path based but we didn't include it in
2.1. So we have a question of what dragging means. We also had
a discussion of including dragging as a gesture since it
predates the mobile gesture discussion.
... I think that dragging that does not have path based
reliance has been in place for a while. I don't disagree that
there are issues but its not part of this SC.
Detlev: I think we have other cases where the new mobile discussion affects content that was generated years ago. From a user perspective, there isn't a clear cut difference between dragging and swiping.
<jon_avila> One of the reasons for this SC was to prevent features such as swipe in from left to open a menu.
Instructions reference both. The critical thing is the directionality and intent. The directionality is encapsulated in the control itself. The affordances tell the user how to move the control.
<mbgower> There is a clear difference to me, which I've made numerous times: does the direction of movement affect interpretation. Swiping MUST be directional to be interpretted, therefore it is path-based. Where someone can drag to the end point on any path, then it is not pathbased.
scribe: People may misswipe but
the control may still work even though people don't intend to
move the way they did.
... it is hard for people with multiple disabilities to drag
something so this should stay in scope.
<Zakim> alastairc, you wanted to suggest using the full term "path-based gestures" to differentiate from previous keyboard aspects.
scribe: My understanding is that we intended to have single point activation to replace path based gestures so my understanding is that both are included. If the group decides we can't do this, then I will give up this point.
Alastair: It does seem to take it
a bit further than I thought it had previously. I am worried
about draggable lists and resizing type things.
... I think this is something we need a poll on. Are we
comfortable saying that any kind of dragging or gesture needs
an alternative?
<jon_avila> poll options might be include directional swipes, gestures that are not swipes, and drag and drop.
AWK: I agree we need a poll. Its unlikely we will resolve it in the next minute. I think we can set up a survey around this to articulate the decision. I have to relearn this. Jon
Jon_avila: I think it was the intent that something like a swipe in from the side would have a single click activation.
Alastair: I wasn't saying that shouldn't be included. If there is something on the screen and you drag it, then there a lot of in betweens.
Jon_avila: I think we should list out all the possibilities and ask what should be included.
AWK: Thank you everyone. Don't abandon family and sleep but work on techniques and 2.2
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) Succeeded: s/Wilcon/Wilco/ Succeeded: s/RESOLUTION: WCAG 2.1 Techniques to be complete before TPAC// Succeeded: s/it could be sortable lists/it could impact sortable lists/ Default Present: AWK, alastairc, jon_avila, Fazio, MichaelC, Chuck, Laura, Detlev, david-macdonald, stevelee, johnkirkwood, KimD, mbgower, JakeAbma, Rachael Present: AWK alastairc jon_avila Fazio MichaelC Chuck Laura Detlev david-macdonald stevelee johnkirkwood KimD mbgower JakeAbma Rachael Regrets: Joanne_Juett Marc_Johlic Found Scribe: jon_avila Inferring ScribeNick: jon_avila Found Scribe: Rachael Inferring ScribeNick: Rachael Scribes: jon_avila, Rachael ScribeNicks: jon_avila, Rachael Found Date: 21 May 2019 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]