Meeting minutes
New PR Triage
<Francis_Storr> https://
WPT Open PRs
spectranaut_: Doing new issue triage every other week, none for today. No new PRs either
… no new WPT tests either
<spectranaut_> rahim: jamie teh raised an issue related to a crash for gecko when a role fallback but the second role is capitalized
<spectranaut_> rahim: I'm writing tests for it
Deep Dive planning
spectranaut_: Table deepdive is coming up in 2 weeks. Anything else we should cover? (*no items mentioned*)
Clarify Accessibility Parent-Child Relationships for menu, group, and menuitem
spectranaut_: Added my Peter if he'd like to add anything
pkra: Giacomo isn't around. I wanted to bring this to the attention of the group; we'd touched on the idea of equivalent of HTML content model (i.e., parsing rules). I feel this issue touches on this, and I was reviewing Giacomo's PR which tries to capture the reality/complexity of things that may have a group alongside the intended children, e.g., menu item in a menu. Can have a group, or many groups
… not so long ago, decided menu item is a child of menu but not necessarily which led to questions around content model. Reviewing this PR and language is complicated trying to capture behavior of menus in particular; trees/menus are generally challenging
… language is not always precise. From CSS, use "donut scoping" in order to simplify language. For example, in this PR, it adds detailed language around specific requirements for this scenario which is undesirable from an editorial perspective, can be confusing
… want to talk what's allowed between menu and menu item (i.e., donut scope), but not going beyond that. I've been thinking about this, and made comments to the PR to come up with better language. One thing Giacomo added was definition of accessibility ancestor (which was lacking before) which is helpful in terms of scoping
spectranaut_: I think I understand the issue but in the example you (Peter) provided, i.e., "authors must limit descendants to...." (look at PR for exact language), are you allowed to have a group within a group?
pkra: I believe so, such as submenu structure
spectranaut_: the reason we introduced accessibility child to clarify allowed children; saying that the next semantically significant node has to be e.g., group/menuitem/separator/etc.
pkra: yes, but once you're in a group, you have to clarify group in a menu so there may be additional restrictions to children
pkra: in this particular section (of the PR), don't think we need accessibility descendant, may just need to specify accessibility children
… what I'm looking for, wondering if this is an opportunity to explore a better nomenclature to move towards a content model, i.e., a language we can better phrase/define things
spectranaut_: you mentioned "donut scoping", is that from CSS?
Jane: it doesn't come up often, but it is a term that has been used
pkra: don't feel strongly on what we call it (content model)
Jane: is confusing to explain accessibility child vs. descendant, look into making the wording easier to understand as a bare minimum
pkra: started adding exceptions such as presentation/none; but we want to expand things such as aria-actions. Want better language to better define/surface these types of models
sarah: rather than donut scoping, we may want recursion which doesn't work well in specs. The recursion bit helps specify that there are multiple groups which is difficult to convey in terms of language. For aria-actions, thinking of globally allowed children (e.g., scrollbar which should be globally allowed)
… we have a bunch of things which are allowed a11y children; for scrollbar, anything can scroll. In this sense, aria-actions allowed anything as a11y children
spectranaut_: another thing in the language we used for accessibility child: we use the word "intervening"
pkra: presentation/none are globally allowed children; can simplify language and get rid of redundancy. Similarly, groups are like that because many roles allow intervening groups
spectranaut_: are there some parent/child relationships that don't allow intervening groups?
sarah: it can be different; listbox can have one group intervening as opposed to menu/tree/treegrid where you can have nested hierarchies
pkra: maybe even tables (thinking of colspan/rowspan); but lists, you wouldn't want nested groups in lists which may be desirable for styling purposes
Jane: allowed on definition lists
<Zakim> jcraig, you wanted to be a wet blanket (and provide no solution) about performance with allowing infinitely deep nesting....
jcraig: the problem with allowing infinitely deep nesting of generics, more of a practical issue. Especially because there are many rules of ARIA where rules determine if something is generic
… as rules get more complex, causes implementations to become more complex which leads to things running more slowly. It would behoove use to come up with reasonable expectations, e.g., if you need to use infinitely deep generics, could suggest that the author put some explicit value (may not solve the problem of div-itis). But could make implementations faster, such as ignoring particular subtree
Jane: is what you're suggesting such as pulling arbitrary number, e.g., 100 divs but 101st
jcraig: specifically not suggesting that
… VoiceOver users start noticing performance problems at 40ms which is surprisingly fast. For this 100 div solution, and other deep div nesting, it contributes to performance problems
Jane: curious about the performance problems; is it the spec or developer's responsibility? Depending on how many generics you can have listed. If you write inefficient code, that's on the developers
jcraig: there isn't some specific spot where performance becomes an issue, it's more of a cumulative issue. The other key difference is that this isn't a performance problem for someone writing inefficient code; e.g., one website writes inefficient code and it only affects that page. It's because the spec adds rules that need to be executed on all pages, and therefore implementations will be slower on all pages, not just the inefficient pages.
sarah: in terms of screen reader performance, curious about the various ways someone can do that while conforming with the spec. I have a bunch of options, but I'm not sure if we've ever disallowed specific things because of performance (e.g., many many live regions on a page, or a really big table). So, I'm hesitant to use that as a reason to not do that, but get your point that it can slow things down for everyone
pkra: I wanted to acknowledge the importance of topic, and intervening generics is already in the spec. What I wanted to bring to the agenda is simplifying language in spec for situations where we want to provide certain intervening elements for structural reasons, to help people understand spec and clearer for us to reason about the spec
… maybe we can do a deepdive eventually on the content model stuff, but I'm not currently ready for that
pkra: did people see Steve Faulkner's blog post? He had a conversation with Jamie Teh, and he wrote on the old problem of exposing content under an aria-label element. Is this something we want to talk about at some point
… putting aria-label on a link, but link has other stuff (i.e., visible content) so visible content never gets exposed
<jcraig> https://
pkra: touches on content model (flow/phrasing content)
sarah: if we changed it, it would be breaking a lot of stuff. People mess it up, but it's also used on purpose which is my concern
pkra: I'm wondering if there's more hiding underneath this discussion
jcraig: SVG images is an interesting case because some SVGs use title; if that was made accessible and browsers see more of them, kind of a chicken/egg problem. Only supported on inline SVGs at the moment, but most authors don't know about that functionality
pkra: I'll file an issue
spectranaut_: feel free to use the remaining time to review issues/PRs please