<Chuck> meeting: AGWG-2023-11-28
<Ben_Tillyer> Apologies for my absence for the last couple of weeks, will email chairs with the reason behind it!
<scribe> scribe: jon_avila
Chuck: Any introductions? Any new people, guest, or new role?
JulieRawe: Starting as liaison for COGA and others.
<Zakim> alastairc, you wanted to announce the WCAG 2.x TF process draft
Chuck: Anyone have any topics for future meetings?
<Patrick_H_Lauke> backlog taskforce
Alastair: Thing to watch out for - trialing new WCAG 2.2 task force process
<Zakim> Chuck, you wanted to say WCAG2ICT content to review
Alastair: Work is intended to happen in Github. Announce every two weeks with things to review. If we can get consensus on PR and no objections then consensus.
Chuck: Sending out WCAG2ICT issues for review by AG group and approve or raise any concerns.
MaryJo: They should be in your inbox!
Chuck: Input type discussion. May clarify keyboard stuff as well.
<alastairc> https://docs.google.com/document/d/18t8JFb6cRPk3Uv8wWVh2AYrv-s_LP6Ir_F3eMHoWWBE/edit
Alastair: Scoping - between
pointers, keyboard, and other input types. Mouse and touch
screens are pointer. Eye tracking, voice, switch, input.
Discussed in general, but want to wider as it's been scopes on
different subgroups.
... More reliable way of selecting target and is to put it down
and then slide over to target and release. Standard events
could be used and assistive technology could support. One thing
to consider is to allow for or not block platform standard
inputs. Then we have other guidelines around gestures and
dragging.
... What inputs should be in scope? We came up with draft
definitions.
... 2 or 3 dimension inputs with/without other attributes like
pressure, speed, etc.
<Patrick_H_Lauke> I'll add that that example of "allowing user to put finger down on touchscreen, move finger, then release on the target they meant" actually goes counter to how browsers/OSs currently operate, so it's not something - in my view - that authors should be required to do. that's at the OS/browser level, and yes authors should not actively fight it if enabled (if ever)
Alastair: For keyboard- selecting
a discrete option and not sending coordinates.
... what does the web content receive - it's divided by one or
the other - for example, a joystick - it may know the option
but not coordinates.
... Voice Input could be a replacement for both. One can fake
the other - like grid approach to fake pointer input. These are
just basic concept to help categorize the scope of the
guidelines.
<Ben_Tillyer> Related document: https://www.w3.org/TR/pointerevents3/
<Zakim> Chuck, you wanted to ask about keyboard
Alastair: Have other groups tried some of these concepts?
Chuck: Constraining author provided input - thinking of input field - where almost anything is allowed from the keyboard - author provided content.
<alastairc> Yea, typing might need to be a separate category?
Chuck: Gregg you are muted
Gregg: The key is to separate the user from the app. The user could be sip and puff to type or could be emg or brain waves - but the author isn't responsible or won't even know all of that. What does the app see? It has a pointer interface and it has a keyboard interface. We should stop talking about keyboard but keyboard interface access. When the program is getting it from the keyboard - it's not coming from the keyboard interface.
<ShawnT> regret+
<scotto> by 'joystick' does this include video game controlers? i'm not sure i'd agree with classifying those as keyboard.
Gregg: Same thing for pointer -
if you set it up from a pointer - it could be mouse, trackball,
or eye gaze - for the user - unless the page itself is going to
reach out to the hardware - which it can't do - it doesn't
matter what those things are.
... We can use the keyboard - and we have a requirement for
things to be possible from keyboard interface - what if you
require 3 modifier keys - the person needs to rely on these
other keys so they can operate the program - it's not the
author problem
... Not true that you can do everything from pointer unless you
have each page on-screen keyboard on the page - everything
possible from pointer would require every view of every page
had a keyboard on it that was always visible. Everything
operable from a pointer - no. You could use an operating system
on-screen keyboard which goes through the keyboard
interface.
Patrick: Alastair's example of putting finger down and moving - that is an OS or browser requirement as it goes against how things are normally operated. A plus one on making clear distinction between author and OS and browser.
<bruce_bailey> +1 to patrick_lauke point about OS support, even though desktop click event is typically on mouse-up (rather than mouse-down). Where mouse-down begins is initiation of a drag operation, so that constrains default flexibility of mouse-up.
Patrick: Might be a third type of interface - such as direct interface.
<Ben_Tillyer> +1 to considering programmatic access as a consideration
Patrick: It could go directly from user and bypasses to straight underlying API and go there and set focus - like an API - that might be something else to consider. Authors run into situations where assistive technology go direct route when only considering pointer and keyboard interface.
<Patrick_H_Lauke> +1 to wilco's point that there are still specific functionalities that some pointers have - pressure, precision, tilt, speed, "hovering pointer", etc
Wilco: Good point Patrick -
should we be talking about lowest common denominator. Some
things a stylus can do that you can't do with mouse.
Multi-point input and things - voice input has differences.
What is the lowest common denominator. You can progressively
enhance if a device has those capabilities.
... Wonder if we are separating keyboard from focus navigation.
You wouldn't use on-screen to navigate with a phone even
through it boils back to events. Perhaps focus nav needs to be
separated.
<Zakim> alastairc, you wanted to say it sounds like Gregg is agreeing with the definitions?
<Patrick_H_Lauke> I suspect in that scenario (AT on a touchscreen not having cursor/tab and swiping to move focus) may actually be an example of the "direct access via API to set focus somewhere" model
Alastair: I think Gregg was highly agreeing with pointing and keyboard device interface This would be lowest common denominator.
<Patrick_H_Lauke> it doesn't send faked TAB keystrokes, and doesn't pretend that the user tapped once somewhere...it just ... "does" move the focus
Alastair: What I was thinking on input - when the user selects the button - wasn't thinking so much about browsing interface.
<Chuck> jon: building on Patrick and Wilco, I'm thinking of different ways of input, motion actuation, gestures through cameras. Some of these could be detectable by the application, rather than going through an interface.
<alastairc> Gestures to cameras - is selecting a descrete option (aka keyboard in this definition)
<Chuck> jon: There could be a 3rd category as well.
<Zakim> Chuck, you wanted to ask about discussing in the subgroups
Alastair: reasonable we can now take those into the subgroups.
<Zakim> GreggVan, you wanted to ask patrick about this direct access thought. Do browsers share that information and allow that direct input to the content?
<alastairc> Gregg - not just browsers, we're trying to make this more general/generic
Gregg: Keyboard without tabs - you could swap a keyboard that had tabs on mobile device - not sure browsers can allow you to have direct access -but in future if browsers do have direct access such as by the brain - we need to separate which is possible and what we require author to support.
<alastairc> Gregg - some useful reading on direct access https://github.com/WICG/aom/blob/gh-pages/explainer.md#introduction (I think that's what Pat meant.)
My thought is if authors support standard methods then they can rely on the browser/platform - but if they do things that don't work with the standard interface then they need to make that accessible in modalities that support different input.
<Chuck> links to the scratch pads...
<Chuck> Keyboard Support Scratchpad: https://docs.google.com/document/d/1BbIHra88rxtHbeBE9cqenCMYcv26ODiOonPLRdt7OHU/edit#heading=h.s93f3iv21wtr
<Chuck> Pointer Support Scratchpad: https://docs.google.com/document/d/1Y9ihiYAgLfR83Cu6phRuPTcBr3N9Kr_uFD9cGuxpsgc/edit#heading=h.txiccm4cn4nl
<Chuck> Provide Help Scratchpad: https://docs.google.com/document/d/1vRFmF6JmftMSXAH6vapz319WWX5phs1dSrPRlcEbgz8/edit#heading=h.t3uqwwnk7ffi
<Chuck> agenda
<Rachael> https://github.com/w3c/wcag3/discussions/33#discussioncomment-7694390
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) Default Present: dj, dan_bjorge, tburtin, Azlan, Jennie, Ben_Tillyer, DanielHE, jon_avila, maryjom, julierawe, kevin, Patrick_H_Lauke, giacomo-petri, sarahhorton, Laura_Carlson, Makoto, bruce_bailey, scotto, Frankie, GreggVan, Francis_Storr, Detlev_, ljoakley Present: dj, dan_bjorge, tburtin, Azlan, Jennie, Ben_Tillyer, DanielHE, jon_avila, maryjom, julierawe, kevin, Patrick_H_Lauke, giacomo-petri, sarahhorton, Laura_Carlson, Makoto, bruce_bailey, scotto, Frankie, GreggVan, Francis_Storr, Detlev_, ljoakley Regrets: Todd Libby Found Scribe: jon_avila Inferring ScribeNick: jon_avila 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: 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]