<Detlev> scribe: Detlev
AC: last agenda item (hidden controls) there is an issue with an updated question
Rachael: Any new members who want to introduce themselves?
Chuck: Review period of FPWD of WCAG 3.0 extended
Responses to 1431 issue (redundant entry)
Alastair has proposed a response, most agree, some have 'something else'
<Chuck> I'd argue re-entering a new password _is_ essential and is covered by the existing shorter exception. As well, a double-email in some contexts can clearly be argued as essential. I think this can be addressed in the Understanding document, and there is no need to update the normative text or note. I'm a bit leery of language that suggests a 'step could be a page' as that could lead to some very unfortunate interpretations.
<Chuck> <pasted in from survey>
<JF> +1 to Mike - when *creating* a new password, you often need to re-enter the PW
Rachael: Mike sees no need to update normativ text, just understanding
AC: not convinced that passwords fall under ' essential'
<CharlesHall> +1 to that interpretation. common ≠ essential.
AC: If asking for immediate
re-entry then you stay at th same step
... password does nit allow copy/paste, that's why it needed to
be called out
<CharlesHall> an unmasked value can be copy/pasted
<Fazio> +1
JF: believe there are cases where password needs entering twice - is resetting password a multiple step process - could count as one, perhaps
<CharlesHall> same step, but bad pattern
JF: If it's on the same screen then it is part of a single step
<Rachael> current language on 3.3.8: For steps in a process, information previously entered by or provided to the user that is required on subsequent steps is either: auto-populated, or available for the user to select.
JF: even with confirmation of password this can be seen as a single step process
<Zakim> alastairc, you wanted to talk to 'step'
<Fazio> Which was the point of the sc
AC: 'step' has nit been defined
for a reason - if you don not need to navigate to it then it is
single step
... suggested to call out password since previous password
cannot be copied
<Fazio> +1
<Fazio> ssso an example in understanding doc should suffice
AC: so more difficult is to determine if changing password counts as essential since there may be different way of achieving it
JF: Often for security reasons
users are asked to confirm / verify changes
... that's why you are asked to enter it twice
Rachael: essential for verifying accuracy
<kirkwood> its also to prevent errors on the user end.
Jake: Not doing it that way may create bigger a11y issues
<kirkwood> in the case of mistyping.
<alastairc> If we accept password (without a specific exception) needs to be re-confirmed for accuracy, couldn't people argue that for other things, like postal address?
<CharlesHall> duplicate entry ≠ confirm ≠ more secure. there are other methods to confirm.
Jake: if it is changed without confirmation (e.g. in mistyping) you may not get back in into the system
<Zakim> alastairc, you wanted to check the logic from the other point of view
<JF> 1.3.4
AC: Just checking that logic from other point of view - if devs were wanting to reconfirm postal address - how can those cases be differentiated?
JK: Important step to verify correct entry
Rachael: Do we need to have an exception for "When re-entering is used for verification..."
<Fazio> +1
GN: verification of postal address happens in display befor submission, can be shown in clear text
<alastairc> so that's arguing for the new exception, I think?
<CharlesHall> a password should be able to be unmasked for the purpose of verification
<JF> +1, additionally type="password" disallows copy and paste
<Fazio> +1
<alastairc> The proposed exception: "Exception: When re-entering the information is essential, or when the information is not available for security reasons such as re-entering a new password."
GN: Reentering password I see as
essential
... Wording 'nit available for security reasons' is difficult,
the system can see it, just not the user
<alastairc> essential = "if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform "
DavidF: Agrees with GN - since password is secure, you have to re-enter it - can be described in understanding doc
<Rachael> Detlev: ?
<Fazio> security can be described as essential in Understanding doc
<CharlesHall> security is essential. this method is not.
AC: Our definition is "if removed.. it would fundamentally change.. cannot be provided in another form" - one can argue that making the password visible means thare are other ways
GN: making passwords visible is not equivalent, at least if password has been automatically generated
AC: But you can use a password manager for that so it never needs to be manually re-entered...
Rachael: Strawpoll
<kirkwood> 1
<mbgower> 1
<CharlesHall> 2
<Rachael> Straw Poll: Is content reentry for verification (such as a password reentry) considered essential? Option 1: Include reentry as essential Option: 2: Not essential, and we need to add to the exception
<Ryladog> 1
<alastairc> 2, but not objecting
<juliette_mcshane> b1
<Rachael> 2
0 (not sure)
<GN015> 1
<StefanS> 1
<Chuck> 2, but not objecting
<JF> Option 1
<MarcJohlic> 1
<morr4> 1
<Fazio> Inot all content reentry is essential
<Sukriti> 2
<JakeAbma_> 1
<Nicaise> 1
<Francis_Storr> 1
<laura> 1
<AWK> 1
<Raf> 1
<Chuck> I count 13-5-1
Rachael: More people believe re-entry is essential
<StefanS> :_D
<CharlesHall> slippery slope. for any other type of input
<Fazio> content reentry is too broaad
Rachael: we need to reword response to issue 1431
<Rachael> Proposed RESOLUTION: Reword reply that it is already considered essential so no change to make
AC: we need to say that we consider it essential, therefore no change needed
<Ryladog> +1
<david-macdonald> +1
<JF> +1
<juliette_mcshane> +1
<MarcJohlic> +1
<Fazio> +1
<Chuck> +1
<GN015> +1
<kirkwood> +1
<Sukriti> +1
+1
<morr4> +1
<Raf> +1
<Rachael> +1
<david-macdonald> would need to add that to understanding
<CharlesHall> +1 to comment, but i don’t believe it is essential in the first place
<JakeAbma_> +1
AC: It's already in the Understanding doc
<david-macdonald> cool
<Rachael> From understanding: There is an exception for essential uses of input re-entry for things like password entry (security), or memory games which would not be possible if the previous answers were supplied.
Rachael: Patric raised issue, suggested update
Rachael (reading out line of argument of Andrew Somers)
scribe: any comments?
AC: AS might be assuming if it has changes of both shape AND color
OK: Rachael: (reads Olivr Keim'S
comment in survey)
... suggests editorial changes
Rachael - that was on the wrong issue
OK: The text seemed too short
(reads his editing proposals)
... Needs not just color/shape differentiation but also
something textual (for non-visual users)
AC: Wasn't covered originally -
we do not generally try to show that every example passes every
SC
... if it runs in parallel like alt text, covering other
aspects makes it too cmplicated
Rachael: Have we dealt with this before - including a not ein the understanding what usage is supported?
AC: we do, in intent and benefits sections
DmD: The understanding doc is for laymen to help clarification
JF: Interesting point - we often indicate who benefits, and that can get too narrow - like visible controls originaly perceived as benefitting coga aspects, but also benefitting LV users
<kirkwood> +1 to JF
Rachael: We should check if we have covered the aspect of screen reader users
<alastairc> Yes, the should focus on the topic in hand, otherwise they would be 15 times longer!
OK: one aspect is speech output - so there is a dange that people read the examples and think they are fine of they differentiate just by shape and color,
Rachael: Should be separate issue - strawpoll
OK: we should cover blind / LV people, stating that they do not benefit there
<kirkwood> Low vision should be first.
Rachael: Would adding language address your concern, OK?
OK: maybe goes too far - let's
move on
... Best would be to extend the example pointing out that blind
users will need textual differentiation
<GN015> Please note that since ..:37 according to zoom Stefan Schnabel is talking, not OK
AC: If you add alt text that is explicit about the difference since you may not rely on shape, but it would not do from the LV perspective
<Chuck> +1 to alastair's explanation
AC: The general Q is do we focus on each SC alone, or do we cross-reference extensively - more a Silver question
Rachael: Think a change is
needed
... though nit sure exactly what it is - there is a gap in
example 1
... We should create an issue to address that gap
... acceptable?
OK: yes
<Chuck> +1 to creating a new issue for the gap
<alastairc> Nnoting I had the same thought previously, there is conversation here: https://github.com/w3c/wcag/issues/750#issuecomment-539454461
<Rachael> Proposal: Open an issue to fix the gap in Example 1 which does not fully support screenreader users
<Sukriti> +1
<Ryladog> +1
<laura> +1
<GN015> +1
<Nicaise> +1
<juliette_mcshane> +1
<JakeAbma_> +1
<OliverKeim> +1
0 (not sure there is an issue)
<JF> +1
<mbgower> 0
RESOLUTION: Create new issue to fix the gap in Example 1 which does not fully support screenreader users
GN: Example 1 refers to table
with glyphs - icons have text alternatives - the instruction
covers legend, there is nothing wrong with that
... a legend should not fail
mbgower: haven't looked at
example - symbol in chart - if legend is an instruction giving
equals, the only way that helps is that users can *see* those
symbols
... it is not an instruction, just a piece of information
connecting types of information
AC: would that mean taking that out?
<alastairc> https://www.w3.org/WAI/WCAG21/Understanding/sensory-characteristics.html
Rachael: Where is the legend in example 1?
<alastairc> https://github.com/w3c/wcag/pull/767/files
AC: The example 1 is being shanged in the PR
AC (reading out text from example)
mbgover: would call that an instruction, not a legend
GN: if you say 'the green diamond' doesn't help blind users - could be better visualised, e.g. in a graphic
Rachael: OK if we add an issue to add to the example?
<alastairc> +1
mbgower: It doesn't matter what the visual is - the instructino just should not refer to visual info (alone)
mbgower (reads text from example) - just describing a scenario
AC: The SC text is explicitly about instructions
Rachael: We have some improvements that we can capture in an issue - are there other objections to the additions proposed here?
GN: One Q is whether the example passes or fails - that must be clear
Rachael: That's pointed out ' rely on color/shape and therefore fail'
GN: Changes included that LV users are supported...
<Rachael> https://github.com/w3c/wcag/pull/767/files
Rachael: Example 1 has refocused to instructions
GN: If we had a table as a graphic, with text alternatives (like a legend) would it then pass?
AC: Change should make it clear that the focus is instructions - the current versions doesn't spell out whether it passes or fails
mbgower: Many understanding docs have issues that should be fixed - this is a good proposal for change
Rachael: Straw poll if we accept this PR
Gundula you may tacke further changes in a separate PR
<laura> +1
<Rachael> +1 to accept PR, -1 to not accept PR, 0 in the middle
+1 for accepting PR
<mbgower> +1
<david-macdonald> 0
<Ryladog> +1
<alastairc> +1
<JakeAbma_> +1
<StefanS> 0
<MelanieP> +1
<Levon> +1
<kirkwood> 0
<Chuck> +1
<GN015> 0
RESOLUTION: Accept PR 767 to address issues #750 and #1532
<OliverKeim> 0
<Sukriti> scribe:Sukriti
<GN015> don't we discuss Question 2 in https://www.w3.org/2002/09/wbs/35422/wcag22-color-updates/results?
<Rachael> https://github.com/w3c/wcag/pull/1500
Gundula: Also contributes to screenreader users including sighted and non-sighted users
Rachael: Would not change language
Detlev: should not always try to cover all aspects in all SCs. Think this is a good change
David: Second that
... in this case, dealing with color blindness. Okay with the
SC with the new text, adding sighted users. Value in being
granular especially in understanding document
<mbgower> +1
<alastairc> +1 to detlev, and DM
Rachael: Looks like we have broader support for the new change
<Zakim> alastairc, you wanted to ask what isn't covered after this change?
Gundula: Feel strongly about it. It does benefit screenreader users
Alaistar: is something that was covered before not covered any longer?
Gundula: The requirement for screenreader support would be dropped
Alaistar: How would it affect the end user?
Gundula: It would be a difference in reporting
<JF> +1 - a violation is a violation
Alaistar: WCAG violation is a violation
Gundula: Might not reflect how a blind user might be affected
<david-macdonald> WCAG words "Color is not used as the only <em>visual </em> means of conveying information..."
<Zakim> mbgower, you wanted to say look at specific benefits
Rachael: Applied not in the WCAG context but in the user groups context?
Gundula: Yes
Mike: The actual SC text is specifically targeted at sighted users who cannot distinguish color
Chuck: Gundula's analysis is persuasive. However, this specific SC text is already referencing visual. Because of it, supportive of PR change
<mbgower> This even has a note: "Note: This success criterion addresses color perception specifically. Other forms of perception are covered in Guideline 1.3 including programmatic access to color and other visual presentation coding."
Rachael: I find it persuasive as
well. In isolated theory, supportive of this PR. Would like to
understand what other documents are using this
... Need more time to research on what this will affect
<Zakim> alastairc, you wanted to say there has been a gradual move from 'wide' understanding docs to more specific ones.
DavidF: what about future proofing? as tech evolves, would implementing Gundula's point would help
Alaistar: We have specific SCs and understanding documents to cover more considerations. It sometimes causes more confusion. This is a case of aligning the normative req. to understanding document
Chuck: legal interpretation should be left to regulators
<CharlesHall> point of reference, the EN standard also evolves with editorial changes. as i am aware, the current is EN 301549:2019 v3.1.1
Gundula: Normative part covers sensory characteristics that are important to screenreader users
<david-macdonald> hmmm... 1.4.1?
Gundula: 1.3.3
<alastairc> https://www.w3.org/2002/09/wbs/35422/wcag22-color-updates/results#xq2
Rachael: would be comfortable only for 2.2 and not retroactively for 2.0 and 2.1
<Zakim> mbgower, you wanted to speak to Understanding doc changes
MG: Understanding documents are not normative
<Rachael> Straw Poll: 1. Change from 2.0 forward , 2. Change for 2.2, 3. No change
<david-macdonald> change backwards to 2.0
<CharlesHall> 2
<mbgower> 1 backward compat
<MelanieP> 1
2
<alastairc> 1, alhtough I think in practice it will be 2.1
<laura> 1
<Ryladog> 1
<Detlev> 1
<JakeAbma_> 1
<Francis_Storr> 1
<Rachael> 2
<david-macdonald> 1
<OliverKeim> 2
<Chuck> 8-4-0
+1
<Zakim> mbgower, you wanted to say how does it technically work?
MG: the actual urls,
understanding documents are linked to the specific
versions
... realistically, the change will only be in 2.2. unless we do
some kind of recursive change
Alaistar: Separate documents for different versions. Main version is for 2.2 and pick changes that should also apply to 2.1 individually on that branch
Rachael: some design changes to make clear which version on github on the way
RESOLUTION: Accept PR 1500 to address issues #1032, #1076 and #1370
<Rachael> https://github.com/w3c/wcag/pull/1500
<Rachael> https://github.com/w3c/wcag/pull/1553
MG: Less concerned now. See that the revised wording has not removed the fact that additional visual info still required.
Andrew S. has said would like the technique to be dropped and proposed changes
Alaistar: comment doesn't speak to the change specifically
Gundula: an example that fails another SC should be dropped
<Zakim> alastairc, you wanted to say that example is a failing one
<alastairc> However, if content relies on the user's ability to accurately perceive or differentiate a particular color
<alastairc> (either implicitly - e.g. green for success, red for failure - or explicitly - e.g. "the blue items represent
<alastairc> the most recently updated entries"), an additional visual indicator will be required, regardless of
<alastairc> the contrast ratio between those colors.
Rachael: The first example is a failure example
<alastairc> https://raw.githack.com/w3c/wcag/patrickhlauke-repoint-1.4.1/understanding/20/use-of-color.html
Gundula: Maybe the second example should be dropped
Rachael: Alternate example?
Alaistar: stars with color to indicate full similar to non-text contrast
<Rachael> https://raw.githack.com/w3c/wcag/patrickhlauke-repoint-1.4.1/understanding/20/use-of-color.html
<Chuck> +1 to amendment
<Rachael> Straw poll: Change example to stars
<mbgower> sure
<Ryladog> +1
<Rachael> +1
<Levon> +1
+1
<GN015> +1
<JakeAbma_> +1
<StefanS> +1
<Detlev> +1
<alastairc> +1 can make later
<JF> +1
<Francis_Storr> +1
<kirkwood> +1
<Rachael> Proposed amendment accepted
MG: Would still have to have a focus indicator - it is additional visual information
Gundula: why is it no longer successful when underline appears on hover?
Alaistar: It's not that you can't use extra visual indicators. Demonstrating the minimum - contrast ratio aspect (quite a few devices where there is no hover)
MG: Still a little concerned about taking away visual information that indicates for example, a link
Alaistar: f73, failure doesn't line up with this. No reference to focus or hover and has been confusing people.
MG: Can live with it because of focus indicator requirements even though lowering bar
David: I wouldn't remove G183
Alaistar: The proposed change is to remove the last two steps not the technique. Still testing contrast
<alastairc> https://www.w3.org/WAI/WCAG21/Techniques/failures/F73
<alastairc> Check that each link in the page that is identifiable by color (hue) is visually identifiable via some other means (e.g., underlined, bolded, italicized, sufficient difference in lightness, etc).
Alaistar: techniques can go beyond the minimum but cause confusion
David - failing a technique doesn't necessarily mean failing SC. Is there a particular issue with the underline aspect?
Alaistar: More confusion than issue
Gundula: Does it makes sense to include a technique that covers desktop since the existing one covers touch interfaces
Alaistar: The technique can go
beyond the minimum but not requiring underline
... we probably have underline and not the text contrast as a
technique
<alastairc> https://www.w3.org/WAI/WCAG21/Techniques/general/G182
Alaistar: g182 is the more general technique
<JF> +1 to Mike
<alastairc> Suggest approveing the understanding doc, come back to the technique later
<mbgower> +1
<Rachael> proposed RESOLUTION: Accept amendment to PR 1500
<Ryladog> +1
<Rachael> +1
+1
<david-macdonald> +1
<juliette_mcshane> +1
<JakeAbma_> +1
<alastairc> +1
<JF> +1
<Detlev> +1
<Levon> +1
Accept amended PR 1500; review PR 1553 later to adjust G183
<Rachael> revise to: RESOLUTION: Accept amended PR 1500
<Rachael> Proposed resultion: review PR 1553 later to adjust G183
s/RESOLUTION: Accept amended PR 1500; review PR 1553 later to adjust G183/RESOLUTION: Accept amended PR 1500
<alastairc> rrsagent make minutes
<Rachael> Propose RESOLUTION: Accepting all changes in 1553 except those made to the proceedure
Rachael: Come back to this after some more thinking?
Chuck: Next meeting Jan 5
<mbgower> Best of the season, everyone!
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/RESOLUTION: Accept amended PR 1500; review PR 1553 later to adjust G183// FAILED: s/RESOLUTION: Accept amended PR 1500; review PR 1553 later to adjust G183/RESOLUTION: Accept amended PR 1500/ Default Present: alastairc, Rachael, JakeAbma_, Francis_Storr, Detlev, Chuck, juliette_mcshane, Fazio, Matt, Orr, MarcJohlic, JF, CharlesHall, Nicaise, Sukriti, Laura, kirkwood, caryn-pagel, StefanS, Levon, Katie_Haritos-Shea, mbgower, david-macdonald, OliverKeim, Raf, GN Present: alastairc Rachael JakeAbma_ Francis_Storr Detlev Chuck juliette_mcshane Fazio Matt Orr MarcJohlic JF CharlesHall Nicaise Sukriti Laura kirkwood caryn-pagel StefanS Levon Katie_Haritos-Shea mbgower david-macdonald OliverKeim Raf GN GN015 Found Scribe: Detlev Inferring ScribeNick: Detlev Found Scribe: Sukriti Inferring ScribeNick: Sukriti Scribes: Detlev, Sukriti ScribeNicks: Detlev, Sukriti WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]