AG Working Group -- 03 Mar 2020

<alastairc> WCAG 2.2 Visual Indicators https://www.w3.org/2002/09/wbs/35422/Visual_indicators/results

<AWK> +AWK

<Jennie> scribe: Jennie

Alastair: We are looking for a scribe for hour 2
... any new members that would like to introduce themselves?

Oliver: I am a new member.

Pascal: I am a new member.

<alastairc> https://www.w3.org/WAI/GL/wiki/Scribe_List

Alastair: We try to rotate people doing scribing activities.
... this is a method of keeping notes during the meeting.

CSUN

Michael: More organizations are cancelling travel. At the WAI level we are still looking at it, to see if staff will go.

<Chuck> Until Oracle mandates no travel, I am planning to go.

Michael: for the Face to Face meeting we will make a decision based on the amount of attrition.

<Zakim> MichaelC, you wanted to give a bit of news if I can get my audio to connect

Michael: we hope to have information tomorrow.
... Does anyone know that cannot go?

<kirkwood__> Can’t go.

<AWK> https://www.w3.org/2002/09/wbs/94845/2020-03_F2F

Andrew: I know that Shawn asked in email for people to update their attendance in the survey, but it is closed.

<Wilco> I'm not, Deque decided today none of us are going

Michael: I can reopen it.

Andrew: I will not be going.

<AWK> Nicaise: not going

Wilco: Deque just announced that we are not going.
... an hour ago.

Michael: sounds like a lot of people have not said they are not going yet, but a lot of people say they have decided not to go.

<bruce_bailey> I have heard that Adobe, HP, Google, Amazon not going

Michael: Just got permission to share: a formal announcement will go out later today.

Chair announcement

Michael: a chair shuffle is occurring. Andrew will be stepping back.

<Chuck> Takes 2 of us to replace one Andrew!

Michael: Rachael Montgomery and Chuck will be joining Alastair.

Alastair: Everyone wants to thank Andrew!

<Chuck> Thank you Andrew... big shoes to fill!

<Detlev> +1 clap hands

<laura> +1

<maryjom> +1 Andrew, you've been a great chair.

Andrew: Thank you. I'm happy to have this collection of chairs, and thank you to Alastair.
... I have been the chair for 7 years!

Note: please do not share this announcement until official announcement later today.

Alastair: I am glad to have the 2 new cochairs, Rachael and Chuck!

<Fazio> Congratulations on a great tenure Andrew

Alastair: Any questions or comments?

<AWK> Thanks all!

Publishing ACT Rules https://www.w3.org/2002/09/wbs/93339/PublishACTRules/results

Alastair: 5 ACT rules.

Wilco: I think we can go through the comments.

Alastair: Image button has accessible name.

Chuck: If you choose not to adopt any of my suggestions, I'm still supportive.
... My concern: the name conveys that it is testing for the suitability of it.
... If it is testing that the string exists, then I would prefer a name change that describes this, but it is not a show stopper.

Alastair: OK. I'm wondering if that aspect is similar to Andrew's comment.
... My thought is because this checks for existence but not suitable, G95 includes the suitability aspect.

<AWK> How about "Image button has non-empty accessible name"

Wilco: that's correct

Alastair: Andrew's suggestion would help make the name clearer.

Andrew: I don't have the same concern as Chuck.
... but the name change suggestion may help those with concerns.
... Re the mapping piece: the 4th item (accessibility mapping) - I'm confused about what that means.
... That's why my comment about G94 came in.
... in G94 it says if you pass G94, further testing is not needed. Why is this needed in context of the rule?

Alastair: I have read it as if you have passed this rule, you have not necessarily passed G94

Andrew: OK.

Chuck: This is exactly my concern. You are testing the existence of text

Andrew: Right. This rule is not about appropriate text, it is a test that is much more machine testable.
... Is there a name, or is there not.
... if you pass it, you don't necessarily pass 1.1.1
... What Alastair says now clicks into place for me.
... You don't necessarily pass G94, because there are further steps there.

Alastair: Yes. That outcome mapping is for this rule, not for the technique.

Andrew: It might be rendundant, if it had said "further testing is needed to meet G94" or further testing needed to meet this SC might help me think about it in the right way.

Alastair: Wilco, do these suggestions sound reasonable?

Wilco: Yes.

<jon_avila> I agree with Andrew that it is not clear and could be seen that if you pass this test you pass G194.

Wilco: I agree.
... Re changing the name of the rule: as a non-empty accessible name - would that length the name too much?

Chuck: That sounds great to me.

<Chuck> +1

Alastair: Rachel suggests: Please consider referring to or adding the note about the title tag failure in at lease one AT/browser combination to the pass example section so that it is clear that while it passes there is a known issue.

Rachael: It says earlier in the document that there is no failure of the tag, it can pass as an accessible criteria.
... It would be nice to reference the known issue for developers.

Alastair: Yes. It shows a support issue, but that is still a passing example.
... Wilco - is that a complex thing?

Wilco: No, that seems fine.

Alastair: These are good suggestions. My comment was next.
... I found a typo, missing an "and"
... Is there a trigger for updating the accessibility support info? E.g. if a popular browser "that exists" changes it's behaviour?

Wilco: yes.
... What we did in the task force. We will review every policy within a year.
... That should be enough for that type of data.

Alastair: It looks like the glossary is shared content.
... It makes up a lot of the content.

Wilco: I think we can take out some of the glossary which is no longer necessary.
... and trim it down. I think there is value having it on the same page.

Alastair: When you read the 1st one, it seems like it is unique to that rule.

David M: Did anyone talk about the duplicate id?

scribe: I hope that will go to the validation side of things?

Alastair: We are still on the 1st rule.

David M: OK

<Zakim> mbgower, you wanted to say off topic a bit BUT is this division we're talking about between the existence of alt text and its meaning in G94 a potential path forward for silver?

Michael G: I am about to go on a tangent!
...G94: this has always bothered me about 1.1.1
... you need to have the meaning captured too. Is this for Silver?
... 2.0, 2.1 items: G94 could be under 1 SC that covers part at level 1 (or whatever) and the second part is if it is equivalent in meaning.
... the human intervention piece is a 2nd step.
... It seems to be an attractive potential.

Alastair: Yes, for anyone actively working on Silver.
... It is nice to have granular rules. We will not continue down that tangent.

John F: If you are interested, you should watch what is going on Silver.

Michael G: if that continues at CSUN, I will be.

Alastair: Any other questions or comments on the 1st rule?

<JF> To be clear - I was saying that my impression of Silver is going *less* specific and not more so

Alastair: We have some around the title, adding a note about the accessibility support failure, the typo. I think that is it.
... any objections to publishing this rule?

RESOLUTION: Publish Rule "Image button has accessible name" as amended

Alastair: next rule is that the HTML Page LANG is valid.

HTML Page LANG is valid https://act-rules.github.io/rules/bf051a

Alastair: 3 with comments
... Kathy Eng (on the task force) is asking for more implementations. I'm not sure what that means.

Wilco: I don't think that is relevant, because we are not including them here.
... they are for the community group to track.

Bruce: I asked Kathy, and she said most have 2 or 3, and this one has only 1. It is just a caution.

Alastair: I see 2.
... Chuck suggests changing the name to include subtag.

<CharlesHall_> late regrets / apologies. i have to drop off the call for an impromptu conflict.

Chuck: Correct. Same conversation as before.

Alastair: Andrew says: Should this rule have a note like the previous one which clarifies that this is testing the validity of the attribute value, not the accuracy of it:

Andrew: or both shouldn't have it.
... When the set is small, we should figure out what the rules are when we describe these things. It doesn't say it is a right.
... The rule is not able to say it is correct or not.
... We have in another one a clarification line.
... We should be consistent.

Wilco: I have been pushing back on adding notes about what is out of scope since everything else is out of scope.

Andrew: Agreed, it is really hard.

Wilco: Can I take this back to the task force?

Andrew: That is fine with me. It will make the task forces work better if you figure out the answer to this.

Alastair: this is not a blocking comment?

Andrew: Yes, this is not a blocking comment.

Alastair: We had no other comments. It is about the name, how we do notes. We can update those later depending on what the task force things about notes.
... Any other questions or objections?
... no other comments.

RESOLUTION: Publish rule "HTML page LANG is valid" as amended

HTML lang and XML lang match

Alastair: another similar rule. 9 publish as is, 1 comment.
... Andrew wants to remove some comments, which I think can be handled.

Wilco: yes

Alastair: any questions or comments?

David M: Just wondering about XML lang - we aren't using that on web pages any more?

<jon_avila> I don't think xmllang is used. Seems like an archaic test.

scribe: is that in regards to IE 10?

Wilco: Yes, but if you use both of them, with the wrong language in 1 of them, things go wrong.

David M: if the XML lang conflicts, mainstream screen readers will get mixed up?

Wilco: Yes, that's my understanding.

Alastair: Not worrying about the XML lang attribute will be fine.

<jon_avila> I agree with David -- I'd like to know more details about what browser the issue was in.

David M: if it doesn't match, it will be fine.

scribe: I think you fail if they are not the same.

Alastair: We will may not be able to answer the question re browser.
... is that a problem for publishing this rule?

David M: I'm not going to hold it up.

Alastair: OK.

<jon_avila> I'm not going to hold it up for publishing

Alastair: OK
... Any comments or objections to publishing both of the rules (#4 and #6)?

RESOLUTION: Publish "HTML lang and XML lang match" and "HTML page has LANG attribute"

ID attribute value is unique

Alastair: Some comments on survey
... Chuck and Andrew saying duplicate IDs don't necessarily cause failures.

Wilco: I agree that it doesn't always cause issues. It can. But WCAG says this is a conformance issue.
... it is to be consistent with what WCAG says should be done.

<JF> and I think that the W3C validator will complain about that too

Alastair: If we got to the point of removing 4.1.1 then this rule could go along with that.

Wilco: We don't get to decide which SC or part of an SC we get to keep or not.

Chuck: I am not wearing my chair hat, but my Oracle hat.
... We've always said that this is not something we are guaranteeing to address unless the customer can show it has real impact on accessibility.
... I agree it is in WCAG, but it doesn't always cause problems.

<AWK> +1 to Chuck

Chuck: It is still a concern to me.

Alastair: Andrew is agreeing.

David M: I'm in agreement with Chuck.

scribe: I think we can remove 4.1.1 and still be backwards compatible because of the language we have around accessibility support.
... I would rather not see this in our rule set yet.

<Chuck> +1 to David

scribe: It can stretch accessibility budgets.

Alastair: So hold until we resolve the 4.1.1 issue.

David M: Yes

John F: I understand the feelings people have around 4.1.1. Re duplicate value, it fails the W3C value.

scribe: I'm concerned about removing 4.1.1 because I think it will impact backwards compatibility.
... David - you are concerned about wasting people's time, but how many people will go back and do regression testing?
... myself personally, I believe this remains a legitimate concern.

<Zakim> bruce_bailey, you wanted to ask if we could tie this test to IDs referenced by ARIA attributes or other AT uses?

Brooks: I agree with John F.

<bruce_bailey> If there is a duplicate ID that AT needs, how could that not be problematics?

Brooks: I don't want to waste a dev team's time.

<alastairc> 1+ bruce

<JF> +1 Duplicate ID values fails the W3C valkidator: https://validator.w3.org/nu/#textarea

<Wilco> +1

Jon A: It is still a valid test for WCAG 2. I wouldn't want a valid test. If they choose to remove it for 2.2 that's fine, but it is still valid for previous versions.

Jon A: There could be other ways to meet the requirements, so I think it is worth continuing to have.

scribe: I think people can choose. It doesn't mean they are not conformant.

Bruce: I'm feeling swayed that we should wait on this one because there is a tendency for tests to focus on things that are machine testable, as opposed to barriers.
... Duplicate ids that impact accessibility, we can tie it to another failure.
... When being referenced by AT, it will lead to problems for a user, but this is rare.
... I would vote for not publishing this.

Alastair: OK. We have a few people thinking about WCAG 2.0 and 2.1
... others saying to wait until we have resolved the 4.1.1 issue.
... We do tend to have a set of associated documents in the Understanding Documents and Techniques.
... It is rather difficult to version our Understanding and Technique Documents.
... For me, I can appreciate the desire to wait until we resolve 4.1.1

Wilco: What surprises me is that nobody has disputed that it is a failure of 4.1.1
... Why then would we not test it?

Alastair: I think it is more a case of us wanting to encourage people to focus on this as a test.

<bruce_bailey> @Wilco because it is too easy for it to be a false fail

David M: When 3 or 4 objections to a change, you typically won't be moving forward with a change.

scribe: I am now saying let's leave it in, and in that case, I'm ok with publishing this.
... I am withdrawing my proposal to removing 4.1.1

Alastair: now you are happy to publish?

David M: not happy, but I want us to be efficient with our time.

scribe: If we aren't going to get 4.1.1 removed, we might as well publish.

Andrew: I don't think we should conflate those 2 things.

<bruce_bailey> LOL, David M talked me into changing my vote to NO, and now he wants to change his vote to YES

Andrew: I thought I heard David M say he wants to withdraw his proposal
... To answer Wilco's question about why not publish? My answer: it ends up being a test that people rely on which insists on engineering time being focused here.

<bruce_bailey> +1 to AWK explaination

Andrew: Duplicate ids that come in by the 100s, that engineers need to spend time on
... in my experience, this undermines the chatter and usefulness of an accessibility report.
... Will I live with this? Sure.
... Will we be sued if we have duplicate ids? It will be hard to show impact, but we would catch it in a different SC.
... Until we have that other discussion I think it is worth waiting.

Chuck: My position isn't tied to 4.1.1 conversation, but I reinsert David's 4.1.1 proposal.
... I still think there is enough of a resource suck in this, but like Andrew, if there is consensus otherwise, I'm not going to harshly object.
... I think it is worth waiting.

David M: I'm doing a study for the Canadian government looking at the automated tools.

scribe: Some vendors have expressed concerns about things that don't create accessibility issues.
... I bet there are tool manufacturers that will be accountable for this

John F: 1: I never really heard anyone answer Wilco's question - why will we test for this?

<jon_avila> It could have an impact in different responsive variations

scribe: Even if we can't demonstrate it doesn't have an impact today, we can't demonstrate it won't have an impact in the future.
... It doesn't pass the HTML validator. It may not impact screen reader users, but it may impact others.

<jon_avila> We have a Failure F77 -- should we remove it? F77: Failure of Success Criterion 4.1.1 due to duplicate values of type ID

scribe: It wouldn't be a lot of work if code was written correctly the 1st time.

<Zakim> bruce_bailey, you wanted to mention ADA drive-by lawsuites

scribe: We don't have evidence to prove there is no impact.

<Fazio> +1 to JF

<Brooks> +1 to JF's comments about how 4.1.1 is about the future, as well as the present state of content robustness

Bruce: Drive by lawsuits, about length of ramps, etc. Most of this time those are just lawyers.
... There are concerns there will be issues like this in the web world.
... Advising people not to be concerned with this...
... If a false positive is too high, why would we double down on it?

Wilco: I keep coming back to: it is in the normative part of WCAG.
... What concerns me is inconsistencies in organizations.
... testing different ways.
... It creates inconsistencies that ACT was designed to address.

<bruce_bailey> I will remind folks that we considered having semantic validity as an SC and we gave that up.

Wilco: We don't solve that problem. I would rather have the rule published, then have 4.1.1 taken out, so we can do it consistently.
... This would help improve consistency.

<jon_avila> If we don't test it automatically then people will be forced to test it manually in order to complete a conformance report.

Alastair: but from what we have been hearing, there are already organizations discounting this test because it will produce false positives.
... publishing this test makes it seem that it is still a valid concern.

<bruce_bailey> I think we need to figure out how to tie duplicate IDs to actual AT failues.

<bruce_bailey> It does not need to be 1:1, but it should be better than the current ratio.

Alastair: If in the mean time we publish something that requires 4.1.1 as it normatively is, it more the perception of it.

* Scribe change?

Alastair: either we publish it with this batch, or delay at least until we have discussed 4.1.1
... I would ask can you live with publishing this rule?

<alastairc> Question: Can you live with publishing this rule? (ID attribute value is unique), +1 for publish

Alastair: +1 for publish

<jon_avila> +1 to publish

<Brooks> +1

Alastair: -1 for not publishing

<Wilco> +1

<Detlev> -1 I'd rather not

<AWK> -1 for not publishing

<bruce_bailey> i disagree with the "can live" characterization

<Chuck> -1 I'd rather not

John F: The real concern is if the duplicate ids have an impact on users.

<david-macdonald> -1 I'd rather not...

scribe: That is not a false positive to the specification

<bruce_bailey> -1 for not publishing

<MarcJohlic> -1

<jon_avila> I agree with JF -- today it's not conformant to WCAG 2.0 and WCAG 2.1 and HTML spec

scribe: You are not using the HTML 5 specification as it was written.
... It is the application of the test may not have a measurable impact on users today.
... we have not done enough testing, and can't see into the future.
... I think we should publish it and move on
... if people don't follow it, that is there choice.

<laura> +1 can live with

<Fazio> hardcore +1

scribe: they may then have to justify it in a court of law.

<Nicaise> +1

<JF> +1 to publishing now

<AWK> 6 yes / 8 opposed

<Raf> +1

Alastair: we have most people having voted into IRC, and I see about 50/50 which is not consensus

<jon_avila> Seems like a vote to not publish is a recommend to tool providers to remove the this test.

<Rachael> -1

<Brooks> scribe: Brooks

<alastairc> scribe:Brooks

alastair: The change (to publish) is what needs consensus

JF: I fundamentally disagree with the idea that testing for duplicate ids isn't an important test.

Alastair: It seems the next trigger point for discussing this is the SC. 4.1.1 conversation.

<bruce_bailey> FWIW, back in the day, I was in the pro-validation camp.

DM: We've had a lot of controversy in the WCAG group about validation in the past. After much argument, the consensus of the group was to not go after issues that don't impact accessibility to preserve budgets to go toward issues that do impact accessibility.

RESOLUTION: Not to publish until discussion about 4.1.1 is resolved for WCAG 2.2

Alastair: We'll have to wait to publish this one until we revisit 4.1.1

WCAG 2.2 Review in steps https://www.w3.org/2002/09/wbs/35422/wcag22-confirm-before-submission/results

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

Alastair: This is one is building on WCAG 3.3.6 and maybe 3.3.3, as well. We already require confirmation before submission. This proposed SC requires being able to revisit the steps before submission.
... Reviewing Jake's comments. Considering how changes in responses, could change the logic.
... Jake is worried that the second bullet will be hard to maintain. I tend to agree that is difficult to scope.

stevelee: If you've got code, which is going to change what values are valid in one step, depending on a previous one, you've got to warn users about how the change will impact the rest of process.

Alastair: Messaging the user about the complex variations that are part of the form logic could be overwhelming.

<Fazio> I like this SC in theory but can see a potential for major cognitive overload

stevelee: trying to figure out how to best phrase what we are trying to get at

<Fazio> especially with the forms Alastair described

<alastairc> "Each visited step in a process can be accessed unless it becomes unavailable for logical, security, or privacy reasons."

Alastair: I'm worried about feasability. The warnings seem like a AAA variation.

stevelee: do we have best practice information listed below?

alastair: It could be listed in the Understanding document.

stevelee: We've discussed this one a lot.

Alastair: The context factor is difficult to capture in the SC language.

stevelee: The whole point of going back to a step is to allow the user to edit information in that previous step. That's missing now.

<Zakim> AWK, you wanted to ask how we know that going back through steps is best for users

AWK: If you have a complex form, let's say 100 questions broken into to 10 steps of 10 questions, it makes sense to be able to navigate by steps. But less complex forms don't have the same requirements. I'm worried that this SC could become too prescriptive.
... I'm worried that we might be taking one good solution to one particular form context, and applying that to all contexts.
... The way that the part about the warning is worded is awkward.

Kirkwood: I'm on now and able to answer any questions.

Stevelee: If there was just one step, maybe covering this under SC 3.3.6 would be best? If its a mult-step process, maby this SC would apply.

Alastair: We took out multi-step because it is part of a process.

AWK: The right way for a complex for to be handled is allow users to revisit and correct information. But, if it's something simpler, it may not be easier to break up the review of a form in a lot of unnecessary steps.

<AWK> Also, do we want this to be scoped to all processes or just ones that collect information

Stevelee: So, this comes back to scoping. Should we consider AAA status?

Alastair: AAA is for things that are difficult to apply across sites.
... A button that goes back, or breadcrumb trail wouldn't be hard to implement.

AWK: My point was that it is going to be difficult for content authors to know how to handle forms of varying complexity to conform to this Success Criterion as written.

Alastair: This seems to be a difficult thing to work out without a lot of examples.

Kirkwood: Could it be that the idea of "step" is general enough that being able to return to a step in a process isn't being as prescriptive as AWK had comment, and therefore not as much a burden?

AWK: I need to think more about that.

DM: I just tried to re-write the second bullet. Does what I wrote sound better?

Alastair: We're still trying to think about feasable this would be.
... I'm trying to think back through AWK's issue. Is navigating back through all of the steps the best approach?

<AWK> If information entered and then edited by the user invalidates other previously entered information, a warning is provided.

Stevelee: One requirement was to be able to go back immediately, is that correct?

Kirkwood: It isn't as much about going back immediately, its mainly about just being able to go back and understand the process. It's more than just a timing issue. It involves managing cogntive loads.

<AWK> 3.3.6 Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.

AWK: I feel like this is a solid thing that we could potentially agree upon. Depending on the scenario, I think there are ways to help reduce cognitive load, without stepping back.

Alastair: Would that be scoped to a process. It feels like SC 3.3.6 is different.

<kirkwood> Seems reasonable

AWK: What about "For each step in the process which requires the user to submit information, the following is true:"? We would probably still need the security/privacy piece on there.

Alastair: I think this would not require navigation between steps. We could still use the techniques that we've proposed.

<AWK> "For a process which requires the user to submit information the following are true"

Kirkwood: So what are we adding to SC 3.3.6?

Stevelee: The editor's note in the proposed SC is from SC 3.3.6.

Alastair: Wilco was not happy with the use of "step," as it is not defined. Maybe we should just address this in the Understanding document.

AWK: I think that there is a common understanding that you could have a procedural step.

Alastair: We like step better, because we don't want to define it as a per-page issue. It's a plain language way of identifying the thing.
... Wilco was also wondering about authentication. There's language in the proposed SC that seems to address that.
... Also had a question about the second bullet, in terms of warnings. I would be concerned about the feasability of that.
... I was proposing dropping that, because it could be creating as many problems as it solves - especially for larger applications.

AWK: I not worried about dropping that. If I change something, and something else is wrong now, I'm going to have to provide a way for users to change that.

Kirkwood: I don't think dropping the second bullet isn't a good idea.

Alastair: There are some ways to get around the warning, by adding generic warnings at the top of every page. We don't want that.

<Fazio> Yeah we want more simple not more complicated

Alastair: The cognitive overhead in going from the end of complex form to the beginning of a form could be tremendous, especially if users are having to process all of the business logic that could be made part of the warning messages. That's why I suggested to move it AAA.

Kirkwood: OK, I agree in taking the second bullet out for those reasons.

Stevelee: When is not worth mentioning warnings?

<Fazio> The human brain can only retain 4 pieces of information, thoughts, etc. at a time in working memory. Keep that in mind

Alastair: If you have to put a warning next to every input that could impact a later step, that could be an issue. Being selective about warning users when they've changed something that has an impact might be a better approach.

<Fazio> Call this info whaat shut it down

<alastairc> New bullet: "If information entered and then edited by the user invalidates other previously entered information, a warning is provided."

<Fazio> I mean all this info might shut it down

Stevelee: As final confirmation step in the end, it could give the warning then.

Alastair: This is being less prescriptive.
... Laura had comment that says the same thing that what Jake brought up. We need to define logical.
... We have again, overhauled this one.

<alastairc> first bullet: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission, unless the information cannot be modified for logical, security, or privacy reasons.

Stevelee: John, are you happy with that first bullet? It doesn't say you can revisit each previous step.

Kirkwood: So now, its "A mechnanism is available for viewing"

Alastair: I think we've addressed everything in the survey results.

Stevelee: So assuming everybody's happy with the changes, what's next?

Alastair: The first step, with this new version, I'll ask if anyone has any alarm bells ringing? Any concerns with the new SC text?

<bruce_bailey> phrasing of 1.2.1 (the following are true) is not consistant with 2.2.2 (*all* the following are true)

AWK: What is the text at this point?

Alastiar: It's your suggestion, Andrew.

<alastairc> For processes which require the user to submit information, all the following are true:

<alastairc> - A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission, unless the information cannot be modified for logical, security, or privacy reasons.

<alastairc> - If information entered and then edited by the user invalidates other previously entered information, a warning is provided.

AWK: We need a new name for this SC, because we aren't talking about steps.

Stevelee: How about "View before submit"?

AWK: I might call it "Error correction"

Stevelee: That is defintely the original intent.

Alastair: Let's go with "Error correction"
... I'll do another status update and send it around.

<AWK> or "Input review and correction"

<kirkwood> +1 to input review

Alastair: We will possibly have a full meeting next week. We'll discuss that with the chairs.

<kirkwood> Per awl

- DRAFT -

AG Working Group

03 Mar 2020

Attendees

Contents