14 Apr 2020


bruce_bailey, JustineP, ChrisLoiselle, alastairc, JakeAbma, sajkaj, Francis_Storr, Jennie, Fazio, PeterKorn, Judy, Pascal_Wentz, Rachael, stevelee, JF, Brooks, kirkwood, MichaelC, Laura, david-macdonald, Katie_Haritos-Shea, Gundula, jon_avila
Charles, Hall, Nicaise, D
ChrisLoiselle, Brooks


<ChrisLoiselle> I'll scribe first hour

<ChrisLoiselle> Scribe: ChrisLoiselle

Planning for updating of ISO endorsement of WCAG

<PeterKorn> Yes you are coming through clearly

<alastairc> Notes about ISO are sent to the list, and here: https://www.w3.org/WAI/GL/wiki/Upcoming_agendas#Apr_14th_.28CA_chairing.29

Judy: Please take a look at background sent via the email list.

<Chuck> No, just zoom.

<Chuck> sent to w3c-wai-gl@w3.org

ISO helps standardization update in countries that may not be fully following WCAG. W3C is looking to update the ISO documentation. It does take many months. Endorsement would probably align with WCAG 2.2, around October.

The work falls on the staff, not the working group.

<MichaelC> Background for Planning for updating of ISO endorsement of WCAG

If questions come up in review stages within ISO, questions may be brought back to AG working group and handled with W3C and AG.

Input is welcome for pros / cons and comments.

Chuck: Our work is to continue with WCAG 2.2. What next action do we have to help facilitate the ISO efforts?

Judy: Process wise, I'd pursue my step with ISO rep with planning for process queue .

General feedback on approach would be helpful for process. Generally W3C management makes decision but welcome group input.

<bruce_bailey> +1 sounds good

<Fazio> ISO carries a lot of weight when I worked for the Air Force

<bruce_bailey> makes sense to wait until 2.2

Judy: To group, anyone have any feedback at moment?

<Fazio> +1

<alastairc> A general thumbs up, and thank you Judy!

<Francis_Storr> Sounds good to go with 2.2 +1

<JustineP> +1

DavidM: WCAG 2.1 or 2.2 to ISO? I love the feeling of becoming ISO . Judy: WCAG 2.2. as the process would align with WCAG 2.2 more than WCAG 2.1

<laura_> +1

<alastairc> DavidF, did you mean to share screen?

DavidF is sharing his screen FYI

Survey Results for AGWG/Silver meeting times https://www.w3.org/2002/09/wbs/35422/2020-04-silverpoll/results

<sajkaj> https://www.w3.org/2002/09/wbs/35422/Conformance-Challenges-FPWD3/

Chuck: Joint Meeting proposal for Silver and AG : Move Friday meeting to allow AG meeting members to attend seems to be well received and voted for 9 times currently.

<Chuck> q/

DavidF: Community attending meeting vs. closing off meeting to meeting members is a concern.

MichaelC: Meetings should be open to community group as they are helping working group members.

DavidF: How would we parse the contributions of working group members vs. community.

MichaelC: The decisions / votes are based on the working group members.

JF: Concern is meeting for 4 hours a week in a 40 hour work week.

<kirkwood> +1 to JF regarding time

Concern is amount of time dedicated to meetings in general on reducing amount of meetings and meeting time.

<Fazio> +1

<AWK> +1 to amount of time concern

Ryladog / Katie: I didn't want us to be in this position. Trying to update WCAG 2.x and Silver at same time. Group merging should be a topic of discussion.

<Brooks> +1 to Ryladog concerns about delaying the merge between WCAG 2.x and Silver.

<JF> -1 for Wednesdays

Alastairc: Friday meeting is not just about day, its about the time. I.e. East (Japan attendees for example) to attend. The other Tuesday meeting , its not double meetings itself it is the condensed time frame to consume all items and report on the meetings and participation of meetings.

<sajkaj> Friday Silver is 2PM Boston, so not very Asia friendly

Possibly moving second Tuesday meeting to another time later in week.

MichaelC: Time survey is not to change amount of meeting time. It was to move meeting times (days of week and time block within a day) NOT the amount of time dedicated to each meeting.

<alastairc> sajkaij - the Friday one is the one where Makoto participates.

JF: The survey didn't read to me in that way. It's still four plus hours a week to attend and monitor.

Chuck: I do hear vocal concerns on amount of time.

<Fazio> J has a point

JF: Attending Silver calls , I attend both Tuesday morning and Fridays usually. Some don't. It seems like a scheduling issue , half a day dedicated to the effort.

<bruce_bailey> fwiw, for another year or so, i am okay w/ 4 hours per week

Chuck: We should work together on if we should move the days / times of meeting to accommodate most attendees.

Alastairc: Makoto does attend Fridays, so dedicates time. If we named the Tuesday a joint meeting, that may point AG members to join that Silver group. But it is difficult to meet with AG after it as well.

Chuck: We should adopt silver meeting time and create it as a joint meeting.

<bruce_bailey> Chuck, pls type proposal

That's a proposal

<Chuck> Proposal: Adopt moving the Tuesday silver call to an easier time for AG, rebrand it, and in a subsequent conversation discuss reducing time requirements.

<bruce_bailey> no need to be formal, i just process better from text as compared to verbal

<alastairc> +1

<kirkwood> easier?

Rachael: Choosing what meeting to move was the first question.

<bruce_bailey> +1 to breaking up Qs separately

JF: Monday , Thursday or Friday are days that could work.

<JF> +1 to reworking the survey question(s)

<kirkwood> +1

<bruce_bailey> thanks, +1 for new survey

Chuck: Proposal to re-work survey to change wording for concerns

RESOLUTION: Re-work, re-word survey

Public Working Draft of 2.2 and standing consent to publish

MichaelC: We have a pipeline for WCAG 2.2 and want to open for wide review. Consensus from AG for publishing is required. Do we have that? Could we have standing consensus from the AG?

Could we vote for standing consensus for AG to publish WCAG 2.2 ? If favorable, we would do a CfC on publishing.

JF: How would we break standing consensus if we wanted to revoke it?

<Zakim> alastairc, you wanted to mention that it would only affect Accessible Authentication so far.

MichaelC: We would allow the ability to revoke. Definitely before final CFC.

Alastairc: We would be attempting to limit emails and reach out on CFC related criteria.

AWK: I would be in favor of standing , as I believe it is worthwhile.

<AWK> My same comment applies to the WCAG 2.2 standing consent and the Note for conformance challenges. The background is only on the conformance challenges.

Brooks: What is the general timeline for public comment ? I.e. focus enhanced gets most time? What is the minimum amount of time these are open for review?

<Zakim> alastairc, you wanted to say it's a rolling thing.

<bruce_bailey> good point brooks!

Alastairc: We need to look at this from a rolling standpoint

An even amount of time given to each one is recommended. Understood that time crunch is necessary in order to review all.

Brooks: Will it be open for say 120 days? Each draft?

MichaelC: Usually 4 weeks time before candidate recommendation.

<david-macdonald> +1

<JakeAbma> +1

<bruce_bailey> +1 to standing conscent 2.2 wd

<Francis_Storr> +1


<AWK> +1 to standing consent for WCAG 2.2 draft publication

<laura> +1

RESOLUTION: To do CFC to the larger group for standing consent for WCAG 2.2 draft publication

RESOLUTION: A CfC to larger group for standing consent for WCAG 2.2. draft publication

Sorry Chuck!

Conformance challenges re-review https://www.w3.org/2002/09/wbs/35422/Conformance-Challenges-FPWD3/

Chuck: Any concerns on the survey or answering the survey

<bruce_bailey> lol, widely adopted, so it must be accessible -- good observation of mainstream assumption!

<bruce_bailey> thanks brooks

GN015: Is the question will the challenges document being closed today the question? Chuck: No. We wanted to know if everyone was able to review and respond to the document by 4/28, but have enough conversation today to resolution of main issues.

Chuck: In comment to Brooks , it sounded to me what was not in document as to what was IN document. Question to you, does this make incremental advancements and is the document advancing the cause?

PeterK: I had same question. In addition to whether there is enough here to propose to draft. I welcome you to add to the next revision of the document to advance what your issues were in terms of what was lacking.

Questions, comments or within a github branch. Second question is are you opposed to general publishing the current draft?

Brooks: I'd be open to that. I'm just stating that things are missing from the conformance document. The concern is that the W3C is not providing clear path to what W3C can do to achieve conformance.

<Chuck> scribe: Brooks

MichaelC: We can pose questions to the public, if we have concerns we want input on.

ChrisLoiselle: At Oracle, our viewpoint is that we do support the Conformance Challenges document. It helps to explain to customers that perfection isn't the goal. Its a continuum. In terms of Accessibility Supported, we code to the standards. We reach out to vendors to see if there's a way to workaround issues we find in testing.

Chuck: Nicaise wanted to change text from "hundreds of pages" to "thousands of pages." Peter, any concerns with that?

<bruce_bailey> +1 to thousands of pages over 100s of thousands

PeterKorn2: I have no concerns, but wanted to get feedback from AGWG.

<Zakim> sajkaj, you wanted to speak to section 5

<alastairc> I'd suggest reducing the "per second" aspect as well!

<bruce_bailey> could be 10s of thousands

<AWK> Realistically, it could be "hundreds of pages" and have challenges apply. This text will be edited again whether we make this change today or not..

Sajkaj: All of section 5 came from earlier research in Silver. Are we internally consistent on review of this yet? I don't think so. I wanted to make you aware of how that section evolved. Nobody seems to be complaining about what's currently in the draft. We are looking to expand the comments, responses we get.
... Not just the things that we've heard today, but also comments from the larger community.

Laura: Ginina already spoke to me issues.

AWK: Success Criterion 1.2 should be changed to Guideline 1.2

Alastair: Everything I've suggested is editorial. Not going to object to publication.

Chuck: Brooks says he's OK with publishing, as long as it isn't permission to publish a final version. What else do we need to do?

<bruce_bailey> +1

Alastair: Does anyone object to publishing this draft?

<Zakim> sajkaj, you wanted to ask about simplified language

Sajkaj: Some comments say the language is too complicated. I'd like to address that after the public working draft. But, wanted to mention this is a comment that came in during the last hour.

PeterKorn2: Mary Jo has a GitHub comment. I think its all editorial on Mary Jo's part.

SajKaj: Can anyone apply the Understanding with Challenges label in GitHub.

<AWK> +1 to publish as draft note

<sajkaj> +1

<PeterKorn2> +1

MichaelC: Someone from the working group needs to do that.

<Rachael> +1 to moving forward

<JakeAbma> +1

<Francis_Storr> +1

<ChrisLoiselle> +1

<alastairc> +1

<Ryladog> +1

<david-macdonald> +1

<kirkwood> +1

RESOLUTION: publish the conformance challenges doc as a FPWD

WCAG 2.2 Touch target spacing (Adjustment to errata): https://www.w3.org/2002/09/wbs/35422/target-spacing/

<PeterKorn2> Apologies, I need to run to another meeting already in progress

AlastairC: Wilco and I have spent considerable time discussing touch targets via email. Since, Wilco isn't here, does anyone else interpret the proposed SC text the same as he has?

<alastairc> Wilco suggested: "For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets, except when:"

alastairc: Is there anyone from the Mobile Task Force who can speak to this? We can go with Wilco's suggestion. Or do people not understand the reasoning behind Wilco's suggestions. I propose we should treat it as one or the other.

<alastairc> Previous suggestion (from me) was: Target size, including spacing between adjacent targets, is at least 44 CSS pixels horizontally and 44 CSS pixels vertically except when:”

Chuck: I like sticking with the current language, and directly asking Wilco directly about his interpretation.

david-macdonald: I didn't understand Wilco's comment either. I think we should go with our current language in the draft and get public feedback.
... I'm trying to find quick ways to test things, so I'm wondering if this can be automated? Will this have to be a manual test?

alastairc: It's potentially automatable - but, we are not sure. I think Wilco and Justine's comments are the only new ones.

<alastairc> >region of the display that will accept a pointer action to trigger a function, such as the interactive area of a user interface component

<alastairc> https://github.com/w3c/wcag/pull/1100/files

alastairc: We had a definition of "target" in WCAG 2.1. Wilco suggested adding a couple of words to make the definition more clear. That would resolve one of Wilco's points. That would need to be an errata.

<alastairc> Potential errate above

JustineP: The first comment in there is an old comment. The second comment is a question about whether the proposed SC is intended to address people with mobility impairments, or is for the larger community?

<alastairc> alastairc: The original research was based on people with disabilities, although it is a continuum (so bigger is better), and 44px was chosen to align with the Interface Guidelines.

Chuck: So JustineP, did you want to see the suggestion included?

JustineP: Yes.

alastairc: We aren't looking for spacing between each target. But if there is, that's fine.
... In terms of being understandable, you might consider what Wilco suggested at 19 minutes past the hour and what I've posted at 20 minutes past the hour.

<Chuck> Wilco's suggestion "For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets, except when:"

<david-macdonald> +1 Alastair's

<alastairc> Previous suggestion (from me) was: Target size, including spacing between adjacent targets, is at least 44 CSS pixels horizontally and 44 CSS pixels vertically except when:”

<AWK> I still find "Adjacent" to be not needed in the SC text

Chuck: I'm interested in your feedback here, Justine - but also everyone else.

<kirkwood> +1 to Wilco

<JustineP> +1 Wilco

<JF> +1 to Wilco

jon_avila: I like Wilco's better.

david-macdonald: Wilco's text talks about an "area."

alastairc: Wilco's comment is about a hit area, plus spacing.

david-macdonald: Concerned that people will mistake hit area with target.

<AWK> Each target is contained in an area with a width and height of at least 44 CSS pixels that includes the target and surrounding space without targets, except when:

jon_avila: Is this centered on the element? Do we need to add language regarding that aspect?
... How would we measure that? Would it be from the center point?

<alastairc> https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit

alastairc: It shouldn't matter where you measure the point from.
... Detlev has some good examples that tackle a lot of cases.

GN: I would be interested in knowing how the public perceives the wording in the SC. Mainly focused on the first sentence.

Chuck: You still like yours, are you OK with Wilco's?

alastairc: I can live with either.

Chuck: Is this something that can go in front of the public?

<jon_avila> I agree with that!

GN: I have a concern with the layers exception. This is one of the most widespread issues in practice. I object to this exception. I recommend that all touch targets that are behind the menu are not active while the menu is open.

Chuck: I thought that the default behavior of user agents was to ignore what's behind the menu. Is that true?

<JF> +1 to Alastair

alastairc: If you've got a dropdown menu, what you are looking for is just the targets in the dropdown. If you extend what's being measured to what's behind the dropdown menu, it would be a burden on testing at multiple breakpoints.

GN: I still believe that content underneath a dropdown menu should not be active while the dropdown menu is expanded.

<alastairc> For example, click the help menu in the Google doc, it then overlays the links at the top of the document.

JakeAbma: Dropdowns can cover other interactive elements. It's impossible to measure the distance with the variability involved with assessing what's underneath the dropdown menu.

jon_avila: What we are saying is that something can be under the dropdown. It's still easy for a user to accidentally activate something that is just outside of the dropdown, but on the active lower layer.

JakeAbma: For every dropdown menu covering part of the web site, such as a list of links, it will be impossible to account for necessary spacing in every instance the dropdown is expanded.
... There will be so few options to implement dropdowns if the underlying layer has to be considered, no one will use dropdowns.

<kirkwood> this would be impossible forany drop down menu.

JF: Never assume that a user has a full screen, a full monitor. We never know what the end user's output will be. We are trying to find a reasonable sized touch area, so that users will not have to touch outside the area in the dropdown. This won't be perfect, but we cannot address every use case scenario.

david-macdonald: Marketing and development teams would find it difficult to coordinate their efforts to make sure that dropdowns not drop down so that they aren' adjacent to the underlying page.

<jon_avila> Question to Jake -from a dev standpoint is it difficult or impossible to put a inert layer with padding behind a pop-up?

<Zakim> alastairc, you wanted to suggest we remove for now, open for public comments. Would mean that pop-over content would need larger targets than they might otherwise.

GN: The UI is only two-dimensional to the user. Imagine a menu that is very narrow. It would be very easy to touch items that aren't intended. If the menu is 50, 60, 80 pixels, it should be wide enough to not have users touching outside the menu.

alastairc: How about we remove that exception, and put this SC up for public comment?

JakeAbma: I'm not sure that it is well understood, what we are trying to prevent. In the Amazon site in the searchbar there is the "All" button. It just hovers over the main menu. And it touches multiple targets. It can even hover over parts of other targets.

Chuck: I'm concerned about taking out the exception, but personally, I'm fine with that if it expedites getting this out there for public comment. Is that what you think, Alastair?

alastair: Yes

<GN015> +1

<bruce_bailey> okay either way

<jon_avila> +1

<Rachael> +1 to moving it forward though I am also concerned abotu removing the exception

<JF> 0

<kirkwood> 0

<Ryladog> +1

<david-macdonald> +1

Chuck: How does the team feel about moving this SC forward, without the underlying layer exception we've discussed?

<ChrisLoiselle> +1

<JustineP> 0

<Francis_Storr> +1

<AWK> -.1


<jon_avila> I'm fine with leaving the exception in.

AWK: I have a hard time seeing this surviving public comment without the exception.

Bruce: I agree to AWK's point.

RESOLUTION: Move the SC forward to public review. Remove the exception and add note about the exception.

<bruce_bailey> that was good!

<alastairc> "Editors note: Are there issues with pop-over content overlapping targets underneath?"

JF: Before we move it to public review, can the working group review the note?

Chuck: My intent that this would go to CfC first.

<alastairc> https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit

JF: I'd like to see the note contents before we go to CfC.

<alastairc> "Editor's note: Are there issues with pop-over content overlapping targets underneath?"

Chuck: alastair says the note is up.

JF: It's not the popover content that I'm worried about, its the content underneath that I'm worried about.

WCAG 2.2 Visual Indicators review https://www.w3.org/2002/09/wbs/35422/Visual_indicators/

Chuck: Are any of these comments old comments?

<alastairc> ackal

alastiarc: I suspect they are. What we really need is research that demonstrates the SC meets the need, and also practical to implement. My suggestion is to defer this one.

<alastairc> my conclusion on the thread: https://lists.w3.org/Archives/Public/w3c-wai-gl/2020AprJun/0074.html

<Rachael> +1 to defer this to silver. (no chair or co-facilitor hats for me)

david-macdonald: We had several members of COGA who were OK with narrow the scope. Recent conversations with some COGA member have told me that some don't think the proposed SC meets the original intent.

<kirkwood> seems needs discussion

<Fazio> that's unfortunate

Chuck: Should we defer consideration until Silver?

<Fazio> we are all for it in COGA

<kirkwood> Defer it

alastairc: We've been through many forms of this, and can't seem to be able to settle on one.

<bruce_bailey> +0 okay with deferring

Rachael: My own personal opinion: I think this really fits Silver criteria, but keep the momentum going for the Silver First Public Working Draft. I'd like to invite COGA to the next meeting to give them an opportunity to weigh in.

Chuck: We are going to defer this to the next meeting.

<JF> bye all

Summary of Action Items

Summary of Resolutions

  1. Re-work, re-word survey
  2. To do CFC to the larger group for standing consent for WCAG 2.2 draft publication
  3. A CfC to larger group for standing consent for WCAG 2.2. draft publication
  4. publish the conformance challenges doc as a FPWD
  5. Move the SC forward to public review. Remove the exception and add note about the exception.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2020/04/14 17:02:58 $

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/propsoal/proposal/
Succeeded: s/Alastiar/Alastair/
Succeeded: s/ eny/any/
Default Present: bruce_bailey, JustineP, ChrisLoiselle, alastairc, JakeAbma, sajkaj, Francis_Storr, Jennie, Fazio, PeterKorn, Judy, Pascal_Wentz, Rachael, stevelee, JF, Brooks, kirkwood, MichaelC, Laura, david-macdonald, Katie_Haritos-Shea, Gundula, jon_avila
Present: bruce_bailey JustineP ChrisLoiselle alastairc JakeAbma sajkaj Francis_Storr Jennie Fazio PeterKorn Judy Pascal_Wentz Rachael stevelee JF Brooks kirkwood MichaelC Laura david-macdonald Katie_Haritos-Shea Gundula jon_avila
Regrets: Charles Hall Nicaise D
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: Brooks
Inferring ScribeNick: Brooks
Scribes: ChrisLoiselle, Brooks
ScribeNicks: ChrisLoiselle, Brooks

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]