<mbgower> scribe:
<mbgower> scribe: mbgower
AWK: TPAC is next week
... We have 16 people signed up.
... Others may be joining by phone
... The link for remote participation can be reached from the
link in the agenda
... It's not the regular call in information
... We want to talk about the agenda. We briefly went over it
last week.
<bruce_bailey> FWIW, i plan to attend (by phone) most of the Silver mon/tue meetings, but very little of our thur/fri stuff (as I have meetings in town EST).
AWK: Thursday after registration
we want to set expectations then Jean will be calling in remote
for Silver.
... THe silver TF will be looking at a variety of topics. I
will update with material I just got from Jean. They are
looking at conformance prototypes.
... It's going to be more comprehensive than we've done in the
past, which will get more people up to speed, providing more
opportunity for discussion and comments.
... Most of the remaining time will be WCAG 2.2
... Friday will be a continuation. If we need to spend any time
talking about WCAG 2.1, we can do it (if we don't finish on
today's call).
... Any questions?
Bruce: No meeting Tuesday?
AWK: Correct, no regular meeting next week.
Bruce: Teleconference info?
AWK: It's on this agenda page
under REmote Participation
... We are not going to meet on Sept 24.
<alastairc> Good reference for future meetings: https://www.w3.org/WAI/GL/wiki/Upcoming_agendas
AWK: everyone who looked at this update to CSS pixel language said 'yes'
<alastairc> (Applies to the note underneath the SC text.)
Bruce: This is an example where
we have the except following the language, instead of in the
SC.
... It would be "Except for parts of..."
AWK: That has nothing to do with this. Can we deal with the erratum first?
RESOLUTION: Accept erratum as proposed
Bruce: In 2.0 it was very much
natural language. In 2.1 the language has exceptions after the
success criteria. I would argue it's very poor form.
... Anyone feel that way?
AWK: We had some exceptions in
2.0 like that.
... I don't view this as a huge problem.
<alastairc> Seems minor to me, I wouldn't have noticed if it hadn't been pointed out...
<AWK> Mbgower: actually prefer the approach where the exception is at the end.
<bruce_bailey> i am hearing mike saying he likes the 508 style!
<AWK> ... sometimes find it confusing when it is mixed in
Bruce: I'm just saying we should be consistent. I'm okay with the 508 style [grin]
AWK: It's something we can take a look at. Can you create an issue, Bruce?
Bruce: I would be happy to
AWK: None of them are unanimous.
AWK: There are a few differenet versions. John Foliot put this together. There are lots of long examples. He was trying to show where this could be a failure.
<AWK> Mbgower: Core concern is that SC doesn't say "CAN'T use autocomplete for inputs not about the user"
AWK: Jake was that your concern too?
Jake: Yes. If we had attributes
only for the user, this might have been possible. But because
we are using existing attributes, we created our own trap for
not being able to create our own failure.
... Of course it's going to create a problem when you see
multiple email inputs.
... Sometimes we want to use multiples. That is a second
consideration
Alastair: I didn't get a chance
to fill in the survey. I agree the SC doesn't give it that
basis. I think it could be adjusted though.
... We could create one where it doesn't use autocomplete.
AWK: Right, the other failure we
can do is have an input about the user that needs autocomplete
and it doesn't use autocomplete or uses the wrong token.
... I hadn't thought about this one in this particular way. in
the HTML spec it says the autocomplete attribute is for inputs
about the user. maybe we glossed over because of that.
<alastairc> Github discussion on this: https://github.com/w3c/wcag/issues/642
AWK: If the goal is to make sure
each field can be programmatically determined, obviously if all
fields are showing the same info, we should be able to say one
is showing the wrong value.
... Did others have thoughts on this?
<Zakim> alastairc, you wanted to say we often find autocomplete="none"
mbgower: You could use concatenated values to distinguish between user and non-user inputs as a sufficient technique
<AWK> it is autocomplete="off"
<alastairc> Noting that there might be a vaild case to use autocomplete="off" if a type-ahead-find input is being used.
AWK: Do people feel like the wg could have said 'for this SC, it is not just that you had to identify the input's purpose correctly but that you couldn't define that incorrectly?
David: I'm concerned about overreaching the SC. We could in the future, but not here.
<alastairc> I think we should allow for improved user-agents, so not to prevent multiple profiles which could fill in multiple users info. So should't rule-out using autocomplete elsewhere.
David: making the things not about the user marked as "none" would concern me. I'd want to think about it.
AWK: Based on comments here, it sounds like there's a core problem with this failure technique.
<alastairc> If it's focused-down to missing/incorrect tokens, should be ok.
AWK: Obviously it does impact if
someone is using autofill it does impact the user negatively if
the tokens are used incorrectly. But it doesn't seem like we
have the SC language to create a failure around that
... I guess we need to write the other failures.
... Anyone have an objection to not approving this one?
Jake: John Foliot, probably.
AWK: I talked to John. We should be able to use some of this, maybe in the understanding document?
RESOLUTION: Do not accept 1.3.5 failure technique as proposed
AWK: We've got one to accept, one to change and one not to accept
Jake: The second sentence maybe should be part of the procedure?
Alastair: I think I removed that from the procedure and put it in the description. I don't feel strongly about it, but was trying to make the procedure less detailed.
Jake: On the email client, some
of the options are available when you go to the email, even if
the actions are only available on the prior inbox screen via
gestures
... Expanded is not the same as going to the next
page/step.
<alastairc> Doesn't part 2 of the procedure cover that?
AWK: So if you swipe and get ABC options, and when you expand you get AB, you would fail because option C is only available via the gesture. But if you can go to the next page, then you can do C on the next page.
<alastairc> In the 2nd example, how about: "One or more of these options are not available from a tap or click." - avoiding the page/view difference.
<alastairc> Or "One or more of these options are not available from a tapping or clicking."
mbgower: in an email client, one can have the options when the user opens the mail item, instead of offering them in the inbox view.
David: There's a long history to
that conversation. Back in the day we would struggling with the
javascript menus. The top level item would go to a new page and
the new page would have the other actions. Technically WCAG is
page level, but we always allowed those.
... Also, the datepicker wasn't on a different page, but you
were doing the same functionality without the bells and
whistles via the input
Alastair: If we just rephrased
things, we could just avoid the whole 'is it a page'
consideration.
... That would remove the concern about it only expanding in
place
<alastairc> Full example text: A swipe-to-reveal control displays a set of options when swiping an item to the left, and another set of options when swiping an item to the right. One or more of these options are not available for simple pointer activation after the item is first opened with a single tap.
<AWK> https://www.irccloud.com/pastebin/lpfDtyTM/
Jake: That makes sense. If we
allow the old school example of the long description, providing
the link, the long description is on another page.
... If we take a more holistic approach, it is not page by page
but you still find ways to active with a single click. You can
put it in a second place and it's fine to be encountered
later.
Alastiar: That's the same conversation we had around reflow. You may have to click through to get to all the same content.
Jake: That's a clear fail.
AWK: If you have functionality that doesn't meet the criteria, but there's an alternative version, as long as you can get to it from the non-conforming version...
<laura> longdesc isn’t deprecated. https://www.w3.org/TR/html-longdesc/
Jake: That feels a little awkward.
AWK: If you zoom in enough that not all content can fit, then withholding information under a submenu...
Jake: expresses concerns with a page where one has to click on every link on the page to get the same experience
Chuck: My understanding of US law is that it supports as long as the path or an equivalent is accessible, we meet the requirement. So my point is it is not a new concept that an alternative exists.
Jake: But we are creating WCAG.
What specific countries do with it or interpret it, is not
relevant.
... IN this example, you can click through and I totally agree.
But saying 'there is a better experience on the next page'
means we need to rethink our testing procedures.
<Chuck> I acknowledge the point on WCAG and that it's the country's business how WCAG is interpreted and implemented.
<david-macdonald> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-conforming-alt-versions-head
<bruce_bailey> the conforming version can be reached from the non-conforming page via an accessibility-supported mechanism, or
<bruce_bailey> the non-conforming version can only be reached from the conforming version, or
Jake: We have a search button. Teams use it for different searches. At the bottom of the page is a universal search which has text alternative. But the other pages have other searches which do not have a text alternative.
<bruce_bailey> the non-conforming version can only be reached from a conforming page that also provides a mechanism to reach the conforming version
David: I just dropped in a link
to a conforming alternative.
... On paper, there's what it requires, then there is what is
happening in the wild. There's a bit of variation in the way we
interpret versus the real language.
... Conforming alternative version is a whole page. So
arguments against that make it sound like I'm
contradicting.
... We've lived with a certain amount of ambiguity. I gave the
drop-down menu example. That doesn't strictly conform, but we
allowed it when there was no other technical solution.
Jake: I'd like to ask something about #2. It says pretty clearly that is provides all of the same funcitonality and information
<Zakim> bruce_bailey, you wanted to mention CAV has caveats
Bruce: The conforming alternative version is part of wcag, so this is an important consideration.
<Zakim> alastairc, you wanted to talk about previous discussions on this point: https://github.com/w3c/wcag21/issues/813 / https://github.com/w3c/wcag/issues/728
Bruce: Iv'e had someone say the calendar date picker is not the same because it provides the day of the week in the view, but the input does not.
Alastair: I'm not sure if the
alternative versions discussion should be pursued. We discussed
in reflow and text spacing. Say Apple News. You have a very
constrained layout, and if someone pumps up the text size, it
will cut off some content. But you have one click thorugh to
open up a view
... I think that is a legitimate approach.
AWK: Getting back to this failure, 2.5.1. The question on this one that we were talking about is the second example.
<alastairc> Suggest: One or more of these options are not available for single pointer activation after the item is first opened with a single tap or click.
AWK: Are we okay going with it as it is?
<alastairc> From Michael's point: One or more of these options are not available after the item is first opened with a single tap or click.
<AWK> Things to change:
<AWK> 1) Remove third example bullet
AWK: Does anyone object to moving third example bullet?
<AWK> 2) Update using Alastair's text "One or more of these options are not available for single pointer activation after the item is first opened with a single tap or click."
AWK: Does anyone object to alastair's change?
<alastairc> Amends: https://github.com/w3c/wcag/pull/880/commits/0d9a2ddccc4b13e2b5899f345b164bcc42f560fb
<AWK> 3) remove procedure step 1 and updating the expected results
<alastairc> This has updated for me: https://raw.githack.com/w3c/wcag/tech-failure-path-based-gesture/techniques/failures/FXX-path-based-gesture.html
<Jennie> I can scribe
<Jennie> scribe: Jennie
AWK: I think we should be careful about doing that too much. It is a valid thing.
Jake: I totally agree.
AWK: Alastair has updated it to the current state.
Alastair: yes. The preview is cached.
AWK: Jake - was there something you wanted to change or add?
Jake: ok as it is.
AWK: given the changes we have, are there any objections to accepting this failure as amended?
<mbgower> +1 accept as amended
<AWK> +1
<alastairc> +1 as amended
Jake: when I checked 2 weeks ago the slide worked in portrait but not landscape mode.
Alastair: that is part of the next technique
<JakeAbma> +1
Resolution accepted as amended.
RESOLUTION: accepted as amended.
AWK: 2 approves, 1 changes. Mike Gower has suggestions
Mbgower: yes, that's right.
AWK: why a note?
<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/MiscItems09022019/results#xq29
Mbgower: that is the exception of the sc being listed there, but the failure is really about not being able to turn something off.
AWK: extra information covered in
the understanding document. I can agree with that. We could
remove that.
... and not affect this.
... the 2nd step in the procedure you are saying you do not
understand, and check ...
Mbgower: I can see lots of people not understanding that.
AWK: check if the motion sensor is essential, and the continue on...check if supported in an accessible interface - would that satisfy it?
Mbgower: what is a user has
tremors, and no AT.
... the fact that there is an accessibility supported interface
that works or doesn't work is irrelevant to my situation. I
just need to turn off the sensor. So this doesn't seem relevant
to me.
... the whole exception is kind of weird. There are lots of
things that might be accessibility supported, but it doesn't
mean that you don't have to have a way to turn it off.
AWK: this failure is around not
being able to disable that motion detection.
... would you say that removing #2 in the procedure?
Mbgower: or rolling it up. If it is not required by an AT (essential) then you need to be able to turn it off.
AWK: you think the intent is that if a motion is required to operate it...
Mbgower: change the first step to say:
<AWK> "Check if the use of a motion sensor is essential or required to make the function accessibility supported."
AWK: if we change #1, remove #2, then the expected results if 1 and 2 are false then the control fails this SC
Mbgower: yes
AWK: can you edit it, Alastair?
<mbgower> Success Criterion upper case?
Jake: in portrait it works, in landscape it doesn't.
AWK: I have seen the example
work, but we should make sure it is working.
... it is a slider, if you tip your device it increases or
decreases. Mike Gower has pointed out that isn't enough, you
need a way to disable it.
... but if it is not working, it is disabled by default
... with those updates to the procedure, which will make it so
there is 2 items in there combining #1 and 2, and we can get
rid of the 2nd paragraph in the description
Alastair: completely?
AWK: the 2nd to last sentence
addresses the indirect motion
... is that covered in the understanding document?
Alastair: should we just make that a note?
AWK: yes, that's fine.
... indicate that it is an aside.
Mbgower: I think I opened an issue up.
<alastairc> Amends: https://github.com/w3c/wcag/pull/845/commits/39d1d1f7f1fc43de8f163637bf97134742afde72
AWK: the note looks like the
exact same text used in this technique.
... it doesn't expand on it any further.
... we make it a note, adjust the procedure, make sure that the
example works. Assuming those are taken care of, any
objections?
<mbgower> You can always just remove the working example for now
RESOLUTION: accepted as amended
AWK: hopefully that will not be
necessary, since i know it has worked.
... we have a few things to edit, and we are done with this
survey.
<AWK> q
<Zakim> mbgower, you wanted to say easy solution is to remove working example
AWK: there are a few in
here
... dragging is the first one
... 24 minutes left in the call. There are 5 of these in
here.
... be quick
... Detlev is not on the call.
... 5 people do not have major concerns. Detlev had some
concerns.
... He says the question is if we include all forms of
dragging...
"I pushed this, I am much in favour of it. But the queston we need to answer is whether we include all forms of of dragging (moving visible map section, reordering lists (directional/constrained dragging), drag-and-drop (unconstrained dragging) or scope out some forms (certainly OS-provided stuff such as enlarging textareas by dragging the corners, but possibly also forms such as unconstrained / free-form drag-and-drop). What kind of developer push-back will this ge
AWK: Justine's comments Detlev can look at
Justine: my second comment aligns with Detlev's
Alastair: my main comment is
around feasibility. I have memories of people bringing up
dragging based examples that were keyboard accessible. When we
looked at how you achieved the same thing with taps and clicks
seemed difficult to do without impacting both regular use and
keyboard accessibility.
... I think research is needed to see if this is a feasible
ask.
AWK: OK. The comments are all in
the same vein in terms of clarifying what we mean by dragging
and expected push back because of essential use of that type of
functionality.
... anyone on the call have additional thoughts they want to
share?
Mbgower: I think research would be helpful. It would be good to determine what functionality is inside operating systems, and what doesn't apply to web-based.
AWK: yes.
... anyone else?
David M: I put my support behind this success criteria and think it is a good idea. Is this already part of 2.1.1?
scribe: I do agree that all
attempts to make dragging accessible in the past have been
unsuccessful.
... I think we need to provide an alternate functionality for
that.
Alastair: sounds like we need to gather examples.
AWK: yes, I think so. It is
important to clarify where this goes beyond 2.1.1. What else is
required by this SC.
... next one.
<jon_avila> it goes beyond 2.1.1 by requiring that things can be done by touch and not just keystrokes.
<bruce_bailey> http://www.w3.org/2002/09/wbs/35422/wcag22reviews/results#xq13
Alastair: David F made a good first go at this one. Nobody has stepped forward to help into a more content focused SC.
<AWK> David Fazio
<alastairc> Information in steps: For pages that are part of a multi-step process, information requested from the user in one step is not requested in a subsequent step unless the information is re-displayed when it is requested.
Alastair: I thought more about this today and I think it would be good to make into 2 different SC. The first one I will paste in
<alastairc> Visible labels: Inputs with labels or instructions display the labels or instructions at all times.
Alastair: this may address some of the comments. I would like to check with David to see if this still meets the original intent.
AWK: no response from David F -
maybe he is muted?
... ok, that is a question for David Fazio to check out and
respond to
... Detlev said "this should not be vcontrued as ruling out
things like copy-paste of passwords."
... Patrick says this is already a failure of 3.3.2.
... Justine do you want to speak to this?
Justine: an exception is needed
along the lines of "essential to the activity" - I can't think
of specific examples.
... we might prepare some text around when recall is
required.
<Chuck> regrets, need to leave a few minutes before call formally end.
Justine: the 2nd comment: plain
English summary that discusses mental fatigue and impact on
ability to learn. Should we remove this, or is it supported by
research?
... 3rd comment from me is that there could be instances when
an application stores information provided by the user, and
then the information is displayed again. There does not seem to
be a place to address subsequent uses.
... the last comment from me: requesting the same information
more than once is a way to reduce errors. E.g. password
confirmation prompts. And "I agree" checkboxes.
<alastairc> Agree with adding an 'essential' exception, should cover the last point as well
Jennie: what is the way we could
include the user research?
... yes, we should list exceptions.
... I will bring the request for a research example to the COGA
taskforce.
Alastair: I recommend a slight rewrite.
<Zakim> bruce_bailey, you wanted to say i guessed that SC would be something like “Content does not rely on user memory for information”
Bruce: if we add the essential exception, that might bump it up to A or AA
AWK: what would make it essential.
Bruce: I don't know, but I heard exceptions.
Alastair: yes, the password might be, or a quiz - memory assessment of some sort.
AWK: OK, there is feedback on
that for David Fazio.
... he can check the minutes.
David F: I think it should stick. I am a formal federal union rep. There is something called cause. You need to have cause.
scribe: there needs to be a cause of action to show harm.
*I lost connection - need other scribe
<alastairc> scribe:alastairc
(missed a bit)
<Jennie> *Thanks Alastair, I'm back.
<Jennie> scribe: Jennie
David F: sounds reasonable. I will look at it.
<bruce_bailey> David F gave example of sighted person using WC cant file complaint about braille being missing
AWK: some people had concerns
around testing this - ensuring all functionality is available
in both orientations.
... AR/VR - hard to specify.
... our current SC is focused around avoiding the problem when
locked or restricted to one view. This one is saying you cannot
have reduced functionality in one orientation, and full
orientation for the other.
... we have a minute left. Any other comments?
Mbgower: wouldn't this be covered by requirements already?
AWK: I think there is a nuance there that we have to say something about.
<JakeAbma> it's same URL
AWK: you are still on the page if you are viewing it in landscape, or portrait mode.
Mbgower: ok
AWK: we have 28 seconds
left.
... we will look forward to seeing many of you in Japan. No AG
call next week during the regular time. The call information is
on the agenda page. We will send it prior to TPAC.
Trackbot, end meeting
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) Succeeded: s/that is fixed./that is part of the next technique/ Succeeded: s/David M made/David F made/ Default Present: AWK, alastairc, JakeAbma, Raf, stevelee, Chuck, Fazio, bruce_bailey, mbgower, MichaelC, JustineP, Laura, johnkirkwood, Jennie, david-macdonald, jon_avila Present: AWK alastairc JakeAbma Raf stevelee Chuck Fazio bruce_bailey mbgower MichaelC JustineP Laura johnkirkwood Jennie david-macdonald jon_avila Found Scribe: Found Scribe: mbgower Inferring ScribeNick: mbgower Found Scribe: Jennie Inferring ScribeNick: Jennie Found Scribe: alastairc Inferring ScribeNick: alastairc Found Scribe: Jennie Inferring ScribeNick: Jennie Scribes: , mbgower, Jennie, alastairc ScribeNicks: mbgower, Jennie, alastairc Found Date: 10 Sep 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]