<Jennie> scribe: Jennie
Chuck: (reading from survey)
<Chuck_> https://github.com/w3c/wcag/pull/1323/files
<alastairc> PR: https://github.com/w3c/wcag/pull/1323
<Chuck_> Change: Requiring people to recall information already entered in the previous steps can cause them to give up or enter incorrect information. The autocomplete feature of browsers is not considered a sufficient because it is the content (the web site) that needs to provide the stored information for a redundent entry, or avoid asking for the same information again.
<alastairc> BTW - I just updated the typo on redundant.
Chuck: Alastair is going to
remove the a
... I agreed with the change, but there is a mispelling of
redundant
Alastair: that one is done
Chuck: The poll question is do you agree with this change to the Understanding Document?
<Fazio> +1
Chuck: 4 have responded to the survey, and do agree
<Nicaise> +1
Chuck: We are reviewing issues
raised against redundant entry
... 1 is if autocomplete can be used to fulfill the redundant
entry
<Chuck_> Requiring people to recall information already entered in the previous steps can cause them to give up or enter incorrect information. The autocomplete feature of browsers is not considered a sufficient because it is the content (the web site) that needs to provide the stored information for a redundent entry, or avoid asking for the same information again.
Chuck: Alastair has made minor syntax changes
<laura> +1
Chuck: does anyone have any objections to this change
<Raf> +1
<Detlev> +1
RESOLUTION: Accept new line to understanding document of redundant entry to address issue 1194.
Chuck: (reads from the survey question 2)
<Chuck_> https://github.com/w3c/wcag/pull/1325/files
Chuck: there are 2 lines changed
<Chuck_> Change 1: This Success Criterion pertains to the current user session and is not applicable a user returns after closing a session or navigating away, unless the user has been allowed to save their entered data part way through the process.
<Chuck_> Change 2: This Success Criterion does not <em>add</em> a requirement to remember information between sessions, however, if the website does save between sessions then the requirement continues to apply.
Nicaise: Can you paste the text into Zoom? It is more accessible for some
Chuck: Yes
... Here is the text of the 2 additions
Mike G: Re autocomplete - can I still ask a question?
Chuck: Go ahead
Mike G: Autocomplete is an author enabled setting.
scribe: I didn't quite understand
"it is the content..."
... It is using something associated with the browser
functionality but it is the author
<AWK> uses "a mechanism"
Mike G: the attribute doesn't cover all situations
Alastair: It was to do with the
reliability
... Even if the author does enable it, it doesn't mean it will
work on the user's end
... Depending on your situation, it is not necessarily on the
end user's control either, like those sharing a computer
... It is a small update to the understanding document
Mike G: Then it goes "because" and if it says "because it is unreliable" or something like that
scribe: I can live with it, but it wasn't that clear to me
David F: More than just that, the user is going to have to remember what they already entered to start the auto complete, as opposed to cued up information
scribe: If you have to start typing what you previously typed...
Chuck: Because Mike expressed
concerns but can live with it, I will move forward to the next
question
... I have pasted the information both in IRC and Zoom chat
<alastairc> mbgower - feel free to suggest an update to that text. I've already merged it, but we can update later.
Chuck: We had 2 individuals who
had something else they wanted to cover
... Andrew can you speak to yours?
Andrew: I think the SC doesn't
have enough language to support that. It could be changed to do
so.
... Maybe something times out, something needs to be
re-entered
... If I come back the next day, there is no guarantee that is
still available
... I think that if we are going to make the process span a
longer period of time, potentially days or weeks, we have to
have some sort of way for those unavailable to be
re-entered
Chuck: Alastair, you had something else as well
Alastair: After reading Andrew's it made me think this is covering almost a non-issue
<Chuck_> Alastair's alternative proposal: Whilst agreeing that sites *should* save information between sessions, we didn't want to make that a requirement and make implementation much harder. Where sites are already providing that functionality, it does not appear to gain anything for us to add that requirement for those that already provide it. Also, given that any site where you can complete a process in one session is in scope, it would have to meet the SC[CUT]
Alastair: For site's that don't
allow you to save something is not in scope, and that sounds
odd
... I can't think of going through a process where you have to
go away and come back later
<MarcJohlic> "to the current user session and is not applicable a user returns after"
Alastair: Trying to get into the complexity of something cross sessions, and only if it already does it, seems odd
<MarcJohlic> Side note: seems like there's an "if" or "when" missing there between applicable and a
<bruce_bailey> +1 to AC proposed response in survey
Alastair: I wrote a response suggesting we didn't want to make it a requirement. For site's already with that functionality, it doesn't seem helpful to add that requirement
David F: I thought we decided it only applied to current sessions.
Chuck: I have a question for Alastair: you are proposing this as a response to the user, and abandoning the changes to the Understanding Documents?
Alastair: yes
Chuck: I see Bruce echoes your response, and Mark has commentary
Marc: It seems grammatically it
needs an "if" or a "when"
... in the 1st change, and it was in the original language as
well
Chuck: Your commentary is on how we can make Alastair's proposal more grammatically correct.
Marc: Yes, and in the original as
well. In line 31
... 30 in the change
Chuck: Thank you for noting
that
... The proposal is on the table to go with Alastair's
response, and not include changes to the Understanding
Document
... other than grammatical
<MarcJohlic> +1 to Alastair's proposal
<laura> +1
<Nicaise> +1
<Sukriti> +1
<AWK> +1
<alastairc> Proposed response: Whilst agreeing that sites *should* save information between sessions, we didn't want to make that a requirement and make implementations harder. Where sites are already providing that functionality, it does not appear to gain anything for us to add that requirement for those that already provide it. Also, given that any site where you can complete a process in one session is in scope, it would have to meet the SC anyway.
Chuck: +1 if you agree with Alastair's response
<JakeAbma> +1
<Fazio> +1
<kirkwood> +1
<Brooks> =1
Chuck: No objections
RESOLUTION: Accept Alastair's response to the issue.
<Brooks> +1
Chuck: It was noted that we seem to be missing a word
Bruce: you also had plus ones for
making the edit
... OK
<MarcJohlic> I'll just add my 'missing word' comment to the change in GH
Chuck: We are not approving the pull request, we are abandonning it
<Chuck_> https://github.com/w3c/wcag/pull/1327/files
<Chuck_> Change: Users with mobility impairments, for example using switch control or voice input, benefit from a reduced need for text entry.
Chuck: I am also pasting this in Zoom chat
<Chuck_> Change: If data is provide by the user with a very different method, such as uploading a resume in a document format, that does not count towards this success criteria.
Chuck: 3 agreed in the survey, 1 wants something else
Sukriti: it doesn't make it clear what applies to what. The spirit of it I agree with
<Fazio> Agreed
Andrew: I don't think that it is covered by the SC as a problem
<Chuck_> Sukriti: This success criteria does not apply if data is provide by the user with a very different method, such as uploading a resume in a document format.
David F: I agree with Andrew, that wasn't the intent of what we were writing
Chuck: Do you have any concerns with the clarification, David?
David F: I agree with everyone
Francis: I question the word "very"
Chuck: Francis - is the use of very a show stopper for you?
Francis: no
<bruce_bailey> agree that we should drop adjective "very"
<kirkwood> very/significant
Brooks: This is something I
brought up when we first discussed this SC, when you are trying
to do a job application
... You take time to create a new resume, then upload it, then
you are asked to provide the same information you just
uploaded
... I'm not sure what is involved with translating that
information into pre-populated form fields
... We may want a note that says if you have a form asking for
what was just uploaded, that there is at least some attempt to
add it in
<Zakim> alastairc, you wanted to say the intent was more about typing things in.
Alastair: From my memory, the
intent was not requiring people to re-type in the same
data
... If you had just done your resume in a document, and then it
is asking you for the same data it seems repetitive, but in the
website context, you are not re-entering it
... Re Sukriti's edit, I'm fine with that
<alastairc> Proposed edit: This success criteria does not apply if data is provide by the user with a different method, such as uploading a resume in a document format.
David F: I agree with Brooks, but it would be going into another scope
<Chuck_> Alternative: This success criteria does not apply if data is provide by the user with a different method, such as uploading a resume in a document format.
scribe: we were thinking about
mental fatigue
... We would need more time to redo it
... Though it would be great
Brooks: I don't want to through this off
<Fazio> +1 to Brooks
Brooks: I just wanted to reintroduce that concept since we hadn't gone down that path. I'm putting that suggestion out there that could be added as a AAA requirement, or aspirational goal
<Fazio> I agree making it AAA
Brooks: Not out of scope here, because it is germain to the conversation
<alastairc> Good to deal with one issue at a time - we're dealing the current AA version.
Brooks: I still approve what you are wanting to do
Chuck: David do you want to make this AAA?
David F: No, for later, as a AAA
Chuck: OK
... I have pasted Sukriti's suggestion, with "very" removed in
IRC and Zoom chat
<Nicaise> +1
<Fazio> would b+1
<Zakim> mbgower, you wanted to say the key for me is "entered"
<Fazio> +1
<laura> +1
Mike G: The wording "previously entered by" is different than "submitted"
scribe: When you submit something you have to type it
<bruce_bailey> +1 for Sukriti's suggestion (minus "very")
scribe: The response is talking
about "provided by the user"
... It is entered by the user
... We can also rely on that
<Francis_Storr> +1
Chuck: I see some +1s, no objections
<Detlev> +1
RESOLUTION: Accept Sukriti's new line to understanding document of redundant entry to address issue 1293.
<Sukriti> I'll make the PR with the edit
Chuck: (reads from survey)
<Chuck_> https://github.com/w3c/wcag/pull/1326/files
<Chuck_> Change: Users with mobility impairments, for example using switch control or voice input, benefit from a reduced need for text entry.
Chuck: 4 individuals agreed,
nobody objected
... Do we agree with adding this as a benefit?
<Fazio> +1
<Nicaise> +1
Mike G: Should it be re-entry?
Chuck: I don't know
... I think either works
<Raf> +1
Chuck: We have a few +1s
<laura> +1
<mbgower> +1
<Sukriti> +1
<bruce_bailey> +1
<JakeAbma> +1
Chuck: Any objections?
RESOLUTION: Accept new line to understanding document of redundant entry to address issue 1276.
<alastairc> +1 (Noting I didn't +1 my own PR previously ;-)
Chuck: Numerous issues have been
raised
... (reads survey question 1)
<Chuck_> Proposed respone: There is significant evidence that it is not always possible for authors to meet a strict 'fully unobscured' requirement whilst sticky headers/footers are in place. Therefore that requirement has been kept to the AAA version of Focus Appearance.
<Zakim> mbgower, you wanted to say it's not just sticky headers
Mike G: I think the overall response is good. It is not just sticky headers and footers.
scribe: If someone alters their
text spacing, there might be a situation where the author
cannot predict every way where this can be altered by the
user
... I'm ok with it, I just think it is not just that
<alastairc> Updated: There is significant evidence that it is not always possible for authors to meet a strict 'fully unobscured' requirement. Therefore that requirement has been kept to the AAA version of Focus Appearance.
scribe: You could even take that part out
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/results#xq1
Chuck: I pasted that into Zoom chat
Brooks: This is an issue I have
commented on in the past.
... Why are we giving a pass to content implementation
approaches that we know aren't going to deliver on the
accessibility issues we have called out as important
... Like focus order, the perceivability of where your focus is
located
... I agree with Mike's statement there
Brooks: The 1st thing we did was give a pass that we had rules in place before that would limit that
Alastair: There are a lot of
different scenarios, including sticky headers and footers
... Text wrapping, when you have a media carousel and it is a
good usability feature to cut off the right hand side...
... Your focus indicator there might be slightly cut off
... We are potentially making an interface worse
<Zakim> mbgower, you wanted to say that an object may be so large it's full focus cannot be in place
Mike G: Imagine someone has a really large link. It may be impossible to fit the entire link in the viewport, and you would fail this
scribe: Even if you have a good
chunk of the focus indicator
... If we don't allow this exception, we run into all these
problems
Brooks: I recognize those, but
they seem like edge cases
... And things the content author has complete control
over
... There is nothing that requires these things, they are
choices
... It seems odd to me to make a pass on these
Alastair: Partly it is because
when you include page variations, media queries, it is common
that things may not fit in the viewport at that size
... It will affect most sites in some way once you test reflow,
text sizing, I think it may affect every site
... Some of the comments were suggesting some kind of
metric
... Like half should be visible - providing a mathematical
approach
... Instead of partially. We haven't dealt with that
... I'm wearing of adding more math to this
<Chuck_> Alternative: There is significant evidence that it is not always possible for authors to meet a strict 'fully unobscured' requirement. Therefore that requirement has been kept to the AAA version of Focus Appearance.
Mike G: Do we want to include any of these considerations in that response?
scribe: Would this benefit from a
few examples? Was that in the Understanding Document?
... We could respond that we will provide examples
Chuck: Mike, you aren't opposed, you just want to beef it up?
<alastairc> Current understanding document: https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html#unobscured
Mike G: Yes. Since some are objecting. Maybe some of what we are talking about will help contextualize it
Chuck: I will share that link in Zoom chat
Alastair: Right now we have a paragraph talking about unobscured, but not examples
Chuck: Is the proposal to add examples to our response or the Understanding Document?
Mike G: Will the next question be to provide them?
Chuck: If someone increased the examples, are we ok with this response? Or are there still objections?
<Detlev> +1 OK with response
Brooks: I think examples would
help, but only if we limit the scope
... It is one thing to not to speak to something, but it is
different to provide a pass
... I object to that
<Chuck_> Alternative: There is significant evidence that it is not always possible for authors to meet a strict 'fully unobscured' requirement. Therefore that requirement has been kept to the AAA version of Focus Appearance.
Chuck: We have the alternative response
<Nicaise> +1
Chuck: Just this response, without examples. +1 if you approve
<Brooks> -1
<Chuck_> +1
<Detlev> +1
<Francis_Storr> +1
<bruce_bailey> +1
<JakeAbma> +1
<Sukriti> +1
<AWK> +1
<mbgower> +1
<alastairc> +1, happy to add to it as well
<laura> +1
<kirkwood> +1
Chuck: Brooks is the lone objector. Are you sufficiently concerned, a show stopper?
Brooks: I think it is a back door
way of changing some solid rules that have a lot of value, and
help authors do the right thing
... I'm not sure if this will set a precedence
... It is bothersome for me
Alastair: In terms of our current
decision tree, we came to the agreement that the current state
doesn't cover sticky headers and footers
... If we have the unobscured bullet removed, I don't think
that covers the sticky headers and footers element either
... If something is temporarily obscured, such as tabbing
downwards or across a carousel
... This is allowing us to catch it in some way
... Do we go with a word like "partially" or a metric
... Within the github thread wherever we have developers
commenting, they say this isn't under their control
... Without the ability to actually solve the problem, I don't
feel comfortable putting that requirement on people
Brooks: I understand that. I
think maybe we can introduce some new markup that would add
some semantic language
... That would work with AT
... I don't want to keep you from what you are going to do
RESOLUTION: Accept the proposed alternative answer for issues 1271 and 1304.
Chuck: (reading from #2 in the survey)
<Chuck_> https://github.com/w3c/wcag/pull/1322/files
Alastair: in the focus appearance minimum it is change the last bullet from not obscured to not fully obscured
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/results#xq2
Alastair: changing the term of
unobscured
... there are 4 files with the same change
Chuck: 3 people agreed with the
change, no objections in the survey
... Does everyone agree with the proposed change?
<bruce_bailey> @chuck, refresh survey. i see 5 hits
<laura> +1
<bruce_bailey> +1
<Sukriti> +1
<Francis_Storr> +1
<Nicaise> what does the change look like when applied with the title?
Alastair: not sure what you mean with the title
<alastairc> Not fully obscured: The item with focus is not entirely hidden by author-created content.
Alastair: that is the AA version
<mbgower> +1
Chuck: Nicaise did that answer your question?
Nicaise: yes
Mike G: My only slight reservation is that unobscured implies that you don't want to be obscuring it. Whereas not fully obscured sets the bar lower
Alastair: Someone commented that
they could not tell the difference between the AA and AAA
versions
... To make it more scannable
Mike G: got it
<Nicaise> +1
Chuck: Any objections?
<Brooks> -1
<Brooks> for the same reasons
Mike G: You want something to be visible. Saying not fully obscured bothers me
Brooks: yes, same reasons as prior one
Mike G: The intent is that you don't obscure it
Chuck: We have predominant +1s
<bruce_bailey> unobscured is higher bar than not fully obscurred
Mike G: How about "fully visible" but I can live with it
RESOLUTION: Accept the recommended changes to address issue 1291.
Alastair: If you want to make an alternative we can come back to that
Mike G: sure
Chuck: Please consider scribing
hour 2
... (reading from question 3 in survey)
<Chuck_> https://github.com/w3c/wcag/pull/1330/files?short_path=64d4293#diff-64d4293ea4b29dd726c9a8cd2ce923c2
Alastair: alt = 2 blue buttons, 1 with a thick yellow line down the left of the button
<Nicaise> Thanks for the example
Chuck: There are a few changes to the criteria itself
<bruce_bailey> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-updates/results#xq3
Alastair: this is because we added to the success criteria to allow for a think border or outline down the shortest edge of a control.
<mbgower> +1
<Nicaise> +1
<laura> +1
Chuck: Please +1 if you support the change
<JakeAbma> +1
<bruce_bailey> +1
<Sukriti> +1
<Francis_Storr> +1
Chuck: Any objections?
RESOLUTION: Accept the recommended changes to address issue 1279.
Chuck: Scribe change time
<Sukriti> I'll do it
<Glenda> scribe: Glenda
<Chuck_> https://github.com/w3c/wcag/pull/1331/files
<mbgower> +1
<Chuck_> Change: The term "components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.
https://github.com/w3c/wcag/pull/1331/files
<Chuck_> "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.
mgower: “the term” makes it read more awkwardly. What about just putting components in quotes?
bruce_bailey: we use components throughout WCAG. Are we only doing this here?
<alastairc> https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html#dfn-user-interface-component
bruce_bailey: anxious that we may not understand all the implications.
<alastairc> https://www.w3.org/TR/WCAG21/#dfn-user-interface-components
Chuck_: there already is an existing line, this is just a clarificiation.
<Chuck_> "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls.
<Raf> +1
Chuck_: please +1 if you support this change
<laura> +1
<Detlev> +0 Feel unsure about it
<JakeAbma> 0
<bruce_bailey> +0
<alastairc> +1
<Chuck_> +1
<Sukriti> +1
<Francis_Storr> +1
<kirkwood> +1
Chuck_: asking for Detlev, Jake, Bruce to express concerns…if any?
alastairc: does it add work to update a note under a def for you MichaelC?
MichaelC: no
<mbgower> Here is the definition in full, FYI https://www.w3.org/TR/WCAG21/#dfn-user-interface-components
RESOLUTION: Accept the change with quotes to the terms for user interface components to address issue 1296.
Detlev: I found it a little confusing to have “components” as a term and “UIC”. I haven’t had enough time to look. I’m okay if the rest of you are okay with it.
<Zakim> mbgower, you wanted to say I pasted in the definition
<Chuck_> https://github.com/w3c/wcag/pull/1332/files?short_path=84f0cab#diff-84f0cab54b4b31921e313a7da8df1158
alastairc: describing the image
with the alt text of “A paragraph of text containing a link
broken over two lines. The red focus outline has a gap on the
right of one part of the link, and on the left of the other
part of the link.”
... okay to have a gap on one side due to the multiple
lines.
detlev: is this really something people would ask?
alastairc: yes, even when we were writing 2.1, we got questions like this.
Chuck_: everyone support this change?
<Nicaise> +1
<alastairc> +1
<Sukriti> +1
<JakeAbma> +1
<bruce_bailey> +1
<kirkwood> +1
<Francis_Storr> +1
<Detlev> +0
detlev: I would appreciate if there was a way to indicate that a 2 pixel underline would meet. And you wouldn’t have to calculate surface area. This would be common and reasonable to meet. I think 3 pixels is too much.
alastairc: we have another issue related to this coming up
RESOLUTION: Accept the changes to the understanding of focus appearance to address issue 1328.
<alastairc> Findable help: https://github.com/w3c/wcag/labels/3.2.6%20Findable%20help
Chuck_: end of our agenda…we can move to bonus content, review issues
<alastairc> Accessible authentication: https://github.com/w3c/wcag/labels/3.3.7%20Accessible%20Authentication
<alastairc> Fixed reference points: https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%222.4.13+Fixed+reference+points%22
<alastairc> Hidden controls: https://github.com/w3c/wcag/labels/3.2.7%20Hidden%20controls
<alastairc> Pointer target spacing: https://github.com/w3c/wcag/labels/2.5.8%20Pointer%20Target%20Spacing
<alastairc> (I think Sukriti has signed up for most of these.)
<alastairc> Dragging: https://github.com/w3c/wcag/labels/2.5.x%20Dragging
alastairc: would be really useful for people to pick up and process one of these issues. It usually takes me about 20 mins per issue. Review an issue, if you think you can tackle it, assign it to yourself. Then propose an update. Then add a ready for survey label.
Nicaise: can somone help me get authorization to self-assign an issue to myself?
<mbgower> br
alastairc: on the github issue, when you are properly authorized, there should be a button with the name of “assignees”. Then it opens a type ahead find. Or, under that, there is a link “assign yourself”.
sarahhorton: I also have trouble getting to the Assignee dropdown. I don’t think I have authorization.
alastairc: send your github username to MIchaelC so he can get you authorized
<Jennie> Just sent mine to Michael, and will start working through Findable Help
alastairc: please take this 30 minutes to review issues and assign one to yourself! If you aren’t authorized, then you can make comments.
Jennie: can you walkthru how to put in a proposed response?
alastairc: assign yourself,
review the issue and comments. Then in a comment, just type in
“Draft proposed response” then put your comment in. Then go to
labels and select “Survey - Read for”
... another way to do this more privately, is do it via email
to the WCAG email list, or to the chair’s email list.
... if you think something needs to be changed in a SC…you can
make a comment in that issue..and the chairs can help make a PR
if that is appropriate.
<sarahhorton> Sorry, my connection keeps dropping
<Sukriti> thank you!
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) Present: alastairc Jennie MichaelC Francis_Storr Fazio Raf Detlev stevelee sarahhorton Nicaise Laura Brooks pwentz Glenda JakeAbma Sukriti mbgower kirkwood MarcJohlic OmarBonilla Found Scribe: Jennie Inferring ScribeNick: Jennie Found Scribe: Glenda Inferring ScribeNick: Glenda Scribes: Jennie, Glenda ScribeNicks: Jennie, Glenda 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]