Meeting minutes
<masonf> github-bot, take up openui/
[command invokers] scroll command
<github-bot> OK, I'll post this discussion to https://
masonf: first issue is command invokers scroll command. flackr to present?
lwarlow: I added this to the agenda, but some time has passes so I wanted to keep the ball rolling on it
masonf: can one of you remind us of the proposal
masonf: there was talk of a functional microsyntax but that's not the direction?
flackr: right
flackr: we should bikeshed the names of the values but they are the 4 physical & 4 logical directions.
bkardell: I wanted to clarify, it's paging right? One whole scroll port
flackr: yes
bkardell: maybe page is better
flackr: we can start with page.
masonf: Like page down?
flackr: yes those make sense. page-block-end maybe less so.
<bkardell> exit, stage left, chased by a bear
masonf: it's descriptive.
lwarlow: this works with scroll-snap and scroll containers. I assume - how do things like page up page down buttons work with scroll snap? The container?
flackr: It's complicated. Well defined, this would mimic that. You scroll by about a page and find a snap point near that destination
flackr: the reason you dont want to go to the next snap item is you might have a set of small snap items, and so moving a page might trap you in those snap items
masonf: the behaviour of the page up and page down keys is expressed in the spec?
flackr: it's hand wavey but we have tests and such. This would hook into the same mechanism.
masonf: Are there other questions? Naming aside. Other questions to be answered?
lwarlow: I guess - is it ready to just propose to whatwg?
lwarlow: bikeshedding doesn't need to happen here.
flackr: i guess so. The target needs to be the scroll container, there's no magic "find the nearest scroll container".
lwarlow: there is an issue in whatwg to handle that, it could piggy back that if there was anything we could come up with
masonf: auto targeting based on ancestor chain?
lwarlow: yeah. It's up for discussion what shape it would take. But for something like this it would probably be the nearest scroll ancestor.
masonf: that's separate and more general anyway
masonf: one plan is to take it to whatwg but another is to prototype this, right?
flackr: yeah probably not too hard to prototype, I assume adding commands isn't difficult
<masonf> keithamus: the spec has a handle invoke step, which is awkward, but implementations are easy
lwarlow: not too difficult
flackr: maybe that's the plan, write a rough explainer, prototype, bring to wg.
masonf: sounds like it has 2 champions, lwarlow and flackr? Presumably one of you will do this?
lwarlow: I am fine to work on the html spec parts. Implementation wise I can help with the command stuff, but not the scrolling bits
flackr: I know about those bits so I can handle those. I'll reach out
PROPOSED RESOLUTION: page as common command name, 4 physical and logical directions, no functional microsyntax.
<bkardell> +1
<lwarlow> +1
RESOLUTION: page as common command name, 4 physical and logical directions, no functional microsyntax.
<masonf> github-bot, take up openui/
Open a11y questions for overflow/carousels
<github-bot> OK, I'll post this discussion to https://
masonf: a11y questions for overflow/carousels... scott? sarah?
<masonf> github-bot, take up openui/
Scoped focusgroup explainer
<github-bot> OK, I'll post this discussion to https://
Jacques: *introductions*
Jacques: *pitches explainer8
masonf: you can't key off of.... so the....
Jacques: when you make the focus group you specify an aria-role, from there we can infer the value. So it's scoped for specific scenarios.
Jacques: so you cant make a div with no role... the old focus group explainer made it required, this one flips the script and says it supplies it.
Jacques: the latest comment about aria making semantic changes is a conversation I want to have. But this is what I'm working with
lwarlow: specified role within focusgroup and role within role attribute, which one wins?
Jacques: aria-role. Authors can do whatever they want in the end
lwarlow: if you have an html element?...
Jacques: in that case, it would take the... I don't think I specified this but it would take the one supplied by focus group. I could be convinced otherwise.
Jacques: I think I would say the focusgroup supplied aria role would win
lwarlow: it has to in some circumstances, if you put it on a div for e.g.
Jacques: I am trying to think of scenarios where you'd want the opposite but I think you'd want focusgroup overriding the implicit role.
scott: 2 things:
scott: 1. one way to move forward with this is to call out that - reading the explainer - I think it could be better explained that while the values given to the focusgroup attribute defines the behaviour, that align with the specific roles, it's not using ARIA. ARIA would be if you provided the ARIA role on it.
scott: the direction you've gone now solves the problem, but you're not using aria roles, they just happen to align.
scott: so the argument of "you're using aria the wrong way" is wrong if you pay attention to what happened.
scott: 2. The way this is trying to force or overwrite implicit ARIA roles for HTML elements. Say someone used it on a div that contained all the options of the customised select, and you put grid as the focusgroup behavior.
scott: what una was looking to do with how to navigate a visual grid of options... so what does that do? Change all the children to grid cell roles? That wouldn't be appropriate
scott: we still have the potential to really break things if we don't scope it down
Jacques: I still think this should be scoped to a subset of aria roles. Not any aria role could be used as the behavior, but a subset. Or am I misunderstanding?
scott: if I understood the explainer, it was saying if you put radiogroup for the focusgroup attribute, divs inside of it would get the role=radio implicit role. If someone were to have a div focusgroup=grid and had options inside of it, they're trying to get bidirectional arrow key behaviour but may inadvertently undo the actual role that's
necessary for those options.
scott: but that's not what this thing is at all
Jacques: I see what you're getting at, the child override is a little messy. Some span from not useful to harmful, as you pointed out
Jacques: at risk of making this more complex I think we'll need to supply more for this.
scott: that's not a bad idea to pursue. The other thing is that we stipulate it doesn't override any roles, except generic. It becomes more behavioural. Potential mappings provided so for a focusgroup of options are bidirectional. more about behavior less about roles.
scott: but a focusgroup on a series of divs... like a mapping on html-aam, if it's just divs we can say this might be a grid lets give them grid roles, otherwise we might not know what they've create.d
Jacques: I need to think on this more but overriding only generic is a great first step
scott: thanks, I think you're pushing it in the right direction
masonf: I had the same comment about re-using role values exactly. There's a value describing the bheaviour you want, and it just happens to align to role
Jacques: exactly
masonf: you might want to sidestep the argument by creating a list of words that then map to roles, if they're different words that's fine.
masonf: changing of native roles that come from elements, there is push back about attributes changing semantics. That's kind of whats happening here so I think there will be pushback
masonf: but there is a concept of a minimum role. e.g. popover. If the element has a strong role, e.g. option in select, you dont change it. If the element is a div it can have a minimum role of - whatever- so you're not overriding defaults that come from elements
nmn: I would say there should be no a11y overrides even in the generic case. Thinking hard I wonder if the entire value can be simplified to what it does for focus and nothing else. 2 things I can think of is either focus trapping, or unify multiple focusable elements as a single tabstop, arrow keys switching between them. Unify or contain, wrap or
no wrap, horizontal and vertical, as the three axes of this.
Jacques: that was the original explainer. The problem is we now need to expose this to a screen reader which is not going to understand how to communicate how to navigate through this.
Jacques: doing all this and asking screen readers to adapt to it means it has no future
Jacques: whereas mapping these to roles, we can tell the screen reader for example that this maps to a radiogroup. No new platform APIs, no causing trouble.
nmn: another possibility - can we have a value that says mirror what the role is? So you don't repeat focusgroup=grid but role=grid focusgroup=<no-value>?
Jacques: original proposal was that focusgroup requires a specified role, but this then became aria defining behaviour which people don't want.
nmn: I'd argue its focusgroup defining the behaviour
Jacques: we really want to make sure that focusgroup requires a behaviour, and if it's defined by aria role then that's determining if focusgroup can be used
nmn: whats the invalid value?
Jacques: focus group would not function
<scott> +1 for things breaking and making devs have to pay attention to their mistakes :)
lwarlow: few comments.
lwarlow: combining grid and wrap in the same attribute might make things more confusing. i.e. reflection, if you had a predefined list of valid values it might be nice to have that as a reflected enum. So maybe wrap is a separate attribute.
lwarlow: I'd like to understand the value proposition this provides, rather than implementing the elements in html. Toolbar, for example, doesn't provide that much in the ARIA space, it's a role, essentially.
<masonf> ...and we're working on `<menubar>`: https://
lwarlow: I'm curious if we have focusgroup=toolbar what is different to specifying <toolbar> as an element
lwarlow: custom elements come up a lot but we can give them some additional behaviour to opt in to this
lwarlow: if you have a composite widget, like select, if we didnt have focusgroup and we had these other mechanisms, perhaps thats better?
Jacques: what you mentioned, the custom element scenario and the flexibility. Adding <toolbar> or a new element to the html spec is going to be a process. It's going to take time. focusgroup is something we could get to having this. That enum of behaviours is more flexible than adding a new html element.
Jacques: with that, I think ideally no one would use divs it would be native elements but reality is folks do interesting things. Adding the attribute means they dont have to write their own focus management and it scopes them into something standardised.
Jacques: keyboard user will do the same thing and screen readers get the right information
Jacques: in the ideal world everyone would use native elements and the ideal element would already exist but we're not there yet
bkardell: I have a split between these two. I see the value in something potentially like this but I see greater value to get people to not use this at all - so if we had native <toolbar> or native elements this could replace, the markup gets a lot simpler.
bkardell: the ability to use it becomes incredibly simple
bkardell: and the ability to use it wrong becomes harder. Almost no markup means hard to mess up
bkardell: so I'd like to see - I assume the idea you have is internally if we made new native elements with these concerns they'd use these mechanisms themselves - so maybe a native element to go through at the same time?
bkardell: I dont know if its a true statement to say one can be done faster than the other?
bkardell: we've done stuff since the original proposal
lwarlow: in terms of use cases, I've written code before that has the comment "we can remove all of this when focusgroup ships". But the scoped nature... we have customisable select, that's select done.
lwarlow: menu element is in some form of progress
lwarlow: toolbar element feels quite simple to propose and add. It seems to be this essentially.
lwarlow: then leftover you've got combobox, in the input datalist sense? And tabs.
lwarlow: tabs is a big thing, if we wanted a native element...
<masonf> nah, tabs is trivial, just ship it
<bkardell> +1
<masonf> :-)
lwarlow: but they also have more than just focusgroup, you cant slap focusgroup on it and call it tabs, you still have to go write the rest.
<bkardell> +1 was meant in reply to "you can't just slap this on tabs"
lwarlow: then theres grid. Maybe the most interesting part. Can't necessarily inherantly replace with an element, number of different forms it can take
lwarlow: specifically a future thing, interesting to solve.
lwarlow: if we get behaviour for toolbar though, it would e nice to get the element. If we propose toolbar and we've got select then we can specify the keyboard navigation, then you get half of focusgoup for free.
Jacques: I agree authors should prefer native. But there will be cases where they want to use a div with aria role, and focusgroup will at least give them consistent behaviour and give them a correct mapping. We live in a world where button exists, but so does role=button
Jacques: I agree native elements where it makes sense but developers are also potentially not going to use them. This is a stop gap to encourage consistency.
masonf: lukes list was a long one!
scott: I am in the middle of this. If we could ship the elements, great, but it does help for people who want to reinvent things like button, custom elements, etc.
scott: there are components that don't have good representation in html or aria, even new things we haven't figured out yet. I think this is similar to popover, where we - in an ideal world wouldnt need popover - but it definitely helped, e.g. customisable select, dialog, you might need a popover dialog, that's a new concept we wouldn't have had
before
scott: is there a benefit to using focusgroup to make a toolbar when you can use a toolbar element? Probably not but absolutely interfaces out there where people have done this and those places can slowly refactor which might be easier than completely rewriting html
scott: so I think theres 2 pathways forward here.
scott: really the only thing toolbar does at this point is that certain screen readers will go into forms mode which allows them to use them without the screen reader overriding them. Hopefully in the future we will have enumeration of how many items are in the toolbar soon - so that'll be another difference.
bkardell: while I would like to see us do both at the same time - one thing that might come out of that is there is a different way to handle this, like an element mixin or something. Maybe people will have less objection than attributes? e.g. elementinternals.type = 'toolbar'
masonf: another one to add to the list of as-yet shipped things
sorvell: going to push back on criticisms of it being powerful and not tied to aria. I think this is good to add to the platform.
sorvell: concern around ARIA being semantic only apply regardless of aria attribute or not.
sorvell: if you're going to use names that are close to aria you're still using it non semantically
sorvell: the thing we have to face is that the criticism levied was people could do bad things with this behavior. People _are_ doing bad things now, keyboard navigation grouping is widely used.
sorvell: making this canonical in the platform only makes it better. Today you can mess it up in 27 million different ways, if we can fix a couple million on those that's much better
sorvell: the point on elementinternals, i think that's not appropriate, there are tons of frameworks - not just customelements. So I think those all do this and need the same functionality.
<nmn> vehemently agree with sorvell!
scott: you said you came in late but maybe review minutes, we discussed the aria pushback
scott: generally, the intent with what was updated was to untie with aria and have it as behaviours that just happen to map to aria roles
scott: there probably needs similarity because people need to know what they're trying to create
scott: the problem with the stuff now without implicit aria semantics is it doesnt make sense with AT. The experience is broken now
masonf: this is a PR right now to add an explainer. Are we okay with just landing this?
Jacques: that would be great, once landed I'll still be making updates.
masonf: since it lands in parallel to the other explainer it might be good to add a link from the old to the new one
Jacques: sounds good to me
masonf: any objections to land the explainer?
<scott> +1 to landing the explainers. it can continue to evolve
bkardell: if you land this, it wont replace the other one?
masonf: the current PR is a new document. So the website will have 2 explainers next to each other.
masonf: how much of the new explainer is new new?
Jacques: it started from a copy paste, but through a filter. Some sections might be word for word, but a good amount are new.
masonf: my only comment, I'd want to have both pointing to the other, and context on both. The reason I think it's valuable to keep both is to help decipher the scoped vs broader thing
<masonf> keithamus: I'd like to replace the old one with the new one, or push the old one further away. Maybe to "legacy/unmaintained"?
<masonf> keithamus: it is that way now, so maybe ok.
<masonf> keithamus: I'd lobby to remove the old one. We have git history.
masonf: counterpoint is that it says we have decided to go with this scoped approach. Have we concluded that?
nmn: in non-active it's fine, if anyone wants to update it we can have another discussion
masonf: a PR to delete it later is easy
<masonf> > Zakim, please leave. <-- does that work?
<masonf> I guess so
Whats the RRS one...?
<masonf> RRS?