<JakeAbma> scribe: JakeAbma
<Jennie> Scribe: Jennie
<JakeAbma> scribe: JakeAbma
AC: any updates?
Janina: number of issues ready for feedback and if fine to be closed
<alastairc> Latest draft: https://w3c.github.io/wcag/conformance-challenges/#introduction
<stevelee> link?
Janina: will change heading structure for document, Michael helps us with that
Peter: really love folks to do is
to mention which issues are something to really talk
about
... and if some parts need to be changed before first draft
publishing
<alastairc> Any issues now, post issues in github. Then survey for next week, specifically on FPWD issues.
<janina> Editor's Draft: https://w3c.github.io/wcag/conformance-challenges/
Peter: work on this for this week, new survey will be made for next week then
<alastairc> https://docs.google.com/document/d/1J3NFw6NPyj7QGddBtRmagrtS-x4t9BWan8PYEdSpMZM/edit
<Detlev> Link in surves and IRC are the same I believe: 4th version
AC: lets start with survey one: https://docs.google.com/document/d/1dk4pYxq9vxj2E1GfeH6RGWvqvtCyGfLGDVFopNf8B_U/edit
John: will we keep touch in there or delete?
AC: touch has overlap with gestures, so might be deleted
John: if path based gestures are
in the air, then if needs to be in the text
... no overlap with hands in the air, as it is not ' touch'
<JohnRochford> Wow, great examples, Jennie!
Jennie: I recommentd keeping
touch
... multiple ways of haptic feedback and ways of responding to
this feedback, for the purpose of tranfering information
AC: will haptic cover both?
Jennie: not sure from AT
perspective
... I like the concept of possible inputs and outputs, but
there's also the decoding aspect
<stevelee> +1
Jennie: we need to keep cognitive and coding in there
Raf: there have been some concepts of rith on the phone
rithm
<alastairc> tapping / rythm
AC: ok, happy to keep touch in
MG: we have keyboard and pointer
gestures SC already, some issues should be added to odality SC
not authentication
... would like a modality SC
<Detlev> +1 to Mike
<alastairc> Note: Entering information into an input field does not in itself require a particular modality as it could be accomplished by keyboard, voice input, or any other accessibility supported method. The success criteria is triggered when a particular modality is required by the content, for example, requiring a password triggers the cognitive function test modality, entering the password in an input field does not.
Steve: the cognitive challenge should be important
AC: but biometrics are also important, and the reason we added them
MG: we're talking about web here, it's strange to come up with biometrics right now
AC: will undermine the modality approach right now
Steve: separation might be a good thing, not all in single list
Jennie: when I hear cognitive
load, that is different than cognitive function test
... I agree we can remove input / output components, focus on
the cognitive part, make it more discreet
<Zakim> mbgower, you wanted to say does anyone have the SC wording from the 2.1 proposed SC?
<alastairc> https://github.com/w3c/wcag21/issues/23
<JohnRochford> Previous version, from 2016: An alternative user authentication is available for users who are unable to use the primary user authentication method, unless it can be shown that all users have access via the primary method. This alternative user authentication method does not rely upon the user's ability to do any of the following: memorize character strings, including memorizing correct spellings; or perform calculations, such as including correctl[CUT]
<JohnRochford> entering numbers and letters from a character string; or speak; or reliably produce gestures; or recognize characters presented on screen, and then enter them into an input field.
AC: summary not to rely on cognitive function test , unless there's an alternative
John: biometrics is the only one without cognitive test of some sort
<JohnRochford> Correction: Steve, not John, said that.
<Zakim> mbgower, you wanted to say the yahoo method is just a prompt
<johnkirkwood> what about the interpretation of strange looking characters/letters
MG: landscape is changed a lot, and re-authentication is much easier, we should focus on the cognitive part
<alastairc> If a method of authentication relies on any one of the following modalities, at least one other method must also be available that does not have cognitive function tests and also does not rely on the same modality.
<alastairc> https://docs.google.com/document/d/1dk4pYxq9vxj2E1GfeH6RGWvqvtCyGfLGDVFopNf8B_U/edit#
<JohnRochford> Alternative SC text: If a method of authentication relies on any one of the following modalities, at least one other method must also be available that does not have cognitive function tests and also does not rely on the same modality.
<jon_avila> I've heard of phishing scams where that bad person call someone and then says they are with the X company and that they will send a text messages to your phone to confirm they are real and to answer yes. When they answer yes in the text message the bad person is then logged in and the then repeats information from the persons account to gain credibility.
<alastairc> If authentication relies cognitive function tests, then there is another method of authenticating.
<Jennie> It is also format - not just the number of characters. E.g. space included between numbers?
<Jennie> Scribe: Jennie
Detlev: Rereading text pasted
above.
... relying on one of the following modalities...
<mbgower> And is the ability to copy/paste considered to be covered by "transcribing characters"?
Detlev: the question is when does
the method of authentication rely on a modality.
... e.g. only biometric.
<JohnRochford> Most common password is a blank one: https://www.forbes.com/sites/daveywinder/2019/09/21/the-most-common-and-insecure-password-revealedits-not-123456-or-admin/amp/
Detlev: does this mean only cases
where there is no password or other keyboard accessible way of
authenticating.
... is that our focus?
<JakeAbma> +1 to Detlev, as my comment in the survey is exactly the same
Detlev: does rely mean that is the only way of authenticating?
Alastair: Put aside things that are already accessible. Think about remembering a password, transcribing information from one place to another.
Detlev: that seems to mix modality of sensory input and output with the cognitive pieces
Steve: Isn't the idea now to replace the word rely?
Alastair: The feedback I'm
hearing is it is hard to understand the categorizations,
especially on the web.
... We are more restricted with what websites can do to
authenticate people.
... What I heard proposed is to say "If it relies on cognitive
function tests"...
Detlev: so we would need to more clearly define what is a cognitive test?
Alastair: Yes, there is a definition of it.
<JohnRochford> Cognitive function test text: Cognitive function tests: Include memorizing character strings (except for your own name, email address, or national identification number); using correct spelling; performing calculations or puzzles; and transcribing characters into an input.
<mbgower> I put a comment into the doc which actually breaks it down into JUST measures of cognitive function
Alastair: but that's the principle.
Steve: yes, I'm happy with that.
Alastair: in some senses, we
would not be covering certain future situations that modalities
might help with,
... but it might make it a more understandable SC for the
current environment.
<JakeAbma> new text still says " relies on any one of the following modalities"
John R: Yes, and along the way we got feedback that said we should include these other modalities
scribe: I think removing them is a much better idea.
Alastair: Mike has put an idea into the Google doc.
Mike G: it sounds like we don't want any of these to be done.
Alastair: If people have any
further comments, and we will need to update the Understanding
Document
... Does anyone object to pairing it back to the original
intent?
<mbgower> +1 pare it back
Alastair: John if you can have a look at Mike's comment, that's a good starting point.
John R: I will do so.
Alastair: Any other comments?
Alastair: this is a new one.
<alastairc> https://docs.google.com/document/d/1pcg6ixAfuwlo6jb2tkZBGTDhF0fAiO49h21E6HCbQ6I/edit
Alastair: I see Jake did lots of comments in the document.
Jake: I did paste them in the Understanding also
Alastair: quite a few of the
comments you made into changes in the document?
... was there anything in the survey you didn't change in the
document or add?
Jake: I placed all comments in the document also.
Alastair: A few things from Steve
Steve: It was renamed, because it
is about confirming before submission.
... the updated text says that.
Alastair: This looks like it
expands on 3.3.6 which builds on 3.3.4.
... On the assumption that at the AA level it was scoped to
legally binding things, and was narrower than it could have
been
... Is it because there is a new user requirement that was not
previously covered, or is it narrower than the previous
one?
... or is it that the technology has moved on and it is easier
to meet?
Steve: This came from one of the
requirements we had in the COGA task force.
... I think the reason is it was felt it wasn't good enough for
the cognitive use case.
... it is the "easily go back" piece so people can more easily
make changes.
John K: Yes, that was the issue - the ability to get back to a specific place in a multi step process so one could correct information.
scribe: and not get lost cognitively in a multi step process. You can see the end results, and then go back to step 5 without going through the whole process.
Alastair: That's fine. It would
be useful to point to whatever theme or research COGA had. I
didn't see it.
... If the justification is it is not covering the cognitive
need as much as we need to, that is fine.
John K: Yes, that is my recollection.
Steve: We will go through the Gap
Analysis - pretty sure it is in there.
... we are currently mapping the requirements, so this may
catch that.
Jake: What did we try to solve
with this success criteria? The intent gives me the idea you
need to be able at any step to be able to get to the others -
that is clear.
... But in the text right now, it also mentions the overview
before final submission, and once you have completed steps it
says some information is added automatically.
... 1 of the issues I added into the survey is that there is
another one for steps - Information in Steps, which is about
autopopulating information.
... That could be deleted for this so it is only about being
able to go backward and forwards, but that is also part of
3.3.6 and 3.3.4, so we need a good understanding of what we are
trying to solve.
Steve: The summary of all entries is covered by 3.3.6?
Alastair: Yes, except that is AAA. And the other refers to legally binding transactions.
Steve: the traversing the steps
has been crossed out - Jake's proposal.
... Keep the first one in because of the level.
... The second one is the crux of the issue - you can get back
to edit.
... The 3rd one is overlapping - you are correct.
Alastair: I think that is David Fazio's.
<alastairc> The overlap could be with info in steps: https://docs.google.com/document/d/18MCz5XDsMmglcAe2j-HzQbpADpw_HtdVjDZ3EHX4-xk/edit#
Steve: the point of that one is that if you enter something once, you shouldn't have to enter it in another step.
Alastair: Yes. This is
progressing fairly well.
... read text from link above).
<johnkirkwood> i think there may be a bit of cross over.
Alastair: This one is about making sure you can go back. There is potential overlap, but there is a difference.
Steve: Do we want 2 SCs?
Alastair: if one gets through and
the other doesn't...
... Jake's made some suggestions. I would suggest not accepting
the deletion of the final bullet just yet.
... My question is whether anyone has any potential objections
with the approach to the success criteria text?
Jake: If we talk about the 1st
bullet: a summary of entries in all steps is presented before
final submission. This can be read in 2 ways.
... in every step, you see a summary
... or a summary is presented before final submission, like an
overview page.
... I know the first page, in the Intent, that it is not about
the overview page, so people don't need to wait for this.
... so people do not forget the issue.
... also a summary of all entries at all steps - needs to be
reworded.
Alastair: I think we need to lean
on how we describe the input
... For a funding application with 6 major sections, each one
of which you want to define as a process. Each has its own
summary page.
... but the entire process has its own summary. If you have
each entry, it would be complicated.
... Imagine it is grant funding, this is the purpose, this is
what we do with the grant, here are our financials.
... Then you get a summary of what you have entered. In this
case i would want each section to be defined as a
process.
... If we give examples this is what is needed.
<Zakim> mbgower, you wanted to say that Rachael and I drafted something very similar for each of the bullets last time
Mike G: I hate going back to 2.1, but we had an SC that was similar to the 1st bullet of this, and one for the exception of this.
scribe: I will locate the
information and forward this on to Steve?
... Yes, I will forward to Steve.
... Last time we restricted this to information that would
cause legal or financial transactions, because it becomes
difficult to say what is a multistep process.
... Otherwise any questionnaire, any single page with multiple
fields, it can get pretty complicated.
... at one point we talked about a read only summary...There
are a lot of things that need to be defined so it doesn't
become harder to interact with the information.
Steve: Yes, I thought about a single page with multiple steps on it.
Mike G: Yes, so we need to nail that down.
Alastair: Yes, talking about
pages won't get us any where.
... I don't know if there is a minimum number of questions.
Mike G: It was called Confirm Important Information. Another was timeouts, and was the ability to notify someone before time.
scribe: reads from the old
SC.
... The one piece that is new: go back and alter data - this is
an important piece to capture.
Mike G: I will send this to Steve.
Alastair: Yes, Steve, please do
go through those.
... I think this is a harder topic.
<mbgower> if you put it as a /me comment, it won't be in the minutes
Alastair: The other main comment
I have is tightening up the exceptions.
... So maybe we need to move this to the meeting next year.
Steve: Is there a page where it just has all the questionnaires?
<alastairc> https://www.w3.org/WAI/GL/wiki/Upcoming_agendas
Alastair: From any questionnaire it should be on the left.
<Detlev> can do it
<Detlev> scribe: Detlev
Jennie: Apologies for late
additions - addressed some comments
... draft SC text, reponse to Bruce#s comments
... Bruce was talking about difficulties of PDF docs viewed in
browser, single page apps, chat bots
<Jennie> On every page in a set of web pages that are actively supported (same link as in current text, needs a definition for actively supported...) that requires a bypass block under 2.4.1 or use a footer, at least one of the following is provided in a consistent location
Jennie: Its quite wordy but needs to separate out those cases where the SC applies
Steve: Is it skip links?
<alastairc> Bypass blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages.
Jennie: Yes - would ask for a consistent location
Alastair: So that would outscope individual pages without navigation
jennie: dificulties to define pages without / with footers
Alastair: So use Bypass blocks or use a footer
Jennie: Exceptions for smaller sites
Alastair: Difficulty to identify which sites are "actively supported"
Jennie: There is no requirement (yet) for sites to indicate whether they are actively supported
Alastair: Should be worked into the document
Jennie: Should I edit / add to
document for further review?
... in the draft SC text there is a new final bullet point
<Jennie> human contact details or link to human contact details
Jennie: bullet 2 (human contact details) should be updated
Alastair: you don't need the
phone number straight, you can link to a page that has it
... looking through survey - comment 4 is good, make that
change
Jennie: "fully automated chatbot does not meet the requirement"
<Jennie> A fully automated interaction option which understands misspelled words, can identify when a person did not find the answer to their question within x number of interactions and then refers them to a human.
Jennie: defining interaction
alternatives
... adressing COGA concerns that it would be able to address
misspellings
<laura> it addresses it for me.
Raf: had concern about chatbots, happy with the current solution
Alastair: Big chunk in SC text, maybe put into a definition?
Point about automated chatbot might bette rbe outside SC text?
Jennie: Text in IRC channel
should be the replacement, positive wording instead of
exclusion
... need to meet all other requirements too
Alastair (putting changes in place?)
Jennie: added a couple of things based on suggestions
Removed para out of intent to Techniques section
scribe: in Failure section, added
more explanation why some of the things fail
... understanding that tooltips are not discouraged, but that
consistent location is required
Jenne: WCAG2ICT content was indicated as weak, therefore I need help on this
Alastair: Would not work on ICT,
probable not to be included
... wondering about people who are intentionally anonymous -
how would that apply to them? It is an edge case
... no contact point for legitimate reasons
Jennie: blogger who does not what
to provide help option
... there should be a way to address these cases - help
appreciated
Alastair: we could include in def
of "actively supported" an angle on "human who can be
contacted", excluding cases where people want to stay
anonymous
... people have nit have a chance to consider changes - can you
implement changes so we bring thos up again for a final
review?
Jennie: When should it come up again for review?
Alastair: 1st or 2nd week of January
Jennie: will implement changes till the end of this week, givng people time to review
<Jennie> Scribe: Jennie
Alastair: We are getting towards
end of useful drafting stage of 2.2.
... Where our current agenda stops towards end of January, but
by end of February we wouldn't add new success criteria.
... Working backwards from the publication deadline, we want to
be using February to finalize the pull requests for success
criteria.
... By end of January we need to agree the SC we are including
in 2.2. are ready to go.
... So in the Google doc or whatever other format we are
looking at the end of January, so it can be made into a pull
request we think people will approve.
Alastair: There are a number of
github issues.
... This is something I did a few weeks ago because I noticed a
number of issues on this that could be tackled together.
... The survey result shows 3 people happy with it. 1 person
who wants some changes.
... I have a lot of information in the pull request regarding
changes.
... E.g. removing the explanation section, adding more examples
into the table...
... and the 1 Andrew was unhappy with was the restructuring of
the headings.
... I think Andrew thought they should align more closely with
the SC types.
... But because this is an Understanding Document, if people
are happy with the changes as presented...
... I will update the headings for the Techniques.
... 1 will be for graphic objects, the other for status
indicators.
... Any questions, comments, or objections to the Understanding
Document?
Detlev: The pull request makes it difficult to see the changes.
Alastair: Look at the bottom one,
and click on it. Once it opens it should be clear.
... if you load the dif
Detlev: Will there be time for comment and review?
Alastair: Yes
... it has been on the agenda for a few weeks but we can put it
to next week.
Detlev: Please go ahead.
Alastair: Any objections?
<Detlev> souns good to me!
RESOLUTION: Publish PR 931 as amended
<alastairc> rsaagent make minutes
<alastairc> rrsagent make minutes
<alastairc> RRSAgent make minutes
<alastairc> RRSAgent create minutes
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) Default Present: AlastairC, Jennie, jon_avila, JakeAbma, JustineP, MarcJohlic, janina, Raf, stevelee, Detlev, JohnRochford, Chuck, Laura, mbgower, johnkirkwood WARNING: Replacing previous Present list. (Old list: AWK, Chuck, Raf, Fazio, janina, Rachael, Brooks, Katie_Haritos-Shea, JakeAbma, JF, johnkirkwood, MarcJohlic, mbgower, bruce_bailey, Avneesh, PeterKorn, david-macdonald-) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AlastairC, Jennie Present: AlastairC Jennie jon_avila JakeAbma JustineP MarcJohlic janina Raf stevelee Detlev JohnRochford Chuck Laura mbgower johnkirkwood Regrets: Bruce John DavidF Found Scribe: JakeAbma Found Scribe: Jennie Found Scribe: JakeAbma Inferring ScribeNick: JakeAbma Found Scribe: Jennie Inferring ScribeNick: Jennie Found Scribe: Detlev Inferring ScribeNick: Detlev Found Scribe: Jennie Inferring ScribeNick: Jennie Scribes: JakeAbma, Jennie, Detlev ScribeNicks: JakeAbma, Jennie, Detlev WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 10 Dec 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]