Meeting minutes
New Issue Triage e-aam+repo%3Aw3c%2Fhtml-aam+repo%3Aw3c%2Fdpub-aam+repo%3Aw3c%2Fsvg-aam+repo%3Aw3c%2Fdpub-aria+repo%3Aw3c%2Fgraphics-
jamesn: For accname #250, doesn't look like accname issue. Should this be in HTML-AAM?
Scott: Don't see a problem with this being referenced in accname, but shouldn't be incorporated into accname. They've been separate for a reason
jamesn: do you want to answer this, Scott?
… I will assign it to myself and close it
jamesn: ARIA #2475, #2470 and 2467 are all editorial
New PR Triage
Francis_Storr: For ARIA PR #2477, I'm updating all the WCAG references from 2.1 -> 2.2
jamesn: there may be a way in ReSpec to reference it without putting in absolute reference (if URL changes, better to not have it hard-coded)
Daniel: I can do that
… assign it to me (and reviewer)
Francis_Storr: on index.html, there is an NSAccessibility link that may need updating
jcraig: you can add me as a reviewer
keithamus: for ARIA #2474, this is for ReferenceTarget
Rahim: please keep me as reviewer as well
WPT Open PRs
scott: has command/commandfor landed?
keithamus: yes, it's already in Chrome
scott: since it's landed, then other implementors will implement this right?
keithamus: ready to ship in safari, Firefox needs more work
… there are internal Chrome tests but don't think WPT can represent details relationships (or expanded)
jcraig: as long as there are two implementations passing, then it should be merged
… that's why the ARIA spec change may be held back if the a11y fixes haven't been made in at least two different implementations
keithamus: are you saying it should be a normative change (depending on what browser's do)?
jcraig: the ARIA merge path (process) is put in WPT changes; if there are no changes it's a moot point but wait for 2 implementations to pass before merging into spec
keithamus: there are no WPTs we've written; if possible, happy to write tests. There are internal Chrome tests which I can point people to
jcraig: seems fine as far as Scott's PR
Scott: this is the PR that Keith and I worked on, unsure what to do at this point
jcraig: anytime I make a spec change with WPT test, I make sure to file a11y specific bugs for all 3 engines
… if there's a gap in a11y implementation, file a placeholder bug (i.e., make this change in WebKit/Firefox, etc.)
pkra: back to process document, we require 1 implementation to merge, and implementation commitment from 2 browsers
keithamus: command/commandfor is shipping in Chrome/WebKit
<pkra> w3c/
Scott: I don't have any approving reviewers for ARIA PR #2354
jamesn: do we need to re-request reviews?
Scott: I've already sent the request, thanks everyone
WPT
pkra: I rebased PRs that I could do because we rolled out prettier formatting for ARIA spec; those seeing changes should take a look
Deep Dive planning
jamesn: we're still trying to get a time for the accname whitespace discussion. Is there anything else we need to schedule (for an Australia convenient time)
giacomo-petri: the SVG deepdive is already scheduled for next week
… question: am I expected to present anything since it's mainly an implementor's discussion?
jamesn: my expectation for deepdive is that they have a general idea of what they want to get out of the session, i.e., something that drives discussion along
… make some progress and a direction that you'd like to see progress go
jcraig: like at TPAC and the ARIA IDL presentation. Pre-preparation to familiarize yourself enough with the topic, and proposed solution forward (even if people disagree)
… whitespace issue is almost as complex as IDL issue
jamesn: need to be careful of putting high bar on these
… having summary in issue in advance is valuable as well. We should expect people to familiarize yourself with the issue before attending a deepdive otherwise, it's a waste of time
zakim ,next item
Adding code documentation for AAMs
Rahim: it may be valuable to have more robust documentation on how spec is implemented, and differences between browser engines
… was thinking of a more self-contained resource (not inline to mappings). E.g., linking to a class that handles html-aam mappings
jcraig: if I'm understanding correctly, this sounds like it's more details about the implementation stack (not just mappings which is not sufficient to implement fully)
… not enough to make an implementation of an accessible browser; because there are new browsers (e.g., Ladybird), a baseline documenting a11y implementation would be helpful
Scott: not necessarily inline with mappings, but kind of like how we link to other specs maybe it could be part of an introductory section (e.g., 1.1)
jamesn: could we start by collating stuff in the wiki and deciding where we want to put it?
jcraig: fair, also recommend getting Mike Smith involved who's working on Ladybird
… there's a limited number of browser a11y engineers figuring this out and reverse-engineering source code. Because Mike is working on this, he would be the perfect resource to determine what could be documented
keithamus: I'm not against the idea, but curious about the utility. Anyone writing a browser will look at existing implementations; is it worth the effort to do this (may not be)
… where do you start? on the other hand, Chrome's documentation on a11y architecture is pretty good
jcraig: maybe link to existing one, if there is one
… good to have an overview of the differences, and heuristics, so there can be more robust experience across web platform and browsers
keithamus: I'm for that but the act of specifying things; where there are gaps, should be producing specs and pouring energy into tests
… easy to link to documentation but if this is significant time spent, may be better spent on encouraging authors to write WPTs and assert on interop issues
… documentation is good, but specs/tests are how we align
jcraig: part of it is also determining what needs to be tested; e.g., Acacia. Is it set up to do cross-platform a11y notification...could lead to new testing methods in WPT as well
… providing pointers to different places for Mac/Windows/Linux for browsers, would be helpful to people like Mike and those interested to browser engineering and possibly contributing
… could start in a wiki
jamesn: feel free to create a page in the Wiki
jcraig: Scott/Rahim, have you talked to Mike? Good idea to follow up with him
Consider supporting multiline comboboxes
Scott: the person that originally opened the issue, he has commented. I've asked him to create a prototype showing what you're trying to do. Someone could work around this issue (e.g., using `contenteditable`)
… issue was `role="combobox"` didn't work on a `<textarea>`
… should ARIA consider this so it can work
jamesn: how does it work with a keyboard?
Scott: maybe more of an issue with visual rendering, e.g., use Left/Right arrow keys to get to individual terms and Up/Down reserved to open combobox
jamesn: it's a `<textarea>` with one row (doesn't show more than one line)
… let's wait for the issue originator to show that it works
Group as allowed acc child of role menu if acc child of menuitem
giacomo-petri: I have two updates: based on current wording, I think that we are allowing everything within `role="group"`. I think we only want menuitems as children
… now that we're looking into a parent/child relationship, we're saying that `menuitem` is allowed only if accessibility parent is `menu`
… basically, we are allowing different children for `menu` but not vice versa
… I don't know if we should allow `group` as a child of a group within a `menu`
… not allowing `group` that as a parent `group`
jamesn: I can see why someone would want to do that if someone has nested items within a menu
giacomo-petri: then we need to update spec to allow it
jamesn: isn't there something in html-aam where complex structures (e.g., input in menu) do this and it's allowed
… maybe this isn't the time to resolve this if we have something pending for customized select that would allow this. Is that reasonable?
giacomo-petri: That's OK, but still need to figure out if we allow a `group` that has a parent `group`
jamesn: can see why people may do that
giacomo-petri: can achieve what you're talking about by using list/listitem; is group nesting really needed