Accessibility Guidelines Working Group Teleconference

21 May 2019


AWK, alastairc, jon_avila, Fazio, MichaelC, Chuck, Laura, Detlev, david-macdonald, stevelee, johnkirkwood, KimD, mbgower, JakeAbma, Rachael
Joanne_Juett, Marc_Johlic
jon_avila, Rachael


<AWK> Zakim clear agenda

<jon_avila> I could scribe

<jon_avila> scribe: jon_avila

TPAC registration https://www.w3.org/2019/09/TPAC/

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

WCAG 2.2 progress update with teams

<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

WCAG 2.1 techniques overview

<AWK> https://docs.google.com/spreadsheets/d/15idlBl1qQTNr2SIi4Drzk1Q1vnWAi5L26GCCv6mjD2g/edit#gid=2133852864

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.

New techniques & issues survey: https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/results

AWK: Nothing unanimous.

New technique: Failure technique for 2.5.6 Concurrent Input Mechanisms (PR 690)

<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

New technique: Using native controls to ensure up events (PR 726)

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

Understanding update: Pointer Gestures clarity (PR 714 / 725)

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

Summary of Action Items

Summary of Resolutions

  1. Complete 2.1 techniques before TPAC
  2. Leave open pending Mike Gower and Patrick working on comments
  3. Accept PR 726 as amended
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/05/21 17:02:01 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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]