https://www.w3.org/WAI/GL/wiki/Wcag21-techniques
We are using the master list from the AG workgroup
<Kathy> https://www.w3.org/WAI/GL/wiki/Wcag21-techniques
Discussion – general failure or specific character key shortcuts defined, and then if there are. To make this testable need some way of finding out. Some kind of bookmarklet that can do that trick?
Go through alphabet and number keys – does that work?
Kathy: where is focus on page
Kim: focus outside a field
Kathy: have to be very specific
about where you would press for the focus. Also how does that
translate to other languages
... I guess it would be the same – all of the character keys on
the keyboard
Detlev: works but seems clumsy –
is there some way of inquiring
... ways of automatically checking to see if single key
shortcuts
Shadi: would be good to send to the ACT TF group for input (public-wcag-act@w3.org)
Kathy: need to get thoughts on how this could be automated – trying to figure out ways to detect the presence of shortcut keys. Looking at this from a testing perspective we would have to look at the JavaScript, which is something that typically isn't done.
Marc: go with something that
would keep the folks into not being in a form field
... character keys
<marcjohlic> "While focus is not within a form field, press each character key one at a time to verify that no shortcuts are activated" ?
Detlev: I'd be curious to see if this can be generalized because there are so many ways to say this in JavaScript. Wilco and friends might know.
Kathy: you can read it has to look for behaviors on the keyboard and what actually happened, but I don't see a way to identify stuff within scripts because it can get so complicated. But maybe Wilco and others can think of a way that I'm not thinking of right now
<shadi> public-wcag-act@w3.org
Detlev: think of waiting between steps
Kathy: write a test to wait for page load – have a script do each character and return the result or look for the result. There is a way to do that part automatically. You're not having developers test every single key
Detlev: on failure – it would be
good if user agent provided a way to disable, if as far as we
know it doesn't exist it might be good to point that out – it
wouldn't do any harm to mention that, give that context
... I'm not sure at what point, maybe when to use – Sets the
context of the failure technique
Kim: Same check mechanism, test the mapping, make sure to include language to make sure is accessible – same language as contrast style switch
Detlev: multipoint and part base
gestures five techniques and one failure I thought they were
too fine-grained
... other techniques that simply say don't use and is there
value in those
Kathy: I think they are redundant
Detlev: yes – I would lump
together path-paced and multipoint
... accessible drag-and-drop in the sense that it works for the
keyboard, they would have to add single-point operable controls
to do the same thing which I'm not sure about, whether we
really want that, but that is an issue that needs to be covered
somehow with the technique. So far I've shied away from
explicitly covering drag-and-drop in this. I hope we can
resolve this pretty quickly in the working group call – get
some position on that.
... Then we might need another technique – there is a
drag-and-drop elsewhere
Kathy: we could probably get even a few people from the main working group to common as well as look at these
Detlev: need people to look at and register their opinion so we have something to start with
<Detlev> https://github.com/w3c/wcag21/issues/937
Kathy: pointer gestures – where things are redundant takeout. I would just go and remove the things that you feel are redundant. We've already got this documented elsewhere so we can go back if we need to see it
Detlev: provide controls would be
the positive, ensuring multipoint would be providing
controls
... there could be suggestions about how so I'm a bit cautious
about just removing it
Kathy: marking it redundant would
accomplish the same thing
... I think a failure is different – whenever we have a failure
condition that's tied
Detlev: I've done the positive technique so it shouldn't be so difficult to turn into a failure – I can do that. I would like to add a technique on drag-and-drop because this is a more complex case
Kathy: I have it on my list to respond to that – I just need time to think about it
Marc: working on motion actuation – hopefully by next week will have the general actuation one done
Kathy: we want to get them into
the working group for comment and then if there's anything that
comes up – like the ones that Detlev brought up where we need
direction or consensus. It's good to have those things and
bring it to the working group's attention and then fleshing
them out here. That's the way to get things done quicker.
... I've been looking at single A one's first,, then going from
there
... I'm starting to write Label in name – looking at what
Detlev did – testing
Shadi: link to existing testing effort
Kathy: it's simple from the perspective of looking at this in theory. It's not so simple to look at this from the actual test perspective
<shadi> https://github.com/auto-wcag/auto-wcag
Kathy: an emotion actuation looking at fleshing out first
<shadi> https://auto-wcag.github.io/auto-wcag/
Shadi: next week we should have a
whole bunch of tests that will be completed for Q2 and now
looking at Q3 as well – let me know if there are priorities.
Not a good way to find things associated with a given SC
... Eventually better interface but right now have to look at
the pull requests
<shadi> https://github.com/auto-wcag/auto-wcag/pulls
<Detlev> https://github.com/auto-wcag/auto-wcag/pull/146
Detlev: here's an example
... this is the one that Wilco pointed to in the main call
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/would be good to get an automatic check tool/would be good to send to the ACT TF group for input (public-wcag-act@w3.org)/ Default Present: Kathy, Kim, Shadi, Detlev, Marc Present: Kathy Kim Shadi Detlev Marc No ScribeNick specified. Guessing ScribeNick: kim Inferring Scribes: kim WARNING: No "Topic:" lines found. Found Date: 21 Jun 2018 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report 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]