Meeting minutes
New Issue Triage
spectranaut_: For aria #2173, this person is seeing a difference between Chrome/Firefox for these <li> elements
keithamus: the concern sounds like the DOM tree would have the custom elements and <li>s (which are slotted); the a11y tree reflects Shadow DOM but it's not working as expected
spectranaut_: may need more of a discussion, or point to incorrect/wrong use of Shadow DOM
keithamus: worth taking to the HTML tracker?
jamesn: Where's the ARIA impact of this issue?
scotto: Could be an implementation issue from Firefox; may not be directly Shadow DOM related. Likely a bug against Firefox
<aardrian> +1 not ARIA issue
spectranaut_: for ARIA #2168, should we agenda+?
New PR Triage
spectranaut_: accname #236 looks like a simple change; does anyone want to weigh in (review)?
aardrian: add me as a reviewer (along with spectranaut_ )
sarah: add me too
spectranaut_: aria #2171: we need reviewers for this as well
jamesn: I can review it
Theo: I can review as well
spectranaut_: Reviews are a nice way to learn the spec
spectranaut_: aria #2170: already reviewed by Peter/Sarah; does anyone else want to take a look?
Theo: I can take a look
sarah: core-aam #229, will be closed
<HaTheo> I
is "undefined" allowed as a value (string) for an ARIA property or state?
Rahim: is "undefined" allowed as a value (string) for an ARIA property or state?
scotto: Specifying undefined on aria-expanded has been valuable if you had a button that allows a control to expand/collapse in certain context; by putting undefined on there, some browsers will prompt a11y tree to wait for a value and it just works (as opposed to putting true or false and changing as a result of user activation, it would not be exposed). in rare cases, I've found it to be useful
Matt_King: it almost sounds like you're relying on an implementation quirk to specify the behavior
… I thought it meant the same thing as aria-expanded not being present?
sarah: I'm reading true/false/undefined, e.g., false is different than undefined in some contexts
Rahim: the original issue lists out what each state/property means for "undefined"
scotto: just wanted to call out that "undefined" as a written value was intended to be useful; need to clarify if it shouldn't be a valuable
WPT Open PRs
<HaTheo> Rahim do you mind adding that issue to IRC. I would love to look at this.
Rahim: wpt #45916, I can review this one
Deep Dive planning
Remove aria-expanded from listbox
spectranaut_: I've opened issues against browsers (and opened a Validators issue) but there appears to be pushback from Wilco
… there has been lots of discussion on deprecation vs. removal in the past. I'd like to hear consensus from the WG more clearly that we'd want to do this against the wishes of Deque's axe
<spectranaut_> ack +
Matt_King: I thought that if we put this in the "deprecated" that it would not invalidate current usage; it would be flagged but it means we could remove it in the future or perhaps make it throw a warning. Not understanding why it would be a problem (i.e., a problem for us to mark it as deprecated in the same way we did changing the global properties to non-global)
scotto: just to clarify, this PR is for removal and not deprecation
Matt_King: I would support deprecation if that's the only consensus path forward
scotto: I put this in the issue as well but we've deprecated other stuff so we can do it for this one too; raises the question of when will it be OK to actually remove stuff from the spec? Does path to removal need to be one point removal and then subsequently removed? Reason for deprecation is because we don't want people to use it anymore
scotto: I don't think the spec should be held up because a validator is using it
spectranaut_: we talked about a deprecation section in a previous F2F meeting. Perhaps this is the time to make this happen
spectranaut_: making a deprecation section is a bigger project
jamesn: wasn't Wilco going to give us a list of deprecation items?
spectranaut_: we should chase this, I can look into after this meeting. I can find where it's referenced/discussed in the past. It sounds like we do want a deprecation section which sounds like a separation issue. Do we want to put this aria-expanded in the deprecation section immediately, or mark it as deprecated in the tables?
spectranaut_: eventually we do want to remove it from the spec
Theo: I had a question; the purpose of this deprecation section is to serve as a final warning before user agents remove it. What's the idea here? Is the criteria to put it in this deprecation section, i.e., that it doesn't have significant usage. Is there a measurable criteria for how we do things differently between the two
spectranaut_: my understanding is that deprecation section is stuff that we want to remove from spec due to no/poor support so we don't want users to think if it's supported. E.g., what happened to this attribute that used to be allowed and why it is no longer (in the spec); Validators can point back to the spec on why something is no longer supported
Theo: the practice today is to put something in the table (characteristics table?); how should people read that differently
scotto: the idea of the deprecation section was to avoid having "deprecated" sprinkled throughout the spec. Instead, could have a dedicated section whether it be roles/attributes. Now, you don't know if it's deprecated, have to look for it/find it in spec
spectranaut_: now, given that we have a deprecation section, do we put in the deprecation table? Rather than leave it in the tables under "listbox". Any objections?
Theo: makes sense to me
Complex dashboards and standalone cards
giacomo-petri: about 2 weeks ago, we discussed a similar issue raised by Mario B. I realized this issue may be 2 separate topics. I'm not advocating for a new role but trying to indicate situations where you have an iframe embedded within a page, i.e., treat a region of content separate from the underlying content. Need this for users and currently no way to do so currently
… I think it would be beneficial authors to enable users to understand this kind of context, i.e., once something is updated, it's changing/updating some specific area of the page and not the whole page
aardrian: I understand that you've compared this to an iframe...is this comparison a visual comparison?
… would it fair to say a better analog may be a "group" or "region" role?
<jamesn> (for minutes on previous topic about deprecation - this is where this was discussed at TPAC - https://
giacomo-petri: the problem is that if you have a link inside a region, it will update the entire page and not the content of the region. Thinking of this in the context where we have cards in a complex dashboard, when you start interacting with a card, only the content in that card will be updated...you could move the focus around but it's not exactly the same as an iframe. If you navigate an iFrame with an AT like VO, it announces "frame" and
dwell into/out of the frame so you can consciously interact with just that island of content
<giacomo-petri> https://
spectranaut_: what is the role when you navigate to an iframe? (group says that it is "document")
sarah: iframe is a document; but an iframe nested inside a document doesn't necessarily get exposed (but does confine virtual cursor)
sarah: we've been discussing this at Microsoft in the context of chat messages; having conversations if SR behaviors should confine cursor (can also restrict AT shortcuts e.g., heading navigation). I think we should approach any attempt to create semantic (role-based) approach for confining with caution as it could have wide-ranging side effects. Not sure it's possible to confine virtual cursor to a region without side effects, should be
approached by authors with lots of caution. I'm not sure how much we want that outside of role="application"
CoryJoseph: just to add onto what Sarah said; it sounds like a modal type of experience without being a modal...the ideal scenario sounds like a help or tutorial panel that sits right/left of a page in a desktop; you'd be consuming and interacting with the help panel. To Sarah's point, you'd be totally confined in the panel or that region and not able to navigate back/forth what you're consuming and the content of the page as needed
<sarah> +1 to the comparison with modal, that's a good one
giacomo-petri: I'm not sure what is expected from the author; how can the author convey these types of behaviors to AT users besides focus management? Is the author only responsible to move the focus around and is this enough to communicate what is happening on the page to users? can't use a modal interaction because it would trap the user inside. E.g., you could be working on card 1 and at some point, move to card 3; the actions are
independent and what you do in card 1 doesn't impact other cards. This is just an example but it could be a panel or dashboard
CoryJoseph: it sounds like a region or section to me; something that announces or makes it clear that you're in a distinct area
giacomo-petri: is it fine to update the content of a single region without communicating to a user. If I activate a link for such a region, would they expect entire page to reload (or just a change to that region)?
<aardrian> Dropping thoughts here owing to time: I think there is merit to exploring this, but I think the expectations need to be more clearly defined.
spectranaut_: it sounds like there's a few concrete things that need solving; e.g., interacting with a card only updates that region of content. Perhaps it would be better to have the individual user interactions that are difficult, that you want resolved by this issue, describe how they can be resolved in different ways
giacomo-petri: I don't think trapping a user inside a card provides the same experience to all users. The intent is to provide a semantic role that allows users to predict what will happen as a consequence of interacting with particular content. To me, simple landmark doesn't convey the purpose of the changing functionality of the card short of providing a description for the card at the beginning (e.g., "activating one of the card's controls
will...")
Mario_B: I think this is very similar to tiles/cards in the dashboard proposal made by me because it's not important how the tile is visualized (looks?)...it's an area where you work within and has contents that you can choose/change and all other cards in this dashboard stay unchanged. Why couldn't we have a tile or card role for this instance?
giacomo-petri: I don't like the idea of card styles because it is restricted to the visual experience. I'm curious if there is something we can add regardless of the visual appearance of the element, e.g., a landmark region that only updates the content inside
… also regarding Sarah's feedback, the idea of an iframe is to convey something that updates without changing the other areas of the page; rather, it was the idea of content that updates regardless of the rest of the page. I'm not saying that when you're inside this card, you only convey the contents of this particular region
sarah: my question is, when you say "convey", are you looking for a new role with localized role name? I can't think of one that would convey this idea as it's pretty abstract so what does it mean to "convey" that? Also, curious about how a nested role="document" without an intervening role="application" element would behave
Theo: I'm curious what the sighted user would see; is it more about indicating that the content is updated after a link is pressed?
giacomo-petri: if you interact with a single card/item, you immediately realize that only one card is updated. For SR users, you don't know what happening even if focus is being managed because you don't have overall context of the page. I.e., that interacting with a particular card only updates that card and not others
spectranaut_: it sounds like there is more to discuss here. What are next steps?
… can put the deepdive label on it and get more detail on the issue