<alastairc> agenda order 1,3,4,5
<alastairc> s/regrets: \/me/
<AWK> +Rachael
<AWK> +Bruce
<AWK> +AlastairC
<Jennie> I can scribe next week
<JakeAbma> me too next week
<alastairc> https://www.w3.org/2002/09/wbs/33280/2019-07_PR_ACT-Rules-Format/results
<AWK> AC: Documents sent around with agenda
<AWK> Public comment period complete
<alastairc> https://pr-preview.s3.amazonaws.com/w3c/wcag-act/415/a756dfc...30f013d.html
<bruce_bailey> IE do not have access to results in survey
<AWK> Wilco: Only needed to update a link, everything else is as proposed
<Rachael> scribe: Rachael
alastair: 33 supported, 1
abstained
... I think we need approval from the group to finish
publishing.
Wilco: To go to publication, the group needs to approve.
<AWK> MC: We don't need the WG approval to move to Rec
Michael: We don't need approvel. The director has to OK. The WG approval is assumed.
<AWK> ... It is in the hands of people higher up
<AWK> Wilco: wanted to bring up about what is currently going on
<AWK> ... we are hoping to publish along side 1-2 rules on the WAI website
Michael: that puts us very close
to the end of the charter. If we don't make it, we can publish
the rules format without the rules but we are trying to get
that done.
... we will have an update on the rules soon.
Alastair: were some published rules needed as part of the process or was it optional?
Wilco: It was. We have 12-15
published rules but we wanted to get more. Trying out review
process. Community group submitted a number of rules. ACT
taskforce is reviewing to make sure accurate and
consistent.
... task force is changing direction from spec writing to
reviewing. Working through rules to make sure they are good
quality before handing off to AG for final review. There is
over 50 rules.
... largely written by community group but by others as well.
Next step is to start incorporating them into the WAI
resources.
Alastair: Turn it into less of a request for approval. Now an announcement of publication is coming soon. Rules are in progress. WG will get notification when ready for review. If you are interested, you can see what the taskforce is doing.
Wilco: Also, we have seen a drop in participation since the SPEC is done. We are looking for people who are willing to help review rules. If you are interested in rules and reviewing rules for testability, we are looking for new participants.
Alaistair: Consider sending that request out as email. Does anyone have questions about Spec or ACT?
DavidM: Is there any interaction between ACT and Silver?
Wilco: No, we haven't looked at
this very much.
... I've reached out before but its worth following up.
... I think as soon as we have rules to show it will help. Its
been abstract in the past. Now we have content so its a good
opportunity to do that.
Alastair: Good point. As we progress through conformance, it all becomes more concrete. Any other questions
?
scribe: then thank you and well done. Almost there!
Alastair: The next item is
plugging the last gap in the 2.1 techniques. It has gone
through a couple of iterations and I think the survey may
include comments from previous version
... we cut down examples to 1. The previous failure examples
were too wide. I think Jake's comments are from the previous
version. I think Michael Gower's comments are on the new
version?
AWK: I think he added comments above the break. I think Mike is suggesting getting rid of the entire paragraph which will solve Jake's concern as well.
Jake: We wanted to add
personalization. This technique shifted to the use of/benefits
of autocompleting forms. This is not just autocomplete. I think
its incorrect to focus on just autocompleting. There is still
an issue for the end user.
... with the example of booking a vacation, you have 4 end
users and there is only 1 primary end user. It just doesn't
completely fit into that model and the explanation. If you are
filling out a form for a relative, the relative is the end
user. You can have multiple profiles stored.
... you have to read the text very well but there are some
loopholes or unclear cases where we might end up with people
asking if its correct.
<AWK> Bruce, Katie's concern predated the major overhaul of this pull request.
<Zakim> AWK, you wanted to say that autofilling forms is a possible benefit of 1.3.5 but we shouldn't focus only on that aspect. I agree that people are getting confused.
Jake: who is the end user? This is way better than it was before but it doesn't cover edge cases and too much focus on autocomplete.
AWK: I agree we should not just
talk about autofilling forms as the benefit of this SC. I think
it addresses some COGA issues but there is also the
personalization of adding icons or modifying text. These are
hard right now because the user agent support is so
nacent.
... one thought I had was to strip this technique down to a
single issue. If someone is relying on autocomplete to satisfy
this, they have to use it correctly. We didn't create a
technique for someone not using autocomplete. We should add
additional techniques.
... part of the discussion of this made me realize that we have
some gaps in what people thought was covered by this SC. Are
those things we intended or need to update in a future
version?
<david-macdonald> "...that request information from the user of the form" Should probably be "that request information ABOUT the user of the form"
Alastair: If we strip out the last paragraph of the description, which is in the understanding document, does that meet the concerns?
Jake: I will have to reread it.
It should be a very simple, clear technique. When you have to
provide name and email. I think the example is not currect. You
have to show a correct purpose in the wrong place. An address
instead of an email.
... if nothing is showing up, then autocomplete isn't being
used.
... If you are using an autocomplete, then AT can show an icon
that indicates where someone can enter their name and email vs
a field where the wrong property is used. Make it very very
simple.
<Zakim> bruce_bailey, you wanted to ask if anyone has insight to Katie’s concern? (she is not on the call, and the comment field is blank, but maybe this came up at Fukuoka)
Alastair: We have a sufficient technique on how to use it. The failure technique is the other side of the coin.
Bruce: Mine might be a new question. Did anyone talk to Katie at TPAC?
AWK: We did talk at TPAC and that
discussion led to stripping this down. I think that the changes
we are making are in line with that discussion.
... Jake, would you agree that in this example where it says
autocomplete="your_name" if this said autocomplete="email" it
would be a clear fail? Right token but wrong place?
Jake: Yes that would be a fail.
AWK: And in the second one where it says bday instead of birthday, is that a failure?
Jake: It makes it a bit strange. You are required to use autocomplete and use the proper value?
AWK: You are not required to use
autocomplete unless there is another way to achieve it.
Autocomplete is the easiest way to do that.
... I wonder whether we could change the first one to say
autocomplete="email" and then leave the second as birthday to
show both situations are a failure.
Jake: Its fine for this example but it's not complete. It is sad that this is just about autocomplete. Microform next to it makes it right.
AWK: What if we add "check that purpose is not conveyed any other way?"
Jake: then at least there is a note. Sure
Alastair: Any other questions?
DavidM: The first line said
"...that request information from the user of the form." Should
probably be "that request information ABOUT the user of the
form." Change from to about.
... this is probably a separate failure. The failure that
occurs when the autocomplete is placed on a field that does not
collect information about the user.
... Was it resolved?
Alastair: I think because autocomplete in HTML doesn't prevent it from being used elsewhere it seems controversial to ban it being used elsewhere even though it causes false positives. We are not in favor of causing false positives but there may be legitimate cases that we don't mean to ban
<Zakim> AWK, you wanted to talk about SC text "The purpose of each input field collecting information about the user can be programmatically determined when:"
AWK: The crux of the argument is
around the text of the SC that says it is about the user. It
doesn't say about anyone. Its hard to say the SC fails when it
doesnt' apply to the broader set of fields.
... I don't think we have a clear resolution.
... the counter is its difficult to tell the information about
the user when all the fields have the same tags.
MichaelG: I didn't think its relevant to the failure technique at all. It is good for understanding document. I thought it was supurfluous.
AWK: Whole paragraph?
MichaelG: The parts I pasted in. The example that exists is an example of using an incorrect one. I think Jake's idea of using the wrong one is also good to have as an example.
AWK: What you pasted in was the first 2 sentences. [andrew read what remains] My gut is that we should get rid of the entire paragraph.
Alastair: The 2nd half doesn't make much sense without the first.
AWK: Any other changes? They are implemented.
MichaelG: The second part does describe when the user agent grabs the wrong information which can be more aggregious.
<alastairc> Could still include: "Inputs that use the autocomplete attribute must use the correct token value, or else the user agent will be presenting information which is likely to confuse the user"
AWK: That case is more on the autocomplete side of things but can be included in the understanding. When we talk about this SC from the icon point of view, then this no longer applies. I lean towards removing.
Jake: I would like to see one
other change. It says in the text 1.3.5 uses autocomplete list
of token values. That is incorrect. We use the list that is
based on the autocomplete fill section.
... based on html token versions but we have our own version.
The list can be extended. We may add or delete. It is not the
autocomplete list of tokens.
<AWK> Success Criteria 1.3.5 is based on the HTML 5.2 <code>autocomplete</code> attribute’s fixed list of token values to because the programmatic association of specified token values (metadata) allows for other machine processing, such as expressing the input label in different modalities.
AWK: Can you suggest text?
Jake: We must refer to user input services. We created our own. Its based on it but not the autocomplete list.
SC 1.3.5 uses the input purposes for user interface...
<AWK> <p>Success Criteria 1.3.5 uses a list of tokens in Input Purposes for User Interface Components (based on the HTML 5.2 <code>autocomplete</code> attribute’s fixed list of token values) because the programmatic association of specified token values (metadata) allows for other machine processing, such as expressing the input label in different modalities.
<JakeAbma> Success Criteria 1.3.5 uses the Input Purposes for User Interface Components attribute’s fixed list of token values because
Jake: Fine with me. I'm not sure you need to mention the based on again but we dont' need to talk about it in more than one place.
AWK: This technique is about misuse of the values. I think establishing the connection is worthwhile.
Jake: We do mention it elsewhere but this is a lot better. One other thing: It says in bold, the end user. I'd like to scope it to the primary end user. There can be 4 end users for a family. So its the primary.
AWK: What paragraph?
Jake: The bold. Next
sentence.
... the idea was to focus on the one filling out the form. I am
the primary end user because I am filling it out for my
family.
... but the entire family is end users.
AWK: The spec doesn't talk about
the primary end user.
... my take is that there is only one user of the form but that
user is acting on behalf of others.
<alastairc> +1 there is one user, and possibly people they fill in on behalf.
AWK: but there is only one user. I think end user or primary end user are saying the same thing.
Jake: Trying to fill a small gap. Clarify that we are only applying to the person filling out the form. We are not focusing on the other people even if they have similar autocomplete values.
<mbgower> I think 'primary user' is over-engineering this, especially since it's just a failure technique.
Alastair: This point is important for the positive technique.
AWK: I just put in those changes. If you want to see it.
Alastair: Last call for comments
or questions about this failure technique
... any objections to accepting this as ammended on the
call?
<JakeAbma> one of each
AWK: Quick question: It looks like I changed the example such that both are valid autocomplete tokens. Do we like it like that or do want one that is correct and one that is incorrect?
Alastair: One of each
<mbgower> yep, 2 separate examples
Bruce: This is a slightly different example than we first started off with.
AWK: The first one is a name field with an autocomplete of email. So either it populates email or shows email icon next to the name field. The second will have birthday as the autocomplete value when it needs to be bday.
MichaelG: Just to confirm this is two examples?
AWK: No. What if I write a sentence that clarifies the difference?
Alastair: Any other
comments?
... To prep for the next bit, we have WCAG 2.2 major new SC
that we will be looking at shortly
Jake: We need a small change in the text. We need to add list to the "SC 1.3.5 uses a of tokens"
Alastair: The last one I pasted
in is hopefully the last version
... list has been added and the example has been updated.
... any objections to this version as ammended?
Jake: One more small item. The last sentence says an important part of this SC is... What is the other part? It suggests another part.
AWK: The other part is that you
use the right values.
... we could make it Another part... It leaves it less
hanging.
Jake: Fine with me.
RESOLUTION: Accept pull request 890 as ammended on call
<alastairc> Noting that #890 is based on #889, so both will be merged.
Alastair: We have 4 remaining SC from TPAC.
Alastair: it was called undo
errors but has a name update.
... Steve and John had been looking at feedback from previous
survey and making updates.
... I expect some results will be on the older version but we
do have some new comments as well.
As a reminder, "Before submission of a multi-step form entry process the user must be able to review, confirm or correct what they have entered in every step." Then it has 4 bullets
scribe: looking through comments. "unwanted" is an issue. I think this has been resolved.
<AWK> good question brooks
Brooks I am getting up to speed. One aspect I am interested in, is what defines a step? I think it informs content authors. I think it is a discrete request for data that is saved temporarily?
scribe: also will passing this SC require a logical relationship between the steps? If step 3 is dependent on answers provided in step 1, would that be important?
Alastair: The recognized
controversial bit is the last part where data will be lost if a
change is made. It's difficult to draw a line between a
legitimate case (changing destination on trip) with requesting
information repeatedly.
... things like process we have defined. I take your point
about what is a step? I think we need to be a bit flexible
about that. There can be logical steps from a user point of
view but it doesnt' matter whether it is a single page or not.
There may be definitions from elsewhere we can use.
<laura> Scribe: Laura
<Rachael> Brooks: I Think steps will help understand. keep it flexible
sl: trying not to be too
persciptive.
... so we didn’t describe what a step was.
brooks: is that tempraily saved?
sl: we had push back on that
too.
... that was s misnomer.
... should be able to review before you submit.
<johnkirkwood> agree to review and make changes 'not just undo' which implies just the last thing done
ac: suitable exception.
<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22reviews/results
ac: Bruce’s comment.
“I don't see how this could be Single A because there are technologies where Undo cannot be supported. I am even skeptical about this be AA, but could be persuaded.”
scribe: now talking about multi
step process.
... and has several requirements after that.
brucre: withdraw my concerns then.
ac: my comment. “I've put some
detailed comments in the document. Overall I think it has
potential, but I anticipate comments along the lines of:
Changing information in an early step of a process can
invalidate later steps/data. E.g. if the process has branching
logic you might go down a different branch. We can't wish that
away, so need some sort of scoping or exception for
that.”
... :”A good example to consider is https://111.nhs.uk/ which (I think)
has been usability tested a lot. You can use a random postcode
(e.g. BS1 4NT) to get past the first item.”
... think that it is fine now.
<bruce_bailey> i love Alastair's example about wanting to revisit logic tree and branching when the result/outcome seems poor
david: don’t know what the user
can do.
... don’t say the user can.
... words “clearly” and “easily” are problematic.
<johnkirkwood> rather than clearly and easily. Just need to say It is available?
david: WCAG uses passive language for good reasons.
MG: replaced preamble.
... very similar to multiple ways.
<johnkirkwood> that sounds right to me, Mike Gower
jk: happy with the changes.
ac: more about the content.
jennie: I like MG’s edits. somehting to clarifly visual and progamatic labels.
jk: don’t recall where labels came from.
david: at any time seems too broad.
JK: at any step in the process
david: possible to return to the updated summary.
ac: tricky one because of dependencies.
david: exception for mulit-branch forms
awk: talking about the visual label.
<Zakim> mbgower, you wanted to say that using words like "clearly labelled" are fine and beneficial in the Understanding document.
awk: like the SC concept. But we need to box it.
mg: need to make it testible.
elaborate in understanding.
brooks: when would a user have an
expectation that a summary woiuld be updated?
... provied instuctions to users as to what is left.
ac: make exceptions more concise.
jake: wondering if we need the 4
bullet points
... seems like they should be in understanding.
<johnkirkwood> agree with that
sl: perfer text to bullet points?
jake: in some processes there will be no summary.
<Zakim> AWK, you wanted to ask what is the difference between review and confirm
awk: what is the difference between review and confirm?
sl: may be a hangover.
<JakeAbma> 3.3.4 and 3.3.6 have same language
sl: it is redundant.
awk: review and correct may be better.
<Zakim> alastairc, you wanted to suggest people have a go in parallel at re-forming the SC text.
ac: a lot of ideas. difficult to do on a call.
<mbgower> This might work: In a multi-step process, all of the following are true: • A summary of entries in each step is presented before submission. • A user can return to prior steps without affecting entered data.
<johnkirkwood> +1
ac: have a group of folks get
together and edit the doc.
... any reservations on the SC?
... patrick had a comment. should look at that.
jake: what is the differens between 3.3.6 and this one?
sl: not just fixing errors. you may change your mind.
ac: scope is differernt.
... worth looking at 3.3.6.
sl: thank you. very useful discussion.
<Zakim> mbgower, you wanted to say I may have reduced this to two bullets?
<johnkirkwood> +1 to adding to document, great!
ac: seems like a reasonable SC
AC: value in the algorithm came from wcag 1.
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22reviews/results#xq16
<bruce_bailey> Rarely or never?
<bruce_bailey> https://github.com/w3c/wcag/issues/360#issuecomment-452655920
AC: updating shouldn’t make any diffences to the results.
bruce: normative typo.
... don’t think the change makes a diffence but we should check
the math.
david: 2 proposals on the
table.
... normative typo and relooking at the algorithm.
<bruce_bailey> i do not understand spotting a mistake, but then deciding NOT to fix it
ac: we are looking at normative
typo
... we could update it as a 2.2. thing.
... don’t feel strongly one way or the other.
... could put a note in underdanding doc.
jake: if we change the value do tools need to update?
<bruce_bailey> again, “not matter too much” is different from “we cannot find any examples where the math works out to different results”
awk: seem like a long time to do
an errata
... are we causing more problems by fixing this?
bruce: either way we should fix
it.
... need to engage with mathematicians.
david: we have very quick cycles
now.
... could create a lot of heat.
<bruce_bailey> if we have been using the wrong value, that does not really justify keeping using the wrong value now that we know better
ac: could be tricky to get feedback from tool makers.
david: wayne is a mathematician.
bruce: I will ask someone too.
<bruce_bailey> I will reach out to Jonathan Lazar at UMD
ac: wilco was leading this
one.
... Brooks was disagreeing with this one.
brooks: what comes to mind is an
implicit agreement between content authors, operating
system/browser/assistive technology manufacturers, users and
web technologies standards makers.
... more of the principle of it goining away.
awk: many instances of some small
issue and no user impact.
... can get to be a huge burden.
<alastairc> Suggest looking at what the tools currently look for: https://lists.w3.org/Archives/Public/w3c-wai-gl/2019JulSep/0223.html
awk: if it gets caught by another SC why is it in WCAG?
ac: sent a email to some tool
makers.
... doesn’t look like it will be a huge problem for them.
<alastairc> trackbot end meeting
ac: will be going into sprints.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) FAILED: s/regrets: \/me/ Succeeded: s/Brrooks:/Brooks/ Succeeded: s/ak/jk/ Succeeded: s/cocspt/concept/ Succeeded: s/qwill/will/ Succeeded: s/an correct/and correct/ Succeeded: s/patrick had a comment. may want to/patrick had a comment. should/ Succeeded: s/ether/either/ Succeeded: s/cyles/cycles/ Succeeded: s/UMB/UMD/ Default Present: AWK, Wilco, Rachael, Jennie, Bruce, AlastairC, stevelee, Raf, MichaelC, JakeAbma, Laura, david-macdonald, Brooks, mbgower, johnkirkwood WARNING: Replacing previous Present list. (Old list: KimD, Jennie, Jemma_, Rachael, Fazio, JohnRochford, alastairc, mbgower, romain, Katie_Haritos-Shea, JakeAbma, david-macdonald, DavidClarke, jamesn, Lauriat, stevelee, AWK) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK Present: AWK Wilco Rachael Jennie Bruce AlastairC stevelee Raf MichaelC JakeAbma Laura david-macdonald Brooks mbgower johnkirkwood Regrets: /me_hhmm audio_issue Found Scribe: Rachael Inferring ScribeNick: Rachael Found Scribe: Laura Inferring ScribeNick: laura Scribes: Rachael, Laura ScribeNicks: Rachael, laura WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 01 Oct 2019 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]