Meeting minutes
New Issue Triage
pkra: re issue 2507… this came out of conversation with scott
pkra: maybe we can talk about this at some time
jamesn: to progress this, we need implementation info about all browsers
pkra: it's just an author requirement, it's already possible to add aria-details
jamesn: not sure if it is supported anywhere
scott: it is
scott: in JAWS and NVDA
scott: 2 or 3. But not implemented in webkit yet
jamesn: in this example… we have describedby and details on something… why is that a good idea?
scott: in the situation we were talking about… and what I've seen come up… someone might have something that's a tooltip, but it's long content or possibly even interactive content. You want to provide an association from the invoking element and the popup, role=tooltip might be useful for that. The aria-describedby could be provided as a short description in addition to the name…but then also provide aria-details to link up the whole popup
scott: would be useful to provide guidance re when to use this for a 'rich tooltip'
jcraig: Scott alluded there were certain scenarios where describedby relationship and details relationship would potentially break with existing things like title attribute
jcraig: there are cases where tooltip was never expose, eg visible mouseover thing that based on algorithms/accname, the description computation / aam, this string is never presented to users of AT
jcraig: so part of the issue here is to figure out how to ensure no parts are left behind
scott: wasn't originally a use case I had in mind, but could be one
jcraig: remember a conversation along those lines, can look up if I can find a specific scenario
scott: I think there's an issue about what should happen if aria description, aria describedby and title, or combo of all of them are used at the same time
scott: arguably this could be another use case
jcraig: as long as AT developers and browser developers are involved in the convo
<scott> here's the other issue w3c/
jamesn: if we stop to recommend this kind of thing, it would be in APG
jamesn: this almost seems like an APG example that should be built
pkra: APG issue has been open for a while
<Siri> +1 to example as we encounter this tooltip issue frequently
pkra: one of the reasons I thought about this was hover cards like on Wikipedia, GitHub
pkra: in some situations details would be better than describedby
jamesn: what should we do with the issue?
janefulton: would be happy to look into updating this in APG
jcraig: one of the things that really helps, is specific real use cases. If there's a Cisco control that wants to take advantage of this
janefulton: we have a number of charting components
janefulton: we could create a dummy version of that that shows a real world use case
jamesn: let's look at w3c/accname#251
jcraig: would like to ask to please don't add new legacy numbering ID's to the source, the names are more helpful
jamesn: we also move stuff around sometimes and reorder things
melsumner: there are comments like 'don't remove this' etc in the source
melsumner: appreciate having those when going through
New PR Triage
jamesn: PR 2506
pkra: needed some subtle changes, is the one you looked at previously
jamesn: PR 2504
jamesn: does it need more reviews, scott ?
scott: wouldn't mind having more folks look at it
scott: changed it to say it's not at the HTML element but at document node, that's the gist of the change. If there's anyone wants to look at the wording please go ahead
jcraig: I think we could test this with a WPT test?
jcraig: if there's no node below that document the WPT would fail? if you compute any aspect of the properties below this hidden node that shouldn't be hidden or should be unhidden… there's probably a WPT that could be writen for this
jcraig: would like to see issue at Interop Accessibility repo… don't need to hold up the merge but would like to see it tested
jcraig: I think there's some other aspects of aria-hidden being tested… this seems like one of those things where we could add aria-hidden on HTML node and body element…
scott: this is just for the role mapping for the HTML eleemnt
s/eleemnt
scott: not to do with aria-hidden
jamesn: want to review this, jcraig ?
jcraig: yes please
jamesn: let's move on to 2503
jamesn: this has 3 approving reviewers already, think this can be merged
pkra: it lacks a prefix in the title
scott: just noting PR 2486 is working on the same area
melsumner: Scott said I could coordinate with Rahim to pull those changes in, what do you think Rahim?
Rahim: would defer to you, melsumner. Mine just adds a class, yours adds a node. Happy to merge into yours
melsumner: ok will do
jamesn: next is #2500
jamesn: we have this on the agenda, right?
jamesn: let's wait until then
WPT Open PRs
jamesn: looks like there is a new one here, jcraig , does it need reviewing? 511771
<scott> web-platform-tests/
jcraig: yes looked at it
scott: this one hasn't been reviewed yet, was trying to fix whitespace but not sure what's happening
scott: it's for update to figure/figcaption
jcraig: thanks for bringing to my attention… should be straightforward if it is whitespace, let's fix offline
keithamus: if you click the plus on the line, you might be able to do it with that
[argument on commit messaging strategy]
jamesn: any more WPT issues?
Deep Dive planning
jamesn: anyone want to propose anything?
jamesn: table with no headers has been on for a while
jamesn: the whitespace from computed accname, we decided not to do it right?
melsumner: it is assigned to me… not sure if I was there recently. I'll check on my side, we don't need a deep dive on this
[ariaNotify] avoid pestering/annoyance of notifications, either too many or too irrelevant
jcraig: this was one of the discussion points in the ariaNotify discussion
jcraig: was requested to track this in individual isues
evelynnkaplan: Alison not here today but I am happy to help contribute
jcraig: a number of these misuse scenarios are from real world examples of how ARIA live has been used
jamesn: question on this for those who have similar APIs in native platforms
jamesn: do you see misuse of these native API mechanisms in applications and why do you think that would be different on the web if you do not?
jcraig: I'll be the first to admit that ariaNotify will solve some of these misuse examples. Eg putting role=status on a timer without knowing about announcements every second
jcraig: that said, we've also seen a number of test case scenarios that I'd still say are potential misuse/overuse scenarios. Part of the ongoing discussion is what could change about the API that could allow the AT or user to filter out certain messages
<melsumner> the misuse I often have to deal with is marketing/upsells
<melsumner> like while the user is within the product doing their work
jcraig: would you like to discussi t today or some other time?
evelynnkaplan: I think it's a pretty meaty topic, lot to consider, especially when it comes to values for the type property
jamesn: ok, we should probably do a longer meeting on this? if someone wants to prep?
jcraig: we had one fairly recently, one of the requests in that was to create a specific issue for it
evelynnkaplan: thanks. If folks have ideas here please comment in the discussion
jcraig: one of those issues that is… it feels slow going, but it is slow going because important to get it right
jamesn: it is an improvement of what we have today. As long as this can be extended in the future, why should we not progress this to make things better without waiting for it to be perfect]?
jcraig: some considerations might cause long term breakage is why we're waiting still
jamesn: don't think we should aim for perfection
jcraig: agreed
jcraig: maybe breakage not the right term, but we want v1 to support the best use cases and not allow for misuses that are hard to correct afterwards
jamesn: yes exactly, misuse scenarios ok as long as we can correct afterwards
jamesn: no new misuse scenarios other than a new API to create them, right?
jcraig: true. But there are a number of things we had to leave in in live regions that were hard or impossible to fix after
jcraig: we have live regions, there are ways to make them work well. And ways to make them work badly.
melsumner: can we learn from other host languages?
melsumner: is there ways to put in more restrictions in an iterative fashion?
jcraig: can think of some examples, like Web Speech APIs
jcraig: a number of engines shipped, and it had things like 'give me a list of speech voices you have' and it got immediately used 99% of cases for finger printing
keithamus: there's a bunch of things we can do to prevent misuse, like permissions dialogs… my worry is that those things will detract from people's desire to use it and they'd go back to ARIA live regions, that are easily misused
keithamus: imperative APIs are harder to misuse… the thing with aria-live is that it can be incidentally misused eg when frameworks get involved
jcraig: there's a number of ways to address that… we could potentially have a timeline for deprecation of aria-live… or we can use heuristics to determine examples, eg when someone puts role=status on something that's obviously a timer, we could ignore it
jcraig: we can't necessarily catch all issues with aria-live, there's a number of patterns, major misuse cases, that we can try and remove once we ship a new API. Maybe even remove the negative impact of those
keithamus: part of the original design of the ariaNotify API was the ID, the self supplied categorisation of the notification; then the user might have a preference list where they could remove particular types of notifications. We went back and ultimately removed notification ID…
keithamus: I feel like if we are going to spend the time to talk about limiting misuse… we should go back to some of those decisions again.
keithamus: the initial design did think about some of these things more
jcraig: everyone working on Webkit/VoiceOver etc is happy for this to forward but we have a few minor differences still, some discussion needs to happen first
keithamus: I don't necessarily think security and privacy are represented … would be good to have examples for misuse
keithamus: socialising this more so that we can get more eyes on it and find things that people could misuse it, and get it in front of using to practice using it… those are ways we can prevent catastrophes
<melsumner> question: should we discuss this at TPAC, OR do we need to implement sooner than that?
jcraig: great example of not how it can be misused, but how it will… is a timer
jcraig: if there are heuristics that we can agree on to detect misuse, and from day 1 filter those out
jcraig: just thinking about… if we ship v1 and our users complain, eg VoiceOver users, if some widely used site… with aria-live last time there was kind of had a hammer approach
jamesn: can we move discussion to the issue so we can move on?
jcraig: yes
Missing author requirement for use of tabs?
jamesn: tabs don't seem to require in the spec for a role of tabpanel
<jamesn> <p>Authors MUST ensure that if a <code>tab</code> is active, a corresponding <code>tabpanel</code> element that represents the active <code>tab</code> is rendered.</p>
keithamus: is 'tabpanel element' the right way to say this? seems confusing
scott: we do it in other places. It's obs not a tabpanel it's an element with role tabpanel
jamesn: do folks believe this is a valid normative requirement?
jamesn: or are there cases where it is not necessary? it doens't really do anything right?
scott: some recent feedback in reviewing some examples…
jamesn: agree it should be there but not sure of real world impact
giacomo-petri: I wonder… if the content below is hidden from visible view, the tablist is visible, but tab content is not rendered, isn't that a possbiility?
scott: use case I am trying to solve for, is someone has a tablist with tabs, which are modifiying content on the page… all examples of tab widgets that are valid use a tabpanel, at least one of them, to swap out the content based on the chosen tab.
Siri: when we use role=tabpanel we are associating with a label? usually?
scott: usually, not always, is part of the problem
scott: it could also be such that someone can infer a association
giacomo-petri: re Scott's point… with content-visiblity:auto, I am not sure the content outside the viewport is in the a11y tree. It could be there in the DOM but it is not exposed in the a11y tree. Not sure what happens if pointing at something that's not visible
jamesn: glad you were talking about prescriptive labeling, controls is kind of problematic in web components
scott: this wording made most sense to me, if someone has suggestions they are more than welcome to send them