AGWG Teleconference -- 31 Aug 2021

<Chuck> meeting: AGWG-2021-08-31

<laura> Scribe: Laura

Chuck: any introductions?
... (none)
... any new topics?

Merge AGWG and Silver after delivery of WCAG 2.2: https://www.w3.org/2002/09/wbs/35422/2021-08-25-Merge/

Chuck: (none)

Survey on: Merge AGWG and Silver after delivery of WCAG 2.2

scribe: In last weeks (8/24/2021) Accessibility Guidelines Working Group meeting, we discussed merging the Silver taskforce into the AG working group.
... This survey is regarding the timing only. A plan on the number and scheduling of meetings, how to handle the community group, etc. will be brought to both groups for discussion and approval by the AGWG and Silver taskforce in the near future.
... Do you approve of merging Silver Task Force and the Accessibility Guidelines Working Group after delivery of WCAG 2.2?
... 17 people supported.
... one opposed.

<kirkwood> agree with Janina’s concerns in the survey

JS: what do we mean by delivered?
... when is 2.x delivered?

RM: we have not been through the full process yes.
... but it would be when approved through publication.

js: could take 90 days.

chuck: I don’t grock the process. It is milestone based.

<david-macdonald> is Michael C on the call? He would know.

<JF> +1 to Janina

chuck: want to make sure everyone is vested in the merge.

<Chuck> +1 to already part of group, and it's more normalization

jf: I voted positively on the survey. Question on community group. what are we going to do about that?

Merge AGWG and Silver after delivery of WCAG 2.2

RM: we need to work out the details. Lot of details. Want to work on the big question first.

jf: we have too many meetings now.

<Gregg> +

chuck: lot of approvals with commentary on the survey.

<jaunita_george> I haven't had a chance to take a look yet, sadly

GV: these are operating under 2 different charters, right?
... 3 is a task force. one is a WG.

<JF> Chaerter here: https://www.w3.org/2019/12/ag-charter

GV: make sure we are in agreement with the charter.

rm: silver is a TF. Long standing group.

<JF> From the Charter: Develop a new standard (name to be decided) to succeed WCAG 2.x based on the work of the Silver Task Force.

gv: want to make sure we are in line with the Charter.

<david-macdonald> https://www.w3.org/2019/12/ag-charter

rm: but we will be rechartering.

gv: want to make sure we are not suddenly walking outside of our charter.

<Rachael> Current charter: https://www.w3.org/2019/12/ag-charter

<david-macdonald> current charter language New standard to succeed WCAG 2.x based on the work of the Silver Task Force (name to be decided) This specification creates a new framework and guidelines to make web content and applications accessible to people with disabilities, supporting a wider set of user needs, using new approaches to testing, and allowing more frequent maintenance of guidelines to keep pace with accelerating technology change. Each [CUT]

jf: links to new charter
... think we are in line with our charter: https://www.w3.org/2019/12/ag-charter

MP: gregg brings up a good point about charter.
... atag note is not in the draft. it needs to be addressed.
... I will paste something in.

<sajkaj> Suggest more discussion of what we want in the new charter--may be more

<JF> +1

<sajkaj> +1

<jaunita_george> +1

<Chuck> +1

<jeanne> +1

<kirkwood> +1

<sarahhorton> +1

<bruce_bailey> +1

<SuzanneTaylor> +1

<Lauriat> +1

<Rachael> +1

<Detlev> +1

<KimD> +1

laura: +1

<david-macdonald> +1

<Jennie> +1

<MelanieP> +1

<JakeAbma> +1

<Rain_> +1

<ShawnT> +1

<Ben> +1

RESOLUTION: Approve merging groups after WCAG 2.2 moves to horizontal review (Additional details to be worked out including how to handle the community group, how to address ATAG and UAAG content within the charter and WCAG 3 process, and meeting schedules)

<Francis_Storr> +1

<Gregg> +1

<jon_avila> +1

<sajkaj> Bye for now!

WCAG 2.2 visible controls: https://www.w3.org/2002/09/wbs/35422/wcag22-visible-controls/

Question 1 - Exception may not align with understanding text #1980

chuck: next survey is on WCAG 2.2 - Visible controls.
... Exception may not align with understanding text #1980
... JonA asks in Issue 1980 whether the exception clashes with part of the understanding document. A simple update in PR 1990 addressed it.
... Oliver Keim wanted some adjustments. “f the control is to enhance keyboard navigation. For example, a link that skips from the top of the page to the navigation could become visible only on focus.</li>

This "old trick" of having a "skip to navigation" link invisible creates a lot of other issues, so I wonder it is so often used as an example.”

scribe: IMHO this example should probably better avoided because the readers may better be attracted to techniques around landmarks and headings so these are exposed correctly and helps screen reader users on a more basic level.
... For keyboard users this "trick" is a "tricked out feeling" as the number of tab stops on a page is not predictable. Due to this I would vote to remove this example.

GN: I have the same opinion.
... I do not agree with the following exception

JA: Don’t want people to fail this.

gv: agree. long standing tech won’t cause it to disappear.
... it will still be in books. Can say it is deprecated.

<jaunita_george> I could help

chuck: sounds like more updates to the undersrtanding doc.

JG: I could try to help.

rm: If you can go to the friday meeting they can assist.

gm: anyone else with ideas should send a note to JG.

Question 2 - The first exception is difficult to understand #1760

<jon_avila> Possible technique to reference https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/ARIA11

chuck: Next question - The first exception is difficult to understand #1760
... LiLoDavis raised Issue 1760 to suggest a re-write to say "The functionality of the interface components is available through an equivalent component that is available".
... Alastair thought this would undermine the logic of the SC text, so responded with the reasoning.

jf: While I agree with Alastair's logic, might I propose a re-write of the actual text to introduce clarity”.
... "Where (When?) a hidden user interface component receives pointer, hover, or keyboard focus that triggers the user interface component(s) to be visible, that information needed to identify that the user interface component(s) are available is also visible, except when:..."
... I also want to note that the Understanding document also states "But information needed to identify controls must be visible when the controls are needed >>without hover interaction or keyboard focus.<<" - which isn't the same thing as what the normative (current or proposed edit) text states, so we need to revisit that somehow.

Rain: The response references other issues that are open to clarify the wording itself. It would be helpful to link to those, since that is the real concern of this issue.

gn: Basically, it is about wording.
... In the response it says: "Note: Other issues are also looking at this worded, so it may well be updated."

I 'wording' meant? If not, what does the sentence mean?

chuck: jf’s comment seems to be the more significant comment. Need AC here to address.

jf: Can go either way. but we have a conflict between the normative text and understanding doc.

WCAG 2.2 focus-appearance: https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Question 1 - Understanding document updates

cheuck: this is regarding WCAG 2.2 - Focus appearance

chuck: PR 2000 makes a few general updates to the Understanding document that will help with various issues.

GN: In the new version it says: "The requirement is to have an indicator that has a 3:1 contrast ratio with the adjacent colors of the component, or to be separated from the component, or to be at least 2px thick.".
... The option 'or to be separated from the component' is not part of the normative text, and also I do not agree. In the corresponding example the focus indicator is hardly visible (close to being not visible).
... Next, it does not fulfill the 3:1 contrast to the unfocused state.

<Ben> Which example are we speaking about?

chuck: GN, your point not related to change.

<Chuck> proposed RESOLUTION: Accept all updates to understanding doc in PR 2000

chuck: should raise an issue in GitHub so your concerns are not lost.

gv: I am over in the changes and see additions in green.

ac: a few chunks are move around.

gv: lines 70- 79 is new content and the topic of this vote.

<alastairc> q_

gv: as soon as you require contrast on controls. Number of options are a very small number of colors

chuck: It may not be part of the move.

gv: anything 1px is a problem.

ac: to gn’s point. It is not spelled out in the normative text. But it is the outcome of it.
... meant to be quick examples of how to pass.

gn: if focus has the same color but is separate from it can pass?

dm: maybe best way to say it would be to add some space. maybe add that to the SC. It is vey confusing.

gv: it could meet the guideline but would not be of value to pwd.

<KimD> +1 to David. SC needs to be clear on its face.

gv: when creating guideline make sure it is useful.
... measure distance to screen and move 10 feet back to test.
... 1 px is not thick enough.

<Zakim> alastairc, you wanted to talk about the testing we did

gv: need to think this one through.

<alastairc> https://github.com/w3c/wcag/issues/1896#issuecomment-883591992

AC: various testing that we have done.
... Surface area of the indicator, bigger is better.
... The contrast of that surface area is compared the un-focused state, more is better.
... The contrast of the surface area compared to it's adjacent colours, more is better.

<david-macdonald> Perhap Jon, you can chime in regarding 1 px offset?

AC: we know the factors that make a difference.

gv: relative to the object can make a difference.

ac: can have one line but 4x as thick.

gv: contrast is a funny one.
... contrast shouldn’t be separate from the size.
... how did you test these?

ac: we had some test pages and LVTF rated them.

ja: part of this SC is a color swap.
... trying to plug some of these holes.
... did some informal testing of different combos.
... smaller lines may be visible to some.
... it depends on the colors. Trying to encourage people to use 2px.
... Not a perfect solution. but could help people with low vision.

<jenniferS> +1

gv: you say 2px is not practical. 98 percent of the population don’t know what a style sheet is.
... if browsers built it in it would be a different story.

<GN015> sorry, I have to drop

gv: make it clear so we don’t drive developers crazy.

chuck: trying to track if you are making suggestions to Understanding Doc or the SC text.

MP: gv is saying that a 1px line is not helpful?

<david-macdonald> scribe: David-macdonald

<Zakim> alastairc, you wanted to speak to niche cases and dynamic nature of focus

<Gregg> My thought is -- 1 pixel line is better than 1 pixel dots of course -- but it is not sufficient

Gregg: My contention is that 1px is not helpful. It should not be sufficient for a visible focus indicator

Melanie: if 1px regardless of contrast isn't sufficient, wouldn't that render all text invisible

<jon_avila> thin fonts are difficult

Gregg: interesting... why is contrast higher for text in WCAG. When we read we read not by looking at pixels...

large letters with skinny stems are not helpful.

Trying to detect a line around an object when the edges are aliased.

is really hard.

when reading you are focused but a focus indicator is trying to grab the user's attention

<JF> +1 to that - my issue with the earlier issue ( Issue 1760 )

<jon_avila> scribe:jon_avila

<david-macdonald> test

<Gregg> I see you now david

Chuck: Alastair and fellow chairs - broader issues were raised around the SC and appearance of the understanding doc is not aligned.

*sure

chuck: Are we happy with enhancements to understanding document. Do they conflict? Then we may have more work to do. If there are concerns in general we need a new issue.

<david-macdonald> Jon: The SC was a question of balance

Gregg: Edits be reviewed to make sure we give good advice and put - tend to avoid 1 px examples even though they might meet it by saying here are some good practices that meet or exceed.
... Try not put in things that just meet it but are controversial in group. 2nd thing post an issue about or send me a notice how to do this to do an issue against the SC.

<david-macdonald> Gregg: we have to be careful not to have text in understanding that is exceeding... its ok to provide best practices in the understanding doc as long as it is identified as exceeding the sc...

<Chuck> proposed RESOLUTION: Accept all updates to understanding doc in PR 2000

Alastair: In generally I'd agree with what goes into understanding doc - these went in because the SC is confusing - we wanted to say default is generally not good enough and this is how to do it and we put big bold and tell people what to do as the easy path

<Ben> +1

<jaunita_george> +1

Chuck: proposing resolution to accept the updates in the PR. Please vote.

<ShawnT> +1

<Gregg> -1

Shawn: Clarification around amendments to the proposed.

Chuck: Only heard concerns - hard to follow - Gregg did you make specific changes to the proposed text.

<laura> s/difference /difference /

Gregg: Introduction needs to be re-thought.

<laura> s/sepatare /separate /

Gregg: We should note that here are things that meet and exceed - but we need to mark them as such.

<Rachael> the preview is at https://raw.githack.com/w3c/wcag/wcag22-focus-appearance-understanding/understanding/22/focus-appearance-minimum.html

Gregg: My recommendation had to do with the compare - how do I get the preview version?

<david-macdonald> Gregg: s/we have to be careful not to have text in understanding that is exceeding/

Gregg: is there a way to get the preview from github?

Alastair: link is in survey to preview.

<laura> s/to Understanding Doc /to Understanding the Doc /

Chuck: Given that we had concerns - I'm going to recommend if Gregg is able to join Friday session we could do exactly the specifics of Gregg's changes. We could come back to the group in those.

Gregg: I can't join on Friday.
... I will send markup to Alastair.

Question 2 - Non-text contrast update

<david-macdonald> scribe: daivd-macdonald

Chuck: Second question. there is an issue for the issue that overlaps non-text contrast. One vote each. Not larger representative.

<david-macdonald> Jon: I think we need to be more clear on whether adjacent contrast is on both sides of the focus indicator, do we have to meet inside and outside contradt with focus indicator is inside the button

<david-macdonald> I'm thinking if it is inside the button t=and there is a button, do we need to contrast with f=birder, button fill and background focus

<david-macdonald> Alastair: If there are multiple colours inside... its either

<david-macdonald> I'm fine with whatever we decide

<david-macdonald> Gregg: looking at first example, meets contrast both sides

<david-macdonald> second example, no contrast with background, disappears with low vision

<david-macdonald> I don;t understand the 3rd example.

can someone please put in a link to the examples

<alastairc> https://docs.google.com/document/d/1xYriil533EW5DfOTDedG1g25JiVNqt0FJcQECys5n0o/edit

<david-macdonald> Alastair: 3rd example has a dark green outline,

<david-macdonald> Gregg: that works,

<david-macdonald> Alastair: 4th example, contrast is high enough...

<JF> +1 to gregg

<Zakim> alastairc, you wanted to add context

<david-macdonald> Gregg: we don't say that focus have to surround the component

we do not require the indicator be a particular shape.

<david-macdonald> Alestair: gregg you might be missing some context, its non text contrast, some people thought it was covered,other didn't. The question this addresses whether the sc is coherent and the way it applies.

<david-macdonald> Gregg: what are we trying to say with the last example

<laura> s/differnce /difference /

<garrison> Going to have to drop. bye.

<david-macdonald> Gregg: Its problematic to contrast with outside and inside. objects that differentiate is a mixture of contrast AND area.

<david-macdonald> Chuck: I'm sensing you have issues with this understanding with non text contrast and also the new SC,

<david-macdonald> Gregg: that is correct. The problems with the understanding is a result of deeper issues with the SC.

<Chuck> proposed RESOLUTION: Accept amended Google doc proposal to address non-text contrast which overlaps focus-appearance.

I created a code pen where the indicator touches both the inner border and the inner background. https://codepen.io/mraccess/pen/gORrOWR

<david-macdonald> Alastair: we still have to address this question on this 2,1 SC. People not in the group are interpreting the SC different from those in the group. So do these additional additions clarify that one questipns

<david-macdonald> Gregg: we should think of the focus indicator as a component.

<david-macdonald> Alastair: that would not work with existing sc text

<david-macdonald> Most of these examples would fail

focus indicators are states

<JF> yes

<Gregg> yes

yes

<Ryladog> yes

<Gregg> +1

<JF> @jon erm... focus indicators are state indicators

<david-macdonald_> Chuck: can we move forward by looking at each exampke

<alastairc> Figure 1

<Rachael> Passes

<Gregg> +1

<Chuck> passes

<ToddLibby> Passes

<Gregg> Pass

<Ryladog> Can you share again?

<alastairc> https://docs.google.com/document/d/1xYriil533EW5DfOTDedG1g25JiVNqt0FJcQECys5n0o/edit

<jaunita_george> pass

<JakeAbma> pass

<Ben> pass

<david-macdonald_> +1

<Ryladog> +1

<laura> +1

<bruce_bailey> +1

<jenniferS> figure 1 passes

<Gregg> fail

<jenniferS> figure 2 does not pass

<Chuck> fail

<sarahhorton> fail

<JakeAbma> nope

<Ben> fails

<jaunita_george> fail

<JF> fails

<Rachael> fail

<Detlev> fails

<david-macdonald_> Figure 2: yellow on outside

<laura> fail

<Ryladog> fail

<alastairc> (You can take my +/- 1 as per the doc :-)

<david-macdonald_> fail

<kirkwood> fail

<ToddLibby> fail

<bruce_bailey> -1 per the doc

<Gregg> passes because it contrasts with BLACK line and white backtound

<david-macdonald_> Figure 3 has green which contrast with white background

<Gregg> not great put passes

<Chuck> ack

<bruce_bailey> fig 3 passes (and per the doc) because of good contrast against white and that it *IS* getting bigger

<Chuck> dm: Discussions going around, were at the time the philosophy of the group. The focus indicator becomes part of the component to which it is attached.

<Chuck> dm: The focus indicator has to contrast with the background.

<Chuck> greg: Not in the SC.

<Chuck> dm: That's my recollection.

<Ryladog> pass

<Detlev> passes

<sarahhorton> pass

<david-macdonald_> passes

<bruce_bailey> black/green effectively the same color , so it is a thicker border which is visibly noticeable

<ToddLibby> pass

<Chuck> pass:

<Chuck> dm back to you

<Gregg> The SC needs to be judged on the wording of the SC not on side conversations

<kirkwood> if it was only one pixel width think it would be a fail, no?

<Chuck> dm: I think that this is the hole in the sc that is trying to be plugged by the new sc. When it becomes part of the actual component, and doesn't make the component bigger, some people will have issues. That's why we are here in this new sc.

<david-macdonald_> Jennifer: I think the exampke is confusing.... previous examples were contrast and this one has size, which is confusing unless we spell it out.

<alastairc> The bit at the top of the examples says "If the focus indicator is only inside the component it would need to contrast with the adjacent background within the component. If the focus indicator is only on the outside of the component, it would need to contrast with the background that the component is on."

<david-macdonald_> Jen: the relationship between blue and green...

<david-macdonald_> Gregg: has to contrast with things that are adjacen to it, so the back is why it passes. We wouldn't recommend this

<Zakim> gregg_bailey, you wanted to say that figure 3 is only NOT a problem in actually because of the (unfocussed) buttons on either side.

<david-macdonald_> Bruce: my reginal comment is that you need to think of focus as an interface comonent thennquestions gonaway.

<jenniferS> I have my glasses on and didn't even see the black line. Oops.

<Gregg> good point. if it was the OK button at the bottom of a dialog with other controls -- then there would be nothing to compare it with

<Chuck> dm: I may be misunderstanding, previous comments are about new SC in 2.2, it highlights the confusion with these 2 sc side by side. We are mentioning about how contrast ...

<Chuck> dm: with itself, opposed to the button having nothing to do with hit, the border contrasting with the background. I don't think that's what it was in the groups mind, it was a state, becomes part of the button.

<bruce_bailey> +1 that non-text contrast is different question than contrast for focus indicator

<Zakim> alastairc, you wanted to say the green wasn't intended with the black!

<Gregg> Add that as a separate item and label it as fail

Color #006000 is a dark green that is < 3:1 with black.

<Gregg> nice contrast between pass (barely ) and fail

<Gregg> Q3

<Zakim> Chuck, you wanted to say we do agree it passes, and there are different rationale for "passing"

<alastairc> but we do need an example with outer-contrast but not inner contrasrt

<david-macdonald_> Alastair: bad example, intended to have a dark border that didn't contrast with ... can't go back and make a focus indicator a separate component because SC considers the indicator part of the component.

<JF> +1, and perhaps a 3c with a "white" thin line

<david-macdonald_> Gregg: if this was an OK button in a dialog and it had focus on dialog load, they wouldn't know it has focus, so making a button bigger is not viable.

<david-macdonald_> Chuck: we can review this in the next session

<david-macdonald_> will close meeting

<AWK_> +AWK

<Ben> Ty all, see you on Friday

- DRAFT -

AGWG Teleconference

31 Aug 2021

Attendees

Contents

Merge AGWG and Silver after delivery of WCAG 2.2: https://www.w3.org/2002/09/wbs/35422/2021-08-25-Merge/

Merge AGWG and Silver after delivery of WCAG 2.2

WCAG 2.2 visible controls: https://www.w3.org/2002/09/wbs/35422/wcag22-visible-controls/

Question 1 - Exception may not align with understanding text #1980

Question 2 - The first exception is difficult to understand #1760

WCAG 2.2 focus-appearance: https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Question 1 - Understanding document updates

Question 2 - Non-text contrast update

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output