W3C

- DRAFT -

AGWG Teleconference

09 Feb 2021

Attendees

Present
Nicaise, Rachael, Rain, ChrisLoiselle, Ben, Francis_Storr, Chuck, Fazio, GN, JakeAbma, Caryn, juliette_mcshane, stevelee, alastairc, kirkwood, mbgower, Detlev, Laura_Carlson, MelanieP, KarenHerr, Sukriti, JF, AWK, jon_avila, Jemma, !, StefanS, OliKei, Raf, GN015
Regrets
Matthew O, Sarah H, Andrew K, Justine P
Chair
SV_MEETING_CHAIR
Scribe
ChrisLoiselle, mbgower

Contents


<Rachael> Our scribe list is at https://www.w3.org/WAI/GL/wiki/Scribe_List

<ChrisLoiselle> scribe:ChrisLoiselle

:)

Inclusive language reminder

Chuck: We are moving to using more inclusive language for various reasons. Please monitor and address issues as they arise, so we can all work better and be more inclusive.

Please allow people to finish a topic of conversation, then present your thoughts in relation to that topic.

It is a work in process, so over time we will all get better at using inclusive language.

Discuss acknowledgements criteria https://docs.google.com/document/d/1Joc5F6YfYPDOK5ryBUsPVP-xUtrrhoQ2Uf7iKGpbLnM/edit

Rachael: I also invite critique.
... Speaks to acknowledgements criteria and places link in IRC.

People can be listed in multiple areas , based on contributions.

We are open to feedback and critique on these areas

Chuck: We are trying to identify where participation was made and acknowledge it as it should be.

Jeanne: I am here to answer questions.

<Zakim> mbgower, you wanted to say are we doing something similar in 2.2?

MikeG: Are we doing this with WCAG2.2 and WCAG3?

Rachael: As of now, WCAG3 . We can have that conversation if we need to for WCAG 2.x

WCAG 2.2 Dragging (Q 1-3) https://www.w3.org/2002/09/wbs/35422/wcag22-dragging-issues/results

Rachael: We will send this out to CfC call for consensus and respond appropriately.

Dragging and its reference to single pointer #1225

<Rachael> 2.5.1 Pointer Gestures (Level A): All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

<Rachael> single pointer: pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures

Rachael: Dragging is next topic . For pointer gestures, there is an issue regarding single pointer and path based gestures.

Discussion was around glossary terms and improving for clarity.

<Rachael> https://github.com/w3c/wcag/pull/809/files

Rachael: Places in pull request (PR) which changes definition.

Gundula: I see path based gesture in definition still.

I.e. half circle or swipe is a path based gesture. It doesn't seem possible to avoid it.

AlastairC: Two Success criteria were referencing it before. Now we have a third success criteria. Why it mattered is the key question to address. Why is pointer cancelation needs path based gestures within it.

<AWK> +AWK

To Gundula's point, the change removes it from first paragraph. The second paragraph should be marked as examples.

<Zakim> mbgower, you wanted to say I can address, a bit

<JakeAbma> might this one help?

<JakeAbma> https://github.com/w3c/wcag/issues/746

MikeG: It terms of 2.5.2 Success Criteria's use, no part of this is executed on down event. If click and action, down and up would be included in a drag. The intent was to capture gesture in logic flow.

I think makes sense to include in drag or path based where drag and then release.

I'm ok with changes within definition. It is talking to what a single pointer is. It may make it less confusing, which is the goal.

<AWK> +1 to Mike.

Jake: I don't recall the summary. We had multiple conversations around it, so placed the issue link in IRC.

AlastairC: If we updated definition, does anyone think this is not compatible with the current Success Criteria?

MikeG: We do say directional , but I don't see changing, just making it clearer for understanding.

AWK: Expansion of single pointer definition - The including of triple finger path based gesture may be confusing. For Single pointer, it is not addressing the core of what we are trying to define. May cause more confusion.

If it is considered right at moment, why are we changing it?

If we want to make it simpler, but a period after screen. The longer paragraph version would make it harder to digest.

<mbgower> "...screen. Examples include single...."

Rachael: I was inclined to not change.

I am fine if that is definition for group.

AlastairC: 2.5.7 linking would be relevant.

MikeG: "...screen. Examples include single...."

Talks to single taps, etc.

<Rachael> pointer input that operates with one point of contact with the screen. Examples include single taps and clicks, double-taps and clicks, long presses, and path-based gestures

AWK: Mike, one point of contact on screen, examples include... may lead to single tap is a single pointer operator. What we want to say is single pointer can be used to make "X"

Rachael: I am not sure if that addresses Patrick's concern.

AWK: I thought we said it was not a conflict.

<jon_avila> I don't perceive a conflict either.

Rachael: that is what I thought as well.

AlastairC: I don't think anyone on call thinks there is a conflict.

MikeG: We have 3 SCs talk about same thing, you need to read a lot to discover the changes.

<Rachael> Straw poll: Option 1 - No change; Option 2 - Slight change; Option 3 - Remove everything after includes; Options 4 - Substantial edit to definition

<JF> +1 to DAvid - subtle but correct

<mbgower> we do :)

DavidM: A path based gesture is a communication of what you are trying to . Perhaps talk to the dragging definition rather than going back to the older one.

MikeG: Dragging definition talks to NOT going through a intermediary point.

<alastairc> Dragging: an operation where the pointer engages with an element on the down event and the element (or a representation of its position) follows the pointer

<Rachael> https://www.w3.org/TR/WCAG22/#dfn-dragging-movements

<AWK> <p>pointer input that operates with one point of contact with the screen. <p class="note">Single taps and clicks, double-taps and clicks, long presses, and path-based gestures are operations that can be performed with a single or multiple point of contact with the screen.</p>

<alastairc> We didn't end up defining 'path based gesture', except (sort of) in the understanding doc.

Rachael: We are now talking about dragging.

AlastairC: We talked to it in understanding, but didn't have a specific definition for path based gestures.

Gundula: Are we talking to current definition or pull request?

Rachael: I will update the straw poll question.

Gundula: How do we find the extra period introduced in call to what we can review?

<Rachael> Straw poll: Option 1 - No change to definition; Option 2 - Slight change to definition; Option 3 - Remove everything after includes; Options 4 - Substantial edit to definition; Option 5: adopt pull request; Option 6: ...screen. Examples include single....

DavidM: You can take me off, I'll write up something to understanding for path based vs. drag and drop.

<mbgower> 1

<david-macdonald> 1

<GN015> 6

Rachael: We have six options for straw poll, please review and put number you are leaning towards.

<laura> 1

<AWK> 1

<JF> 1

<Rain> 1

<juliette_mcshane> 1

<alastairc> 2, but happy with 1

<MelanieP> 1

<Chuck> 6, but happy with 1

<kirkwood> 1

<Rachael> 1

<Francis_Storr> 1

<Detlev> you have lost me... too many options... happy with any

<Sukriti> 1

Chuck: I can live with option 1.

<JakeAbma> 1

AlastairC: I can as well.

Gundula: I can also live with it.

Rachael: Who will take the action to update the response?

DavidM: I can take first pass and send back to Chairs for review.

Rachael: Thanks, yes please.

<Rachael> proposed RESOLUTION: Keep the definition as is, amend PR to update understanding, and draft new response.

<Chuck> +1

<Ben> +1

<laura> +1

<Rain> +1

<kirkwood> +1

<Detlev> +1

<Nicaise> +1

<Francis_Storr> +1

<mbgower> +1

<JakeAbma> +1

<JF> +1

<KarenHerr> +1

<MelanieP> +1

<Sukriti> +1

<GN015> +0

<david-macdonald> +1

RESOLUTION: Keep the definition as is, amend PR to update understanding, and draft new response.

Dragging - essential example #1336

<Rachael> pull request: https://github.com/w3c/wcag/pull/1612/files

Rachael: Places link to pull request. Question is whether or not we can accept that.

Is Ben on this call?

BenT: I advise against using gesture based , i.e. e-signatures. I thought it went against gov.uk sites best practices etc.

<Zakim> alastairc, you wanted to ask for other examples...

<Rachael> drawing?

AlastairC: The issue was what examples could we provide. What would be essential and be included in dragging?

Rachael: Gaming and drawing be another?

AlastairC: The ink following your signature example.

<Rain> ?+

<alastairc> How is: "There may be cases where a dragging movement is essential, for example, drawing a free-form figure, or playing a game where the aim is to follow a particular path as accurately as possible."

Detlev: Circuit board construction kit and connecting kit. Is that consider dragging? I would say yes, but it SC would not cover anything else. There's also a drop target aspect on connection and construction scenario.

<mbgower> Drawing is the most obvious example of something essential, IMO

Rain: Why are we offering an exception at all in this case? I.e. on the finger follow movement and in between movement via keyboard or other modality?

Detlev: The point was that it is a pointer requirement. There is no way to meet it with keyboard. It was separate for that reason, i.e. the input device.

The connector scenario does not have anything to do with keyboard requirement, thus should be kept separate.

AlastairC: There are feasibility issues. You could imagine a pencil icon on screen and instead of drawing with a pencil, you'd press up down left right .

<Rain> This background helps, thank you

<Rachael> "There may be cases where a dragging movement is essential, for example, drawing a free-form figure, or playing a game where the aim is to follow a particular path as accurately as possible."

Rachael: Is there a way where we'd put the connector scenario in as an example?

AlastairC: I think it is covered in the understanding documentation.

MikeG: I have concerns on dragging, but will open separate issues.

<Rachael> proposed resolution: accept ""There may be cases where a dragging movement is essential, for example, drawing a free-form figure, or playing a game where the aim is to follow a particular path as accurately as possible."

<Ben> +1

<Detlev> +1

<Francis_Storr> +1

<juliette_mcshane> +1

<Rachael> +1

<mbgower> +1

<JakeAbma> +1

<alastairc> Updated here: https://github.com/w3c/wcag/pull/1612/files

<Rain> +1

<Nicaise> +1

<Sukriti> +1

<alastairc> +!

<JF> +1

<Chuck> +1

<MelanieP> +1

<kirkwood> +1

RESOLUTION: accept ""There may be cases where a dragging movement is essential, for example, drawing a free-form figure, or playing a game where the aim is to follow a particular path as accurately as possible."

Google feedback on dragging #1454

<Rachael> Draft response at https://github.com/w3c/wcag/issues/1454#issuecomment-770486321

Rachael: Next topic is 2.5.1 and 2.5.7 examples and clarification on success criteria
... Are there any concerns with reply as written?

<Rachael> proposed RESOLUTION: Accept draft response to address issue 1454.

<Nicaise> +1

<Ben> +1

Please plus one if you agree with update to pull request.

<laura> +1

<Rachael> +1

<JakeAbma> +1

<juliette_mcshane> +1

<Rain> +0

<Detlev> +1

<Chuck> +1

<Francis_Storr> +1

<JF> 0

<Sukriti> +1

<kirkwood> +1

<Raf> 0

RESOLUTION: Accept draft response to address issue 1454.

WCAG 2.2 Accessible authentication (Q1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-accesssible-auth-updates/results

Rachael: To MikeG, please submit issues on dragging so we can review further as needed.

<Rachael> https://github.com/w3c/wcag/pull/1611/files

Rachael: Pull request with a response provided.

Gundula: When I see the suggested change, I feel that going into details first then talk to general secondary , I would swap those out . General then detailed.

AlastairC: First is how is this applying to captchas, then the second is that they don't always appear and noting that in regard to testing.

If testing , the captcha may not appear , etc. More testing then general applicability note.

Rachael: Do you a suggestion on taking in Gundula's point on the two sentences switching?

AlastairC: I think it makes sense either way.

Gundula: More of a suggestion than anything.

<alastairc> Current: Some CAPTCHAs and cognitive function tests used for authentication may only appear in certain situations, such as when ad blockers are present, or after repeated incorrect password entry. This criterion applies when these tests are used regardless of whether they are used every time or only triggered by specific scenarios.

Rachael: Is there a preference on order sentences?

<Rachael> proposed RESOLUTION: Accept PR 1611 and response to address issue 1256 with the paragraphs swapped

<Chuck> +1

<Rain> +1

<Sukriti> +1

<laura> +1

<Ben> +1

+1

<JakeAbma> 0

<Raf> +1

<GN015> +0 (sentences swapped, not the paragraphs)

<kirkwood> 0

FrancisS: This works for me.

<Rachael> proposed RESOLUTION: Accept PR 1611 and response to address issue 1256 with the sentences swapped

RESOLUTION: Accept PR 1611 and response to address issue 1256 with the sentences swapped

Thanks Mike!

<mbgower> scribe: mbgower

WCAG 2.2 Visible controls (Q1 only) https://www.w3.org/2002/09/wbs/35422/hidden-controls-12-2020/results

<Rachael> Pull request https://github.com/w3c/wcag/pull/1617/files

Gundula: In the answer, I missed a clear statement of "yes" to the question.
... Once the form of the page is in edit mode, you can change the focus indicator, so I didn't understand the use case.

Rachael: the example is based on an editor with an edit mode.
... We might need more clarification?

Gundula: Yes.

Ben: My concern has been addressed by AWK's update.

Rain: I'm curious if it would make sense to make the wording clearer on the goal.

Rachael: Is someone willing to suggest alternative language?

<Rain> I'm willing to do that if someone will introduce me to the process (since I'm new)

Alastair: For Gundula's first point answering 'yes', maybe I'm missing something?

Gundula: In issue 1455, the first SC is cited.

<Rachael> "clarify if the requirement for controls being “visible" also means that the control must not just appear on the screen, but also meet all other SCs that would affect visibility, like: meaningful sequence, sensory characteristics, and everything under distinguishable..."

Rachael: Does anyone object to adding a response to that question?
... Does anyone have any language they'd suggest for adjusting the examples?

Rain: I'm happy to take up trying to rewrite these examples, but would like some time.

<Rain> Very helpful, thank you

<Rachael> Proposed RESOLUTION: Add a sentence clarifying that the other SC apply and revise the example text within the broader context of the understanding (Rain)

<Rachael> proposed RESOLUTION: Add a sentence clarifying that the other SC apply and Rain will craft updates for issue 1455 and team will review in a subsequent call.

<Chuck> +1

<Ben> +1

<Rain> +1

<GN015> +1

<JakeAbma> +1

<Francis_Storr> +1

<Sukriti> +1

<david-macdonald> +1

<MelanieP> +1

<Rachael> +1

RESOLUTION: Add a sentence clarifying that the other SC apply and Rain will craft updates for issue 1455 and team will review in a subsequent call.

WCAG 2.2 Fixed reference points (Q1-2 only, Q1 is updated) https://www.w3.org/2002/09/wbs/35422/wcag22-fixed-ref-points-updates/results

<Raf> +1

UPDATED: Google feedback on Fixed Reference Points #1449

<Rachael> Pull request: https://github.com/w3c/wcag/pull/1619/files

Rachael: Concerns that this is very focused on epubs.

<Rachael> Draft response: https://github.com/w3c/wcag/issues/1449#issuecomment-772877790

Rachael: The PR includes a few suggested changes, including renaming the technique.

Alastair: I incorporated Mike's response in the currrent version.

Rachael: AWK's may also be an older response.

Alastair: The changes are to do with the Understanding document.

Gundula: In the issue itself, the SC is referred to.
... In the response, it refers to an updated version of the SC.
... I feel the Understanding needs to be changed, otherwise they are not synchronized.
... This will cause misunderstandings.

David: I think it's in the definition.

<Rain> Alastair - it looks like I do have access, thank you for checking

David: We've really tightened it up in the last iterations. If you are doing this, you have to provide a link. I think we can clean that up.

Alastair: I think we did a pass on the Understanding document to try to reduce it down to the SC.
... I'm struggling to see the unalignment between the Understanding document and the SC.
... We have made editorial updates, and are asking them to review it.
... We can make more changes without affecting our response.

Oliver: A page break is not something you necessarily see. I would use the same text as the Understanding text.

Alastair: It's understanding the scenario.
... If you are using a medium that doesn't have page breaks, these are invisible page break locators.

Oliver: As an end user, I'm looking for page numbers.

Alastair: If you are following this technique, you'd get page numbers, but they wouldn't necessarily align with where pages break in your ereader.

Gundula: 'Page break locators' might lead to confusion. What about using "Page locator"?

Rachael: Would the consistent use of "page locator" address your concern?

<Rachael> acl StefanS

Oliver: Yes

<StefanS> https://w3c.github.io/dpub-aria/#doc-pagebreak

Stefan: The dpub definition of pagebreak is worth mentioning

David: The term 'page break locator' came from the epub team. I agree I'd like to see it, but I'm concerned to change the specific language used by the team.

<Zakim> alastairc, you wanted to say page locator would be confusing

Alastair: if I was coming to it fresh, the term 'page locator' would indicate the mechanism to get somewhere, whereas we are talking about the target you are trying to get to .

Rachael: Would consistent use of 'page break locator' and its early definition help address this?

Alastair: I don't think this is aligned with the Google updates.

Rachael: Would consistent use of 'page break locator' help?

Alastair: I think this is a different issue than raised by Google.

JF: To the point that David raised, I believe in CSS, you have breaks before and after. So depending on your perspective, it's either 'before this' or 'after that'.

<Rachael> Three issues: 1) response to google, 2) match between understanding and SC text, 3) terminology "page break locator"

JF: In terms of understanding or interpreting a 'page break'.

<david-macdonald> we can add this to the SC understanding

<david-macdonald> https://w3c.github.io/dpub-aria/#doc-pagebreak

Rachael: I would like to suggest we have someone identify the match issues (#2).
... I'd like to have someone else look into the terminology.

Gundula: Do you envision a conversation on the list?

Rachael: Yes, on the list.

JF: Until we answer #3 - defn of page break locator, we can't respond to Google.

Rachael: Was your concern broader than the term?

Gundula: Yes.

<alastairc> Current definition: programmatic markers that are arranged in a meaningful sequence to determine the location of a page in relation to others in the set.

Rachael: Can someone tackle the 'page break locator' question?

JF: I'm just looking at what the average run of the mill developer has, and they have 2 CSS attribute values. Would they constitute a programmatic marker?
... They are for formatting. I don't know if they have any wayfinding function?

Alastair: They don't.

JF: Maybe we have to break the potential confusion.
... We should mention CSS being unaligned editorially.

Rachael: I'm looking for someone to take this on.

JF: I'll try.

<JF> ACTION: JF to work on disambiguation of page break and the CSS properties

<trackbot> Created ACTION-350 - Work on disambiguation of page break and the css properties [on John Foliot - due 2021-02-16].

Rachael: Please send it to the list. Others can jump in if you start the conversation.
... Going back to the response to Google, are there concerns with the response as it stands?

<Rachael> https://github.com/w3c/wcag/issues/1449#issuecomment-772877790

Alastair: There is a broad question in the initial bit around how it applies, what the scenarios are, possible research...
... A lot of the response and changes were to address that.

<Rachael> propsed RESOLUTION: Accept response and work on understanding and page break locator terminology

+1

<Ben> +1

<alastairc> +1

<JakeAbma> +1

<Raf> +1

<Chuck> +1

<Sukriti> +10ths

<Rachael> +1

<Rain> +1

<rboardman> +1

<Francis_Storr> +1

<GN015> +0.5

<kirkwood> +1

<JF> 0

RESOLUTION: Accept response and work on understanding and page break locator terminology

<david-macdonald> back

"on the same page" #1302

Alastair: I think this has already happened. I think we're done.

<Rachael> Proposed RESOLUTION: Accept previous change as solution to this. Now redundant

<david-macdonald> +1

<kirkwood> +1

<Rain> +1

<Ben> +1

<Chuck> +1

<Rachael> +1

<Francis_Storr> +1

<Sukriti> +1

RESOLUTION: Accept previous resolution as solution to this issue.

Alastair: We are at that pre-CFC stage. Please review issues.

Rachael: We will be dedicating the first part of our upcoming issues addressing WCAG 3.0 FPWD issues

Summary of Action Items

[NEW] ACTION: JF to work on disambiguation of page break and the CSS properties
 

Summary of Resolutions

  1. Keep the definition as is, amend PR to update understanding, and draft new response.
  2. accept ""There may be cases where a dragging movement is essential, for example, drawing a free-form figure, or playing a game where the aim is to follow a particular path as accurately as possible."
  3. Accept draft response to address issue 1454.
  4. Accept PR 1611 and response to address issue 1256 with the sentences swapped
  5. Add a sentence clarifying that the other SC apply and Rain will craft updates for issue 1455 and team will review in a subsequent call.
  6. Accept response and work on understanding and page break locator terminology
  7. Accept previous resolution as solution to this issue.
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.200 (CVS log)
$Date: 2021/02/09 17:40:39 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision VERSION of 2020-12-31
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/Gundulla/Gundula/
Default Present: Nicaise, Rachael, Rain, ChrisLoiselle, Ben, Francis_Storr, Chuck, Fazio, GN, JakeAbma, Caryn, juliette_mcshane, stevelee, alastairc, kirkwood, mbgower, Detlev, Laura_Carlson, MelanieP, KarenHerr, Sukriti, JF, AWK, jon_avila, Jemma, !, StefanS, OliKei, Raf
Present: Nicaise, Rachael, Rain, ChrisLoiselle, Ben, Francis_Storr, Chuck, Fazio, GN, JakeAbma, Caryn, juliette_mcshane, stevelee, alastairc, kirkwood, mbgower, Detlev, Laura_Carlson, MelanieP, KarenHerr, Sukriti, JF, AWK, jon_avila, Jemma, !, StefanS, OliKei, Raf, GN015
Regrets: Matthew O, Sarah H, Andrew K, Justine P
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: mbgower
Inferring ScribeNick: mbgower
Scribes: ChrisLoiselle, mbgower
ScribeNicks: ChrisLoiselle, mbgower

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: jf

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]