Meeting minutes
New PR Triage
jamesn: w3c/aria/#2369
… add mapping table for customizable select
… still in draft
scottohara: a lot is done, there is still a todo to note how browsers may need correct for popup semantics
jamesn: would anyone like to review?
… or prepare for review, once it’s ready
Rahim: me
aaronlev: me too
jamesn: and will put James Teh on to review as well
WPT Open PRs
jamesn: we’ll skip for this week
Deep Dive planning
jamesn: we have one scheduled for Nov 21
… on Dashboard Boundaries, 2-3pm Pacific Time
… any other deep dive topic proposals?
melsumner: yes, BGaraventa and I would like to talk about whitespace
jamesn: maybe a week between Thanksgiving and Christmas?
melsumner: let’s try for Dec 5
jamesn: this relates to accname/#95
Consensus needed: Publish a snapshot CR of Core-AAM
jamesn: need consensus to publish snapshot recommendation for core-aam
… any objections?
<pkra> +1
jamesn: otherwise these minutes can represent consensus
Rahim: jcraig is not here and may have an objection
jamesn: I could send out a formal email call for consensus
dmontalvo: yes, that’s a good suggestion
jamesn: I’ll do a 48-hour one for this
HTML AAM: how to handle attributes and aria-* on button/selectedoption within a select
jamesn: scott: would you like to explain?
scott: the gist is that with the new markup pattern for HTML customizable select
… one would use a combination of CSS but also a button is being proposed as a child of the select
… which would enclose <selectedoption>, which may be renamed to <selectedcontent>
… to display the selected option in the collapsed state
… what, if anything, should be allowed on these buttons from an ARIA point of view
… because the button is meant to represent the chosen option
… so things that would be allowed for a button, like aria-expanded, don’t make sense in this context
… so hoping to get consensus from the group
… my current opinion is that a lot of these attributes should be ignored
… and even that some of them may need to be bubbled up to the parent <select>
… would like to hear thoughts from others
… it’s almost meant to just be a visual styling hook than an actual semantic button
jamesn: are there running examples?
aaronlev: you can run in Chrome or Edge
<scott> https://
aaronlev: <options> don‘t need to be plain text anymore, they can contain images, etc.
… so putting <selectedoption> also allows for that
… should we just bubble up ARIA properties from the <button> to the parent <select>, like `aria-disabled`
<melsumner> if it's just for styling it's not semantic, so don't allow aria attributes IMO
Matt_King: weird to put aria-disabled on the button rather than the select
<melsumner> you'd put the disabled attribute on the select element anyway
scott: putting the <button> inside the <select> is almost exposing a shadow DOM approach, but by reusing <button> we get some other stuff for free, like Windows HCM mode
… these are 2 new elements being allowed inside a select to style the default, collapsed view of an element that triggers a popup
… our pathways are 1) we ignore them, because they are styling hooks, or 2) we try to respect specific attributes and reconcile them with competing ones on the <select>
… approach #1 is essentially “this <button> is not like the one you’re used to”, don’t expect it to act the same
Matt_King: there *could* be a very short list of ARIA properties that could be useful here, but they are hard to imagine
… ignoring them all feels like the right place to start
scott: aria-valuetext could maybe make sense there, if we agreed that it is a good idea — but I’m not proposing that, to be clear
keithamus: a couple other things to consider: if the <select> sees a <button>, the implementation will delegate focus *to* the button
… there are more than just a11y ramifications with this being a button, there are also stylistic implications
… still a very open conversation
… on whether this should be reuse the <button> element
scott: if it’s not a button, we’d still need to consider what ARIA attributes would be permitted
… I think delegating the important behaviors from select to button is a bad idea
keithamus: in older browsers, the <button> would be parsed away
smockle: this proposal tried to align with author expectations
… follows intuition
… of “things that are invalid drop”
aaronlev: implementation notes: we have built this in Blink
… our assumption is that AT will want to see the <select> structured in the usual way
… we want the tree structure to be this select object, with children
… so if there is a special button, we don’t expose that
… but if there is a focus event, we map it back to the select
… or forward it to a special custom button, if applicable
… and we reflect other non-ARIA properties from the button to the select
… but the `for` attribute, for example, is a complicated case
… for browser simplicity, it would be nice to ignore ARIA properties, if we don’t think it matters to authors
<melsumner> +1 for "button is just really a styling hook"
<melsumner> (in this context)
scott: my initial plan will be to spec this as ARIA attributes should be ignored
smockle: *where* will we spec this?
scott: in the ARIA spec, probably... nowhere — but in HTML-AAM and ARIA in HTML, we could clarify it there
jamesn: that it _wouldn’t_ map to button, right?
scott: right
… this will be called out specifically as a new mapping table for button
… “as long as it’s just 1 item in the a11y tree, we’re good”
Clarify tables, grids, treegrids
melsumner: I work on a design system in a JS framework
… been protective of tables, to not make too complicated
… but my designers are testing the boundaries
… and looked at the spec and found some aspects that I think are no longer useful
… and sometimes at odds with assistive tech behavior
… I think these definitions don’t really work
… especially treegrid doesn’t seem to work IRL
Matt_King: what are the things that you thought are allowed in table, but actually are not?
melsumner: if the tabular container maintains a selection state, what does “selection state” mean?
… in Excel, you can select a row, and that would match that
… but this wording suggests that table columns cannot be resizable or sortable
Matt_King: maybe that specific wording needs to be revisited
… we definitely have a sortable table example in the APG
… and we’ve never believed you shouldn’t be able to sort a table
jamesn: I agree that this definition of table is bad
… we need to fix it to more clearly distinguish table from grid
… move back to something simpler
… maybe grids are keyboard operable with arrow keys, otherwise it’s a table
… it should be fine for other controls to manipulate the contents of the table
scott: I think table definition is problematic and should be simplified
… I would reject any suggestion that if you want to sort, resize, etc. that you need to use a grid — those things should still be permitted on a table
siri: thank you for that clarification
jamesn: you may want to use grid, for example if you have thousands of rows in the table
siri: okay, so it depends on navigation
melsumner: how much time do you expect the user to work inside this thing? Is it a lot of content? That is an important differentiator
Matt_King: I think we should spec it more like how jamesn described it, around keyboard operability
<melsumner> Sarah Higley wrote about this: https://
scott: some of these things would be good notes to add, outside the normative spec language
… some of the things we might want to recommend against might still be perfectly valid tables in HTML
… so need to make sure we don’t prohibit those
jamesn: but we could still point out that they would be _not optimal_
scott: yes, we just need to be careful that we don’t say anything to suggest that a valid HTML table would be somehow invalid
… we can’t tell them it needs to be a grid
Matt_King: yes, and we can also say _if_ you choose to make a grid, then it needs keyboard operability, etc.
giacomo-petri: what about the opposite example?
… take a very static table with no interaction
… is that fine as a `grid`?
Matt_King: yes
jamesn: are we resolved? melsumner, would you like to create a PR?
melsumner: yes, I’ll do that
Inconsistency in allowed uses of placeholder and aria-placeholder
scott: I’m assigned to this
jamesn: I’ll remove the agenda label
add mapping for html focusgroup attribute
scott: we had a focusgroup deep dive a while ago
aaronlev: focusgroup creates an up/down or left/right experience
… we could have AT convey the directionality
aaronlev: using this with links is weird because users don’t have conventional expectation for arrow key behavior
jamesn: why can’t we allow it on links, and then the AT can convey that arrow keys should work
aaronlev: that’s the gist of this issue
jamesn: this would allow focusgroup on breadcrumbs for example, then it could be a single tabstop
scott: if focusgroup is going to be a global attribute, which it seems like it will need to be
… we can’t say it can only be used on composite widget roles
… so if it is global, then we do need to decide what kind of cues can we give to AT
… “this won’t work like other links on the page”, etc.
… in our focusgroup deep dive, we talked about how there is no visual affordance for this
… there will be UX problems for a lack of a visual affordance
<melsumner> TBH Scott, "I don't know how to use the internet anymore" is sorta how I feel a lot of the time these days, lol
sarah: we don’t have any real mapping for this
… so would be curious how SRs with different modes would handle this
… right now it depends on role
… I also have a horror story
… I know a team who wrote an entire JS library to manage arrow key operability to move between static pieces of content
… enough people thought this that they decided a library would be justifiede
… but we also have a legit use cases
… it’s worth considering that some people might want to make it arrow key between static <div>s of text
aaronlev: should work for the most obvious cases at first
… and then SRs can begin to support those easy cases
… we could use the minimum role so that when someone uses focusgroup or focusitem, then it would get at least something minimal to the AT to convey
… and then aria-orientation could be useful
… although we’d need to add a 2D orientation
jamesn: someone working on this needs to come up with a proposal