<Chuck> meeting: AGWG-2021-07-06
<ChrisLoiselle> scribe:ChrisLoiselle
Chuck: Any new topics that the
group would like to address?
... Reminder, we had to delay Silver content, there is no
Silver content on current agenda.
... AlastairC is hosting a WCAG 2. issue review.
AlastairC: Meeting is around issues on WCAG 2 , same time on Fridays as this call, 11am ET
<alastairc> https://www.w3.org/events/meetings/fdbff191-ae2e-48ee-87d7-37b2b20c653a
Chuck: Participation is welcome.
Jake: It is same time as errors working group, correct?
Sarah: 10am Wednesdays is the
Errors working group.
... 10am ET is Silver now, previously 2pm ET
10AM ET on Fridays is Silver , clarifying last statement.
Chuck: Talks to Jake's comments on Headings enough question related to current topic.
5 people answered Make H69 advisory (and review the other techniques
5 people said say something else
2 Keep H69 as sufficient, but update it to indicate lack of support
Gundula's comments: I do not see how a clean heading structure helps in bypassing blocks. It is a good technique for 2.4.10, but navigating by headings is not really a technique to conveniently bypass a block.
"skip this section" is one action
"go back to heading navigation (wherever it is)", " find the heading of the section I want to skip (memorizing the heading !!!)", "find the next heading", "go there" are four actions, error prone, hard to perform when distracted or having memory loss, and relies on a feature which likely is not available for non-screen-reader users.
Gundula: I can live with it being advisory , so I see it somewhere else.
Chuck: Stefan? I'll read his
comments.
... Appears to be along the lines of deprecating H69.
AlastairC: I believe Stefan and
Gundula were onboard with making it advisory. I believe some
are coming at this as something that is beneficial to screen
readers.
... The thread on GitHub is that it is for sighted users as
well. The understanding talks to that as well.
We either keep techniques as they are and update understanding documents, or it is applicable to sighted and non sighted users.
Chuck: I think there is benefit to users who are not screen reader users.
<johnkirkwood> Definitely should be applicable for users with mobility and also cognitive issues.
<JF> Additionally, AT > "screen readers"
Chuck: I would not tie it
specifically to assistive technology
... Should the working group not have a consensus , then status
quo stands.
JF: assistive technology is more than just screen readers. I.e. screen readers use the heading structure as a navigation method.
AlastairC: There are some plugins
that help that display headings, but not necessarily navigating
them .
... there can be benefits beyond screen reader users.
... it is fairly restricted to screen reader users
currently.
JohnK: It is heavily used by
assistants , i.e. surfacing through search engines as
well.
... It helps surface information for technology tools such as
Alexa or Google assistant , etc.
<Zakim> Chuck, you wanted to ask about updating understanding only
JF: I believe there is utility in the technique. This type of structure being included in the document should make it valuable. Perhaps a note on known support plus emerging tech explanations on how it is currently being used.
<david-macdonald> https://www.davidmacd.com/blog/sighted-keyboard-only-user.html
Chuck: Perhaps updating understanding document . Which option does that fall under , unless it is "in something else" bucket?
AlastairC: Keep H69 as
sufficient, but update it to indicate lack of support .
... To John's point, heading structure around bypass blocks
.
<Zakim> alastairc, you wanted to differentiate from 1.3.1
<Fazio> I don't like this exercise of have I ever
DavidM: Theory around keyboard
only user not using a mouse. Is there anybody on call that does
that? I've never found someone that only uses a keyboard.
... We have never had a user said I can't use this. It was
around screen readers originally. It isn't around exact
movement.
... first is I have yet to meet a keyboard user that doesn't
use a mouse. I.e. we don't have a virtual cursor as a sighted
user.
Jake: It was a 123 comments around the topic. People were opposed , most of them. The criteria didn't feel right for a lot of people. Position was to delete a benefit . Not sure if the way is the correct way to do it.
<alastairc> Question: Have you ever recommended headings as a method for bypass blocks?
<alastairc> Or seen it used for that purpose by others?
Jake: Getting rid of a benefit doesn't seem right. The arguments around keyboard users and screen readers do have other ways. I don't think we should make it easy for us to remove something in understanding and be done with it. It should be a deeper dive if we are updating.
Jennie: People who use switches , for some individuals, multiple ways of interacting . Talks to augmentative communication. Rights to independent living as a use case. The individuals may have not known that they had the ability to make a complaint.
<Zakim> Chuck, you wanted to say I have met such a user
Chuck: I have met an individual that does use keyboard only.
Fazio: I don't think we should do this at all regarding have we ever seen a user do x, y. z.
If we create an opportunity they will use it.
<alastairc> Wilco - one of the benefits is "People who use only the keyboard or a keyboard interface can reach content with fewer keystrokes. "
<JF> +1 to Wilco
Wilco: This is a standard . We can't just change our mind about this. It's been circulated for 10 years. If we want to address a concern, we add a new success criteria.
<Zakim> Chuck, you wanted to ask what does Fazio suggest to resolve issue 1712?
It is not something you state in a standard to change the standard.
<MelanieP> +1 to Wilco
JF: On precedent of changing criteria, I'm with Wilco on leaving it as is.
Jake: The github issue starts on a contradiction where technique doesn't fit.
I.e. it has been there, it is perfect is not right. The understanding document needs to be looked at.
<Zakim> alastairc, you wanted to say the understanding doc isn't that clear
Jake: The question is around is around is headings not enough...
AlastairC: There are benefits
called out in understanding document that don't specifically
talk to benefits of screen reader users. I.e. more keyboard
only users or switch access users.
... It may be originally aimed at screen readers, but benefits
users as well. It may not match as to what it was meant for vs.
what people understand they are reading.
Headings being sufficient for this is the core issue within Github.
scribe: not making a change is making a change. If skip link or another method on top of headings is needed. My thought would be to make advisory.
DavidM: We tried to do the right thing when we wrote the guidelines. On cognitive, in my experience, people do use mouse keys, but I'm open to someone showing me otherwise on approach and use.
<Zakim> Chuck, you wanted to say I think a lot of people are violently agreeing on this and to make a proposal on a course of action
AlastairC: Talks to backwards compatibility with DavidM on WCAG 2.1 vs. 2.2 use and conversation around H69 technique and understanding.
Chuck: Request is that someone updates understanding document and relates that to H69 for path forward. It would be good to see how this relates.
Wilco: Do we leave that up to the editor ?
Chuck: We would want to review a proposal from the group , and that we review the proposal from the editor.
Wilco: I understand that WCAG is not perfect and that understanding needs an update.
AlastairC: Poll options: a) Update understanding doc to remove benefits (make SR focused); b) In WCAG 2.2 make H69 advisory; c) In WCAG 2.1 & 2.2 make H69 advisory . SR = Screen reader.
The compromise option , on WCAG 2.2. make H69 advisory.
The strongest option would be WCAG 2.1 and 2.2 and make H69 advisory.
<Glenda> Aren’t WCAG 2.x’s supposed to be backwards compatible?
Understanding document to inform someone that H69 is a sufficient technique.
<alastairc> Glenda - It would be compatible because passing 2.2 would pass 2.1
Chuck: If we change the understanding document, it is not normative. It won't be backwards incompatible.
<Zakim> Chuck, you wanted to say understanding is not normative
<Fazio> +1 jake
Jake: We rely on understanding document on what we mean by a sentence. In real life, we explain in understanding a lot and would impact normative tests.
Wilco: I don't think we can't just change headings. It would be that skip links become mandatory.
<Glenda> only a q to say that normative is really normative.
Glenda: Informative is contextual and doesn't change meaning. If it does, we aren't a standard.
AlastairC: It would cause a
review of other techniques, i.e. the skip navigation part of
topic.
... On normative vs. non normative, the change in understanding
would remove a benefit and clarify the understanding document
to make it more screen reader benefits.
Glenda: I understand that it helps screen reader users but not around it not being normative vs. non-normative.
Jakes: On informative techniques vs. non normative vs. normative and sufficient technique documentation is a concern.
Glenda: agrees on Jake's comment.
<Chuck> Poll options: a) Update understanding doc to remove benefits (make SR focused); b) In WCAG 2.2 make H69 advisory; c) In WCAG 2.1 & 2.2 make H69 advisory . SR = Screen reader.
DavidM: Over the years, it is harder to take things away , i.e. sufficient techniques. The idea vs. in practice , trying to add a failure technique is very hard to do. Adding context to conversation.
Chuck: Poll options: a) Update understanding doc to remove benefits (make SR focused); b) In WCAG 2.2 make H69 advisory; c) In WCAG 2.1 & 2.2 make H69 advisory . SR = Screen reader.
<Chuck> a
<laura> A
<Wilco_> a
<david-macdonald> a
<JakeAbma> b
<Detlev> a
<MelanieP> a
<alastairc> b / c
<johnkirkwood> a
<JF> A
<sarahhorton> b or c
<Fazio> B or C
<Glenda> My primary vote is “A”. I could live with “B”. I cannot live with “C”.
<Ryladog> a
<MattOrr4> a
<Francis_Storr> a
<Jaunita_George> A
<alastairc> Of the As, could anyone not live with b?
<Regina> a
Poll options: a) Update understanding doc to remove benefits (make SR focused); b) In WCAG 2.2 make H69 advisory; c) In WCAG 2.1 & 2.2 make H69 advisory . SR = Screen reader.
<Wilco_> yes
<Ryladog> yes
<laura> yes
<JF> prefer not B
<MelanieP> cannot live with b
<Detlev> can live with b
<Zakim> Chuck, you wanted to poll
<Chuck> not live with B
<Francis_Storr> not b
Jake: I am wondering, when we create a new SC , before public comments, is there a possibility to ask for public comments? The majority of this group vs. the github group may be different in point of view.
<Glenda> Rather than ask other a11y experts their opinions, we need to ask companies around the world who have used H69.
For understanding, for 2.2. vs. 2.1 update , is it talked to in the Github issue in public comment or rather in conversation here?
AlastairC: I do understand the conversation in Github is important.
<JF> +1 - the Understanding doc gets updated, so NOT status quo
<david-macdonald> I can do that
Chuck: On updating the understanding , nothing gets set it stone. We are asking to have someone to write an understanding update .
Jake: Is there any answer to my
question concerning the thread?
... The github issue may have push back , based off of our
update to the thread.
Chuck: Talks to MikeG's comment ,
I think this example needs more work than just adjusting the
figure caption.
... Talks to Ben Tillyer's comment in results of
questionnaire.
Wilco: My comments Change "the unfocused default version must already have sufficiently contrasting colors" to "the all states and variations must already have sufficiently contrasting colors"
<Chuck> +1 wilco
AlastairC: I think that misses the point on what this is trying to say.
I think it is around is this necessary for understanding. . I.e. what is I have a dynamic graph. In default state, not everything appears.
In interactive state, mouse or focus, they do contrast...is the question around dynamic. Something needs to be there to tell what the content is, but not necessarily the pie chart divisions problem.
As long as you can find the thing , i.e. hover or focus, then it comes into focus, then it was ok. I think DetLev's update is good for that.
thanks, Wilco!
<Wilco_> scribe: Wilco
<Wilco_> Chuck: Alastair stated how the proposed changes might be misunderstood.
<Wilco_> Alastair: The PR clarifies the original intent. My comment was about all states / variations.
<Chuck> proposed RESOLUTION: Accept PR 1672 to address issue 1670
<Wilco_> Chuck: Most people were support of it
<Chuck> wilco: Don't follow. The SC explicitly mentions states. Does that not mean all states are included?
Wilco: The SC talks to states , does that mean all states are included?
<Chuck> wilco: How does that not mean that all states are included? That seems that this is what is being said.
<alastairc> https://www.w3.org/WAI/WCAG21/Understanding/non-text-contrast.html#dynamic-examples
<Wilco_> Alastair: The dynamic example demonstrates a mostly non-contrasting pie-chart, except the one in focus. This was an important example.
<Wilco_> ... If you say that all states have to have contrast than that's problematic for certain infographics.
<Chuck> wilco: I see where you are getting at. It doesn't seem what the SC is saying.
<Chuck> alastair: This is graphical objects. It is part of the graphic required to understand the content?
<Chuck> wilco: I can live with it.
<Zakim> Chuck, you wanted to say that regardless of the commentary on the states, the example is the example
<Wilco_> Alastair: The unfocused default version must already have sufficient contrast. If the blue one from the example was faded out, that wouldn't pass, but if the other parts are faded out.
<Wilco_> ... Or it might have a strong boundary around the circle, and hover would bring up the value.
<Wilco_> ... This comes under alternative versions too, the information is there.
<Wilco_> GN: But users who have good sight can see the graph at once, but users with reduced sight would have to access the information one slice at a time.
To Gundula's point: An infographic can use text which meets the other criteria to minimise the number of graphical objects required for understanding. For example, using text with sufficient contrast to provide the values in a chart. A long description would also be sufficient because then the infograph is not relied upon for understanding.
<Zakim> Chuck, you wanted to ask about alternative conforming versions?
<Wilco_> Alastair: That is how screen readers access the information too
<Chuck> proposed RESOLUTION: Accept PR 1672 to address issue 1670
<Wilco_> 0
<Chuck> 0
<alastairc> +1
<Jaunita_George> 0
<JF> 0
<Detlev> +1
<GN015> +1
<johnkirkwood> 0
<laura> +1
<Francis_Storr> 0
<Wilco_> Alastair: Its not a huge update, but as long as no one disagrees I suggest we go ahead.
RESOLUTION: Accept PR 1672 to address issue 1670
<Wilco_> Chuck: ... reads comment from Andrew
<Wilco_> Chuck: ... reads comments from Wilco
<JF> +1 to Wilco
<Wilco_> Chuck: Have a bit of an issue with not reaching for erratas. It has been a fairly painful process to get them approved.
<Wilco_> ... By going for an errata, it still gets a fairly rigorous review.
<Wilco_> Alastair: The straight-forward one is to change to "input from a device". That gets to the original issue, it wasn't intended to refer to a device.
<alastairc> https://github.com/w3c/wcag/pull/809/files
<Wilco_> ... The updates to single pointer could be addressed in understanding. That would be a smaller, more editorial change. Then the examples could be put into the understanding document.
<Wilco_> ... So reduce the change that would be within this PR, and moving some of the changes to the understanding document.
<alastairc> Pointer input "input [ins]from a[/ins] device that can target a specific coordinate (or set of coordinates) on a screen,"
<Wilco_> Chuck: So we poll to see if the group is okay with that approach, then bring it back once those changes are made.
<Wilco_> GN: If the change is made in the understanding documents, they would still be translated?
<Wilco_> Michael: The understanding documents get translated much less frequently.
<Chuck> POLL: Do you agree with reducing the scope of the errata, updating the understanding doc and reviewing changes in a later call?
<Wilco_> +1
<Jaunita_George> +1
<Chuck> +1
<johnkirkwood> +1
<JakeAbma> +1
<JF> +1
<Wilco_> Chuck: This will happen then.
<Wilco_> Chuck: ... reading the question
<Zakim> alastairc, you wanted to explain an update
<Wilco_> Alastair: I did a slight update an hour, based on survey feedback.
<Chuck> proposed RESOLUTION: accept amended PR 1898 to address issue 1855
<alastairc> Web sites can employ username (or email) and password inputs as an authentication method if it enables the user-agent (browsers and 3rd party password managers) to fill in the fields automatically. If the login form meets <a href="identify-input-purpose">Success Criterion 1.3.5 Input Purpose</a>, and the form controls have an appropriate accessible name in accordance with <a href="name-role-value">Success Criterion 4.1.2 Name, Role,
<alastairc> Value</a>, the user-agent can reliably recognize the fields and automatically fill them in. However, if the user-agent is blocked from filling in the fields by a script then the page would not pass this criterion because it prevents the mechanism from working.
<Rachael> I am ok with those changes.
<Wilco_> ... The changes are around that browsers can recognise it, and that they aren't blocked from autocompleting.
<Chuck> +1
<Jaunita_George> +1
<Rachael> +1
<Wilco_> +1
<johnkirkwood> +1
<Detlev> +1
<stevelee> +1
RESOLUTION: accept amended PR 1898 to address issue 1855
<Wilco_> Chuck: 8 people agree, no disagreements. There are a few comments.
<Wilco_> Alastair: To Gundula comments, I don't think confirming alternatives accumulate. One has to conform fully. You can not mix and match.
<Wilco_> Rachael: If we include RSA tokens, we have to note it is the standard, there is an accessible one
<JF> +1, perhaps we should say "digital tokens"?
<Chuck> proposed RESOLUTION: Accept response to address issue 1879
<Wilco_> +1
<Chuck> +1
<Wilco_> Alastair: I'm going to look if we should mention digital tokens in the understanding documents.
<Wilco_> JF: Rather than point out a brand name, we should be generic.
<Wilco_> Alastair: Only using it in response to a comment that mentions RSA.
<Rachael> +1
RESOLUTION: Accept response to address issue 1879
<Wilco_> Chuck: Reading Wilco's comment
<Fazio> true
<Wilco_> Alastair: In redundant entry we came to separating security from the essential exception. Andrew has a point.
<Wilco_> ... If you have a timeout during authentication, is that a problem for that method?
<Wilco_> ... If you time out during authentication, you'd start again.
<Wilco_> Chuck: That is my understanding, I'd refresh.
<Fazio> can cause cognitive fatigue though
<Wilco_> Alastair: If the login times out, you'd start again
<Wilco_> ... Worse case scenario someone has to dig out a key and plug it in. I think that is why it is a short time, but it does probably come under timing adjustable.
<Fazio> I was thinking that too
<Fazio> sounds sufficient but could be arbitrary
<Wilco_> Alastair: With WebauthN, whatever authentication method you use with your device is up to you. The protocol itself sets a time limit.
<Wilco_> JF: A plug-in token is only one of many methods.
<Chuck> proposed next step Determine what the situation is with webauthn and timing adjustable
<Wilco_> Alastair: We wouldn't, it hands of to WebauthN
<Wilco_> ... I don't think the comment is going to address the question. If you're relying on WebauthN, it does need to pass everything.
<Wilco_> ... It is potentially problematic if it can't pass everything. I don't know if it is possible to put an exception in this SC for another?
<Wilco_> Chuck: We're looking for a volunteer to address this.
<Fazio> send it to coga
<Fazio> John Rochford
<Wilco_> Alastair: We may need someone more familiar to the spec.
<Fazio> John Rochford was the author
<Wilco_> Chuck: ... reading comment from Patrick
<Wilco_> JF: What if the niche solution is the only one that works in certain scenarios. At that point I don't know what to say.
<Wilco_> ... There is a balance here that we need to address, which I don't think we have.
<Chuck> wilco: off top of my head, supports means using technologies that are widely available to that conforms to WCAG.
<alastairc> "must have accessibility-supported user agents that are available to users"
<JF> +1 to Wilco - non-web content
<Chuck> wilco: We are discussing here non web technology, I don't see how this is in scope. Seems we should suggest it's out of scope for WCAG.
<Zakim> JF, you wanted to note that "websites" is too narrow
<Wilco_> JF: Website is but one kind of digital content. Native apps are not websites anymore. In some ways it's not really web technology, but I am concerned there may be scenarios that we can not support what we're asking for.
<Wilco_> Chuck: I think the response needs some work. We don't have any immediate suggestions as to what.
<Wilco_> ... We don't have a volunteer to write a new response.
<Wilco_> Chuck: Question 5, is of system level tests are out of scope
<Wilco_> ... There is a simple change in the understanding document.
<Wilco_> Alastair: The PR adds just two words.
<Wilco_> ... If users want to use a pin, they can, if they don't, then they don't. It is handing the method to the user's device.
<johnkirkwood> +1 to site specific
<JF> propose replacing "site-specific" to "content-specific"
<Wilco_> +1 to site specific
<Wilco_> GN: Content specific might be better. The group concentrates, but in legislation it is transferred to all kinds of software. I'd rather we word it generically.
<JF> +1 to Gundala, there is reality and there is 'code purity'
<JF> "instance-specific"?
<Wilco_> Alastair: We have a dozen mentions of site. If we made that agnostic, it is a big update.
<Wilco_> JF: The proposal is not to clean up, moving forward if we can be more generic we should be.
<Zakim> Chuck, you wanted to ask if there's some alternative language?
<Wilco_> Chuck: What is the suggested alternative
<Wilco_> JF: content specific, or instance specific
<Wilco_> JohnK: I heavily favour site specific. We're talking about content that is owned by a company.
<Chuck> proposed RESOLUTION: Accept PR 1909 and response to address issue 1900
<JF> -.5
<Wilco_> 0
<Chuck> .5
<alastairc> +1
<GN015> -0.5
<Detlev> not sure
<Wilco_> Chuck: No consensus on this at the moment.
<Wilco_> Alastair: We can bring it back next week
<Wilco_> GN: I feel these questions are much harder than memorising a password.
<Wilco_> ... If I say "in new york" or "new york" they are different answers. It is hard to remember the specific answer.
<Wilco_> Alastair: The proposed response is we don't intend to allow for other things. Gundula is proposing to add to the response.
<Wilco_> ... The main thing for me is, should we make changes. The answer seems to be no.
<Chuck> proposed RESOLUTION: Include the new paragraph to address issue 1912
<Wilco_> alastair: The new paragraph says it is helpful to add.
<Chuck> +1
<sarahhorton> +1
<GN015> +1
<Detlev> +1
<alastairc> https://github.com/w3c/wcag/pull/1940/files
<Wilco_> 0, didn't read
<Jaunita_George> +1
<alastairc> +1
<alastairc> "Another factor that can improve the changes of success for people with cognitive disabilities is being able to see the password as it is typed it. Password visibility is not a requirement of this criterion, but a good way of reducing the cognitive load, so including a feature to optionally show the password is very helpful."
<Rachael> -1
<Wilco_> JF: Word "changes" should be "chances".
<Wilco_> Rachael: COGA was talking about this during the last meeting, I'm not sure they'd agree. I would like to make sure.
<Wilco_> Chuck: We'll engage COGA, and not resolve now.
<Wilco_> Rachael: I'll bring this back next week.
This is scribe.perl Revision VERSION of 2020-12-31 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/sight/site/ Default Present: JF, alastairc, Chuck, Jennie, Francis_Storr, ChrisLoiselle, johnkirkwood, Jaunita_George, Fazio, Rachael, sarahhorton, MelanieP, MattOrr, stevelee, Katie_Haritos-Shea, Laura_Carlson, Wilco_, KarenHerr, Glenda, kirkwood, GN Present: JF, alastairc, Chuck, Jennie, Francis_Storr, ChrisLoiselle, johnkirkwood, Jaunita_George, Fazio, Rachael, sarahhorton, MelanieP, MattOrr, stevelee, Katie_Haritos-Shea, Laura_Carlson, Wilco_, KarenHerr, Glenda, kirkwood, GN, MattOrr4, GN015 Regrets: Bruce Bailey, Aimee Ubbink, Ben Tillyer, Nicaise Dogbo, Todd Libby Found Scribe: ChrisLoiselle Inferring ScribeNick: ChrisLoiselle Found Scribe: Wilco Scribes: ChrisLoiselle, Wilco 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]