Meeting minutes
New Issue Triage
<pkra> ugh, sorry. I have to drop off already -- sorry for not really being here today.
jamesn: ARIA #2516, 2515 are both editorial; for ARIA #2514, can come up with terminology (seems like something a non-editor could do but same across specs)
Daniel: I can self-assign myself (to ARIA #2514)
New PR Triage
WPT Open PRs
jcraig: Nothing on my end. I will be done (with a PR) by the end of the call
Deep Dive planning
jamesn: have we already discussed tables without table headers, or is this new?
aardrian: I did weigh in on a table headers GitHub issue relatively recently, but not this one so new to me. To manage expectations, I do want to do table deepdives but no capacity until May
<keithamus> q_
aardrian: want to have stuff buttoned up so I can be prepped for TPAC conversations
keithamus: on my docket to explore as well, will get to it. Before TPAC is a good deadline but worth deferring until then
jamesn: worth pointing AI bot to (browser) codebases of tables as a starting point
… myself and Val are out for various weeks in June, so we may be cancelling a few meetings in June. Daniel M. could run them but may be cancellations in June/July (due to US holiday)
… depends on business we have to cancel them
Children Presentational discussion
jamesn: extra discussion took place last week. Pointed out to Wilco that we don't want to deprecate across the board. Wilco doesn't know what a more specific proposal would be, i.e., presentational children is a mistake. Can't think of a more narrow list of roles
… in the ARIA Editor's call, we discussed it. I wanted to take a look at what we say about presentational children in the (ARIA) spec
<melsumner> buttons inside of buttons should break your build, that's such a chaotic thing to do.
jamesn: *reading from ARIA spec section 5.2.9 Children Presentational*
… make a user agent requirement that UAs expose them. Not sure if there is a listing in the spec of all roles that have children presentational
jamesn: there is a list with all roles that support children presentational
… can't really think of how someone could put a child on a checkbox and make it useful. When I look through this list, can't think of a use for checkbox. Images, yes that happens often (are they really images, or interactive graphics)
Rahim: What's the difference between "children presentational" and "presentational children"?
jcraig: children presentational is an attribute of the container, e.g., a progress bar. Presentational children is a description of any DOM elements that are inside that container
… sliders, scrollbars, separators (are examples that have presentational children)
jamesn: how can the thumb of a slider have children?
jcraig: sometimes sliders have clickable areas inside slider tray; sometimes you can interact with slider/track/thumb separately
<melsumner> TBH we need research on this
jamesn: browsers may be correct that people want to have children on various things
<Zakim> spectranaut_, you wanted to ask does Wilco want some kind of interop decision across browsers on what to do for these roles?
spectranaut_: I wanted to say that I think this request from Wilco is an interoperability-based one, i.e., can we (ARIA WG) help normalize a decision across browsers. WebKit seems most dissimilar so a question in part for WebKit and is it something that they (WebKit) are willing to change for better interoperability. If not, think about what the "MUST" statement here, e.g., removing children presentational from roles as James suggested
jamesn: Wilco would like all of them to be removed
spectranaut_: still think it's an interop problem. Does Chrome/Firefox expose presentational roles? button/image ones are obvious
jcraig: even the button one could be handled by aria-actions, i.e., action on same element. Image is more "open" as explorable content
jamesn: when aria-actions come, it allows these problems to be solved. People are doing this all the time even through they shouldn't be
… e.g., on a card you can favorite it, all sorts of other things
… (actions = aria-actions)
aardrian: I've seen devs use ARIA to get around HTML prohibition on nested interactives. Which results in unexpected output (HTML serializes, not nests). So I fear accName would need an update
keithamus: in agreement with Val. Feels "scorched earth" to remove this...going back to spec, there is a SHOULD that should be changed to MUST defining carve outs that browsers make around presentational children, not container nodes but child nodes themselves so nice to have greater granularity there. Right step forward here
<aardrian> I've seen devs use ARIA to get around HTML prohibition on nested interactives. Which results in unexpected output (HTML serializes, not nests). So I fear accName would need an update.
<melsumner> agree, aardrian
scott: not just a browser interop (issue), but also that not all ATs/screen readers will handle this the same even through Firefox/Chrome would have made elements that are child presentational exposed in a11y tree doesn't mean items are consistently accessible by AT browse mode/browser mode/depends on mode of navigation, such as focus or browse mode/e.g., focus/browse mode/browser mode)/depends on mode of navigation, such as focus or browse mode/browse mode/browser mode/depends on mode of navigation, such as focus or browse mode/e.g., focus/browse mode/browser mode). For example, voice dictation features don't know what to do with nested interactives
… nice to have browser interop, but not useful if the AT doesn't know what to do with it
… not opposed to removing some of the child presentational bits but not ideal to do it across the board. Should take a measured approach to this. Also discussed with Aaron, part of this is that some of it was done for good reasons but perhaps it should not have been and get very specific about what elements have presentational children, their content model, etc. It seems that it's circling around the same topic, i.e., ARIA needs to be more
specific and carve out what rules we want for specific rules with some being forgiving to authors while others are more specific
jamesn: I wanted to ask Keith on changing SHOULD to MUST; is that something we have in the spec and carve outs where they (browsers) should expose presentational children? (Keith agrees)....sounds like being more specific about browser behavior, being consistent is good and we can get AT to support the cases that are supportable and don't worry about unsupportable cases because browsers wouldn't be exposing them
<Zakim> jcraig, you wanted to +1 scott's discussion of downstream AT support
jcraig: Scott said most of what I wanted to say. Are we confident that we know all these scenarios to confidently include/exclude the currently presentational children? I'm not confident of that, i.e., making MUST statements. Going back to Scott's comment for native app UI with a button inside text field, but uncommon in native app UI to have interactive image (thus exposed as a container rather than image)
… there's a cautiousness that I want to convey that if we change something, need to have AT buy in and not get rid of them entirely. Most of us agree that is "scorched earth" but also not adding a "MUST expose" elsewhere until we're confident most scenarios have been fully considered
… we can test the WPT side of things but can't necessarily test AT side of things, and don't have as much a direct relationship with AT vendors
melsumner: strong +1 to Scott's point on being more explicit. I think we need strong user research before doing this because devs do strange things all the time
… if we can prove the correct/supported way to do something, need to provide patterns/guides for that instead of providing support for everything devs want to do
Matt: I'm glad Scott mentioned interop and James' caution and Mel not having chaos. I think the cautious path forward with explicit action is, I would really like for us to define the AT test cases as we're going through and take them one by one. I would love to have patterns for test cases that we put into APG and test with ARIA-AT project. Both projects are pretty mature and we can do this to build data to make solid decisions
… we also have in APG the ability to do experimental patterns. Could serve as test beds for developing the AT interop test cases that we want
jamesn: I want to ask a question about where aria-actions is since it will solve a lot of these problems in a slightly different way. For many of these cases, aria-actions would help and would allow these things to be available if they're children of something. We may want to push that feature more rather than tackling this differently
<Zakim> jcraig, you wanted to say maybe we can include something like "MUST/MUSTNOT expose in these known scenarios, but MUST fall back to expose when encountering something unexpected (dev did something weird; err on the side of exposing the nodes)"
jcraig: as a response to aria-actions, Jamie/Matt King provided feedback on the PR. It's been open for awhile
<jcraig> actions w3c/
Matt: we have a lot of notes on that from TPAC
jcraig: maybe there's a scenarios where we say "must not expose children of these..." *if it matches known scenarios. However, if engine encounters something like an author error that results in it not being exposed, could err on the side of exposing what author did even if it means invalidating what the author did
… don't see a reason to have something inside progressbar (children presentational in this instance seems fine) but if you put a focusable, or element with `button` role, could invalidate and keep `progressbar` role on container. Allows cautious approach of allowing author's intent to get to user without breaking the scenario (rather than hard and fast rule that something is a `progressbar` so don't expose anything beneath it)
keithamus: was a little concerned when you said "matches known scenarios" because these can be quite complex
jcraig: just certain rules we have in there (particularly "author error" scenarios where it can undo in the scenario). Thinking of scenarios where authors make errors on purpose which can be tricky
… like a button inside textfield is a common one where ARIA is used (or button inside menu button).
jamesn: does that work (button inside text field)?
jcraig: works for native app UIs
jamesn: is button a sibling to it, rather than child?
aardrian: is a sibling in the DOM
… those workarounds didn't work, or how user expected it to work
jcraig: that's a scenario that's limited to the web because the developer is used to that (rigid structure of web is limiting them)
jamesn: perhaps not a problem that needs solving since there is a way to do. In this example, it's solved by making it a sibling (rather than child)
… people can do things incorrectly to achieve that pattern which causes a11y to break. If we can solve that common problem, we may make things better
… if we can find a pattern where we can push through but needs thought/deliberation/testing
jcraig: I wonder if we're getting close to relying on AI to figure this out
jamesn: conclusion is that we don't know what do?
melsumner: I disagree. I think we do know....need to document everything we know to say "yes" to this idea, then gaps can become apparent and can assign tasks, figuring out what we can/can't do
jamesn: can say to Wilco that we're not doing your idea of your broad "open this up to everybody" but rather that we need specific patterns to address this
<jamesn> w3c/
melsumner: *volunteers to take a look at this issue now*
PR Reviews
jamesn: for ARIA PR #2037, is still in draft status with a lot of comments. Mel may not be comment at the moment, but was created by you....should it stay open or close?
melsumner: if there's too much disagreement, can close it. If it's about integrating feedback, I can do that
scott: I've worked on a few aria-hidden PRs; this issue was a related PR and re-used as much work as we could. But this PR might be handled by later PRs but please double-check on what needs to remain open (or split off into other PRs) but likely already taken care of
jcraig: for ARIA PR #2015, that sounds familiar. A long time ago in ARIA, there was a requirement for managing focus in toolbarswhich was a Windows-specific pattern that was removed. This PR may be follow-up from that where it wasn't corrected in one place (but was in another)
Matt: it was handy to have a list in spec for "Managing Focus" section but we also have those statements that are in those sections for the individual roles so seems like it's just a matter of keeping these two in sync?
jcraig: yes; any objections to merging this right now?
Scott: I need to figure out why I said I did not agree with it. I did review it
jamesn: (Scott) if you can read through your comment, and work out what it was (that you disagreed on). Looks like some formatting-related conflicts to figure out as well
… might have to re-do this PR based on the changes rather than trying to fix it
melsumner: I think this is one of the areas where the PRs tend to stuck for a year because some feedback that is outside the scope of PR, for better incremental progress, why not put that in a new issue so as not to block incremental update for PR
jcraig: for this one, if we have two reviewers on what is effectively an errata change, it can be merged. But for prose changes (based on Scott's comments), that deserves another review
Scott: not that I disagreed with the change, could also negatively affect something else. Prefer for it to be all done at once, rather than a spec change that causes downstream changes
giacomo-petri: I agree with Scott that this PR introduces new issues but not opposed to merging. May confuse authors that they can handle focus within menu/listbox, etc. E.g., use `activedescendant` to manage focus via focus on container
Matt: managing focus can be roving `tabindex` or `aria-activedescendant`
Scott: but says authors can manage focus OR use `activedescendant`
Matt: introductory text content needs a bit of tweak (for clarification around focus management techniques)
jamesn: Scott, you'll work out what the disagreements are (*Scott agrees*)
<Rahim> s/do want to table deepdives/do want to do table deepdives