Meeting minutes
Definition of User interface component
<Joe_Humbert> w3c/
<Joe_Humbert> https://
<Detlev> presnet+
<pauljadam> Remove the applet example to change it to some sort of custom control example like a custom accordion on iOS native app
@detlev should we use form element and button instead of form element and link?
Maybe "form element (such as links and buttons)" ?
<shoobe01> +1 to adding
<shoobe01> I think inline links in apps are mostly dumb but almost every one I have worked on the rest of the team insists on adding some, so worth keeping for majority of users of the document, yes.
actions: @quintinb to raise a PR
<Joe_Humbert> Note 2: User interface components include form elements, buttons, and links as well as components generated by code.
<quintinb> +1
<rachaely> +1
<pauljadam> +1
<Tanya> +1
<shoobe01> +1
<Rob-w> +1
<Carol> +1
<Detlev> +1
<pauljadam> old school java applets :)
<pauljadam> custom control example like accordion or something,
<pauljadam> or a custom carousel or something
<rachaely> +1 to Paul's suggestion
shoobe01 also find the example confusing
<pauljadam> It sounds like a button used to move you through a form in a java applet 🤷♂️
It sounds like they were trying to do something more complex than a button, but it goes weird
<Detlev> +1 to Joe's suggestion
Suggestion: A carousel can have 3 separate user interface components, next, previous and random access position selection
pauljadam this is probably because things like new controls need to be accessible as well.
<pauljadam> I think either or works
<pauljadam> Yes to carousel example!
<pauljadam> random access position selection seems strange :)
<pauljadam> just call it pagination buttons
Haha still better than an applet
<Tanya> +1 to carousel example
<rachaely> i agree with the carousel, but maybe next, previous and pause?
<pauljadam> next previous and pause sounds good
Cool will submit a PR with the carousel example
Thanks pauljadam
<pauljadam> 👏
Definition of Change of context
<Joe_Humbert> w3c/
<Joe_Humbert> w3c/
Files changed tab -> Review changes drop down -> Comment or Approve
<Rob-w> Can't approve the PR on this machine, but I approve it in principle
Definition of Keyboard interface
spicy
<Joe_Humbert> w3c/
<Joe_Humbert> w3c/
shoobe01 I just wrote the visible edits yesterday to make sure I was happy in concept. It's not a bad concept, updating to modern tech would be helpful. Do we need to look at the commentary below? Do we need some other examples for other accessibility inputs?
Rob-w my feeedback relates to the mouse operation - I think WCAG and specifically this presupposes that web works with mouse. That's why we struggle to fit it in here. I don't think anyone would say mouse type operations are keyboard. We must insist that mouse is supported.
<quintinb> +1
<shoobe01> +1
<Joe_Humbert> +1
Maybe a really silly q - HOW do you not support mouse in mobile? Surely it just replaces sausage input?
<Detlev> It seems to fit into Success Criterion 2.5.6 Concurrent Input Mechanisms
<Detlev> ...but that is only AAA
<rachaely> yeah a user agent requirement
quintinb we just need to ensure that the responsibility is in the right place
pauljadam does it fit in any other success criteria or is it new?
<shoobe01> Yes, both major mobile OSs support external pointing devices, a cursor will show up on screen when they are attached (AFAIK, doesn't override, touch still works also at the same time.
Rob-w from iOS, for the most part the OS supports pointer input but it can be not supported via bad coding
Rob-w my preference is that it mouse and pointer gestures do get fitted in
ACTION: Rob-w to investigate where mouse input goes
pauljadam This is a little confusing
Carol 2.5.1: There are times when a component requires a path-based gesture for touch screen devices but not with a mouse. Taking an example of a generic slider:
Using a mouse: If the user clicks on the thumb control of the slider and moves vertically, the slider will respond by moving to the right or left, even if the movement is mostly upwards. There will be no page scrolling as a result of the vertical movement as long as they drag with focus on the slider. Therefore, the slider does not require a
path-based gesture with mouse pointer.
Detlev It was always meant to focus on simple taps. It doesn't fit in the keyboard question. 2.5.6 concurrent input requires that you can carry over keyboard to another mechanism, but it's problematic as it's AAA
pauljadam could we move this to AA
<shoobe01> +1
Agree that mouse should be included with pointer
<shoobe01> I think we have a good argument because of the possibility (for routine work or a11y interfaces) of attached pointers on mobile, AND the touchscreen still working of course.
Trusting Rob-w to "pointer" us in the right direction
<Rob-w> wag 3 seems to cover it quite nicely https://
Detlev does this include virtual keyboards and how a mouse can interface as a keyboard?
<pauljadam> that means you can't be allowed to meet the keyboard requirement by using mouse keys or a virtual keyboard only
<Detlev> proposal looks good to me
I like it
<Detlev> "virtual mousklicks where the pointer is moved over the target via key input"
Apple version of Mouse Keys: https://
shoobe01: Change of focus like old school tab order, do we need to include that?
Definition of User Agent
extra spicy
Tanya raised a concern that comments are happening in 2 places, both parent and sub issue
Maybe we should just create an action to consolidate the comments and come back next week since we have 1 minute left?
<Tanya> in 2 weeks
ACTION: Joe_Humbert to consilate comments to parent issue