<Chuck> meeting: AGWG-2023-06-27

<ChrisLoiselle> I can do it but need to drop at 10 to hour for another call.

<ChrisLoiselle> scribe : ChrisLoiselle

Announcements

Chuck: Next week is July 4th. US holiday. No AGWG call.
... you can review issues and proposals.
... any updates from subgroups?

Shadi: Policy makers sub group met yesterday. Transitioning from phase 1 to 2. Use cases document extraction. Looking in to guidance document.
... Prior WAI work on standards harmonization. We are looking at planning and managing guide and roles and responsibilities mapping. Looking broader than use cases. Scope to be a bit broader on good practices in policy adoption.

Review schedule and upcoming subgroups (20 minutes)

Chuck: shares AGWG schedule for summer (June, July and August)

Rachael: This is tentative. This week we want to start content subgroups on guidelines.

<Chuck> Here is the proposed schedule: https://docs.google.com/document/d/1dMUwBqq5LYintI5xF5s3u6jTNnhb43PuQwR8-8kMSZU/edit

Rachael: July 6th targeting WCAG 2.2 to PR

<Chuck> :-)

<Wilco> Subgroups planned: Content order, Harm from motion, Timing and interruptions

<dj> s/$/and Charles/

Rachael: Github centered process to be started in July with focus on two subgroup topics , error notification and clear language
... WCAG 3 update , Fallback date for WCAG 2.2. is July 11th and meeting overview of new process.
... July 18th - meeting start of AG review for WCAG2ICT for FPWD
... August 10th WCAG 2.2 publication , fallback 17th
... August 17th new charger for AG starts . Silver taskforce ends and WCAG 2.x taskforce starts.
... Github roll out and training in August as well. August 31st new charter and concentrating on WCAG 3 topics.

Chuck: Any questions?

WCAG 2.x backlog issues, 7 questions https://www.w3.org/2002/09/wbs/35422/wcag2x-backlog1/

Question 1 - Is static content in tab order a failure of 2.4.3? #1572

Chuck: Backlog issues for WCAG 2.x . We are concentrating on WCAG 2.x now on the call.
... Will go through in traditional manner. Reads 1572 and shares results on Zoom.
... talks to 18 agreed with update and 3 with adjustments.

AlastairC: I think Gundula's response was that it should be phrased shorter. Comments from Andrew are in PR and we can review after comments.

Chuck: Reads Oliver's comments. Focus order follows reading order.

Oliver not on call.

<alastairc> I wasn't sure if Oliver's comment was an addition or change, or something else.

Chuck: Reads Gundula's comments on shortening.

Gundula: One line of column 1 then column 2 then column 1.

AlastairC: it is focus order so it would be interactive elements than reading order. Reading across columns would fail meaningful sequence vs. focus order.

Gundula: Jumping back and forth between the columns reads that way for me.

AlastairC: illogical order and relationship could be there, however you'll be reviewing two columns of text with links in them. There is no particular order to follow. Wouldn't be a fail if you went down right hand column first then left hand second.

<alastairc> For Jennifer's comment - that would be a new issue on focus-visible / focus-appearance rather than this one.

<Chuck> https://yatil.net/blog/wcag22-visible-focus

Chuck: Jennifer S. commented on survey, Chuck reads survey comment.

talks to focus visible and references Eric E's work on visible focus.

<AWK> +AWK

AlastairC: I didn't see a useful way of shortening. I also think that Jennifer's recommendations would be separate issue from this survey result.

<Francis_Storr> https://github.com/w3c/wcag/pull/1643/files

Francis: I agree with update. I want to query on the code example that Patrick referenced.
... Nesting a link inside a button and vice versa. In the code sample that Patrick mentioned, it shows that it fails. Focus elements and nested elements within it.

his example fails, does the other of link inside a button and vice versa fail?

Chuck: If it visually appears as one vs. the other, I have been failing as 4.1.2 name role value.

Francis: On the wording of focus order I wanted to clarify you can fail under there.

AlastairC: If you have one functional thing but two focus stops but one functional component that would be the fail that Patrick is raising.

<AWK> +1 to alastair's interpretation

AlastairC: if the both functionally work that I don't think they'd be failing this.

<Wilco> AGWG approved this ACT rule on the subject: https://www.w3.org/WAI/standards-guidelines/act/rules/307n5z/

Lori: Nesting and tabbing , keyboard functionality , tab in to element after focus is on component and there is nothing there.

AWK: It is ok to access to static content vs. the tabbing to div that contains a link , you can't interact with div, but you can interact with link.
... I am questioning on whether that is a failure or not.

Ben: Button within link, link within button. 4.1.1. parsing is where I usually had failed that. HTML4 button within link was not recommended.
... talks to Accessibility Trees and programmatic aspects on failing against 4.1.2

<Zakim> alastairc, you wanted to comment on the wrapped exampe

<Wilco> @Ben, you can't in Safari, and depending on which roles are nested not in Firefox

AlastairC: If the control receives focus multiple times, that is illogical territory . Achieving function vs. not.

<Ben_Tillyer> Thanks Wilco for that info

MikeG: I think we can add to this for more examples. We've seen this problem in that user is tabbing by keyboard and nothing happens on page. That is use case. If tabbing 20 times and nothing happened, that would be a failure.

if happens 2 times, I'd flag it but it would be a degree sliding scale problem.

<Wilco> Alatair, yes, nested controls fails the "Element with presentational children has no focusable content" ACT rule

MikeG: I think Patrick has done great work on how we are looking at this for keyboard users.

<Zakim> Chuck, you wanted to say that's probably a different topic

Chuck: Is it a link or button topic is a passionate topic but I believe this outside of the direct conversation we are having.

AlastairC: AWK's comment on adding term of necessarily to the phrasing.

AWK: With WCAG 2, focus order being defined... we need focus to preserver meaning and operability.

<mbgower> "If a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability."

AWK: a correct order needs to be followed. May not be a uniform order. Difference in reading order per culture or different interpretations
... focus order is following a visual order. Point I was trying to make is that focus order is meant to follow visual presentation.
... uses links at top of page and out of order tab order and focus.
... original question was on non interactive elements receiving focus

Chuck: I can live with this . preference to avoid confusion and have that be taken out.

<GN015> +1 to chuck

AlastairC: This PR also closes 1572 and 2655
... if people aren't objecting to it, we could accept it.

AWK: I need to review other issues to determine.

<alastairc> The other issue: https://github.com/w3c/wcag/issues/2655

Rachael: I think clarification is helpful. I think there are situation on user testing that breaking visual order is helpful. I think it does have benefits in clarity.

<AWK> Can you share those examples, Rachael?

Chuck: to AWK, on other issue 2655 . Did you want to take time outside of this call?

<Rachael> Examples: Training slides where next is visually to the far right and would require tabbing through previous, help, etc before getting to it even though it is the most frequently clicked button

AWK: I am looking at the issue https://github.com/w3c/wcag/issues/2655

other is 1572

<Rachael> and placing the link to the descriptive transcript or audio description visually below a video but programatically before the video.

<Chuck> I think that's 2655

AWK: Which is the one that is addressing the visual order of page point?

<dan_bjorge> agree, neither of those is talking about following visual order, both of those are talking about focusable static stuff

AlastairC: I believe 2655.

AWK: 1572 seems identical to the other.

Chuck: I think reviewing further and taking up for another day is worthwhile.

AlastairC: We can wait or we can push the changes proposed.

MikeG: Why not pull that line out from pull request and track separately ?

<AWK> lines 56 and 86 are where this statement is made, FYI

Chuck: With removing the line, I would need to make sure what we are updating with the PR.

Dan: I don't think anyone is disputing the issue that the PR is covering.

<Chuck> don't vote on this yet: RESOLUTION: Accept amended PR 1643 to address issue 1572 & 2655

Dan: I have seen cases where logical order and reading order is not aligning but positively impacts users. I am supporting focus order not following visual order.

<AWK> Also, we don't (and probably can't) define "visual presentation order", which makes evaluating something against visual presentation order difficult

MikeG: Does AlastairC have ability to bring up a proposed update without line 86 and 56 (per AWK)

<alastairc> https://raw.githack.com/w3c/wcag/patrickhlauke-understanding-focus-order-note/understanding/20/focus-order.html

AlastairC: the for clarity would be updated thus the numbered list would be re numbered .

MikeG: I think cross referencing is worth while .

Chuck: Push back for review with feedback needed.

AlastairC: Talks to lines needing update. Was it just the full clarity aspect?

AWK I think the clarity section then the paragraph above.

AWK: What is the visual presentation of the web page? How is that defined.

We seem to talk to both sides of the issue focus order and particular order vs. visual order.

<Zakim> mbgower, you wanted to say I may have a useful suggestion

AWK: I am unsure of if this is responding to a comment or addressing something else.

MikeG: On Gundula's comment on two column presentation, I agree that is not a good example. Perhaps a page with left nav and top nav.
... focus order and logical order of focus.

vertical vs. horizontal nav

<Zakim> Rachael, you wanted to say top to bottom and left to right may be cultural

Rachael: Directional top bottom and left right may be cultural.

<Zakim> Chuck, you wanted to ask for scribe change

Lori: +1 to Rachael's comment. Also want to point out "drawers". Side or bottom components like drawers. Add ons on top of page.

<mbgower> scribe: mbgower

<ChrisLoiselle> Thanks!

Chuck: There seem to be two different concepts. One is the change is significant and needs to be pushed back. The other is folks want to keep talking about it.

Question 2 - Understanding for Contrast does not call out Color Blindness #2033

Alastair: Some comments around "visual order" assumptions. We can move onto the next one

Chuck: Bruce proposed PR 3240 to add colour blindness concepts.

Alastair: I'd like Bruce to take us through the updates.

Bruce: I'm happy to try to do that.
... This should be a relatively minor update.

<bruce_bailey> https://github.com/w3c/wcag/blob/main/understanding/20/contrast-minimum.html

Bruce: That's the current url

<bruce_bailey> https://github.com/w3c/wcag/blob/issue2033_patch_sc143_understanding/understanding/20/contrast-minimum.html

Bruce: And that's the most recent one.

<bruce_bailey> https://github.com/w3c/wcag/pull/2034/files

Bruce: I'm going to walk between the two of them and what has changed.
... It looks like more than it is because of some formatting changes. I think I've addressed some comments well. Line 14 on the original file and line 16 on the update.
... I introduce the term "colour blindness".
... One thing that was not controversial was adding in an outside reference.

<dan_bjorge> I think it's easier to review both PRs together - this link gives a view of that (at the bottom, after the list of commits): https://github.com/w3c/wcag/compare/main...issue2033_patch_sc143_understanding

Bruce: I did a PR on top of a PR because I was trying to call the edits on top of the edits. That didn't work well.

<bruce_bailey> https://github.com/w3c/wcag/pull/3240/files

Bruce: There was a bit more discussion but I don't think anything substantive
... There was one grammar issue. There was a suggestion of a more technical sidebar, which I don't think makes sense for this update.
... "Colour blindness" is a colloquial term that is useful to mention.
... I wanted to take this in a couple of stages to address comments from a few weeks ago.

Chuck: Any follow up Alastair?

Alastair: I think it's good to go through some of the comments.

<Zakim> Chuck, you wanted to say I'm concerned about the technical side bar

Alastair: I was trying to figure out how to integrate Andrew Sommers comments.

Chuck: It's a fascinating comment on the science of perception. We could go down the rabbit hole, but i think the approach by Bruce is sufficient.

Gregg: Just a quick comment. We have people concerned with "colour blindness". As most people know, most people who are blind are able to see somewhat, and it doesn't mean that someone who is 'colour blind' cannot see colours.

[Chuck reads comments]

Gundula: I cited only for context. The change is only in the last sentence.

Chuck: Any possibility you can summarize your response?

Dan: Yes, basically what Andrew says.
... Andrew is more of an expert than I am, but his suggestion seemed more concise and accurate.

<Zakim> bruce_bailey, you wanted to paste in two paragraphs in PR3240

Bruce: I'd like to paste into IRC the first paragraph of intent.
... I don't think that's controversial

Alastair: The one I'm showing now (lines 16-23) is a combination of both PRs.

<alastairc> https://github.com/w3c/wcag/compare/main...issue2033_patch_sc143_understanding

Alastair: My comment was that I struggled with Andrews. The first paragraph is good.

<Zakim> GreggVan, you wanted to say we should use Color vision difference -- rather than "deficiency" Suggest we say "color vision differences, often referred to as

Alastair: The rest is going beyond... I didn't find it useful or understandable. We have lots of alternatives, and I think we need to find the balance between concision and accuracy.

<Rachael> +1 to wordsmithing session

<jaunita_george> +1

Gregg: I'd like to stay away from "defiency"

<Chuck> +1 to Gregg on luminance and luminosity

Gregg: We also need to be careful on controlled luminance in our conversations. The two words don't mean the same thing (luminance and luminosity)

Chuck: It looks like there's a sentiment to work on wordsmithing, and outside this call.

Alastair: This seems like a good Friday session to work on, and try to come back with one thing.

Question 3 - Separate techniques for Target Size #3231

Chuck: We have 3 agreeing and 6 wanting adjustments

[Chuck reads out responses]

Gundula: I meant "even more" not "even ore"

Francis: Patrick's feedback I've fixed. It was a good point.
... C42 has been around for years, but has not been attached to a criterion. I have slightly separated out C42 and the new one based on some of those comments.
... I noticed Dan had comments I hadn't looked at yet. I didn't want to muddy the waters further.

Alastair: I think the comments have been quite specific. I think it's straightforward stuff to go on with. If we're suggesting C42 should be for AAA and the new one should be the AA minimum, I think that should be fairly straightforward updates.

<Chuck> propose RESOLUTION: Accept amended PR 3231 to address issue 3231 and review in list

Alastair: I think we can agree to update those and publish. I don't think this needs more meeting time.

<Chuck> proposed RESOLUTION: Accept amended PR 3231 to address issue 2433 and review in list

<Chuck> +1

<Francis_Storr> +1

<garcialo> +1

<bruce_bailey> +1

<jaunita_george> +1

<corey_hinshaw> +1

<alastairc> +1

<LoriO> +1

<laura> +1

<ShawnT> +1

<dan_bjorge> +1

<Detlev> +1

+1 Francis will figure it out :)

RESOLUTION: Accept amended PR 3231 to address issue 2433 and review in list

Question 4 - Adding brief descriptions for all WCAG 2.0 A and AA requirements, understanding docs

Chuck: 11 people have approved.

<Chuck> mbgower: I've been reviewing comments. I've been thumbs up that which I agree with, and adding questions to others. They are all useful.

<Chuck> proposed RESOLUTION: Accept PR 3219 to add brief descriptions for all WCAG 2.0 A and AA requirements

Alastair: I think it's just a case of Michael responding to all of those and replying. I think we're good to publish after that.

Gundula: I felt that there were several things not finalized. Is it ready for resolution?

Chuck: There doesn't seem to be anything controversial. If you feel like there are, we can consider.

Gundula: I haven't seen a response to my question on simple versus single pointer.

<Chuck> mbgower: I'm not sure I saw that, but I can have a look at it.

<Chuck> alastair: Think it's on dragging movements.

<Chuck> mbgower: Maybe confusing. A double click would be fine. I think that's probably fine.

<Chuck> mbgower: It's asking for... I can look into it. We are asking for a simple pointer alternative. You can provide other ways. I'll have a look.

<Chuck> gn: It was intentional?

<Chuck> mbgower: Reads ok as is.

Gregg: "Simple" I think is a correct word, not "Single".
... A complex interaction is not what we're looking for.

<Zakim> alastairc, you wanted to comment on the pointer thing

Alastair: I agree that simple is a good word.
... It might be worth another look.

<Zakim> Chuck, you wanted to ask if we should wait for Mike's updates and then re-review in list?

Alastair: Similar to before, Mike can review and respond to comments. If anyone has concerns we can bring back or otherwise accept.

<Chuck> proposed RESOLUTION: Accept PR 3219 to add brief descriptions for all WCAG 2.0 A and AA requirements and review in list

<Chuck> proposed RESOLUTION: Accept amended PR 3219 to add brief descriptions for all WCAG 2.0 A and AA requirements and review in list

<Chuck> mbgower: This is the first round, I'm working with education outreach team. This is a first phase.

+1

<jaunita_george> +1

<laura> +1

<alastairc> +1

<bruce_bailey> +1

<dan_bjorge> +1

<garcialo> +1

<Chuck> mbgower: Treat this as any iterative update to the understanding. The next iteration can build on this. The more we add on, the harder it is to review everything.

<Chuck> mbgower: EOWG may offer some changes. We know that we worked from this language before...

<Chuck> lori: Makes perfect sense.

<GN015> +1

RESOLUTION: Accept amended PR 3219 to add brief descriptions for all WCAG 2.0 A and AA requirements and review in list

<LoriO> +1

Chuck: We will not be having a call on July 4 but will resume on July 11

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)

FAILED: s/$/and Charles/
Default Present: Chuck, dj, ChrisLoiselle, Rachael, Ben_Tillyer, Wilco, Jennie, GreggVan, shadi, ShawnT, Francis_Storr, dan_bjorge, mgarrish, bruce_bailey, corey_hinshaw, kirkwood, MichaelC, sarahhorton, mbgower, Laura_Carlson, AWK, LoriO, Detlev, GN, jaunita_george, alastairc
Present: Chuck, dj, ChrisLoiselle, Rachael, Ben_Tillyer, Wilco, Jennie, GreggVan, shadi, ShawnT, Francis_Storr, dan_bjorge, mgarrish, bruce_bailey, corey_hinshaw, kirkwood, MichaelC, sarahhorton, mbgower, Laura_Carlson, AWK, LoriO, Detlev, GN, jaunita_george, alastairc, GN015
Regrets: Makoto Ueki
Found Scribe: ChrisLoiselle
Inferring ScribeNick: ChrisLoiselle
Found Scribe: mbgower
Inferring ScribeNick: mbgower
Scribes: ChrisLoiselle, mbgower
ScribeNicks: ChrisLoiselle, mbgower

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.)