Meeting minutes
New Issue Triage
spectranaut_: A lot of the new issues are from me, from mono repo work
for aria #2241, discussed a few years ago but we should formalize a process for this
jamesn: need to mindful of process; need for them to work with APA (Accessible Platforms Architecture which serves as horizontal review group for other specs)
jcraig: people that are doing review are in ARIA WG (not APA)
spectranaut_: will figure out whether it needs to be discussed later this week
jamesn: for #2238, anyone who has knowledge of github and GH APIs, help would be appreciated
New PR Triage
<giacomo-petri> https://
giacomo-petri: for aria #2237: scope of conflict resolution is split into two. Grouped the notes in the PR into different paragraphs; the notes are related only to the last bullet (as opposed to related to the entire conflict resolution group)
… scott has been added as a reviewer
WPT Open PRs
<elguerrero> Have to drop off suddenly, regrets!
spectranaut_: no open WPT issues aside from adam's issue (wpt #46527)
<jamesn> https://
Deep Dive planning
spectranaut_: in two weeks time, we have a deepdive planned for Jun 27
… related to clarification around "undefined"
jamesn: we won't be meeting on July 4th (holiday)
TPAC Draft Schedule
spectranaut_: heads-up that a draft has been scheduled for TPAC
jamesn: in the TPAC schedule, search for "accessible rich internet applications" for our sessions
… in September later this year, in Anaheim, California
Monorepo Update
jamesn: registration for TPAC opens within the next week; webpage is almost done. I would highly recommend registering and using the room block
spectranaut_: we have now merged all of the specifications into the ARIA repository. If you open a new PR, open it in the ARIA repo
… action items open for spec editors to review all of the PRs we've moved over, and make sure the PRs have relevant information to continue review process. Also, ensure closing the old PRs against the individual specs
… Peter K and I will handle the AAMs with less active editors
… if you have issues with process or tools, please file against ARIA repo
Matt_King: Thank you for making this happen, Valerie. It was a big lift
… special thanks to Peter/Daniel as well. Hope it pays off
dmontalvo: we want to keep the old editor's draft URLs, still working on fixing this
<spectranaut_> w3c/
BGaraventa: could you flag this as an action item for me (as spec editor)? [accname #238 which is assigned to Bryan/Mel]
spectranaut_: any questions or concerns?
ARIA Notify Followup
spectranaut_: for aria #1957, there are some new issues following deepdive from a couple weeks ago. We've (ARIA WG) been adding one agenda item for aria-notify follow-up per week, should we continue doing that?
sarah: sounds like a good approach
Consider adding headings to feed's allowed accessibility children
sarah: for aria #2236, we discussed this in triage last week. It's a use case where, in a feed such as a blog feed, in addition to headings in articles you have additional headings that group content. I ran into this using role="feed"/"article" for chat message roles. Had headings that were time-stamped, so you could get a new time-stamped message on a frequent basis
… could be a use case to have headings in "feed"; instead of specifically adding heading, per Scott, might make sense to look at content model for allowed roles
… other examples include where posinset/setsize are allowed
Matt_King: I have a concern about this related to "feed"; the contract/understanding on the AT side is that you're navigating feed by article, that you'll hit (navigate to) everything. How might we address that such as this case, where headings are wrapped in an article
sarah: I've been doing user studies on chat usage; I've found that people use headings to navigate although arrow keys are available. People switch fluidly between the two, or jumping to arrow (browse mode) navigation when it makes sense
… heading information is available, i.e., time-stamp information. Don't notice anything missing when navigating via arrow keys
jamesn: I'm unhappy if we go the heading route; we even need to go the content model route which seems like a huge task. Especially if we want to do this across more things, and thinking more carefully about other things that may be potentially useful on a feed
… any of the generic text ones make as much sense as a heading; a separator makes sense. Do we look for use cases for all of them? It's a choice we want to make about the complexity we want to add to the spec
Matt_King: if you add both "heading"/"separator" roles, not sure why that's different
jcraig: this is a good opportunity to express previous opinion; feed is a container that could be a flow container which contains a number of things. It would be nice if it contained encapsulated articles and heading but not necessarily an authoring error
Scott: maybe I'm missing something, is there something in spec that says you can't put things in there right now? As far as I can tell, conformance checkers are treating it as if not listed in required roles, they are flagged as failures
<jcraig> From the spec: Allowed Accessibility Child Roles: article
<jamesn> A list of roles which are allowed on an accessibility child (simplified as "child") of the element with this role. Authors MUST only add child element with allowed roles.
<sarah> jamesn said what I was going to :D
Scott: I'm looking at the spec now, and unless I'm missing something, it seems ambiguous. To James Craig's point, if we do a content model, we should clarify that there are no requirements for "disallowing" things
<sarah> https://
Matt_King: Two points regarding permissiveness and content model. RE: content model, if it's not too big of a lift to go in the direction of a content model for ARIA, I think it's great for the long-term extensibility and clarity of the spec (and that it works from the HTML side) although it's likely not an issue that needs to be resolved overnight
… could be a great incubator for that idea
… RE: permissiveness, if it was conceived as/intended to be a list, i.e., an actual structure as opposed to a random container such that there is a clear navigation ideology (like lists/tables, that are useful structures). We need to be careful there that we don't put random elements in lists/table, the point is for it to be a useful structure
spectranaut_: Can anyone justify why it (content model) is useful?
Scott: Group elements by type and what's allowed where; can have exceptions to those, e.g., links are of a particular content model but can't put other interactive children in link. Essentially, it's a way to group things in a way of what's allowed and calls out what is excluded
… I've run into this with developers, putting div with button role inside link; HTML validator allows this for ARIA although it's not OK
… this is why Steve F. made "ARIA in HTML"; it's informative currently. The benefit was to describe rules that weren't in ARIA and didn't have a place to live
<Zakim> jamesn, you wanted to say and it allows a bunch of weird stuff
jamesn: the content model in HTML may encourage bad practices, although it can cause issues
Scott: it's not perfect, and doesn't align with parser. You can break the content model and in many cases, that is OK
sarah: I was going to suggest that we don't replicate HTML content model; things that are useful IMO are widgets like buttons/links, composite widgets, interactive roles allowed within interactive widgets
… things that don't exist in HMTL could be useful in ARIA for spec work
Matt_King: we do take advantage of abstract roles in spec language, but can be problematic at times
siri: Going back to what Matt/James was saying, what is the advantage to using feed/separator? A label isn't provided so how does this benefit screen reader users. If we provide time stamps as heading content, how does this help users?
Matt_King: Some screen readers have the ability to navigate by separator; but limited to HTML separator and not ARIA separator
spectranaut_: there doesn't appear to be a conclusion from this discussion
<spectranaut_> siri
Matt_King: we could have a blended option; as a lightweight approach, add heading/separator as allowed children of feed in the near term
… someone could then start pulling together the concept of a content model which could make it into the next spec version (e.g., v1.3)
sarah: I would be happy to write the PR for this, although I know Scott is interested in this
… can put together a draft of content model stuff to concretize discussion
ARIA should clarify distinction between “contents exposed as descendant text nodes” vs “name from contents” (Was: listitem should include name from Contents or name prohibited) and -> td, th naming doesn't align with ARIA
jcraig: for AAMs, we don't have a clear distinction between things that have an accessible name (from contents, e.g., <a>, text leaf nodes) as opposed to a11y APIs that don't expose an element's accname from contents
… some tests rely on testing accname for listitem; errata/bug related to whether this would name from author or contents
… almost like a property we could use to test, e.g., have name, description and this other thing that would be "contents" which would be testable from a WPT perspective. E.g., listitem, paragraph, where name doesn't necessarily apply
spectranaut_: when you say that it would help us test, e.g., getComputedContent like getComputedLabel
jcraig: something like el.getInnerText; then, verify from a11y tree, does the browser internal engine have the same thing that is exposed down to the platform
… another thing that would come out of this, we're able to test less because of this errata. Perhaps this would be more valuable from a testing perspective to compare across engines
… html-aam also doesn't identify how list items can be named. We could say name from author prohibited in spec
Scott: my opinion hasn't changed; author naming of list items doesn't do anything from my testing. Some cases, e.g., moving focus to them, some AT/browser combinations will announce author name from aria-label. However for browse mode, author label isn't exposed...regardless, why are you making list items focusable at all
… I'm more in favor of prohibiting it since the use of it isn't well supported anyway (less things for browsers to fix). The last we talked about it, Sarah had mentioned the desire to make an interactive list role although that work may be undone by work for interactive lists
jcraig: should we use the same pattern for all similar roles (e.g., paragraph)? Then name would be prohibited for listitem and use the same pattern down the line for equivalent elements
sarah: I agree with that (just use a different role); putting name prohibited makes sense
spectranaut_: it sounds like there is an action item to remove name allowed for listitem. Does anyone disagree?
<sohara> +1 to name prohibited from listitem