Meeting minutes
New Issue Triage
giacomo-petri: browsers handle tables without headers inconsistently
giacomo-petri: it is beneficial to clarify in standards how browsers should treat tables without table headers, for consistency
spectranaut_: Is there any history about how to handle this?
jcraig: Even if a table has headers, if it’s otherwise invalid, at least some engines (e.g. Webkit) will not try to expose a malformed table to the accessibility API, because that’d do downstream harm to ATs.
jcraig: Even an explicit role="table" is sometimes ignored. This is bigger than just missing headers.
jamesn: A longer conversation could be good. It could be good to have an algorithm. I’ve dug into this in a previous company. Even the size of the first cell is used as a heuristic for whether something is a data table or layout table.
Francis: GovUK had a good talk on the question “What is a table?” Things like background color, number of rows, whether header had bold text.
aaronlev: This could be a deep dive topic. The original algorithm in Mozilla was copied to other browsers. It was written by me in a day when there weren’t as many CSS properties and tables were commonly used for layout. Maybe that’s less common now, such that these heuristics are no longer needed?
aaronlev: Based on feedback (e.g. re: ease of navigation), it might be useful to expose things as tables.
<jcraig> https://
jcraig: I think the way to do this is to do a comparison of the major implementations’ data table heuristics.
<aaronlev> Blink's IsDataTable(): https://
jcraig: Example heuristics: Are there zebra-striped rows? Is there an explicit role defined? If we can get to the center of the Gantt chart between Gecko, Webkit, and Chromium, that’s probably enough.
aaronlev: The functions are long, but well-commented. They are mostly the same.
aaronlev: Maybe we shouldn’t do this; maybe we should just expose tables as tables. These rules were written 20 years ago, when tables were more commonly used for layout.
Matt_King: When tables are misused or over-used, the exposure of all those tables (sometimes layers deep), getting screen readers to deal with nested tables is really hard.
New PR Triage
spectranaut_: w3c/
<aaronlev> Why authors should avoid aria-relevant
<aaronlev> https://
jcraig: Rahim has a lot of thoughts re: what we could do with IDL going forward; I’ll take an action to block the merge of 2326 because we should make decisions re: IDL as a group (e.g. whether to continue with DOMString reflection).
spectranaut_: Rahim mentioned brining an IDL topic to TPAC, last meeting
spectranaut_: It sounds like there’s nothing to do (on 2326), because it’s blocked
aaronlev: I co-wrote an article (pasted above) re: why aria-relevant is horrible and we should get rid of it. It doesn’t work, and it’s inconsistent; there’s other ways of doing the same use cases. It’s added when people add loads of aria attributes.
jcraig: VoiceOver has specific behaviors with regard to deletions (e.g. down-pitching). So, if you want to make that kind of behavior work with live regions (which is rare), then aria-relevant=removals is the only way to get that working.
aaronlev: We could deprecate aria-relevant.
jcraig: Here’s my reasoning for not deprecating—even flaky things in ARIA that either work partially or in a single implementation—so many of these APIs that have never been testable in a cross-platform way, and there's a very high likelihood that they will soon be testable across browsers in WPT, either with AccessibleNode and-or the Acacia AAM testing that Valerie has been working on. Once we can see those test results, we'll be able to made a more educated decision about whether to deprecate././or the Acacia AAM testing that Valerie has been working on. Once we can see those test results, we'll be able to made a more educated decision about whether to deprecate.
WPT Open PRs
jamesn: Looks like a fix for a previous PR that was causing an error
spectranaut_: I’ll take a look at it after this meeting
TPAC planning
spectranaut_: We’ve cancelled the meeting on September 19th (the week before TPAC).
spectranaut_: James and I have been working on putting the amount of time per discussions, and constraints (ordering, presenter conflicts).
<jcraig> or the Acacia AAM testing that Valerie has been working on. Once we can see those test results, we'll be able to made a more educated decision about whether to deprecate.//or the Acacia AAM testing that Valerie has been working on. Once we can see those test results, we'll be able to made a more educated decision about whether to deprecate./
keithamus: What is the best way to reach out?
spectranaut_: Reach out to me and James, or edit the wiki page.
spectranaut_: Working to schedule IDL session.
Spec for menu/menuitem does not provide enough author guidance for structure
spectranaut_: Sarah found many examples of UI menu components and did a brief analysis. What does this mean for Aaron’s desire for an algorithm?
sarah: There are a lot of instances where the DOM structure isn’t hierarchical. In a lot of these libraries, every menu is rendered in another `div` at the end of the DOM. The closest menu item, walking up the tree, would always be the last menu.
aaronlev: So is the issue that there isn’t a previous one, or that the previous one is wrong?
sarah: You would get incorrect results, not no results.
aaronlev: So, we have to use `aria-controls`?
Matt_King: Is `aria-owns` as good as (or better)?
Matt_King: When you are computing name from content for a menuitem or treeitem, when that item contains a group (or menu), then the accessible name calculation will not walk inside of that group when it’s calculating the name of the menuitem/treeitem.
aaronlev: Browsers do it, but it’s not specified.
<jcraig> s/\/.\/or the Acacia AAM testing that Valerie has been working on. Once we can see those test results, we'll be able to made a more educated decision about whether to deprecate././
Matt_King: The reason I ask about `aria-owns`: It re-arranges the accessibility tree. But the presentation matters a ton if you’re in browse mode or virtual cursor mode.
spectranaut_: Are we closer to solving the original problem?
aaronlev: We can use `aria-controls` or `aria-owns`. We can’t use the previous menuitem to a menu, because of Sarah’s findings.
Matt_King: We need to prototype using `aria-owns`, e.g. in APG.
aaronlev: `aria-controls` is rarely-used, but it’s a safe way to get this information. If the APG is updated, and indicates `aria-owns` is a possibility, then we can update.
Matt_King: So—looking at Sarah’s examples—using the DOM structure would create more problems than it solves. Falling back to the default name (“menu”) would be better.
aaronlev: Agreed. And thanks Sarah.
spectranaut_: Are there any spec changes needed?
aaronlev: The spec for menu and/or menuitem needs to specify that the author should use `aria-controls`.
Matt_King: I want to leave that—whether authors should use `aria-controls` vs `aria-owns`—open for discussion.
Matt_King: Maybe we should do this experiment before updating the spec.
<Zakim> jamesn, you wanted to note that both owns and controls /could/ cause issues for web components until we allow cross root relationships
Matt_King: Proposing `aria-owns` when the parent-child relationship does not indicate
jamesn: Someone could explicitly name their menu, right?
aaronlev: People don’t generally name their menus, in a menubar. Would that cause redundant announcements?
Matt_King: I don’t like that, because if they put a different name than the name of the parent, it would be named confusing. Naming based on menu structure helps you keep track of where you are.
spectranaut_: So, next steps: Make an issue on APG to add an `aria-owns` example. Re: Suggesting either `aria-owns` or `aria-controls` in the spec text: Matt requested we wait on the example.
Matt_King: We can raise this on the APG call. We could take one of the existing examples (preferably an exact copy) and change the HTML and the CSS. It could be a fairly quick PR.
spectranaut_: It would be a good project for someone experienced working with HTML and CSS.
Matt_King: Ideally soon.
Adam_Page: I’ll volunteer to add that example.
Remove group as allowed child of tree
giacomo-petri: Next time, please.
spectranaut_: This has 3 approving reviews. We need tests for this.
spectranaut_: I’ll comment on this issue about what tests need to be written.
spectranaut_: Giacomo, please add questions for async discussion in the issue.