W3C

– DRAFT –
AGWG-2023-10-31

31 October 2023

Attendees

Present
alastairc, Bri, bruce_bailey, Chuck, dan_bjorge, dj, Francis_Storr, jeanne, kirkwood, Laura_Carlson, ljoakley1, Makoto, mbgower, Rachael, sarahhorton, scotto, ShawnT, tburtin
Regrets
Jennie Delisi, Justine, JustineP, tzviya
Chair
Chuck
Scribe
bri

Meeting minutes

I have to drop when we switch to breakout rooms so I can scribe

Chuck: thanks for joining! some are festive for halloween

Chuck: first topic, anyone want to introduce themselves?

Chuck: remember to present+

Chuck: any new topics?

Chuck: announcements: day light savings changes

Chuck: reminder clocks will be switching or have switched

Chuck: another, charter is in process. there will shortly be a call for participation

kevin: nothing else to add right now. big phrases like "soon" and "coming"

Chuck: any questions regarding charter?

Chuck: chairs, anything else?

WCAG 2 issues https://www.w3.org/2002/09/wbs/35422/wcag2x-backlog1/results

Chuck: first one, reviewing WCAG 2 issues. about 40 min

Chuck: any objections to sharing screen?

Chuck: sharing screen. first question is rewrite SCR37

Chuck: reading information

alastairc: stating Kantel isn't here and has points

alastairc: first is about focus others is about opening modal dialogues

alastairc: explained Francis's point

alastairc: reading the comments

Chuck: MichaelG asked if we plan to provide a working example

alastairc: I dont think so but we can. wasn't part of the previous one

Chuck: wilco has a comment. wilco can you summarize yours?

Wilco: summarizes his own comment

<Chuck> proposed RESOLUTION: ccept amended PR 3024 to address SCR

Francis_Storr: assign a number because it could be leapfrog to something else

<mbgower> I was thinking this could be linked to 2.4.3 Focus Order

Wilco: cool, so ignore second point

alastairc: on the relationship, system looks at understanding documents and creates links to techniques. It's not included in PR

alastairc: sorry it's a focus order

alastairc: i think it is sufficient

alastairc: does that help? Francis do you remember off hand?

Francis_Storr: no, more make it into HTML modal dialogue

alastairc: it's a sufficient technique that include things not required in WCAG

alastairc: is there an objection to this update?

alastairc: this will remove SCR37

Chuck: that's for Wilco?

alastairc: primarily yes

<mbgower> +1 to replace SCR37 with H## and to make it a sufficient technique for 2.4.3, situation 3

Wilco: Yes, personally

alastairc: have you looked at the original?

Wilco: if we put something new, we should look at the original

<Zakim> Chuck, you wanted to ask if we are making progress

Chuck: that's the question here. is this incrementally improving the technique

Chuck: perfection is desirable but let's not roadblock if there's improvement. but that's opinion

<alastairc> Old but live version: https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR37

Wilco: I'm concerned we are suggesting things that are requirements

Chuck: alastiar I can do a proposed resolution to see where we stand?

<Chuck> proposed RESOLUTION: Accept amended PR 3024 to update SCR37

alastairc: I'd like to narrow down what success looks like for this

Chuck: proposing resolution to update SCR37

<Chuck> +.5

Chuck: not jumping immediately, more a poll

<mbgower> +1

mbgower: can we make it rename and renumber?

Chuck: sure

<alastairc> +1, happy to continue work

<Wilco> -.5

<laura> +1 Agree in not letting the perfect be the enemy of the improving what we have.

<Chuck> proposed RESOLUTION: Accept amended PR 3024 to update, rename and renumber SCR37

<Rachael> +.5 - if changes can be made in the next two weeks, continue working

<dan_bjorge> -.5 - hard to judge without knowing the context in which it will be referenced

Chuck: Mike, is that what you had in mind? Hope it's clearer

<ShawnT> +1

mbgower: yep

<scotto> +1 - the current example is not a sufficient technique to make a proper dialog.

<bruce_bailey> +1

<Makoto> +.5

Chuck: judging there isnt a hard consensus here

alastairc: okay I'll follow up after the meeting

Adding why it is important to 2.1 SCs #3312

Chuck: no resolution. continue working it. advancing to question 2

Chuck: adding why it is important to 2.1 SC 3312

Chuck: reads description. 6 agrees, 1 wants adjustment

Chuck: gundula isn't on the call but wanted adjustment

Chuck: I'll start the conversation

Chuck: both target screen readers. I'm not sure I agree with this comment

Chuck: ummm Mike

mbgower: input ones, that is not listed in benefts section

<alastairc> +1, the idea behind input purpose was primarily for cognitive issues.

mbgower: I'm not sure AT's would surface

mbgower: several situations people point out benefits missing

<bruce_bailey> i agree that input purpose is not AT centric

mbgower: I don't think we should introduce things not in the understanding documents

alastairc: no I think we should rebut this so it is in the minutes

GreggVan: is it true that font is not mentioned in SE but we're mentioning in the brief?

mbgower: I can speak to that

<alastairc> The proposed in-brief for text spacing: https://github.com/w3c/wcag/pull/3312/files#diff-9aed7c10a9693b74332635ceaf20a22180d0814f0705774b6b2bca0733fb8e0c

mbgower: SE is about text spacing

GreggVan: if the understanding is poorly written, then instead of writing an inaccurate end brief, we should change the understanding then write an accurate brief

<Zakim> Chuck, you wanted to say that's not really what the in brief is intended to be

Chuck: the scope is more plain language, not a correction

<Zakim> alastairc, you wanted to comment on the intent and understanding doc

alastairc: the intent of text spacing is to allow people to override fonts

<alastairc> For example, a user may need to change to a wider font family than the author has set in order to effectively read text.

alastairc: success criteria test doesn't mention changing fonts but the intent does

<bruce_bailey> https://www.w3.org/TR/WCAG22/#text-spacing

mbgower: I was going to say the same thing

mbgower: I'm open to making the case that it should AT

<laura> +1 Alastair recalls correctly.

dan_bjorge: I want to express support for both

dan_bjorge: understanding doc does mention AT

dan_bjorge: font changes as motivation for the issue doesn't matter

<alastairc> Confused, it is, the only reason it isn't mentioned in the SC text is because that isn't how you test it.

GreggVan: I agree. Doesn't matter what the orignial motivation for SC

GreggVan: you can't put something in the understanding doc that isn't in the SC

GreggVan: if it's not in the SC, it shouldn't be in the understanding doc and if it is needs to be flagged and fixed

GreggVan: those things are clearly AT. I would like to understand what "skeptical of AT" meant

<Zakim> alastairc, you wanted to say we could figure out how to do it, and did it.

alastairc: I'll leave that to Mike. pushing back on "didn't know how to do something"

alastairc: main intent was to allow people to override fonts

alastairc: just because success criteria doesn't mention it, don't think it's a valid reason to not include it

<Zakim> mbgower, you wanted to say that the Understanding document's Intent section often addresses concepts beyond normative text

mbgower: original 2 rows, now covered by what author is doing, what SC requirements, those are directly addressing norm of text

mbgower: third is user benefit and intent

mbgower: thiks it's legitmate to look at understanding doc and see what is addressed there

<alastairc> The proposed text for this is "Why it's important: Some people need text with different spacing or fonts."

mbgower: skeptical comment, what meant: need to make sure there is a case AT is included in the benefit section

mbgower: I'm already in process of adding it to new issue and go back and look at understanding document

GreggVan: correct me if wrong, if I write that it is impossible to change font, I will pass SC but will fail understanding?

GreggVan: understanding will say I can change font

GreggVan: understanding doc saying we can change font is not accurate. am I correct or wrong?

mbgower: reads the last line of understanding doc

<alastairc> I think there's a different between "AT" that we typically refer to, and the AT that would be used to benfit from 'identify input purpose'.

GreggVan: clarifies how he understood what was read

mbgower: that's not what summary says

<Zakim> bruce_bailey, you wanted to say SC 1.4.12 uses "font" repeatedly. Understanding not requiring change of font face / font name -- just font characteristics.

<GreggVan> +1

<Zakim> alastairc, you wanted to comment on overriding fonts

<mbgower> <dt>Goal</dt><dd>Users can adjust text spacing to make it easier to read.</dd> <dt>Author task</dt><dd>Ensure content adapts to user-defined text settings.</dd> <dt>Why it's important</dt><dd>Some people need text with different spacing or fonts.</dd>

<laura> +1 to bruce

bruce_bailey: I think we can say "font characteristics"

alastairc: time we wrote it, we had a discussion about if it's possible to prevent users from overriding fonts

GreggVan: yes plus one to Bruce

<mbgower> I have that in as a suggestion, and can make it so

GreggVan: the understanding doc talks about the probability but if you add "characteristics" to the summary, that should solve it

<Chuck> proposed RESOLUTION: Accept amended PR 3312 ("in brief")

GreggVan: responds to the comment on the use of AT

Chuck: proposes resolution

Chuck: accept ammended PR 3312

alastairc: what is the ammendment?

mbgower: it is already in there

<alastairc> Last bit ammended to: "Some people need text with different spacing or font characteristics."

<laura> +1

<alastairc> +1

<bruce_bailey> +1

<ShawnT> +1

<dj> +1

<GreggVan> +1

<Francis_Storr> +1

<sarahhorton> +1

<kevin> +1

<dan_bjorge> +1

<Chuck> +1

<Wilco> +1

<mbgower> +1 I'm also adding the other comment on input to omnibus issue

<Makoto> +1

+1

<tburtin> +1

Chuck: any concerns?

<Chuck> proposed RESOLUTION: Accept amended PR 3312 ("in brief")

RESOLUTION: Accept amended PR 3312 ("in brief")

Chuck: we have 6 minutes left. either sneak peek or quick resolution for #3333

Chuck: read description

Chuck: Gundula had comments

alastairc: I don't understand her first comment

alastairc: if something is open and receives focus, it can't obscure focus

scotto: just clarity. there's use cases when you open something and focuses goes into it. that's not true for everything

scotto: not everything opened by user will receive focus. whether it should is a different topic

GreggVan: difference in term "usually" and "never"

GreggVan: you can't have a usually followed by a never

Chuck: I didn't read it that way. technical semantics I am agreeing with

<alastairc> The specific area Gundula seems to be commenting on: https://github.com/w3c/wcag/pull/3341/files#diff-a1e686474a9da05fc533ce56cd7a154aa4c12cbbf42591ac35b181ea0ea57f84R126

GreggVan: agreed with how Chuck read it

alastairc: yeah this specific area doesn't say "never"

scotto: while focus may move into an element, there are use cases when it doesn't dismiss focus automatically

GreggVan: this is a note in the SC so we can't tweak it correct?

alastairc: we are in the understanding but it is explaining a note in SC

GreggVan: if we do the "if, then" approach, that will make things clearer

<Zakim> Chuck, you wanted to assess where we are at

<alastairc> If this isn't agreed: "allows for user-opened content to obscure the item receiving focus, provided the user can bring the item with focus into view using a method that doesn't require navigating back to the user-opened content to dismiss it."

<alastairc> Then we need to re-group on it on Friday.

Chuck: I'm assessing where we are because we are at time

alastairc: what Scott said, it sounds like we aren't agreeing with the statement in the understanding doc. If true, we need to regroup on Friday

alastairc: basically, if you open something that obscures, it's okay if you can go back and dismiss it. Scott is this what you are concerned?

scotto: I'm fine with the text written. But I had heard it would be okay if someone had to move back to the obscured element

<Chuck> proposed RESOLUTION: Accept PR 3341 to address issue 3333

Chuck: I'm interpreting that Gundula isn't getting a lot of support on her concerns so this is fine?

alastairc: I think so. I will ask Gundula

<Chuck> +1

<bruce_bailey> +1

Chuck: resolution to accept 3333

<scotto> +1

<laura> +1

<ShawnT> +1

<dj> +1

<alastairc> +1, I'll circle back to Gundula

<Makoto> +1

<dan_bjorge> +1

<Francis_Storr> +1

<sarahhorton> +!

RESOLUTION: Accept PR 3341 to address issue 3333

<sarahhorton> +1

Chuck: last opportunity?

Chuck: so resolved

<mbgower> For the record, I added the two input purposes to the issue on Understanding documents w3c/wcag#3429

<Chuck> Scribing ends here, as group will do exercises

<Chuck> Pointer support scratchpad: https://docs.google.com/document/d/1Y9ihiYAgLfR83Cu6phRuPTcBr3N9Kr_uFD9cGuxpsgc/edit#heading=h.txiccm4cn4nl

<Chuck> Clear Purpose scratchpad: https://docs.google.com/document/d/1KhzQdfr3yGHEIWLva-SLahFNk6K6YlrUqJNkANOv0FA/edit#heading=h.xbv57ky3kd2

<Chuck> Prevent Harm: https://docs.google.com/document/d/1S9K4i0CAiTHCWXD0_LnpS90E2l9VC_Xs18UmOXhGzaw/edit#heading=h.t3uqwwnk7ffi

<Chuck> alastair and Rachael, are you wrapping up? Can I close the rooms?

Summary of resolutions

  1. Accept amended PR 3312 ("in brief")
  2. Accept PR 3341 to address issue 3333
Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Succeeded: s/characterisc/characteristics/

Succeeded: s/about if it's possible to let users override fonts/about if it's possible to prevent users from overriding fonts

Maybe present: GreggVan, kevin, Wilco

All speakers: alastairc, bruce_bailey, Chuck, dan_bjorge, Francis_Storr, GreggVan, kevin, mbgower, scotto, Wilco

Active on IRC: alastairc, Bri, bruce_bailey, Chuck, dan_bjorge, dj, Francis_Storr, GreggVan, jeanne, kevin, kirkwood, laura, ljoakley1, Makoto, mbgower, Rachael, sarahhorton, scotto, ShawnT, tburtin, tzviya, Wilco