<AWK> Zakim agenda order is 1,2,3,5,4
<laura> Scribe: Laura
<stevelee> preset+
AC: reminder early pricing is
good for only a week or so more.
... 9 people registered so far.
AC: my first charter
process.
... need a charter by october.
<alastairc> https://raw.githack.com/w3c/wcag/charter-2019/charter.html
AC: we have a draft.
... will be similar to our previous charter.
<scribe> …new dates
bruce: will charter state 2.2 can have normative changes from 2.1.
<Zakim> bruce_bailey, you wanted to ask if charter mentions permission to deviate from 2.0?
MC: won’t get to into that detail.
<Zakim> AWK, you wanted to speak to timeline and process a bit
awk: talk about that separte from
charter
... we have to get charter to management by end of june
... not in a panic mode to get this done.
... will be responsible about of time needed.
ac: let chairs know if you have any comments.
<JF> Q
bruce: some normative changes from 2.1 to 2.2?
ac: been discussing color and
4.11
... looking at significant changes.
awk: we need to address the issue
in some way.
... we are working on proposals for 2.2 and then hammer out
backwards compat and changes.
... all tbd
jf: color and 4.11 we haven't
made a decision.
... lessen is okay. I think I would have an issue with making
it stronger.
... leave contrast alone
ac: add a sentence for focus visible?
jf: if adding breaks tool chains then no.
<bruce_bailey> @JF if you (or anyone) thinks TT says something this group questions, please raise the alarm!
jf: concerned about conflicts
<bruce_bailey> +1 on the color contrast discussion getting dense !
jf: we need a new contrast SC not fix the old SC.
<bruce_bailey> To be clear, I am not proposing that 2.2 revisit 1.3.1
jf: regarding 3.3.1 and landmarks: could add a new sc but not change 3.3.1
<Zakim> bruce_bailey, you wanted to say i do not have large ambitions, but some phrasing in 2.0 is not consistant
<AWK> we probably shouldn't get into discussing the merits of any specific changes to 2.0/2.1 now
bruce: if TT says something this
group questions, please raise a stink.
... group is open to feedback.
<bruce_bailey> The one thing I would like for us to consider is changing 1.2.3
bruce: if we are open to
normative changes, would like a conversation on 1.2.3
... some places where phrasing should be updated.
ac: add an issue in GitHub. with wcag 2.2 label.
david: regarding contrast discussion greg explained how algorithm was created.
<bruce_bailey> @JF, yes 1.2.5 superceeding 1.2.3 is terribly confusing to people
<Zakim> JF, you wanted to say that 1.2.5 at AA supersedes 1.2.3
jf: 1.2.5 at AA. It supersedes
1.2.3
... it is an education problem.
<bruce_bailey> @JF back in 2008, i thought teaching 1.2.5 supercedes 1.2.3 would be easy
jf: could update the understanding doc. but not change normative language.
<bruce_bailey> it has not been easy
ac: ACT survey
... rules are like wcag failures
<alastairc> https://www.w3.org/2002/09/wbs/35422/ACT-rules-process/results
ac: 4 answers replied to the survey.
<alastairc> Process: https://github.com/w3c/wcag-act/issues/353
ac: thought is very clear and
good.
... focus on top of the issue.
<Zakim> AWK, you wanted to say that the content is non-normative so if we find problems in the process we can easily change it
ac: need to look at how to hook into understanding
awk: the content is non-normative so if we find problems in the process we can change it
wilco: heard from shadi. pubish rules separately since a redesign is underway.
ac: for discussion. some issues in Github.
ac: some progress since last week.
<alastairc> DAvid's updates: https://github.com/w3c/wcag/pull/583
some things to go into a survey for next week.
<alastairc> https://github.com/w3c/wcag/pull/669
ac: Micheal and detlev should take a look at Rachael’s Technique for device motion actuation
mg: did some followups on label in name. but not seeing in editor’s draft.
awk: take a look now.
ac: did merge some PRs.
... still looking for orientation and gestures techniques.
<mbgower> https://github.com/w3c/wcag/pull/732
<alastairc> https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/results
ac: trying to pin things
down.
... stemmed from an issue detlev created.
... some changes to understanding doc.
bruce: definition changed from option 1 to 3
ac: things in option 1 included
in 2 and 3
... Option 2 The medium option is to base the 'path based
gestures' aspect on whether it is a pre-set direction (or
directions). If a movement has to follow a pre-determined
direction it is covered. If it is unrestricted it is not
covered. This is covered in the updated pull request.
... all of the above examples would be in scope (fail without
an alternative), as anything that is not required to be
free-form must have an alternative.
<alastairc> https://docs.google.com/spreadsheets/d/1NGxqbwbcaG8dwSs5H2eTRy0gDELTdSuAi1ad0le4fDU/edit#gid=0
ac: option 2 focused on what is a
path based gesture and how it differs from drag and drop.
... made a spreadsheet with lots of examples.
<bruce_bailey> i feel like "drag and drop" (without alternatives) might sometimes be permissible under 2.1.1 -- but not with any of the examples in the survey
<Zakim> bruce_bailey, you wanted to ask if "excluded" means allowed?
<Zakim> JF, you wanted to ask about signatures - in scope or not?
jf: don’t see signatures in spreadsheet
ac: Drawing, e.g. a signature or freehand picture out of scope.
<AWK> Signatures are path-based. As a path-based gestures there needs to be a way to accomplish the same task with a single pointed unless the path based gesture is essential.
jf: we should be explicit.
... one is creative and one is legal.
<bruce_bailey> we have dodged the question about drawing
ac: using starting and ending points is problematic. as soon as you lift your finger it doesn’t matter.
<Zakim> bruce_bailey, you wanted to say we address "painting" but not "drawing"
bruce: is freeform drawing in or
out of scope? painting out of scope.
... not time based.
<alastairc> "An exception is made for functionality that is inherently and necessarily based on complex paths or multipoint gestures. For example, entering one's signature may be inherently path-based (although acknowledging something or confirming one's identity need not be)."
ac: understanding doc explains.
awk: last week we resolved “The
WG intended that path-based gestures in 2.5.1 does not include
gestures that only depend on the start and end points.”
... if we have a path based gesture that relies on 2 points it
is not a gestures.
... needs to have at least 3 points.
email example is an example of a path based gesture.
<bruce_bailey> hmm, not sure i agree about the email example
<mbgower> +1 to the 3-point method of defining 'path-based' in relation to gestures.
chuck: start point “relative” to
end point.
... need to have “relative” in the definition.
<mbgower> +q to say we're obviously stretching, but 'direction' seems to me to be the ultimate determinant for path-based in relation to gestures
ac: tried to take out free form in the understanding doc.
<AWK> -1 to the relative approach. You can leave a slider in the same place if you want, but this also loses the connection to the use of path in keyboard SC
<Zakim> mbgower, you wanted to say we're obviously stretching, but 'direction' seems to me to be the ultimate determinant for path-based in relation to gestures
mc: we are trying to reverse
engineer the SC.
... user is required to initiate
... initiate a direction
ac: need to consider a slider…may not require a direction.
<mbgower> is that really true, Alastair?
ac: 3 point would help with that use case.
<alastairc> https://shopify.github.io/draggable/examples/drag-events.html
has an example in spreadsheet.
scribe change?
<Zakim> bruce_bailey, you wanted to say that mousedown+move-a-little is just a selection
bruce: disagree with the email
example.
... like 3 point definition.
ac: added another column to the spreadsheet.
david: if you can’t do it with a single pointer then its okay.
ac: need to be careful with
that.
... depends on definition.
<mbgower> "relative direction"?
chuck: pitch again for using relative
<Zakim> AWK, you wanted to say that the slider example for Alastair is implementation specific
awk: sider is a good example. can be coded correctly or incorrectly.
<AWK> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range
awk: 3 point model makes it clear.
scirbe change?
ac: 3 point model scopes in everything we need and scopes out drag and drop.
<david-macdonald> scribe: david-macdonald
<alastairc> https://github.com/w3c/wcag/pull/403
Detlev: the original intent of the mobile task force was to ensure that any type of path based gesture would be covered in the success criterion. We scoped out drag-and-drop because we felt it was just too hard to do
I haven't thought long and hard about the three point and we will consider it not on this call. The problem was scoping out dragging, means that will scope out almost anything that we intended with the success criterion
Strictly speaking any type of content slider would be out of scope which means there would be very little left that would fail in terms of path based gestures which I think would not a nine or our original intention
<alastairc> Swipe, strict (e.g. next); Swipe, open (e.g. mail); Swipe, multi-value; Full page swipe (open); Slider (strict); Slider (open); Horizontal scrolling box (overflow-x).
Alastair: I'm pulling up my list now of things we want to put in and out of scope
These are the things that I think are covered
For instance the horizontal contents letter that you mentioned. I think we have a difference of terminology regarding what year talking about a swipe gesture versus a drag
putting a figure down moving at one direction and letting it go. I think that's covered
Detlev: content sliders are sometimes supplemented using drag-and-drop. If you put your finger down and wait just a fraction of a section longer you find you have no directionality enforced
An author wants to find a loophole would be able to argue that there is directionality involved
And then they can justify that they don't have to put in an alternative
<alastairc> Then excluded: Sortable list; Drag-drop to pre-defined places; Drag-drop to anywhere; Resize-drag of box corner; Panning Map; Drawing; Helicopter game
Alastair: we need some examples in this and I think we are in a relatively good position to do that.
Michael: if there is another method of swiping to carry something out then that's not a loophole then that's another method of interacting. I understand your point where you believe that mobile task force initiated something. We can say that for every SC. What often where we end up as light different than the task force attention
<AWK> +1 to Mike
If somebody comes up with a way of activating something with a swipe of our press and hold and go whatever direction they want it's no longer a requirement of direction so as not a loophole it's just two methods of operating the same thing.
<Zakim> AWK, you wanted to mention http://w3c.github.io/Mobile-A11y-TF-Note/#touchscreen-gestures
Andrew: I was going to point out to people that task force note around touchscreen should provide some additional clarity. But it does not really because as a best practice it talks about allowing users to either use a simple path or swipe gestures.
Yes we should talk about this for 2.2, but the original intent of the mobile task force was to have it to be a single tap and I believe that's what it was at one point. If it evolved and we think there's still gaps there then we need to address that in 2.2
Detlev: I think the normative text as it stands does not rule out that we cover dragging as well as swiping. I don't see that it's absolutely necessary to draw the distinction because it depends on our definition of path based and we haven't made that definition at so it depends on how we define path based to divine what's in scope without a scope. And we had a survey about that and we have six people in favour of keeping both of these things [CUT]
So there is no consensus right now that we would draw the distinction and exclude dragging
Michael: what is the definition about base that doesn't allow tracking.
<bruce_bailey> From 2.1.1: except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints
Detlev: the language that we have
previously but the start point in the endpoint ignore that
there's something else that's important which is the ability to
drag something across the screen and that is why we have the
continued reference to the exception 2.1 is not helpful because
now are talking with operational gestures that have an intent
to operate on screen making a swipe or dragging a certain
direction would indicate that
... I think we are free to define past based to cover the
substance of operational path based gestures and how we do that
is that we don't refer to the old exception language.
<Zakim> JF, you wanted to note that it's more than just "your finger" - you can be using a stylus as well
Alastair: I tend to agree that to 2.1.1 references not useful.
<laura> s/pubish rules separately since a redesign is underway/Publish rules separately since a redesign is underway./
JF: it's not just the finger it's also stylus. Thinking about project silver I could see the supply to touchpad interfaces where you sign your name. And asked me to sign on the screen there and the stylus is provided. I will be careful that we don't get so caught and that about swiping on the screen that were talking about any touch enabled interface where there is a pointer interaction. Whether it's a physical pointer are finger or something else.
Alastair: anyone else?
This was kicked off by Detlev's original issue. Were trying to find what's scope by trying to find Pat-based gestures. I'm just somewhat struggling to do that in a way that makes sense for all these different interactions.
If you essentially scope out drag-and-drop as in the free-form drag-and-drop, and things like drawing, then it's very difficult at not have that apply to things like sliders and certain types of swipe as well
So far the three point definition or method if you like seems to hit what I thought we were looking for. I can appreciate that sortable list should also be accessible but it comes down to should whether it should be accessible through the success criterion
Which I think is a slightly different question
So in terms of the examples I put above, which is above 1211, includes all kinds of swipes, sliders, certainly in terms of the mobile context if you have to go horizontally instead of vertically. An horizontally scrolling box which Detlev defined as a content slider. I think those are all in scope. The excluded ones are drag-and-drop, signatures, helicopter game and sortable list
<Detlev> +1 it has my support
Are those examples of in scope and out of scope what we would like to support has path based gestures?
JF: can any of these things be completed using the keyboard alone. I have left and right and up and down arrows, so I don't see how panning around map would be very difficult.
Alastair: we have keyboard separately
JF: the slider can be operated with the keyboard arrow keys.
<Detlev> @JF we are talking situations where pointer users have no kb
Alastair: the slider example at the top of the scroll or the bottom would now be in scope and so that would change.
<Zakim> mbgower, you wanted to say I think we need to focus on interpretation of movement
Alastair: there is a difference between making a required by keyboard but the question is about whether we need to make a work with a button
Michael: on the map if you want to think about a gesture is an interpretation of a movement versus moving left right up down. If you put your finger down and just repositioning the map. But unlike a yahoo email swipe move gesture left in be interpreted as initiation to interpret a message.
Alastair: I think we've gone as far as we can with this. We have a plus one from Detlev which I find heartening
<AWK> We are going to need to undo the resolution from last week in order to accept this
<AWK> Last week: The WG intended that path-based gestures in 2.5.1 does not include gestures that only depend on the start and end points.
<alastairc> Poll - do you agree that the 3 point method is the right approach to defining path based GESTURES?
Alastair: I think we just refining it. We are just adding the three-point method to bring in and scope
<bruce_bailey> please add example of painting (in contrast to drawing)
<AWK> +1 to 3 point
<bruce_bailey> please add at least one more game example to spreadsheet
<AWK> Pac Man!
Bruce: if were not making a distinction between drawing and painting that were missing something because painting includes speed pressure how thick is your style this. Where's drawing doesn't matter what I used to create it with.
<JF> +1 to Bruce
<bruce_bailey> i know of switch based interfaces for drawing
<bruce_bailey> i do NOT know of how to switch enable painting really
Alastair: or the ends of path based gestures was to put in anything that transfers the path to the content such as drawing. Painting is a superset of drawing which includes more characteristics.
<bruce_bailey> drawing is not usually how hard or how fast
<Detlev> +1
+1
<laura> +1
<mbgower> +1
<Chuck> +1
<JF> +1 to 3 point method
<MarcJohlic> +1
<bruce_bailey> paint effect usually depend on speed, and may depend on pressure
Alastair: I definition is the next thing to do. I did have a sort of draft but I need to update that based on this three-point method because I think it'll be a bit neater.
JF: I'd like to see this definition before we close the issue.
Alastair: will have to get the text in and then I'll agree that that's a we intended.
RESOLUTION: the approach is agreed-upon and it will be written up
Alastair: I don't think I can face number two right now. It comes back to path based gestures.
<Detlev> let me just say we have added buttons to the slider
Alastair: so go to the next one: it is about resize text. The proposal is to discuss how to we get to 200% when something is magnified to 400%
RESOLUTION: accept pull requests 715
PR: 692
<alastairc> https://github.com/w3c/wcag/pull/692/
DETLEV: I question whether just saying "Hey Kim" would have such an effect.
Michael: yes if the focus is not an input than the speech recognition will type in the words by their letters, and any associated character key shortcut will be triggered if it's not an input
RESOULTION: accept PR 692
<alastairc> https://github.com/w3c/wcag/pull/693
RESOLUTION: accept PR 693
<alastairc> https://github.com/w3c/wcag/pull/701
<JF> +1
RESOLUTION: accept PR 701
<alastairc> https://github.com/w3c/wcag/issues/369
JF: I don't want to lose any of these ideas even though they have not been fully baked. I think if nothing else we stand those off to the people of Silver because they may some thoughts resources around that. I agree however with Bruce that if we had a list of what the gaps really are can we make it bit of an effort to create them.
All of a sudden we were working on 2.1 and we had taskforces that were exploring the edges and the gaps in our requirements. But I don't think we should just abandon them. They were there for a reason and we should at least make sure that we have addressed that reason.
If we don't have techniques in our we asking for compliance?
<alastairc> Survey results https://www.w3.org/2002/09/wbs/35422/Tech_Und_survey/results#xq19
Michael: there is an implied promise when we say the word future technique. It might be better if we just said not yet published. Perhaps finding something that's not quite so promising about the future might be a little less embarrassing to hang around for 10 years. I agree with John it's good to keep the intentions because somebody could be motivated later on.
JF: I'd go further and I agree with the notion of a promise. I think we should put some effort into seeing how many of those techniques we could write up. Changing the name is like rearranging deck chairs but I think would be better spent trying to get some techniques in there.
Alastair: the quick reference draws in anything that has a title,
MichaelC: an update of the techniques in the quick reference is on the way right now with Eric and myself.
Alastair: is it possible to pull out a list of the things that got removed
Michael C: we could pull out a diff document between what was pulled out and what was there before
Alastair: sounds like the consensus is that we should keep them but were not quite sure how to at this point.
Some people suggested that we ask for volunteers to write them up, or have somebody to analyse them and make suggestions to the group and what to do, and send them over to Jeanne and Shawn over at the task force.
s/sean/Shaun
Alastair: we'll get that list together and it will probably come down to people working through the understanding Dobbin to decide on which ones should go in.
<JustineP> Muted in a loud environment but +1 to this approach
RESOLUTION: Michael Cooper to compile a list of the techniques that were deleted.
<scribe> ACTION: Michael Cooper to compile a list of the techniques that were deleted
<trackbot> 'Michael' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., cooper, melledge, mdgilbert, mbgower).
CTION: MichaelC_ Cooper to compile a list of the techniques that were deleted during the empty future technique clearing
RESOLUTION: Accept PR 721
<laura> bye
<alastairc> 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/charis/chairs/ Succeeded: s/2.21/2.1/ Succeeded: s/4.4.1/4.11/ Succeeded: s/thing/think/ Succeeded: s/1.31/1.3.1/ Succeeded: s/algorthen/algorithm/ Succeeded: s/superceeds/supercedes/ Succeeded: s/in the spread sheet/in the survey/ Succeeded: s/simlar /similar / Succeeded: s/chater/charter/ Succeeded: s/separte/separate/ Succeeded: s/managment/management/ Succeeded: s/panick/panic/ Succeeded: s/responsible abount of time though/will be responsible about of time needed/ Succeeded: s/ignificant/significant/ Succeeded: s/havent/haven't/ Succeeded: s/sentecne for focus visisble/sentence for focus visible/ Succeeded: s/contast/contrast/ Succeeded: s/is was/is/ FAILED: s/pubish rules separtely since a redesign is underway/Publish rules separately since a redesign is underway./ Succeeded: s/orentation/orientation/ Succeeded: s/stemed/stemmed/ Succeeded: s/incuded/included/ Succeeded: s/expicit/explicit/ Succeeded: s/legial/legal/ Succeeded: s/explanes/explains/ Succeeded: s/emaile/email/ Succeeded: s/with a a single /with a single / Succeeded: s/incorrrectly/incorrectly/ Succeeded: s/in every thing /in everything / Succeeded: s/separte/separate/ Succeeded: s/desion/decision/ Succeeded: s/yahoo thing/yahoo email/ Succeeded: s/i do know of how to switch enable painting really/i do NOT know of how to switch enable painting really/ Succeeded: s/please add at least one more game/please add at least one more game example to spreadsheet/ Succeeded: s/except/accept/ Succeeded: s/Sean/Shawn/ FAILED: s/sean/Shaun/ Default Present: AWK, Raf, Laura, alastairc, Detlev, bruce_bailey, Chuck, JustineP, stevelee, Fazio, SteveRepsher, MichaelC, david-macdonald, JF, johnkirkwood, mbgower, MarcJohlic, Rachael Present: AWK Raf Laura alastairc Detlev bruce_bailey Chuck JustineP stevelee Fazio SteveRepsher MichaelC david-macdonald JF johnkirkwood mbgower MarcJohlic Rachael Regrets: Nicaise Jake Found Scribe: Laura Inferring ScribeNick: laura Found Scribe: david-macdonald Inferring ScribeNick: david-macdonald Scribes: Laura, david-macdonald ScribeNicks: laura, david-macdonald WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 04 Jun 2019 People with action items: cooper michael WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]