AGWG teleconference -- 23 Jun 2020

<laura> Scribe: Laura

Making Content Usable Wide Review https://www.w3.org/2002/09/wbs/35422/content-usable-June-17/results

AC: took a couple of recent discussions.
... RM held a meeting on it.
... 6 responded. All said yes to go to wide review.
... any comments from folks who couldn’t do the survey.
... none.

<PascalWentz> Having issues reaching https://www.w3.org/2017/08/telecon-info_ag

AC: looking to publish for wide review.

<PascalWentz> It says access denied and theres no login option

<alastairc> https://www.w3.org/2002/09/wbs/35422/content-usable-June-17/results

AC: ag participants should be able to access the survey link.

<GN015> I had the same issue not reaching the dial-in information. Try a different browser.

<Jennie> * I don't see Pascal in the Zoom

<alastairc> https://www.w3.org/2017/08/telecon-info_ag

ac: meeting link is https://www.w3.org/2017/08/telecon-info_ag

<JustineP_> Yes, I used the link

<mbgower> w/pq/pw

RESOLUTION: Publish "Making Content Usable" for wide review.

<PascalWentz> Thanks. It worked with the Chrome Browser. Microsoft Edge seems blocked.

Add Findable help to WCAG 2.2 draft https://www.w3.org/2002/09/wbs/35422/findable-help-finalisation/results

ac: call back to findable help.
... we dealt with comments on list but wanted to bring it back to the group.
... MG I did some editorial changes to address your comments.

<alastairc> https://raw.githack.com/w3c/wcag/wcag22-findable-help-updates/understanding/22/findable-help.html

<Zakim> AWK, you wanted to share minor editorial edits

mg: ok thanks

awk: editorial capitalize web.
... ”Web”
... “web applications”

gn: question one “one of the following available”

AC: could include both. Not a requirement to have more than one.

Jennie: not required to have 2 mechanisms on the page.

ac: reads Detlev’s comment.

Detlev: trivial misreading of the SC.
... "is included or linked in the same relative order" may be misunderstood

RM: working on the editorial changes.

awk: I fixed all of the editorial changes.

ac: cool.
... any suggestions to fix Detlev’s concern?

<alastairc> "For single page apps or any set of web pages, if one of the following is available, then at least one of the following is included or linked in the same relative order on each page:"

ac: inclined to leave it as is.

<alastairc> For single page apps or any set of web pages, if one of the following is available, then at least one of the following is included or linked, in the same relative order on each page:

<Chuck> For single page apps or any set of web pages, if one of the following is available, then at least one of the following, in the same relative order, is included or linked on each page:

Detlev: both need to be in the relative order

<Zakim> bruce_bailey, you wanted to ask about "linked" -- do we use that term elsewhere?

bruce: do we have to say linked? sounds casual.

<Chuck> For single page apps or any set of web pages, if one of the following is available, then at least one of the following is included in the same relative order on each page

ac: “links to”

awk: How about “accessed to”?

jennie: linked is clearer. accessed is more ambiguous.

<alastairc> For single page apps or any set of web pages, if one of the following is available, then at least one of the following is included or linked to, in the same relative order on each page:

<bruce_bailey> 2.4.4 and 2.4.9 (link purpose) use link as noun

Detlev: like using “accessed”. Tech neutral.

<AWK> "then access to at least one of the following is included in the same relative order on each page:"

<bruce_bailey> otherwise, "linked" appears only once in WCAG 2.0 and then only in introduction

<alastairc> ack q+

<AWK> Access to help mechanisms may be provided directly on the page, or may be accessed via a direct link to a different page containing the information"

<kirkwood> direct access

<AWK> Access to help mechanisms may be provided directly on the page, or may be provided via a direct link to a different page containing the information"

<bruce_bailey> Can it be reworded using link (noun) instead of linked (verb) ?

<Zakim> GN, you wanted to suggest "then to at least one of the following access is included in the same relative order on each page:"

gn: suggest "then to at least one of the following access is included in the same relative order on each page”

ac: “then…” comes across a bit strange.

awk: think you are right but will it happen?
... not likely in practice.

<alastairc> "For single page apps or any set of web pages, if one of the following is available, then at least one of the following can be accessed in the same relative order on each page:"

ac: constructing SC language.
... "For single page apps or any set of web pages, if one of the following is available, then at least one of the following can be accessed in the same relative order on each page:"

Detlev: like “accessed”

<AWK> Access to help mechanisms may be provided directly on the page, or may be accessed via a direct link to a different page containing the information"

<Detlev> No I meant "access" as suggested by AWK..

jennie: would the note go with the SC text?

<kirkwood> +1

ac: yes

<Rachael> +1

<Detlev> +1

<GN015> what about: "then for at least one of the following accessed is provided in the same relative order on each page:"

jennie: works for me if other coga members are okay with “access”.

<GN015> sorry, ... "access is provided" ...

awk: editing the SC now.

<alastairc> For single page web applications or any set of web pages, if one of the following is available, then at least one of the following can be accessed in the same relative order on each page:

Detlev: preferred accessed in the same relative order

<AWK> https://www.irccloud.com/pastebin/VMpvTTK8/

<AWK> For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one of the following is available, then access to at least one of the following is included in the same relative order on each page:

Detlev: I like that better

<Jennie> +1

<Rachael> +1

<Chuck> +1

<JustineP_> +1 to latest wording

laura: +1

<kirkwood> +1

<GN015> -1

gn: big companies may have difficulties. Would like better wording.

ac: struggling to see t scenario

jennie: Coga considered the scenario.

chuck: 3 types of help 3 pages could have a different form of help.

<JF> +1 to Rachael

rm: this is level A. Very basic. AA could be more prescriptive.

<Jennie> +1 to Rachael

gn: would you like to see wording?

<GN015> suggestion: then for at least one of the following access is provided in the same relative order on each page:

awk: yes.

gn: “suggestion: then for at least one of the following access is provided in the same relative order on each page:”

<alastairc> For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one of the following is available, then for at least one of the following access is provided in the same relative order on each page:

awk: to me it says the same thing.

rm: prefer gn’s

<kirkwood> gn seems easier

chuck: problems with “then for”

<AWK> a> or any <a>set of Web pages</a>, if one of the following is available, then for at least one of the following access is provided in the same relative order on each page:q+/a> or any <a>set of Web pages</a>, if one of the following is available, then for at least one of the following access is provided in the same relative order on each page:q+

<Jennie> Could we do GN + Chuck's and remove "for"?

jf: Struggling with term “relative order”
... tab order? visual order? tripping over the word “order”

<Jennie> 3.2.3 "Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user."

ac: based on 3.2.3

jf: more comfortable with something such as “placement”
... relative location or placement.

ac: relative order should be constant visual and source code.

jf: can we use “tab order”?

ac: sc not aimed at keyboard users.

<Chuck> For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one of the following is available, then for at least one of the following access is provided in the same relative location on each page

ac: reluctant to move away from what we previously discussed.

ac: think what we have works.

<Zakim> depends, you wanted to comment on context

jennie: consider it as a combo of reading order and tab order .
... we wanted it in the top third of the page.
... discussed a lot of other options.

jf: then we need to define “relative order”

<Jennie> From 3.2.3 understanding: "Presenting repeated content in the same order is also important for visual users who use spatial memory or visual cues within the design to locate repeated content."

jf: lift language from 3.2.3

ac: we have a definition already.

<alastairc> https://www.w3.org/WAI/WCAG21/Understanding/consistent-navigation.html#dfn-same-relative-order

<Zakim> Chuck, you wanted to ask that "relative order" is intended to be "usefully" ambiguous?

jf: works for me.

<JF> +1 to linking to definition

ac: want to link to "relative order" definition.

<alastairc> Access to help mechanisms may be provided directly on the page, or may be accessed via a direct link to a different page containing the information"

<bruce_bailey> access is a noun?

<Detlev> +1 to comma

<alastairc> For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one of the following is available, then access to at least one of the following is included in the same relative order on each page:

<bruce_bailey> better

<Chuck> +1 to 54 minutes past hour

<AWK> For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one of the following is available then access to at least one option is included in the same relative order on each page:

ac: 2 versions Plus one or Plus 2

<bruce_bailey> +1 for 2nd ver

<GN015> -1

<Rachael> +1 to 2nd version

<Detlev> +1 vor 2nd

<JakeAbma> +1 to 2nd version

<AWK> +1 to 54 or my newer edit

<JustineP_> +1 2nd version

Laura +1 to 2nd version

<Francis_Storr> +1 to second.

<kirkwood> +1 to 2nd

<Jennie> +1 to earlier version, I think, but it keeps moving...

ac: leaning to 2nd version.

<kirkwood> eleminate second following

<alastairc> For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one of the following is available then access to at least one option is included in the same relative order on each page:

can anyone not live with the second version?

<Chuck> +1

<Chuck> +1 CAN live with

<bruce_bailey> +1 to last version

<AWK> +1

<Detlev> +1 happy

<JustineP_> +1

<kirkwood> +1

<alastairc> +1

<Rachael> +1 ok with it

Laura: +1

<Jennie> +1

<Francis_Storr> +1

<PascalWentz> +1

<CharlesHall_> +1

RESOLUTION: "Add Findable Help" is ready for CFC and wide review

ac: For <a>single page Web applications</a> or any <a>set of Web pages</a>, if one of the following is available then access to at least one option is included in the same <a>relative order</a> on each page:

Focus visible enh issues 3 https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues3/results

<JF_> +1 with language as long as link to definition of relative order is made

<Detlev> scribe: Detlev

Add another size metric

<alastairc> Minimum area: The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control.

Alastair: first question whether we need to add a size metric
... Jake suggested to add to that to allow cases where a thick line down a control or button is added

<alastairc> The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the element.

Alastair: to take care if changes in size by responsiv edesign formatting
... (reads Jon Avila's comment from survey)
... wording could be changed to address that
... Does exclude normal underlines, minimum would be 3 px width of underline
... (reads Bruce
... comments)
... what's the reference to 2px minimum in another SC?

<Chuck> detlev: I think it's a horrible phrasing, not happy, but want to cover those things that are covered in codepen for same type of links, same height but gets longer.

<Chuck> detlev: In those cases it would be absolutely fine to be able to use the same size indicator, because the payload hasn't changed.

<bruce_bailey> okay, i was thinking of earlier draft

<bruce_bailey> https://www.w3.org/TR/WCAG22/#focus-visible-enhanced

<Chuck> detlev: Indicator would be in same relative position of the payload.

<Chuck> detlev: Not pressing, just an idea.

Alastair: (reads Detlev's comment)

<bruce_bailey> Contrast or thickness: The focus indication area has a 3:1 contrast ratio against all adjacent colors for the minimum area or greater, or has a thickness of at least ***2 CSS pixels.***

Alastair: We want to keep complexity of SCs down - the more you try to capture every possible case, the harder the language gets

<bruce_bailey> i am okay with 1 css pixel

Alastair: Focus visible: First bullet defines a min surface area, next bullet point takes into account contrast to adjacent colors
... Simpler would be 2px full border, full stop. But we waht to provide some flexibility, not be too prescriptive

Detlev: I rest my case

<alastairc> Any improvement on: "or has a thickness of at least 8 CSS pixels along the shortest side of the element."

Alastair: Any comments on Jake's exception (8px thickness on shorter border)

<alastairc> https://codepen.io/JakeAbma/full/rNaggxZ

Alastair: Example has 10px thickness - 8px might be a bit arbitrary, but refers to several a11y oriented sites

AWK: When its wide it is not a big deal, but for squarish things you might get designer pushback

Alastair: In those cases you get a smaller surface area, so possbile to meet another way

<Sukriti> This one also looks similar to a checkbox and might indicate an action needs to be taken instead of indicating focus

Alastair: quick poll...

<alastairc> Poll, would it be beneficial to add this new metric? "The focus indication area is greater than or equal to a 1 CSS pixel border of the focused control, or has a thickness of at least 8 CSS pixels along the shortest side of the element."

<bruce_bailey> +1

<JakeAbma> +1

<alastairc> -0.5

+0 Still find it too prescriptive, but resting my case...

<Chuck> 0

<mbgower_> 0

<OmarBonilla_> 0

<AWK> +1, perhaps with an editor's note to point out the need for feedback on the values

<JF_> 0

<kirkwood> 0

<laura> 0

<GN015> could you repeat the old metric as well? (It has moved very often.)

Alastair: it's the metric without the exception

<Sukriti> 0

<CharlesHall_> what is the side of a circle or polygon?

<JF_> +1 to Charles

<GN015> -1

<CharlesHall_> “along the shortest side” could work on a polygon, but not a circle

Chuck: Should indicate need for feedback

JF: Looking at edge cases, like 2-3 pixels tall - will it show?

Alastair: You can wrap it in a 1px border oar use an indicator with the same surface area

JF: There is no minimum target size - but what about targets that are not square, like a circle?

Alastair: You'd need something 8px thick - so it it cannot be applied stick with the perimiter/surface equivalent bit

JF: would it have to be at least a third?

Alastair: In this use case it is much less
... we need to qualify it in the Understanding doc
... If there is no shorter side, it does not apply

Chuck: Can't see momientum for including the exception
... not enough reason to add exception

Alastair: No dealbreaker to go ahead without exception - Bruce, Jake?

Bruce: What's the harm to add the exception - no one is against it

Jake: Example speaks for itself - it cannot be justified from a visual perspective - perceptionally it is fine and we then rule it out - there is no logic in there
... the argument is pretty clear, it is a frequent case - the focus indicator mostly stays the same - bad to then call that a FAIL
... WCAG should not make designers do something counter-intuitive - it is not what I expect us to do - we will get many questions about that

<Zakim> mbgower_, you wanted to say why not include. Less opposition than proponents

Alastair: Two counter points: Text is easier to understand without exception; 2) it exception is included the indicator at the smalöl side may easily be missed

mgower: Are changes in SC text are captured in the different versions of the SC text so people can track progress and compare versions?

Alastair: We have been doing three rounds on this, had many comments - so the history is in comments to issue raisers ("here is the updated version")
... Some people strongly in favour, self somewhat negative, many lukewarm on it

Chuck: Summing numbers: there is a majority of "don't cares" - I would now be a +1

Alastair: Negative about including it by Gundula?

Gundula: Ofte ngit stuck when this kind of focus indicator was used. We should not push people in that direction - people are accustomed to framing indicators

<Chuck> Chuck: For clarity, I remain a 0. My vote turns to a +1 if asked if I can live with this metric being added.

<kirkwood> +1 to framing point by Gundula

Alastair: The intent is to keep the focus indicator visually appearent. The exception tries to cover the case where there is no change to focus indication but wider, it fails becaus the surface area of the control goes up

Gundula: Why should focus indicator be smaller?

Alastair: It is not smaller in relatino to the text
... If text goes taller the indicator should follow
... It does - the issue is the width of the control

Gundula: is the issue the white space?

Alastair: Yes
... (showing codepan example in responsive view)

Gundula: the whole area, the list item is the link

Alastair: Bigger hit area is good, should not be punished

<alastairc> https://codepen.io/JakeAbma/full/rNaggxZ

Gundula: Seems too prescriptive - why are dashed focus indicators excluded, it has good visibility but may be ruled out by the SC

Alastair: Dashed indicators are not included as long as they meet the surface area requirement
... (calculating surface area from perimiter)
... no type of indicator is excluded if surface area is met

John K: The example speaks to limited vision - it took me quite some time to see this type of indicator

scribe: an indicator surrounding the action point is better for people with limited vision

Would be difficult for some even if it was 20px wide

scribe: surronding indicator makes a huge difference

Alastair: Point for keeping indicator proportional

<Chuck> detlev: I wondered if there was a chance to refer to the usable part of the control, what I call the payload of the control.

<Chuck> detlev: If you have a fat outline right next to the text, is there a way of phrasing such that we can discard the ...

<Chuck> detlev: linking the indicator to the payload?

Alastair: There was a note for visual indicators for controls with a wider hit area - so this is related
... but this example is different, very wide. We heard some examples why accessibilitywise it can be a problem for some LV users

Jake: Best one would be surround - but why is longest side OK? maybe it should be stricter, mandating border all around?

Alastair: We do not what to excude other options like chanign the background
... If we leave it as it is, we are pushing people towards background change or border all around

<Chuck> +0 to add the metric, +1 can live with adding it.

Alastair: bottom line is many people aren't too sure - we need to find a resolution

<Chuck> +1

<JakeAbma> +1

<Rachael> 0

<bruce_bailey> +1

<Sukriti> +1

<JF_> 0 / -.001

<laura> 0

Who can live with adding it: -1 for not adding, +1 for adding

<CharlesHall_> 0

<OmarBonilla_> 0.5

<GN015> -1

Alastair: Reason to add an editorial note requesting comments on the metrics

RESOLUTION: Add the metric with an editors note to point out the need for feedback on the values, for public review.

Matching the start of 2.4.7

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues3/results#xq1

Alastair: We switched the start of new SC to 2.4.7
... followed by a rebuttal, suggestign a different approach

<alastairc> "For the keyboard focus indicator of each User Interface Component, all of the following are true:"

Alastair: Advantages of that formulation: it does overlap less with 2.4.7 and 1.4.11

<Zakim> mbgower, you wanted to say why not just keep the published version? Same result.

mbgower: Supports rowing back change - 2.4.7 already requires focus to be visible, we do not wan to fail the same thing in two places

<alastairc> "For the keyboard focus indicator of each User Interface Component, all of the following are true:"

<alastairc> For the keyboard focus indicator of each User Interface Component, all of the following are true:

mbgower: no strong feeling about either option

<alastairc> When a User Interface Component displays a visible keyboard focus, all of the following are true:

mbgower: (stating currently published version) - should be retained

Alastair: Going back to currently published version makes most sense - this is supported in the survey

Bruce: (survey) new wording would make it easier to tackle focus hidden issue

Alastair: No objections to keeping text?

<alastairc> "When a User Interface Component displays a visible keyboard focus, all of the following are true:"

<CharlesHall_> not a fan of the word “keyboard” but not a hill i die on

<alastairc> "For the keyboard focus indicator of each User Interface Component, all of the following are true:"

mbgower: If the keyboard focus is completely obscured, it is no longer visible so it may create confusion

RESOLUTION: Re-introduce the following text "When a User Interface Component displays a visible keyboard focus, all of the following are true:"

Add 'unobscure' bullet

<alastairc> "Unobscured: The focus indicator is not entirely hidden by author-created content."

Alastair: Suggestion was to add a fourth bullet

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues3/results#xq5

Alastair: to make sure focus is not hidden behind fixed position content
... (summing up survey results)
... universal agreement to cover that case

<alastairc> Update: "The item with focus is not entirely hidden by author-created content"

<CharlesHall_> focus indication is also often partially obscured / obfuscated by adjacent elements (like tabs)

mbgover: Cannot see that this gives authors a way out on the other three bullets, which still count

<alastairc> https://alastairc.uk/tests/wcag22-examples/sticky-footer4.html

<Zakim> mbgower, you wanted to say that I have added a modification that I think improves this

Alastair: (shows test page with visible text link indicator - on a wrapper that indicator is partly obsured even though the link as all-around border. Happens in the wild
... )

<alastairc> https://github.com/w3c/wcag/issues/1145#issuecomment-644028281

Alastair: Fairly commen for indicators to be partly cut off - hoping for a wording for overlays, 3D content, whatever

<Sukriti> items with shadows/ elevation?

mbgower: It says "All the following are true" - example won't pass the other three bullet points
... would it fail for 'minimum area`'?

Alastair: Yes

mbgower: item not entirely hidden still fails first bullet

Alastair: So what would the fourth bullet add?
... (looking at test case, sharing screen)

mbgower: Focus indication after top menu landing on content obscured by header - so this would fail by virtue of the fourth bullet
... So this case is addressed, also popups where focus lands behind them
... lots of ways to implement it so it passes

Alastair: have to wrap up

<mbgower> Thanks!

Alastair: lots of ifs and buts, we need to resume this next week

- DRAFT -

AGWG teleconference

23 Jun 2020

Attendees

Contents

Making Content Usable Wide Review https://www.w3.org/2002/09/wbs/35422/content-usable-June-17/results

Add Findable help to WCAG 2.2 draft https://www.w3.org/2002/09/wbs/35422/findable-help-finalisation/results

Focus visible enh issues 3 https://www.w3.org/2002/09/wbs/35422/focus-visible-enh-issues3/results

Add another size metric

Matching the start of 2.4.7

Add 'unobscure' bullet

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output