– DRAFT –
AGWG-2021-08-17

Error Prevention guideline and associated methods

<AWK> +AWK

CA: Jake: you felt this was "drafty", was there anything else you'd like to add?

JA: it doesn't feel mature, but love the guidelines, but would like to see more content.

CA: Mike Gower has disagreed.

<Rain> +1 to Jake's comment, I had a hard time evaluating because it was too bare to really understand

MG: also think this feels draft-like and incomplete. I don't think this is a big impediment and feel like it needs a couple more drafts.

CA: if we address some of these and then take it to CFC would that be ok?

MG: yes.

JS: would like to ask Sarah if there's anything in MG's changes that would be controversial?

SH: I think the comments are all helpful and the kind of feedback we've been looking for, so getting it from AGWG is great. Would also like to get it from the general public.
… I don't think there's anything controversial and would like to ask for more of this kind of feedback from AGWG.

<Zakim> JF, you wanted to comment on the Tests

SH: not sure if can address everything fully for this release but could address for the next iteration.

JF: concerned with some of the normative text and feel like some of the tests are incomplete.

<Zakim> jeanne, you wanted to coment about tests

JF: I was struggling with some of the tests.

JS: wanted to add that the joint ACT + Silver group has been working on a new format for the methods. Will add a note that more ACT tests will be coming.

<JF> Identify inputs that only accept data in a given format.

JS: for the 4th quarter draft, we want the existing content rewritten in the new format and complete.

JF: what do we mean by "format"? I'm looking for greater specificity but can wait for the new content.

<Chuck> proposed RESOLUTION: Move amended Error Prevention Guideline to CFC for addition to the next update of WCAG 3.

CA: reads Wilco's comment.

MG: I found that the structure of 2 parts of the template caused some friction in reading them. Has left comments.

JS: we are tweaking the templates, haven't quite finished them yet.

<jeanne> +1

<bruce_bailey> +1

<JF> +.5

<Lauriat> +1

<sajkaj> +1

<Chuck> +.9

<sarahhorton> +1

<MelanieP> 0

<mbgower> 0

<AWK> 0

<kirkwood> +1

<Rain> 0

<JenniferC> 0

<ShawnT> 0

<OliverK> +1

<jenniferS> 0

<KimD> +1

<Raf> 0

Resolution: Move amended Error Prevention Guideline to CFC for addition to the next update of WCAG 3.

Editors Note about Approach

<Chuck> https://lists.w3.org/Archives/Public/w3c-wai-gl/2021JulSep/0072.html

CA: there is some proposed new wording for the upcoming release.
… we spoke about this last week. This proposal has evolved over the past week and now. We're hoping there's support on this call for this editors' note.

<JF> https://www.w3.org/TR/2011/WD-html5-20110405/

JF: in principle, I support this but wonder if we can use a mechanism like this former HTML5 working draft (https://www.w3.org/TR/2011/WD-html5-20110405/) Can we look to adopt something like this for our working drafts?

<Zakim> jeanne, you wanted to say that it goes in each of the draft documents which is needed for the Explainer CFC

<Rain> +1 to adding an obvious and always visible note (though not a scary one)

<Lauriat> +1, with Rain's point

JS: Interesting and pretty cool idea. Decision for that would be Michael's.

<ShawnT> +1 to JF's suggestion

JS: part of what we're trying to do today is to agree to get this content into the explainer so we can get the next quarterly draft out on time.

CA: I like the format as well but we don't have time to adopt it for this release.

WF: asks why we're doing regular updates when content isn't always ready vs. when it is.

CA: Silver is working on an iterative model to allow the public to review earlier so that the public can give us more feedback more quickly.

<Wilco> +1

RM: agile-type approach is very valuable, but if we release things in a too-early state, we risk fatiguing authors and the public who are reviewing work that's too "early stage".
… can we have a "release bar" where a level of completeness / quality is met?

<kirkwood> +1 to Rain, if we don’t know who would?

<JF> +1 to Rain - we don't have a "change log"

<Zakim> jeanne, you wanted to answer wilco on heartbeats

<JF> *log

RM: I worry about the broader community feeling overwhelmed.

<mbgower> +1 to Rain

JS: in general, W3C working groups have a regular cadence of releases, which is encouraged by W3C management. Many groups publish monthly.
… we thought when we chose quarterly releases that we would be told that wasn't often enough.
… this is bringing us inline with other major W3C groups.
… how much we publicize the release is up to us. What I would like to do with the next heartbeat release is tell people which sections have changed so people get the pertinent info to review.
… appreciate Rain's feedback but do need to have a regular release cadence.

DMc: I feel that the team working on Silver has worked really hard and has a working culture and it might be disorientating for them to be thrown into the AGWG group which has a different way of working and different people.

<jenniferS> +1 to davidmacdonald (I suspect this was alleviated by the in-person meetings that used to occur)

DMc: If possible, would it be able to pause / slow down the cadence until both groups know each other better?

<Zakim> Chuck, you wanted to address david's commetns

WF: wants to clarify that I'm not against regular releases.

WF: It seems to me that this group hasn't formed its opinions on the new content yet and that feels too fast.

<Zakim> AWK, you wanted to say that heartbeat publications is not new.

WF: it's great that the W3C management wants more regular releases, but there are plenty of groups that haven't released in ages, so if we slowed down our releases that wouldn't be exceptional.

AK: agrees with Wilco on release schedules and David on task forces working together.

<Zakim> Chuck, you wanted to make a proposed path forward

AK: in the past, there has been some issues with task forces and working groups disagreeing.

CA: hopes to set expectations on the timing on this heartbeat release.

MP: I've looked for a definition of a W3C heartbeat release but can't find it. Having that information would be useful in helping to understand expectations for releases.

<Chuck> proposed RESOLUTION: Accept editors note about approach to support the explainer being sent for CFC.

SH: are you looking for feedback in the concept of the note or the substance of it?

<david-macdonald> https://lists.w3.org/Archives/Public/w3c-wai-gl/2021AprJun/0243.html discussion of heartbeat

SH: maybe we should say that there could be changes to structure and style.

RM: I'm hearing discomfort with this.

<Rachael> option 1: Move forward with this heartbeat and then revisit approach option 2: Delay this heartbeat and discuss approach

<jeanne> -1 to not commiting to a Q3 publication

<jeanne> Option 1

<david-macdonald> 2

<Chuck> Option 1

<KimD> 1 PLUS discuss approach for future

JA: I'm hearing that it's not purely about the approach, but there are returning concerns from different people about the alignment on how we approach things

<JF> +1 to jake

JA: from Silver task force and AGWG. It feels like we're hearing concerns that we haven't discussed.
… it feels like we need to be a better "group together".
… it doesn't feel like we're all aligned.

CA: since we've made some commitments and expectations, we're not any worse of off by meeting those and then starting a conversation next week on approach, etc.

<Zakim> JF, you wanted to ask who made those commitments?

CA: this will allow us to meet expectations.

JF: who's the "we" in the "we made some decisions"?

<Zakim> sajkaj, you wanted to discuss option 1 but also to discuss the expectations during TPAC

JF: I don't think there's a huge harm in missing a heartbeat, I think it's happened before in the W3C. We need to stop, have the hard conversations, and get reorientated.

<AWK> FYI, the "heartbeat" requirement was in section 6.2.7 of earlier versions of the process document. Now it is in section 6.2.6

<AWK> A Working Group should publish a Working Draft to the W3C Technical Reports page when there have been significant changes to the previous published document that would benefit from review beyond the Working Group.

<AWK> If 6 months elapse without significant changes to a specification, a Working Group should publish a revised Working Draft, whose status section should indicate reasons for the lack of change.

JS: not publishing can be as bad as publishing poor-quality content.
… TPAC is coming and this is an excellent opportunity to sit down for half a day and talk this through.

<Zakim> jeanne, you wanted to answer JF on making commitments

JS: there's not enough time in a two-hour weekly call to do this.

JS: the person who made the release commitment was Michael Cooper.
… it wasn't a decision I made. It wasn't a decision that was made at a task force or working group level.

<Zakim> JF, you wanted to note that the heartbeat is a (RFC 2119) SHOULD: https://www.w3.org/2020/Process-20200915/#revising-wd

CA: with chair hat off, I'm being persuaded to pump the brakes.

JF: we're not obligated to publish right now—RFC 2119 has this as a "should".

<Rachael> option 1: Move forward with this heartbeat and then revisit approach option 2: Delay this heartbeat and discuss approach

<Zakim> jeanne, you wanted to say that we need something before TPAC when eyes are typically put on the group

alastairc: thanks :)

<Wilco> option 1 seems reasonable to me, can live with option 2

<Chuck> option 1 (still)

<sarahhorton_> option 1

JS: we should publish something before TPAC.

<Lauriat> option 1

<JF> TPAC 2021 starts 2 months from tomorrow

<alastairc> option 1

<KimD> Option 1, PLUS process clarity in near future

<jeanne> option 1

<AWK> Option 2, hopefully a short delay.

<JF> Strong OPtion 2

<MelanieP> 2

<ShawnT> 2

<JenniferC> Option 2

JS: we're looking at, in a 6-month period, about not having published much of substance and am very concerned about getting into trouble with the W3C.

<Rachael> 2 with short delay

<david-macdonald> 2

<JakeAbma> 2

<Rain> Strong option 2, but can live with 1 as long as the process is discussed

<bruce_bailey> option 2

<sajkaj> ~option 1

CA: decision of the group is Option 2.

<mbgower> can live with either

<Rachael> +1 to JF but perhaps mid september to allow for pub time

<Lauriat> +1 to JF

<Chuck> +1 to JF

JF: TPAC is in 2 months. Do we want a date, e.g. end of September, to publish?

<JenniferC> +1

<jeanne> +1 to mid September -- it is still Q3

RM: it would be good to have something in mid-September to be ready for TPAC.

<Chuck> proposed RESOLUTION: Slip next WCAG 3 heartbeat to mid-September

<JF> TPAC starts Oct 18th

<Chuck> +1

<jeanne> +1

<Rain> +1

<Rachael> +1

<AWK> +1

<bruce_bailey> +1 for mid september

<kirkwood> +1

<KimD> +1

<Wilco> 0

<MarcJohlic> +1

<Lauriat> +1

<sajkaj> +1 reluctantly

<david-macdonald> +1

<JF> +.75 (I'd rather still shoot for end of Sept.)

<MelanieP> 0

Resolution: Slip next WCAG 3 heartbeat to mid-September.

Sarah: thinking that it would be helpful to define what is needed for the next working draft for 3.x.

Chuck: Agree, we need to discuss. Will add as agenda item for upcoming meeting

Sarah: to address document content needs or group expectations, or both?

Chuck: think both

<Zakim> JF, you wanted to suggest that part of that mid-Sept deadline is revisiting the comments from our FPWD - have any been resolved in the new heartbeat?

JF: Sarah's q is good. Also want to make sure that the next draft also addresses comments from public review.

<MelanieP> +1 to John

<Zakim> jeanne, you wanted to answer JF

Jeanne: so far we have addressed 30-40 comments in this draft. Need to count the total to give a percentage.
… only CFC is the ACT one and that addresses 18 comments
… some other ones are ready to close related to subgroups
… explainer doc will address 5-8 more

JF: We should define what we want for the Sept WD
… that helps show more quantifiable progress

Janina: Also pointing out ITI comment on user generated content. Other issues raised are going to be addressed also and will be good to get feedback

WCAG 2.2 Consistent Help: https://www.w3.org/2002/09/wbs/35422/22_consistent_help/

Chuck: Shifting our focus to WCAG 2.2 issues

Question 1 - Consistent Help note doesn't make sense to me #1924

<mbgower> agreed, Alastair

AC: All comments are resolved except Ben's. Not sure that his suggestion addresses his comment
… can follow up with Ben

<Chuck> proposed RESOLUTION: Accept amended PR 1984 to address issue 1924.

<mbgower> +1

<Rachael> +1

<Chuck> +1

<JF> +1

<alastairc> +1

+1

<OliverK> +1

<Jennie> +1

<sarahhorton_> +1

<Raf> +1

<ShawnT> +1

<StefanS> +1

Resolution: Accepted as amended

Question 2 - Success Criterion 3.2.6 Consistent Help (A) #1892

<Chuck> https://www.w3.org/2002/09/wbs/35422/22_consistent_help/results

Rain: responded to the idea that whether the help exists is out of scope since it isn't on the web
… those clarifications should be included with the number

AC: Vaguely recalls discussion hours of operation aspect

<Zakim> Rain, you wanted to suggest "the status of help availability is indicated"

AC: challenge coming up with something in web scope

Rain: something like "hours of support or operation are indicated"

<JF> status or availability?

<Jennie> I think the issue was when there were smaller websites without an active phone number because someone could not guarantee a response.

AC: may be harder than it seems

<Zakim> Chuck, you wanted to echo that recollection

RM: Can we address in U doc?

JF: clarifying status and availability
… tend to agree that small orgs will struggle with that a part of the requirement

AC: Core of the Q is should we reorder the items in the SC to suggest a prioritization
… believe that the answer is no - we aren't trying to rank them
… so documented in U doc

<Zakim> Chuck, you wanted to agree that the availability/status can/should be a separate issue.

Jake: thinking about this and thought that if it wasn't available it isn't available for anyone, so this may be a usability question

<Chuck> proposed RESOLUTION: Accept amended PR 1968 to address issue 1892.

<Chuck> proposed RESOLUTION: Accept amended PR 1968 and response to address issue 1892.

<sarahhorton_> +1

<Chuck> +1

<alastairc> +1

+1

<Rachael> +1

<Rain> +1

<Jennie> +1

<Raf> +1

<OliverK> +1

Resolution: Accept amended PR 1968 and response to address issue 1892.

<bruce_bailey> +1

<JakeAbma> +1

<kirkwood> +1

WCAG 2.2 Redundant Entry: https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry/

<Chuck> https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry/results

Question 1 - Clarify "available for the user to select." #1973

MG: Found that the bullets made it harder to read
… suggesting edits

CA: Perhaps MG can edit the PR for next week?

MG: Away next two weeks

MG: Would be clearer without the bullets right now, IMO

Question 2 - Ensuring single transactions (from the user's perspective) are covered #1880

CA: No resolution on question 1

AC: tricky one.
… small providers could put in a service button for payment
… hard to ensure that information the user has put in gets transferred to 3rd party provider
… so session becomes a confounding factor
… session was added to clarify scenarios with multiple purchases

DM: thinking about 3rd party content here

<alastairc> SOrry, missed linking to the issue, which was: https://github.com/w3c/wcag/issues/1880

DM: in silver it is looking to be in scope
… may impact our thinking here

MG: recollection was that we added "session" to be clear that the information wouldn't be retained over a longer period of time
… we need a delineation for 3rd party stuff
… there is also a concern about security of content

<Zakim> alastairc, you wanted to say we're very much in wcag 2.x conformance and to say it's about 2.x conformance, and https://www.w3.org/TR/WCAG21/#cc3

AC: way forward - remove session and keep process and add info to U doc
… "if you complete process and come back on the same site, that is a new process"

<Zakim> mbgower, you wanted to say we didn't want it to be perceived as a requirement to retain user information between partial sessions

<kirkwood> suggestion: “process and/or session” ?

CA: AC suggested an amended option 1

MG: we wanted to avoid any suggestion that authors needed to retain info between sessions

<alastairc> Already in the understanding doc: "This Success Criterion does not add a requirement to remember information between sessions. A <a>process</a> is defined on the basis of an activity and is not applicable when a user returns after closing a session or navigating away."

<mbgower> Okay. I can live with that.

<Chuck> proposed RESOLUTION: Accept amended option 1 and PR 1992, scope in 3rd party providers

"Past AC" thoughtfully already wrote the U doc text and it is in the doc

<sarahhorton_> +1

<OliverK> +1

<ShawnT> +1

<bruce_bailey> +1

<mbgower> +1

<Raf> +1

+1

<kirkwood> +1

<mbgower> (scoping in 3rd party)

Accept amended option 1 and PR 1992, scope in 3rd party providers

Resolution: Accept amended option 1 and PR 1992, scope in 3rd party providers

Question 3 - Does redundant entry require saving PII? #1843

Personally Identifiable Information

<Chuck> proposed RESOLUTION: Accept Alastair's response to address issue 1843

<Chuck> +1

<OliverK> +1

<sarahhorton_> +1

<jenniferS> +1

<Rain> +1

<bruce_bailey> here is a ref for PII https://www.gsa.gov/reference/gsa-privacy-program/rules-and-policies-protecting-pii-privacy-act

Resolution: Accept Alastair's response to address issue 1843

WCAG 2.2 Page break navigation: https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/

Question 1 - Are pages with print CSS that includes page breaks excepted? #1868

<Chuck> https://www.w3.org/2002/09/wbs/35422/wcag22-page-break-nav/results

<Chuck> proposed RESOLUTION: Accept proposed response to address issue 1868

<Chuck> +1

<sarahhorton_> +1

<ShawnT> +1

<mbgower> nice segue, John :)

<Raf> +1

Resolution: Accept response to issue 1868

Question 2 - Is EPUB Web Content? #1869

<david-macdonald> agree

<Chuck> awk: I think it's an incorrect spelled word.

<Chuck> proposed RESOLUTION: Accept amended PR 1994 to address issue 1869

<alastairc> "The scope of this criterion is web content which is part of a <a>Web page</a>. EPUB can fulfill this definition if it is available to read at a URI. The more common case that is in scope is an EPUB book converted to be read by a web browser."

<kirkwood> Fulfil and fulfill are both correct spellings of the same word

<Chuck> +1

<ShawnT> +1

<sarahhorton_> +1

+1

<OliverK> +1

<JF> per Grammerly :-)

<Rachael> +1

<alastairc> +1 despite the spelling

<Raf> +1

<david-macdonald> 1

<JF> +1

<mbgower> +1

Resolution: Accept amended PR 1994 to address issue 1869

Question 3 - Google feedback

<alastairc> https://github.com/w3c/wcag/issues/1893

<Chuck> proposed RESOLUTION: Accept proposed response to address issue 1869

<Chuck> +1

<ShawnT> +1

<Chuck> awk: Comment, it sounds like the wg doesn't have browser based epub readers.

<Chuck> alastair: didn't mean to give that impression.

<Chuck> awk: An ebook rendered within a browser still has a reader around it?

<Chuck> awk: That's from response.

<Chuck> awk: refer to "outside of a browser based epub reader"

<alastairc> " As explained in the note at the bottom of the intent, it would apply to an HTML (browser) based version of an e-book (including ePub files rendered by a browser). An ePub file rendered by an ePub reader would typically have the navigation provided by the user-agent."

"Also, the SC is unlikely to apply to ePub files being shown only in an ePub reader. As explained in the note at the bottom of the intent, it would apply to an HTML (browser) based version of an e-book (including ePub files rendered by a browser). An ePub file rendered by an ePub reader would typically have the navigation provided by the user-agent."

<Chuck> awk: first sentence.

<Chuck> alastair: shown offline in an epub reader?

<Chuck> awk: or only shown offline in an epub reader.

<mbgower> Yeah, take it out

<Chuck> dm: Is there an "onlineness"? Amazon is online.

<Chuck> alastair: Cloud kindle reader is an example.

<Chuck> dm: Is a kindle reader at an url?

<Chuck> alastair: There is a browser based kindle reader.

<Chuck> jf: There are browser plugins.

<mbgower> "As explained in the note at the bottom of the intent, this Success Criterion would apply...

<Chuck> proposed RESOLUTION: Accept amended proposed response to address issue 1869

<Chuck> +1

<ShawnT> +1

<sarahhorton_> +1

<OliverK> +1

<JF> +1 to wordsmithing

<mbgower> +1

<JakeAbma> +1

Resolution: Accept amended proposed response to address issue 1869

Question 4 - What is and is not programmatically determined #1969

<bruce_bailey> +1

<alastairc> "For a Page Break Locator to be a "programmatically determinable destination marker", it needs to have a role that identifies it as a page break, and a method of determining which page in a sequence it represents. This would not apply to an element which visually shows a page number, unless it also had a recognised role. <a href="H99">Technique H99</a> provides an example of a page break locator."

<Chuck> proposed RESOLUTION: Accept PR 1995 to address issue 1969

<mbgower> +1

<OliverK> +1

<bruce_bailey> +1

<Chuck> +1

<david-macdonald> +1

<mbgower> recognize

<mbgower> also, it should be "has" not "had"

<kirkwood> ;)

<sarahhorton_> +1

<ShawnT> +1

<JF> +1

<Chuck> proposed RESOLUTION: Accept amended PR 1995 to address issue 1969

<mbgower> +1

Resolution: Accept amended PR 1995 to address issue 1969

Trackbot, draft minutes

<trackbot> Sorry, AWK, I don't understand 'Trackbot, draft minutes'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.