Meeting minutes
New Issue Triage
Rahim: aria #2286 is for the next editor's meeting
<keithamus> `// prettier-ignore`
daniel-montalvo: I'm assigned to work on #2285
jcraig: OK to forward dupe for aria #2281
jamesn: what are the implications for this?
jcraig: aria-invalid has different missing/invalid value defaults; putting this into the attribute's characteristics table could clarify this
jamesn: we might have different missing value defaults depending on the role; some reticence in engines to do this because if we put this in, then IDL needs to return these (which requires validation by web engines)
jcraig: not a problem for enumerated attributes; the way that IDL works is that they reflect as nullableDOMStrings
… one thing that could cause a problem is the boolean-like value types (e.g., true/false/undefined ones). Another one is aria-invalid which doesn't have a well-defined set of values
jamesn: main concern is around implementation concerns but otherwise, no problem with moving forward with it
keithamus: there's a related issue with ARIAMixin; I'm happy to pick this issue up (aria #2281). I think it'll be a lot of work. Will work with Rahim on this
Rahim: for aria #2279, Rahim/James to work with Anne
jamesn: for aria #2277, looks like an editorial one related to inheritance (e.g., something being inherited and required)
New PR Triage
jcraig: aria PR #2284 is the followup from the orphaned role deepdive and from Scott and I's discussion
… not worried about the technical side, mainly prose. Not introducing a new requirement, just removing a UA requirement that implementors thought was too restrictive
Rahim: aria PR #2172, need other reviewers
keithamus: you can add me as reviewer as well
WPT Open PRs
jamesn: nothing new it appears, anything you need James C.?
jcraig: nothing is new
Deep Dive planning
jamesn: any proposed deepdives for next few weeks? unless it's time-critical for a deepdive, should probably postpone deepdives for TPAC
TPAC Agenda Discussion
<spectranaut_> discussion board for topics: https://
<spectranaut_> wiki for draft schedules: https://
jamesn: we're thinking about how to start planning the agenda; the agenda is pushed by the group (not the chairs). It's what the group wants to talk about; please come up with ideas for things and ideally, leading certain conversations with facilitation by chairs
… we created a discussion board (aria #2283); if you have an idea that isn't fully fleshed out, you can note that in the discussion board and see if others want to collaborate and come up with larger topic. The other way to do that is to add a tag to an issue, or have an issue that would form a 20-30 min agenda item, add the F2FCandidate label which flags to us (chair) as something people want to talk about at TPAC
… please include comment around why you want to talk about it, and what the target of the discussion is
… need potential/targeted outcomes rather than freeform discussion without direction
jamesn: there's an agenda with tentative schedule for TPAC in the wiki
Clay: should I remove old F2FCandidate label on issues (e.g., aria #1957)?
jamesn: it doesn't have that label but will remove the "F2F" label now
… you can re-add the new label with a comment clarifying why you want to talk about it
… 11 people registered so far from our group (great)
spectranaut_: will be a well-attended TPAC with reps from browsers (and hopefully have AT representation there as well per James N.)
keithamus: is it worth mentioning that there are concessions (e.g., lower fees) for reps?
jamesn: yes, trying all possible ways to ensure good attendance
Update HTML-AAM to use title for description instead of name, when the name is prohibited
aaronlev: basically, I was looking at what we do when an accname is calculated for something that is name prohibited; I tried to not allow authors (within our own internal systems) to have name on name prohibited element
… can put title (attribute) on anything; e.g., if you have a title on an element with name prohibited, we should move it over to accDescription
jcraig: great idea as we shouldn't drop author-provided string
aaronlev: if a white-spaced trimmed version of title vs innerText, then we should drop it. Lots of time people use CSS property (e.g., text-overflow: ellipsis), using it to see "..." additional content
jamesn: what needs changing?
aaronlev: html-aam doesn't say that you can't do this; spec as written says title can be used for name or description (and didn't see anything in accname spec that says you can't do it)
Scott: not explicitly written in html-aam but good idea. There's a couple ways I'm thinking of presenting this information and I've been thinking about ways of doing this, e.g., name prohibited being a single algorithm, rather than element-specific. Also want to make a companion PR for HTML elements that can't be named (e.g., <head>)
Clay: spoke about #506 and a related deepdive, did that happen
Scott: no; although listed as potential deepdive topics
aaronlev: want to have screen reader users test this as well (where name gets moved to description generally if name is prohibited)
aaronlev: curious about the case where the title is the same as the child content; or if the description is the same as the child content (important in the text-overflow: ellipsis case where you're visually showing a tooltip)
Scott: I do think that ignoring the title (as child content) could be something that goes in accname; these are 2 separate PRs
jamesn: lots of definitions of whitespace, whitespace is defined differently in HTML vs. CSS (James C. mentions that ARIA links to HTML definition for whitespace
zakim ,next item
User agents must not support aria-owns across shadow root boundaries
aaronlev: there was some skepticism about this; aria-owns is very challenging generally. It's a useful attribute but lots of things can happen from implementation perspective (e.g., inserting referenced node earlier in the document, aria-hidden nodes)
… if there's no actual use case for using aria-owns across shadow roots (e.g., pointing into a shadow root using aria-owns), then would say not to do for now, and implement it for other use cases (e.g., activedescendant)
… not saying we would never do it; if someone comes up with a use case (but by then we'll have debugged it with other attributes with stronger foundation for how to do it)
jamesn: how do we make it clear to developers that this shouldn't be expected to work?
aaronlev: we could put a console error; we're starting to this more for illegal markup (e.g., aria-hidden on <html> or <body>)
jamesn: also not sure how to spec this. Does anyone disagree think we should 100% do this if we're doing the other attributes?
keithamus: I don't disagree; given that it's only going to be for setting, should it be a console only report error (exception)?
… I think it's possible to raise an exception from a setter method (pretty sure you can do this in IDL). Could we throw an error instead of a console warn
Should aria-valuenow be required if aria-valuetext is used?
jamesn: don't think we came to a conclusion on this
Scott: I want to draw everyone's attention to the comment I added in the issue; per the previous conversation on this, want to reiterate that the proposal is not that there isn't value for aria-valuenow(or used together), there are use cases where they don't want to use valuenow. They may not want to have valuenow value announced as well
… thinking of instances where you have YouTube video player (e.g., hearing "15%" along with valuenow value of timestamp)
… also worked on a range slider component and it didn't make sense to announce the numerical value. E.g., use cases where requiring the attributes doesn't make sense if you're trying to override it
<giacomo-petri> +1
jamesn: I was prepared to advocate for both; the range slider component you mentioned is a compelling example of making it not required (valuenow) if you have aria-valuetext
<spectranaut_> +1
sarah: is that for slider and for progress bar?
aaronlev: for progress bar, there is a percentage (such as NVDA's sonification of loading actions)
jamesn: looks like there's consensus to change it for slider but not progress bar
Scott: I will make a PR to clarify that it's not required for that specific role (slider), but people can optionally do it if they want
jamesn: we should add a note when someone may want to do it as it's not obvious
Clay: to clarify, it is going to be provided (valuetext) unless aria-valuetext is provided?
jamesn: essentially one or the other is required
Adam_Page: I can take a look at that PR
Scott: yes please; add me as reviewer and I'll add what I need to
<Rahim> s/aria PR #2172, need another reviewers/aria PR #2172, need other reviewers/
<Rahim> s/aria PR #2172, need another reviewers/aria PR #2172, need other reviewers//
<Rahim> s/<Rahim> s/aria PR #2172, need another reviewers/aria PR #2172, need other reviewers//
<Rahim> s/<Rahim> s/aria PR #2172, need another reviewers/aria PR #2172, need other reviewers//