Meeting minutes
<spectranaut_> agenda
New Issue Triage
spectranaut_: issue aria 2382 from scott
scott: this comes from customizable select work.
… it would be a lot easier to customize the return value if we added aria-valuetext
… right now people need to use very creative markup to make things work
… I gave an example.
… additional visible and invisible content is necessar.
… this came from a conversation with sarah.
… who had more examples
jamesn: does this fit into other discussions around aria-valuetext and calculations around that. Does that fit?
scott: I wasn't sure but this felt more urgent since it will likely happen son.
jamesn: I'd like to see that happen together.
spectranaut_: you should find those other issues when agenda-ing this.
sarah: we can discuss this in isolation I think.
scott: I linked jamesn's original issue
spectranaut_: next new issue aria 2381
… this is on the agenda
… next aria 2376
… is a collection of issues with aria-sort.
… I asked some questions.
… the main suggestion is not to limit sort to one column.
jamesn: I agree with most of the comments there.
New PR Triage
spectranaut_: aria 2380, editorial on PDF-aam.
… I'll review.
jcraig: thank you, it's a respec issue
spectranaut_: next aria 2378 on html-aam.
… about using title when alt=""
scott: as I commented, this was an intentional change 2 years ago. However, it seems there was a WPT test that I had missed and engines aligned on the opposite of that decision.
… so no alt="" is ignored if title is not empty.
jcraig: was that a change we made based on an WPT test?
scott: I had linked to the issue that was discussed for over a year before being merged.
… the outcome was to specifically to ignore the title attribute if alt="" is used.
… however the opposite test was merged into WPT.
jcraig: ok. so the test was wrong, causing this.
scott: right. I missed it
jcraig: same.
… I'll dig into the WPT history.
… and possibly comment
spectranaut_: not clear what our next steps are.
… I'll add no-consensus until we're clear on the issue.
bryan: doesn't alt="" map to role=presentation?
… so that would kill the title, no?
scott: that was the argument. The long standing guidance was that alt="" means the image is decorative.
bryan: so it's also that mapping?
scott: yes.
spectranaut_: so we need to figure out if implementers would consider switching this back.
jcraig: I dug a little. seems like scott and I didn't review each other's work.
… is this due to a difference in relevant specs?
scott: there might be a discrepancy. e.g., Mel had looked at it early on, she considered it a bug that Firefox would use the title when alt="".
… not saying that's Mel's position. Just for context.
jcraig: it's a good thing to run into. We might run into other similar issues in svg-aam or dpub-aam.
scott: I'm concerned that the argument is "everyone has implemented it this way" but that way is wrong.
jcraig: true but this particular case doesn't seem as clear cut to me.
Rahim: when the attribute is missing or another labeling technique is used, does alt="" win in those cases?
scott: the sequence is aria-label/dby, alt, then alt="" precedence, then if alt missing title can be fallback.
Rahim: missing alt is not alt=""?
scott: no. missing means it's an image but we have no description. alt="" means presentational.
… even called out in HTML, e.g., CMS having an image but not knowing the alt text. empty may not be a good default.
… otherwise it would default to hidden.
aaron: this is an ancient thing from before aria.
spectranaut_: next PR aria #2377
… accname change.
… re-orders some steps.
… seems to be another mismatch in implementations
bryan: can you add me and Melanie?
spectranaut_: thanks.
… next PR aria #2375, html-aam popover from scott
scott: minor edit to call out that regardless of popover state, all popovers have same mapping.
spectranaut_: any reviewers?
sarah: I can do it.
Rahim: I can do it.
Adam_Page: I can do it.
WPT Open PRs
spectranaut_: new PR from sideshowbarker. tentative removal of tests regarding accname
jcraig: I was probably auto-assigned.
… is that related to the previous issue?
… maybe not.
Rahim: is there an end-of-year deadline for WPT?
jcraig: not really. We give ourselves a score. There will be a rollover investigation.
… so all remaining 2024 items should be moved to 2025. But everything we get done is very good. And 2023 it was very nice to hit 100%.
Deep Dive planning
spectranaut_: we have a deep dive today, at 2pm Pacific.
… on dashboard boundaries.
… then another at 2pm Pacific on Dec 5
jnurthen: warning: those deep dives will be in teams
spectranaut_: any other topics?
spectranaut_: also please remember that there is no meeting next week
add mapping for html focusgroup attribute
spectranaut_: we wanted to continue this discussion.
… the last one ended with "someone has to come up with a proposal"
… this is on html-aam?
scott: I don't think focusgroup is actively developed right now?
… I will probably need to help out eventually.
Needs assignment: Spec for menu/menuitem does not provide enough author guidance for structure
spectranaut_: needs someone to take it on.
… we had a lot of discussion about structuring menu items.
… we had a decision to encourage aria-controls and owns.
… it might not be a huge thing to resolve but can we move it forward?
aaron: more examples are probably useful to understand what people and AT likes.
… talkback wanted to something along those lines. But perhaps others do not. I'm not sure about single-switch interfaces or voice input.
… if anybody can think of something that would break, that would be good.
… when we looked, mostly menus have inscrutable structure. Not a lot of similarities. Seems like people try to get some JAWS, NVDA to work, who only care about the focus.
spectranaut_: so it's not clear if ATs want this?
aaron: talkback does want it. But unclear if others. Not sure if anyone goes beyond screenreaders.
sarah: I did test with switch input controls. But they mostly move across web interfaces. It's hard to test a completely different way.
spectranaut_: so we need more input beyond talkback.
… we can keep it open. If we remove agenda, it will be lost in the backlog.
pkra: do we have a suitable label? Like "needs AT interest"?
spectranaut_: right. Not sure how much that helps though.
pkra: at least when you view it, you know why it's stuck. Like needs consensus
spectranaut_: right and we want to work on AT relations.
aaron: yes. and should we have a deep dive on interfacing with ATs and open source projects?
jamesn: we had a few?
jcraig: the most recent was from me on AT support in specs.
spectranaut_: I'll update the issue with a summary
WebKit does not fall back to 'nameFrom: contents'
spectranaut_: jcraig had added agenda
jcraig: they files a bug that showed a difference between firefox + webkit vs chrome.
… tyler tracked it down further.
… it arrives at the point of "when no other name can be found"
… I think perhaps editors can align on the behavior.
… I think tyler thinks chrome behavior is logical. would love to hear from aaron if that was intentional and other implementors.
bryan: could you add me?
aaron: me too
scott: I did a quick test yesterday, came to the same conclusions as Tyler. Though only on windows, so no safari
jcraig: the only downside I can see is that if there's a typo leads to no label (e.g., attribute typo), then the label might be very long. But perhaps a good signal to developers.
… I just want to make sure we make a conscious decision here.