W3C

AGWG-2020-12-01

01 Dec 2020

Attendees

Present
Chuck_, Rachael, Laura, alastairc, stevelee, Fazio, kirkwood, Caryn-Pagel, sarahhorton, JakeAbma_, Matt, Orr, MarcJohlic, MelanieP, bruce_bailey, mbgower, MichaelC, Wilco, Katie_Haritos-Shea, juliette_mcshane, JustineP, david-macdonald, (sorry_to_be_late, held_up_by_a_meeting), GN015
Regrets
AWK, Nicaise
Chair
Chuck_
Scribe
Laura, Rachael, ChrisLoiselle_

Contents


<laura> Scribe: Laura

Findable Help (Question 1-7) https://www.w3.org/2002/09/wbs/35422/findable-help-issues/

Response to #1437

chuck: I'm going to read the question.
... "Thomas Reuters asked if content authors need to clearly state that human contact details will be provided once the process of the automated contact mechanism is complete in issue 1437."
... Scha14 has put together a draft response.
... everyone on the survey agrees.

<alastairc> "Clearly stating that human contact details will be provided once the process is complete would be good practice but is not a requirement of the success criterion"

Bruce: I would like the proposed response pasted in.

<bruce_bailey> +1

<kirkwood> +1

RESOLUTION: Accept the suggested response from Scha14 to address issue #1437

Response to #1367 about "Set of Web Pages"

chuck: "guyhickling raised a question about what makes up "a set of webpages" in issue 1367."
... Alastair has put together a draft response.
... 3 people want something else.

bruce: I agree with the response, and find it complete and sufficient, but already Guy Hickling says he wants more. So could/should we say that the WG declines to get more specific? As Alastair notes, the definition has been good enough for a dozen years!

AC: Guy raised a good point (in a follow up)

<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/findable-help-issues/results#xq9

AC: "in all those other [WCAG 2.0] SCs there is no requirement for one page to be identified as part of a particular set (a page could even be part of more than one set). Those SCs simply required that if some content showed on multiple pages, then it had to be shown consistently on all those pages where it showed."
... So "Consistent Navigation" doesn't require that navigation be shown on all pages in the set, only that where it does show it must show consistently.
... think this does put us under a burden of proof to show, either through examples or a definition update, how people can consistently identify whether any page is part of a set.
... bit of an onus on us.
... maybe provide more examples.

Sarah: I agree that the wording is problematic, given that you typically don’t evaluate a set of pages but rather individual pages or components
... a bit confusing

GN: "I agree with Guyhickling a more precise clarification is needed to determine how and where 'Finding help' applies. Does the definition lie with the author, yet each page needs to belong to one set? Can a page belong to more than one set?"

Chuck: chair hat off.
... may want more examples and crafting a new response.

GN: yes.

<alastairc> "Help 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: see above proposal.
... understanding would have to be adjusted.

Sarah: what is the difference between this and consistent navigation?
... we have a lack of clarity.

<jon_avila> Even within a set you don't have to the same type of help - just that it's in the same order.

Clarify whether help is provided.

<Zakim> alastairc, you wanted to talk difference between help & navigation

<jon_avila> The reason this is different than navigation is that contact details might not be navigation - for example a phone number.

ac: history: The desire human is ideal. But not possible.
... help mechanism could be a phone number.

<kirkwood> “findable help” is how its often referred.

ac: need examples.

Chuck: workshop the SC here or offline it.

Wilco: slightly reluctant.
... do we have an example where it would be difficult to gauge if a page is in a set of web pages?

AC: would be easy to find.

Wilco: doesn't sound like it is a new problem.

ja: if any pages that are part of a set has help they have to be in the same relative order?

Ac: yes.

Sarah: If I am on a page that doesn't have help, but others in the set do, does that fail?

Ac: yes.

<jon_avila> If any page in a set has a help mechanism - then each page in the set of web pages needs to have a help mechanism from the list below and needs to appear in the same relative order.

Ac: it is complicated
... yes.
... suggest that someone update the understanding doc.
... think we will be getting GitHub issues about this.

Chuck: volunteers?

RESOLUTION: Update response to issue #1367 and include additional examples in understanding docs, and review in a subsequent meeting.

<alastairc> AC: I will email around about this issue and needing the examples being worked on.

Question 3 - Response to #1436

ac: basically the same as the last question.

Question 4 - Response to #1434

Chuck: Thomas Reuters asked about prioritizing the help options within Findable Help in issue 1434.
... Scha14 has put together a draft response.

AC: don't think the response covered the whole question

<alastairc> The success criterion does put the ways of help in a rough prioritisation order, but it does not cover prioritisation when the site provides multiple ways. There are too many variables to provide direction for this aspect, for example, the "Human contact mechanism" (messaging) might be better supported by the organisation than the "Human contact details" (phone). The group believes this aspect should be up to the site/organisation.

AC: I suggest: The success criterion does put the ways of help in a rough prioritisation order, but it does not cover prioritisation when the site provides multiple ways. There are too many variables to provide direction for this aspect, for example, the "Human contact mechanism" (messaging) might be better supported by the organisation than the "Human contact details" (phone). The group believes this aspect should be up to the site/organisation."

GN: I understand the priority lies with the author(s). If this is right, it might be useful to clarify it in the understanding document as well.

<stevelee> lol

Chuck: GN seems to be going an additional step.

ac: useful as a second task.

Gn: agreed

RESOLUTION: Accept the amended suggested response from Alastair to address issue #1434

Chuck: Gundula, would you like to take this on?

GN: yes

Question 5 - Response to #1394

Chuck: jpascalides raised 4 questions about Findable Help in issue 1394.
... Scha14 has put together a draft response.

Ac: following adjustements (comment) For item 3, we could add that we've been through this discussion before, e.g:
... Examples of self help options are stated in the understanding document in more detail. The group has been through an iteration of the SC that included all the examples. However, it is inconsistent with other success criteria, and makes the SC harder to read. Since there are several examples for each of the options and it would be inconsistent to only include examples for one, the examples went in the understanding document for readability.

RESOLUTION: Accept the amended suggested response from Alastair to address issue #1394

Question 6 - Understanding update to address #1347 and #1368

Chuck: Issue 1347 and Issue 1368 ask for clarification for findable help in single web applications.
... Sukriti put together a pull request to update the Understanding document: PR #1538 that adds the text:

<Chuck_> proposed text For a single page Web application, if the same URI routes to pages or views with different layouts or content, then each of those pages or views, have the supported ways of finding help in the same relative order.

Chuck: For a single page Web application, if the same URI routes to pages or views with different layouts or content, then each of those pages or views, have the supported ways of finding help in the same relative order.
... I'm not certain what this sentence is trying to tell me. I need additional details on the "intent" before I can offer suggestions.

GN: Using the term 'URI' sound clear, but might make things more complicated.
... this level of detail is not needed.

AC: has caused confusion.
... as you click around it can update the uri.
... useful to have some clarifying statement around it,
... missing an in-between state.

<Chuck_> alastair's alternate proposal: A single page Web application (compared to a _Web_Page"_) shows multiple "pages" or views of content at the same URI. If a web application uses routing and shows different URIs for each view, that is considered multiple _web_pages_ because the URI changes.

Ac: need to explain somewhere.

<alastairc> https://github.com/w3c/wcag/pull/1538/files

<jon_avila> We might want to consider something like this which we use else where "content that changes the meaning of the Web page"

SL: Don't think it is quite good enough.

<alastairc> Current definition: https://w3c.github.io/wcag/understanding/findable-help.html#dfn-single-page-web-application

JA: we have some wording in the change of context that we could use.

<alastairc> "Pages obtained from a single URI that provide navigation which changes the meaning of the Web page"

Ac: we do have defined SPA. "Pages obtained from a single URI that provide navigation which changes the meaning of the Web page"
... some folks were confused.

<jon_avila> Then we should remove definition of single page app

Sl: boils down to restful
... breaking the basis of the Web

JA: maybe remove the SPA definition?

Jake: +1 ing Jon's comment
... multiple versions of how you implement SPAs.
... better to remove it.

<Zakim> alastairc, you wanted to say that it was added to cover some (odd) situations

Ac: struggling to remember why SPA was added.

sl: SPA is causing problems

Ac: Maybe clearer if we swapped it around.

<jon_avila> The word variations could be an issue with responsive variations

AC: maybe simplify the SC text and explain in the understanding doc.

Sl: yes it was tied up on PDFs.
... put the SPA part later.

Chuck: tracking various responses.
... 3 options.

<Ryladog> +1

Ac: small mod to swap things around.

<Ryladog> I dont like the idea of removing SPAs as a def

katie: not opposed.

<Zakim> alastairc, you wanted to say we can agree the update now, and look at the SC text later.

katie: would like to future proof.

Ac: if we agreed to the mod version now we could close these issues off.

scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

<Rachael> scribe: Rachael

Alastair: suggest update PR #1538 to address issues #1347 and #1368

Chuck: Suggesting that to narrowly address the issue that was raised.

alastairc: yes

<alastairc> A <a>single page Web application</a> (compared to a <a>Web_Page</a>) shows multiple "pages" or views of content at the same URI. If a web application different URIs for each view of the content, that is considered multiple _web_pages_ because the URI changes.

Chuck: We had concerns that brought us to the other resolutions but to narrowly address these issues, does anyone have any concerns about Alastair's amended response?
... and updating the pull request (see above)

alastairc: Read post at 12:03

Chuck: Does anyone object to that?

RESOLUTION: Accept the amended suggested response from Alastair, and update PR #1538 to address issues #1347 and #1368

<Detlev> uses is missing but I guess you know that

Question 7 - Group of changes together #1242

Chuck: Guy H raised seveal issues. Sukriti put together a PR. Andrew wanted something else. Are you on the call?
... AWK was probably regretes.

<Zakim> Chuck_, you wanted to change scribe

Chuck: Read AWK's comment.

Alastair: I think this was an older issue. There was very little difference when comparing. I think this may be removing information we added. I Think this has become null and void.

<laura> Nothing seems to be scribed to the minutes document https://www.w3.org/2020/12/01-ag-minutes.html

GN: When I Read this I answered very shortly before the meeting. I was very confused by the wording.

<Chuck_> proposed text For _single page Web applications_ or any _set of Web pages_, if one or more of the following ways of finding help is provided, then access to at least one way of finding help is included in the same relative order on each page

<laura> Nothing seems to be scribed to the minutes document https://www.w3.org/2020/12/01-ag-minutes.html

<ChrisLoiselle_> I can scribe, one second

<ChrisLoiselle_> scribe:ChrisLoiselle_

<alastairc> Latest text: "For single page Web applications or any set of Web pages, if one or more of the following ways of finding help is supported, then access to at least one way of finding help is included in the same relative order on each page:"

<alastairc> Logging is ok: https://www.w3.org/2020/12/01-ag-irc

I only have from 12:10 on , as I had to add myself back in FYI.

AlaistairC: asks Gundula follow up

Yes, multiple within each category.

Gundula: I see, yes. Seems good to me.

AlaistairC: We are disregarding the pull request, as other things are met. We can follow up with Guy H. on issue and proposed text.

RESOLUTION: Follow up with Guy Hickling on the amended proposed text, and disregard PR.

MichaelG: Proposes possibly adding SPAs into definition of web page , to simplify SC

<Zakim> mbgower, you wanted to say consider incorporating single-page into set of pages defn?

DavidM: On set of web pages, we wanted to have site wide conformance model, but couldn't agree on sub domain, etc. We were trying to capture "across the website"

I.e. what is happening on one page is happening on another. For example, left hand navigation order display.

The definition of the web page or web application was with the same URL.

MichaelG: Talks to web application intent within SCs and how this could be incorporated into set of web pages and normative text examples.

Target Spacing (Question 1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues/

DavidM , Chuck: We can review further later.

New formulation of the SC text

Chuck: Pointer Target discussion. https://www.w3.org/2002/09/wbs/35422/wcag22-target-spacing-issues
... Talks to text write up and current feedback. Opens it up to BruceB.

<Zakim> alastairc, you wanted to say the last condition was an error

BruceB: The condition at end, would make more sense at front of the text in the description to explain it better. It then goes into targets in targets.

AlastairC: Talks to redundant bullet. The last sentence above the note can be disregarded.

MichaelG: Likes how it is shaping up. Asks about nested and overlapping. If something is overlapping, 24 pixels is still valid. It is an issue when nested, thus the exception.

Nested: Where one target is entirely enclosed within another target, each provides a unique target area of at least 24 by 24 CSS pixels;

<david-macdonald> ++1 on that recommendation

:)

Wilco: I think the previous suggestion does the same as what I was suggesting. I have examples of overlap that I can share.

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

<Wilco> https://codepen.io/wilcofiers/pen/abZxPow

AlastairC: pastes in shared editing space.

Wilco: Shares different examples in codepen.
... I1 through I4, Example I1 and I2 pass, I3 and I4 fail.

MichaelG: Describes H3 and H4 failing , when a square target is in a rectangle target. That fails nested. H4 is two square targets in a rectangle, thus failing as nested.

Chuck: I believe Michael G.'s recommendation meets what Andrew K. was talking to earlier.

DavidF: I have never came across this , in a nested , real world example.

AlastairC: An example would be links within labels. Also map pins on a map , both interactive.

DavidF: Thanks, that makes sense.

<Detlev> and tiny x close buttons in ads...

Chuck: To Gundula, has this information changed your mind?

Gundula: Not fundamentally. There is still the pain point of the 24 pixel.

I feel that it is not mature, but I do like the alternative wording.

MichaelG: This has to also apply to a non touch paradigm. I.e. where they are embedded in another target.

DavidM: I think we may have lost the word "visually enclosed". I think we need to add that in, for nested...

Chuck: To all, adding visually to the text, is that ok?

MichaelG: To David, do you have an example?

<jon_avila> Target area doesn't have to be visual

DavidM: Button inside an anchor. We want to make sure.

<alastairc> Definition of target: https://www.w3.org/TR/WCAG22/#dfn-target

MichaelG: We can have a target that is smaller, AlastairC and Wilco have talked to this more than I have.

Wilco: It is problematic with text with background and padding.

AlastairC: Putting in visually, may add confusion. Target is a region of the display that accepts pointer action. Presentation may vary.

DavidM: Maybe a note underneath it to describe it where it clarifies?

<Wilco> suggestion: Entirely overlayed on another

<jon_avila> Cards?

DavidM: It is a failure to put a anchor in a button. Product tile, buy now is a button, but whole anchor is a target for landing page. Button is inside anchor.

<Zakim> Chuck_, you wanted to ask what is it a failure of?

Chuck: What SC is failed?

DavidM: 4.1.1. nested properly

MichaelG: Entirely Positioned?

<jon_avila> enclosed?

<Chuck_> dm: Targets in the dom.

<alastairc> Note: This criterion is about how targets are arranged on screen, not how the code is nested.

scribe note, I need to step away, can someone cover for two minutes?

<Rachael> scribe: rachael

david and mbgower: general agreement

<david-macdonald_> +1

<mbgower> +1

<ChrisLoiselle_> scribe:ChrisLoiselle_

<Rachael> Chuck: Proposed resolution to accept Michael G's resolution.

Rachael, I'm back. thank you.

DavidM: A note is not normative in WCAG 2. model.

Chuck: Does anybody object to the resolution?

<Detlev> +1 to amended text

AlaistairC: I would like to speak to Gundula's points.

On user agent exception, companies are more of a should than a must, and some companies don't meet their own guidelines regarding pixel size.

<david-macdonald_> +1 on the exception

<Zakim> alastairc, you wanted to speak to Gundula's points

SarahH: On Gundula's points on size. Size requirements are not just for mobile.

AlastairC: They are different for mobile, 48 pixels...
... 16 pixels is the smallest for Microsoft, Apple has its own, etc.

SarahH: We could derive system minimums and possibly apply that to web site

<Zakim> Chuck_, you wanted to suggest we shoudn't work too hard to game proof.

DavidM: Talks to diagonal measurement and how that may become best measurement practice. I.e. one would pass, one would fail. Explaining how to measure should looked at.

<jon_avila> We mean horizonal or vertical line rather than diagonal?

Wilco: You wouldn't take the diagonal.

<GN015> would you mind giving the resulting text for "Accept Michael Gower's amended update to the SC text, with additional note per David MacDonald" ?

MichaelG: Talks to measurement explanation. on The google doc shared in the zoom call.

<jon_avila> I agree we need to make the closest point more clear and not anywhere on the closest edge

<alastairc> "Nested: Where one target is entirely enclosed within another target, each provides a unique target area of at least 24 by 24 CSS pixels;"

DavidM: agrees. Suggests we explain this further in understanding documents.

<alastairc> "Note: This criterion is about how targets are arranged on screen, not how the code is nested."

RESOLUTION: Accept Michael Gower's amended update to the SC text, with additional note per David MacDonald

Redundant Entry (Question 1 only) https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/

Redundant Entry and User Frustration #1431

Chuck: presents third survey question

results can be found here https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/results

<Fazio> It depends

Chuck: Gundula From my point of view, double entry to prevent errors when giving email address or setting a password is essential. So I see it as already covered. Nevertheless I can live with the suggested change.

Gundula: Yes, that is what I meant by that.

DavidF: Intent was to leave those as exception. If we went five fields down and we asked for an email again for confirmation, that will be exception.

If it asks again separate from that, that would be the fail.

<Zakim> alastairc, you wanted to mention essential definition

AlastairC: Essential definition is a bit too specific, where essential could be possibly met in another way. I wasn't opposed to it.

Thanks , sorry !

<Chuck_> Re-entry of an e-mail address for the purpose of preventing error is considered to be part of the exception of 3.3.8 Redundant entry. To clarify, we can make the following change:

<Chuck_> Exception: When re-entering the information is essential.

<Chuck_> Exception: When re-entering the information is essential, or unless re-entry is used to prevent user error, such as re-entry of a new password.

DavidF: I think that creates a loophole.

They are doing that for error purposes , which impacts the entire SC.

User entering twice, interference with user's brain and cognitive issues occur.

DavidF: I give you my phone number. Later you ask for my address. The numbers get mixed up in the brain for people with cognitive disabilities.

AlastairC: If it is something like an email address, it would be available to address. If its visible to you on screen it would be on same step. No argument there.

Chuck: Is the original exception ok?

AlastairC: The exception is not needed, since it is within the same step.

<alastairc> Current start: "For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either:"

Wilco: Are you arguing that step is an entirely new page?

We would then need to define step.

AlastairC: it was helpful not to define that when we reviewed it. One control next to each other...

DavidF: Enter and confirm email address...Step 2...

Chuck: No resolution on this, we will defer to next time.

<alastairc> rssagent, make minutes

rssagent , make minutes

<alastairc> https://www.w3.org/2020/12/01-ag-irc

Summary of Action Items

Summary of Resolutions

  1. Accept the suggested response from Scha14 to address issue #1437
  2. Update response to issue #1367 and include additional examples in understanding docs, and review in a subsequent meeting.
  3. Accept the amended suggested response from Alastair to address issue #1434
  4. Accept the amended suggested response from Alastair to address issue #1394
  5. Accept the amended suggested response from Alastair, and update PR #1538 to address issues #1347 and #1368
  6. Follow up with Guy Hickling on the amended proposed text, and disregard PR.
  7. Accept Michael Gower's amended update to the SC text, with additional note per David MacDonald
[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/12/01 20:05:51 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
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/reductant/reluctant/
Succeeded: s/yse/yes/
Succeeded: s/Maybeclear/Maybe clearer/
Succeeded: s/Essential definition is vague ,/Essential definition is a bit too specific,/
Present: Chuck_ Rachael Laura alastairc stevelee Fazio kirkwood Caryn-Pagel sarahhorton JakeAbma_ Matt Orr MarcJohlic MelanieP bruce_bailey mbgower MichaelC Wilco Katie_Haritos-Shea juliette_mcshane JustineP david-macdonald (sorry_to_be_late held_up_by_a_meeting) GN015
Regrets: AWK Nicaise
Found Scribe: Laura
Inferring ScribeNick: laura
Found Scribe: Rachael
Inferring ScribeNick: Rachael
Found Scribe: ChrisLoiselle_
Inferring ScribeNick: ChrisLoiselle_
Found Scribe: rachael
Inferring ScribeNick: Rachael
Found Scribe: ChrisLoiselle_
Inferring ScribeNick: ChrisLoiselle_
Scribes: Laura, Rachael, ChrisLoiselle_
ScribeNicks: laura, Rachael, ChrisLoiselle_

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


[End of scribe.perl diagnostic output]