– DRAFT –
TPAC 2025 - ARIA WG Day 2

Update from Open UI, Part 2

<bkardell> present_

<ZoeBijl> SH: one of the things being incubated by open-ui is interest invokers

<ZoeBijl> there’s a new interest event

<ZoeBijl> or declaritively for JS

<Jamie> s/??/OpenUI/

<ZoeBijl> the really cool part is that ??

<ZoeBijl> right now the way you do hover cards etc

<ZoeBijl> usually when you use your mouse to hover

<ZoeBijl> this is done with hover and focus events

<ZoeBijl> and this doesn’t work for everyone

<ZoeBijl> with interest invokers we have specific events for this

<ZoeBijl> this means you can in theroy you can make this work for voice control

<ZoeBijl> by having VC use a custom command

<ZoeBijl> ??

<ZoeBijl> lots of possibilities to make this accessibility

<ZoeBijl> browsers provide the interest event

<ZoeBijl> devs will have to use that to make the UI functional

<ZoeBijl> Scott and I have been providing feedback in the group

<ZoeBijl> but we would like further feedback from the group

<ZoeBijl> *starts slides*

<ZoeBijl> open questions

<ZoeBijl> 1. Does the aria-details for desktops SRs? Compare to aria-actions?

<ZoeBijl> 2. Should the ::interest-hint pseudo element be excluded from the accessibility tree?

<ZoeBijl> 3. Voice control contacts?

<ZoeBijl> 4. Optional: touch access

<ZoeBijl> LR: I want to clarify ??

<ZoeBijl> the plain ones would be when you have a popover with text content

<ZoeBijl> the other would be anything besides just text

<ZoeBijl> the way we implemented this

<ZoeBijl> with plain text there’s no aria-details

<ZoeBijl> we use aria-description

<ZoeBijl> with the other ones we ??

<ZoeBijl> the name stays the same

<ZoeBijl> you add an aria-description

<ZoeBijl> it’s quite nice because the SRs i tested speaks the name + the description and the relationship

<ZoeBijl> ?? my take would be that an event should happen

<ZoeBijl> one way to verify this would be to alt+tab and then alt+tab back into the window

<ZoeBijl> and then ??

<ZoeBijl> is this splitting that just chrome does?

<ZoeBijl> SH: that is interesting

<ZoeBijl> i do want to mention that this is not just a relationship for popovers

<ZoeBijl> this event will fire even if it’s not a popover

<ZoeBijl> it’s a programmatic event, so you don’t know what it would do

<ZoeBijl> can you clarify ??

<ZoeBijl> LR: yes

<ZoeBijl> the case i was describing was just interest for the popover

<ZoeBijl> MF: if it’s not a popover you’re on your own

<ZoeBijl> SH: this is about ?? interest

<ZoeBijl> what is the mechanism for idnicating interest

<ZoeBijl> LR: so not declaritive?

<ZoeBijl> SH: not neccesarily

<ZoeBijl> it could be both

<ZoeBijl> this is more about specifically about this being a new event

<ZoeBijl> it’s about how do you trigger that event

<ZoeBijl> LR: i agree that from a semantics perspective this should be implemented

<ZoeBijl> from aria-details, from a SR user persepective, needs some tweaking

<ZoeBijl> maybe a good outcome from the discussion could be ??

<ZoeBijl> this is an informal survey of users

<ZoeBijl> what is the shortcut of going to aria-details

<ZoeBijl> and nobody knew

<ZoeBijl> JT: for declaritive…

<ZoeBijl> we have aria-expanded

<ZoeBijl> it will, or should, fire an event

<ZoeBijl> when an interst target appears or disappears

<ZoeBijl> and it also declares aria-details

<ZoeBijl> your interest is in regard ??

<ZoeBijl> in which case you would have to ecplicitly set aria-details?

<ZoeBijl> SH: my question is more about how you explicitly trigger interest

<ZoeBijl> for example if you’re in browse mode

<ZoeBijl> JT: couple of things

<ZoeBijl> 1. AT sniffing

<ZoeBijl> 2. i’m not following using the aria-details mechanism

<ZoeBijl> it’s not an action, it’s a query

<ZoeBijl> ??

<ZoeBijl> but even if there were asking for the details relationship, it’s not interest, it’s a programmatic query

<ZoeBijl> an action might be acceptable

<ZoeBijl> ach Jamie

<Zakim> Jamie, you wanted to clarify interestfor vs custom interest events

<ZoeBijl> MK: the way you’re talking about this

<ZoeBijl> it sounds liek there’s a difference from someone looking at the accessibility tree

<ZoeBijl> and at an event

<ZoeBijl> is that correct?

<ZoeBijl> is that necessary

<ZoeBijl> i forget if interestfor is limited to popovers?

<ZoeBijl> MF: no

<ZoeBijl> SH: ??

<ZoeBijl> and everything else

<ZoeBijl> interestfor=popover

<ZoeBijl> MF: essentially there’s only delcaritive ?? attribute

<ZoeBijl> SH: there is the event right?

<ZoeBijl> that you can listen to?

<ZoeBijl> MF: yea

<ZoeBijl> JT: but the browser won’t trigger it?

<ZoeBijl> so neither should AT?

<ZoeBijl> SH: oh i thought it would trigger it

<ZoeBijl> MF: no there’s no interest event

<ZoeBijl> there’s no API

<ZoeBijl> LR: can you clarify what feedback you want?

<ZoeBijl> SH: essentially…

<ZoeBijl> interestfor pointing at a popover or other elements

<ZoeBijl> i assume we want the method of indicating interest to be the same between those events

<ZoeBijl> MK: do you mean in the accessibility tree?

<ZoeBijl> do you mean authors or users?

<ZoeBijl> SH: i mean users

<ZoeBijl> LR: one idea i once had

<ZoeBijl> right now the aria-details relationship only happens when the intrest target is shown

<ZoeBijl> what would happen

<ZoeBijl> the first thing people would say is we can't expose the details relation because the target isn't in the accessibility tree

<ZoeBijl> could we indicate in the element that there is more content?

<ZoeBijl> maybe using aria-expanded and collaps?

<ZoeBijl> SH: the problem with that is that you could have interst on an element that has aria-expanded

<ZoeBijl> say you have an accordian header

<ZoeBijl> aria-expanded would be for the content, but the interest could be for a separate tooltip

<ZoeBijl> MK: the SR user could request the actions

<ZoeBijl> which sets focus

<ZoeBijl> with focus there the actions get exposed

<ZoeBijl> that’s how we get around the sniffing concern

<ZoeBijl> but in this case…

<ZoeBijl> couldn’t you do the same thing with…

<ZoeBijl> SH: you could

<ZoeBijl> MK: you do have a problem in the ations page

<ZoeBijl> the thing we didn’t address

<ZoeBijl> stuff that’s not focusable

<ZoeBijl> does it need to be focusable?

<ZoeBijl> MF, SH: yes

<ZoeBijl> buttons and links

<ZoeBijl> MK: ??

<ZoeBijl> ask the AT to set focus?

<ZoeBijl> SH: i think aria-actiosn would work

<ZoeBijl> MK: wondering if we have the same AT requirements

<ZoeBijl> or would that cause issues for SR users?

<ZoeBijl> siri: you said whenever you hover it shows

<ZoeBijl> SH: yes

<ZoeBijl> siri: the issue i see

<ZoeBijl> ??

<ZoeBijl> SH: that’s definitely an example

<ZoeBijl> on wikipedia you get previous if you hover over articles you get a preview

<ZoeBijl> same with social media

<ZoeBijl> if you hover a username you could get a preview of the profile

<ZoeBijl> siri: most of the time we’re talk about SR users

<ZoeBijl> what about voice control users?

<ZoeBijl> SH: that’s the third question on the list

::interst-hit pseudo element

<ZoeBijl> SH: it’s part of the button or link you want interest for

<ZoeBijl> we discussed this in OpenUI

<ZoeBijl> my proposal was to not have this in the accessibiltiy tree if we do this with specific AT fucntions (??)

<ZoeBijl> it would be a pointer target

<ZoeBijl> JC: it would be a pointer target

<ZoeBijl> so you can click it?

<ZoeBijl> but you wouldn’t expect an event on it

<ZoeBijl> SH: yes

<ZoeBijl> but it wouldn’t prevent you from adding it

<ZoeBijl> i wouldn’t expect AT to have to interact with it

<ZoeBijl> JC: didn’t we talk about this for aria-actions?

<ZoeBijl> ??

<ZoeBijl> i would expect that would be the way to invoke it

<ZoeBijl> SH: it’s not just there as a way to show interest

<ZoeBijl> the element that has `interestfor` still shows the popover/associated element

<ZoeBijl> so show on focus will already happen

<ZoeBijl> MK: you said that the author could indicate the availability for `interestfor`

<ZoeBijl> does that mean that the browser is in reposonse to attribute is automatically showing something next to the element

<ZoeBijl> that’s a tab target?

<ZoeBijl> SH: yes

<ZoeBijl> the presentation would depent on how you style it

<ZoeBijl> MK: so the author is providing that element in CSS?

<ZoeBijl> SH: yes

<ZoeBijl> it would be a CSS pseudo element?

<ZoeBijl> MK: and it would appear when?

<ZoeBijl> JT: always visible

<ZoeBijl> MF: with the `content` property or something

<ZoeBijl> MK: that presents a problem with WCAG probably

<ZoeBijl> having two targets so close to eachotehr

<ZoeBijl> ??

<ZoeBijl> SH: yea voice control and screen readers would be the two relevant ones

<ZoeBijl> MK: ??

<ZoeBijl> SH: that’s also the other reason i think it shouldn’t be exposed

<ZoeBijl> the use case driving this

<ZoeBijl> you can expose this with ??

<ZoeBijl> and that means if you’re using a SR sometimes there might be an extra button for something that has interest

<ZoeBijl> and sometimes there isn’t

<ZoeBijl> MF: i think it’s important to remember that it’s auxillary

<ZoeBijl> akc jcraig

<Zakim> jcraig, you wanted to ask edge cases about invoking events and delays

<ZoeBijl> JC: iOS has a “two tab” behaviour

<ZoeBijl> specifically on iPad where you have desktop sites

<ZoeBijl> say a fly out menu

<ZoeBijl> the two tap will essentially trigger the hover event

<ZoeBijl> allowing the flyout menu to show

<ZoeBijl> most of the concerns or open issues

<ZoeBijl> are related to the mainstream interface

<ZoeBijl> i’m just trying to pass these along

<ZoeBijl> there’s no real concern

<ZoeBijl> the ??

<ZoeBijl> the descoverability of long press has been logn been discussed

<ZoeBijl> it’s useful for lots of things

<ZoeBijl> there was another one that may be dismissed

<ZoeBijl> there was long, medium, short keyboard delays

<ZoeBijl> these seem to be gone?

<ZoeBijl> MF: yea these are gone

<ZoeBijl> it’s no times

<ZoeBijl> the keywords are gone

<ZoeBijl> times are there

<ZoeBijl> JC: ah ok

<ZoeBijl> MF: there is an explicit thing in there for user agent overrides

<ZoeBijl> JC: the other thing that hasn’t been fully considered are things like the Apple Vision Pro situation or tmaybe meta glasses

<ZoeBijl> i think that’s it

<ZoeBijl> don’t need a response right now

<ZoeBijl> just so you can think about it

<ZoeBijl> SH: thank you

<ZoeBijl> yes i want to talk about that with you jamie and maybe matt

<ZoeBijl> *jokes about having interest for the topic*

<ZoeBijl> show agenda

<ZoeBijl> *discussion about another meeting*

<Jacques> This is the whatwg schedule: whatwg/html#11711 (comment)

Menu Element

<ZoeBijl> DF: hi

<ZoeBijl> one of the things we’ve been working on in the OpenUI is menus

<ZoeBijl> the word menu is brutally overloaded

<ZoeBijl> we specifically talking about system menus

<ZoeBijl> like those found in operating systems

<ZoeBijl> but also web applications

<ZoeBijl> a word processor for example

<ZoeBijl> the point of this presentation is to make everyone aware of the proposal

<ZoeBijl> and have discussion about the accessibility considerations

<ZoeBijl> the motivation is that this is a common pattern on the web

<ZoeBijl> we did a survey on n sites

<ZoeBijl> the wya to trigger these is ??

<ZoeBijl> hovering works universally

<ZoeBijl> but keyboard and clicking are sparse

<ZoeBijl> activating items works mostly with click and keyboard

<ZoeBijl> but not universally so

<ZoeBijl> also looping

<ZoeBijl> so using arrow keys to move between menus and submenus

<ZoeBijl> implementations vary

<ZoeBijl> there are a bunch of other weird behaviours

<ZoeBijl> such as `Tab`

<ZoeBijl> support varies wildly

<ZoeBijl> we have a lot of interesting proposals

<ZoeBijl> such as the Popover API

<ZoeBijl> *shows test page*

<ZoeBijl> this is all keyboard navigation

<ZoeBijl> we have (exclusivity) checkable menu items

<ZoeBijl> this whole thing is using prototype ??, no JavaScript

<ZoeBijl> the code is pretty simple

<ZoeBijl> we have a new `menubar` element

<ZoeBijl> and `menuitem`

<ZoeBijl> and `menulist`

<ZoeBijl> you can make radio menu items with a `fieldset`

<ZoeBijl> we started by kicking up dust and tryign to handle everything

<ZoeBijl> we learned pretty quickly there’s a lot of difficulty and complexity

<jcraig> Apologies for stepping out abruptly. There's a critical VTT captions topic in Timed Text WG being discussed now.

<ZoeBijl> especially with regards to accessibility

<ZoeBijl> this resulted in us splitting off navigation bars

<ZoeBijl> which would be a `navigationbar` element

<ZoeBijl> thank you to all the accessibility people for being patient with us

<ZoeBijl> Sarah, Scott, other people in the room, and probably others!

<ZoeBijl> this means we can focus on menubar

<ZoeBijl> LR: when you showed the example you said the `menubar` has `menuitem` in it

<ZoeBijl> shouldn’t it have `menulist` and then `menuitem`?

<ZoeBijl> DF: the `menubar` first has `menuitem` and these then invoke the `menulist`

<ZoeBijl> the basic high level thing here is that we have native ARIA role mapping

<ZoeBijl> `menubar` to `menubar`

<ZoeBijl> `menulist` to `menu`

<ZoeBijl> `menuitem` to `menuitem`

<ZoeBijl> we also have a bunch of discussion around `aria-expanded`, `aria-checked`, and `aria-disabled`

<ZoeBijl> we were landing on the behaviour of `<menuitem disabled>` has `aria-disabled=true`

<ZoeBijl> to make them “soft disabled”

<ZoeBijl> we also discussed `aria-owns`

<ZoeBijl> and how we shoudl expose the hiarchy

<ZoeBijl> in the DOM we don’t nest `menulist` inside `menuitem`

<ZoeBijl> those are siblings

<ZoeBijl> should they be siblings in the accessibility tree?

<ZoeBijl> or should they represent the visiaul hiarchy with `aria-owns`

<ZoeBijl> it was suggested to keep them as siblings

<ZoeBijl> a big part of this is keyboard support

<ZoeBijl> ???

<ZoeBijl> the other thing is orientation

<ZoeBijl> horizontal/verticle

<ZoeBijl> which could use `aria-orientation`

<ZoeBijl> ~Fin~

<ZoeBijl> let’s open up the floor

<ZoeBijl> Rahim: thank you for the presentation

<ZoeBijl> question around the implementation like mega menus

<ZoeBijl> one common pattern that i come across a lot

<ZoeBijl> if you have a menu

<ZoeBijl> really you have a trigger to toggle the menu

<ZoeBijl> sometimes they marked as menus

<ZoeBijl> sometimes are details

<ZoeBijl> DF: good question

<ZoeBijl> all design items that would support a mega menu

<ZoeBijl> everything would go into the `menulist` (??)

<ZoeBijl> all the difficulty around mega menus is around ??

<ZoeBijl> i like to think we kinda support it out of the box

<ZoeBijl> ZB: wouldn’t that be more for the `navigationbar` element?

<ZoeBijl> DF: yea ??

<ZoeBijl> another is that they (??) have much more toolbar commands

<Zakim> Jamie, you wanted to ask about accesskeys, menulist labelling, a11y tree parenting, grouping and posinset/setsize

<ZoeBijl> JT: some quick points

<ZoeBijl> have there been consideration for accesskey

<ZoeBijl> MK: if you type “RE” in a menu it will go to the menuitem that starts with that

<ZoeBijl> JT: do menu items name their submenu? like the menu item "file" should name the submenu that is opened ??

<ZoeBijl> because it probably should

<ZoeBijl> i dropped a comment on the aria-owns issue

<ZoeBijl> i can link to it

<ZoeBijl> [add link here]

<ZoeBijl> i’m concerned about people doing wacky stuff like sticking iframes, headings, and whatever in menuitems

<ZoeBijl> if people can do it they probably will

<Zakim> jamesn, you wanted to ask how you are going to stop people using it for navigation menus

<ZoeBijl> we should looka t ocntent model restrictions

<ZoeBijl> JN: in aria we struggle from people using this for navigation menus

<Jamie> My comment regarding aria-owns and tree reparenting: openui/open-ui#1297 (comment)

<ZoeBijl> DF: we knew that people would

<ZoeBijl> so we want it to work for that from the start

<ZoeBijl> which led ius to the `navigationbar` proposal

<ZoeBijl> we hope this will lead to accessible situations

<ZoeBijl> MF: ??

<ZoeBijl> DF: one example is

<ZoeBijl> for restricting cotnent

<ZoeBijl> display none on nested links

<ZoeBijl> LR: first letter navigation

<ZoeBijl> this is how SR users navigate menus they arleady know about

<ZoeBijl> it’s minimising the number of keystrokes

<ZoeBijl> second

<ZoeBijl> you talked about menu types

<ZoeBijl> like checkbox and radiobutton

<ZoeBijl> example from google docs

<ZoeBijl> is alt+/

<ZoeBijl> you type the menu item you think you know

<ZoeBijl> and it’ll show where that is

<ZoeBijl> DF: we have an issue open about this

<ZoeBijl> filterable menu item on top

<ZoeBijl> there are problems around getting fuzzy search etc just right

<ZoeBijl> MK: three things

<ZoeBijl> content model stuff that Jamie mentioned

<ZoeBijl> in the proposal

<ZoeBijl> are there restrictions on what can be in a menu item

<ZoeBijl> DF: it’s not resolved yet

<ZoeBijl> we don’t want nested interactive content

<ZoeBijl> we expect most things to be in menuitems (??)

<ZoeBijl> MK: i see a lot of things that doesn’t fit within the current ARIA menu roles

<ZoeBijl> putting things like headings in menus

<ZoeBijl> normally the way around that

<ZoeBijl> the popover would include

<ZoeBijl> headings

<ZoeBijl> it would become a dialog

<ZoeBijl> SH: comments about the type to navigate

<ZoeBijl> reminded me of select too

<ZoeBijl> i wanted to make a note that we may want the same behaviour for ??

<ZoeBijl> i can open an issue about that

<ZoeBijl> considering them both at once might be relevant

<ZoeBijl> so developer preferred type ????

<ZoeBijl> *break time till 11:10*

<ZoeBijl> show agenda

<ZoeBijl> show agenda

<ZoeBijl> item+ Menu Element

<ZoeBijl> show agenda

<ZoeBijl> w3c/aria#2659

<ZoeBijl> GitHub: w3c/aria#2659

<dbaron> github: w3c/aria#2658

snap-to-activate

<ZoeBijl> DB: this is maybe a slighjtly different stage of presenting something

<ZoeBijl> this is pretty early in the design process

<ZoeBijl> if the feedback i get from the group today

<ZoeBijl> is “no you’re doing it completely wrong”

<ZoeBijl> that ok, this is the right time

<ZoeBijl> alternative proposals are good at this point

<ZoeBijl> i want to show some examples

<spectranaut_> a link to the explainer: https://github.com/WICG/declarative-partial-updates/blob/main/snap-to-activate-explainer.md

<ZoeBijl> i don’t want to limit the discussion around the questions

<ZoeBijl> but i have some questions

<ZoeBijl> we’re trying to look at building at better gesture driven interface

<ZoeBijl> it’s fairly common on touch devices where swiping to the side does something

<ZoeBijl> might be navigating to some other part of the UI

<ZoeBijl> might be ??

<ZoeBijl> some example, in order of increasing complexity

<ZoeBijl> i’ll start with the simpler examples

<ZoeBijl> one of the simpler examples

<ZoeBijl> i took most of these from android

<ZoeBijl> in the photos app on android, if you swipe to the side, you go to the next photo

<ZoeBijl> if you swipe in the opposite way you go back

<ZoeBijl> it’s not destructive

<ZoeBijl> if you do this on the web, you probably expect the URL to change

<ZoeBijl> on the web this would be a page change in a SPA

<ZoeBijl> this is the maps app

<ZoeBijl> i want to see the previous or next traim

<Jamie> s/from Android/from native Android apps/

<ZoeBijl> i can swipe to the sides to do that

<ZoeBijl> the UI is complicated

<ZoeBijl> but it’s the google maps app

<ZoeBijl> where you selected a particular subway station

<ZoeBijl> and a direction to go

<ZoeBijl> you’ve chosen a train

<ZoeBijl> and it shows you a time when the train will leave and when it will arrive

<ZoeBijl> and if you swipe to side it will show the next train

<ZoeBijl> it’s kinda like navigating the photos

<ZoeBijl> but the UI is more complicated

<ZoeBijl> a slightly more complex action is pull to refresh

<ZoeBijl> i took this from a web interface

<ZoeBijl> if you pull down it shows a little error and then a little loading icon

<ZoeBijl> it will fetch and display new content if any

<ZoeBijl> it’s a bit more destructive

<ZoeBijl> requires a bit more care

<ZoeBijl> the final example is a bit similar

<ZoeBijl> in concerns anyway

<ZoeBijl> this is the UI for Gmail on Android

<ZoeBijl> showing a list of messages

<ZoeBijl> if you swipe to the side it shows actions for the message

<ZoeBijl> like delete, archive, move, etc

<ZoeBijl> this again is even more destructive in action

<ZoeBijl> i’m of the thinking here that a bunch of these things involve things that are scrollable

<ZoeBijl> scroll-snapping in CSS

<ZoeBijl> but how do we hook up ?? to something

<ZoeBijl> to scroll-snapping

<ZoeBijl> ??

<ZoeBijl> a bunch of them are not going to work

<ZoeBijl> some that seem not dissaturous so far

<ZoeBijl> the ability to snap to a particular place

<ZoeBijl> to a button or link elsewhere in your UI

<ZoeBijl> this has some advantages

<ZoeBijl> these gesture driven UIs

<ZoeBijl> are not necessarily the most discoverable

<ZoeBijl> if there is alternative UI to these gestures, which is not uncommon

<ZoeBijl> that maybe eleviate some problems with it

<ZoeBijl> but at the same time we do want the gesture driven UI to be discoverable and accessible as well

<ZoeBijl> one idea that we have floating

<ZoeBijl> the things you interact with ??

<ZoeBijl> and snapping with to ?? activates the button over there

<ZoeBijl> one question about this

<ZoeBijl> does this ?? the accessibility at all?

<ZoeBijl> i’m not asserting that it does

<ZoeBijl> i’m asking the question

<ZoeBijl> could we be thinking about the accessibility differently than we are

<ZoeBijl> another questions

<ZoeBijl> my understanding about this UI

<ZoeBijl> there are various ways AT can make announcements about the availability of these things

<ZoeBijl> if we take an approach like this

<ZoeBijl> how should the mechanisms like this be ??

<ZoeBijl> distributed between ?? and AT

<ZoeBijl> how much can build into the browser engine

<ZoeBijl> those are some of the questions i have

<ZoeBijl> at this point i’m mostly interested in…

<ZoeBijl> feedback both about whether this sorta basic idea of mapping to activate another thing is horrible

<ZoeBijl> and to the questions i have

<ZoeBijl> LR: all the examples you gave

<ZoeBijl> and some of the ideas of the solutions

<ZoeBijl> are of the higher level

<ZoeBijl> in here’s an action and here’s a ??

<ZoeBijl> it feels like it was very abstract

<ZoeBijl> as a user

<ZoeBijl> when you’re describing the use cases

<ZoeBijl> the best example we have is voice over with the actions rotor

<ZoeBijl> VO for iOS/iPadOS has the actions rotor

<ZoeBijl> authors can create this idea that there are actions for elements

<ZoeBijl> my question is

<ZoeBijl> why a possible solution couldn’t involve a semantic pairing

<ZoeBijl> if the solution couldn’t be one step higher in the hiarchy

<ZoeBijl> DB: i think it’s clear

<ZoeBijl> some of the questions that’s

<ZoeBijl> it’s sort of a larger solution

<ZoeBijl> that isn’t just about this space

<ZoeBijl> it seems some of the questions

<ZoeBijl> it’s an interesting thing to think about

<ZoeBijl> how it fits in with other pieces of work

<Zakim> alice, you wanted to ask about the distinction between non-destructive and destructive actions

<ZoeBijl> AB: i thought that the distinction you made between non-destructive and desctructive actions was interesting

<ZoeBijl> the first just looked like a scroll

<ZoeBijl> same with the train example

<ZoeBijl> the ones you described as destructable look like actions

<ZoeBijl> the pull to refresh is like activating a button

<ZoeBijl> it activates a button to delete and then repopulate

<ZoeBijl> i wonder if those actions need a specific solutions

<ZoeBijl> scolling is just scrolling

<ZoeBijl> but those actions are destructive

<ZoeBijl> and i was wondering if SR users are interacting with those more destructive actions

<ZoeBijl> like the pull down to reefresh

<ZoeBijl> MK: the pull down to refresh is the same for SR users

<ZoeBijl> the equivalant action in most native actions

<ZoeBijl> is the scroll down gesture

<ZoeBijl> AB: and you get an announcement of what will happen

<ZoeBijl> MK: if there is it’s normally done by the app

<ZoeBijl> i guess similar to sighter users, you learn about it the usual way

<ZoeBijl> word of mouth

<ZoeBijl> or how ever people learn about this…

<ZoeBijl> MF: on touch interface it’s reversable

<ZoeBijl> you can cancel the actions

<ZoeBijl> MK: ah ok, SRs can’t do that i don’t think

<Zakim> Jamie, you wanted to raise the parallel to custom actions, AT discoverability

<ZoeBijl> JT: wanted to echo some of what Lucas was saying

<ZoeBijl> some of this aligns with aria-actions

<ZoeBijl> currently there needs to be some kind of DOM element

<ZoeBijl> that you can use to ?? that element

<ZoeBijl> might difficult because there is no visible DOM element to use

<ZoeBijl> and AT sniffing

<ZoeBijl> is there some way that we can bind ?? to actiosn?

<ZoeBijl> to Alice’s point

<ZoeBijl> scorlling to show some UI is not a ?? pattern

<ZoeBijl> i image a voice control user going “scroll left” to show the menu

<ZoeBijl> i don’t think that's a good pattern

<ZoeBijl> i hope we can do better

<ZoeBijl> AB: in my example it wasn’t a toolbar

<ZoeBijl> JT: ??

<ZoeBijl> we have to be careful

<ZoeBijl> that scrolling is not a natural fit for destructive

<ZoeBijl> SH: you wouldn’t allow authors to do this via aria-actions

<ZoeBijl> ??

<ZoeBijl> but it wouldn’t be AT sniffing because ??

<ZoeBijl> that could in theory autmated a scroll actions

<ZoeBijl> JT: and then it wouldn’t be AT sniffing

<ZoeBijl> there’s precedence for that

<ZoeBijl> we emulated key presses to avoid AT sniffing

<dbaron> (SH talking about browser implicitly wiring something up to aria-actions)

<ZoeBijl> SH: not saying that’s the best solutions

<ZoeBijl> but i do think that actions would be possible to use

<ZoeBijl> noamr: another example is native apps where you scroll between different parts of the app

<ZoeBijl> like scroll snapping

<ZoeBijl> scrolling through the tabs

<ZoeBijl> it feels more like scroll to activate

<ZoeBijl> VY: David do you want any clarification

<ZoeBijl> or feedback in the future?

<ZoeBijl> DB: i can follow up individually

<ZoeBijl> the one other thing is

<ZoeBijl> to alice’s point one of the things about the photos example

<ZoeBijl> one of the pieces is

<ZoeBijl> there’s two things

<ZoeBijl> one is scrolling

<ZoeBijl> and the other is it’s changing the URL

<ZoeBijl> which is different from just scrolling

<ZoeBijl> thank you all for the feedback

<ZoeBijl> feel free to file issues on the repo

<ZoeBijl> WICG/declarative-partial-updates

<Jem> siri

<noamr> Could someone post a link for aria actions? PR or something else?

<Jamie> aria-actions PR: w3c/aria#1805

<ZoeBijl> take up next item

<sarah> aria-actions issue as well: w3c/aria#1440

process discussion with W3C

<ZoeBijl> BZ: hello everyone

<ZoeBijl> like most newly ellected people i’m excited to make some changes

<ZoeBijl> i hope to make the process document a bit more readable and accessible

<ZoeBijl> right now it’s very long and very dry

<ZoeBijl> very technical

<ZoeBijl> written like your internal lawyer is supposed to be reading it

<ZoeBijl> while the AB has some ideas

<ZoeBijl> we want feedback from WGs

<ZoeBijl> you are the ones working with it

<ZoeBijl> as you move docuemtns through the process

<ZoeBijl> my hope is to get a dump from anyone that has anything to say

<ZoeBijl> *asked to stop scribing*

<daniel-mac> s/tooling aspect/the tooling aspect/

<Zakim> daniel-mac, you wanted to mention tooling aspec

<ZoeBijl> related document: https://www.w3.org/policies/process/

<ZoeBijl> *lunch time!*

<Adam_Page> Matt_King: I thought customizeable select did get mapped to combo box role?

<Adam_Page> sarah: is that true on all platforms?

<Adam_Page> jarhar: I’m working on follow-up

<ZoeBijl> take up item 4

Updates from Open UI, Part 4

<Adam_Page> ... for <select> element, when you put `size` or `multuiple` attribute, it changes role to `listbox`

<Adam_Page> ... so you can roll your own combo box

<Adam_Page> Matt_King: that’s already the case for the normal <select> if size = 1

<Adam_Page> ... it’s mapped to combo box

<Adam_Page> jcraig: follow-on from jarhar

<Adam_Page> ... what native control is going to get built that will actually be customizable

<Adam_Page> ... using Hilton recent searches example

<Adam_Page> ... a list with multiple actions

<Adam_Page> ... and headings inside

<Adam_Page> ... presumably some sort of filtering algorithm

<Adam_Page> sarah: there is a proposal for that

<Adam_Page> jcraig: that would be author-specified?

<Adam_Page> jarhar: check out the explainer

<Adam_Page> jcraig: anne should be involved

<Adam_Page> jarhar: haven’t brought to WHATWG yet

<Adam_Page> jcraig: you can’t stop progress; openUI features need to be accommodated

<Zakim> jcraig, you wanted to ask about the actual filtering

<Zakim> Jamie, you wanted to ask how OpenUI combobox would be different to input datalist, are we duplicating here?

<Adam_Page> Jamie: confused between openUI combobox vs datalist proposal

<Adam_Page> sarah: 2 proposals

<Adam_Page> Jamie: don’t they solve the same problem?

<Adam_Page> jamesn: people will want to be able to do both

<Adam_Page> Jamie: I need to understand that better

<Adam_Page> sarah: for the datalist combobox, the options exist on the page

<Adam_Page> ... for the ability to put an input into the <select> the input exists in the popup

<Adam_Page> sarah: search boxes should not be combo boxes, according to my UX research

focusgroup

<Adam_Page> ... let’s move on

<Adam_Page> ... focusgroup

<ZoeBijl> https://gist.github.com/smhigley/d370d79e52015cb011685f2cf8b80eca

<Adam_Page> sarah: Jacques did a great thing

<Adam_Page> ... forces authors to choose what type of focusgroup it is

<Adam_Page> ... set list of tokens

<Adam_Page> ... read the gist

<Adam_Page> ... toolbar, tablist, radiogroup, listbox, menu, menubar, grid

<Adam_Page> ... all but grid are linear

<Adam_Page> ... don’t have to guess what people intended; they’re forced to choose from this set

<Adam_Page> ... more likely to get it right this way than building their own

<Adam_Page> All: bravo!

<Adam_Page> sarah: can also specify: orientation, wrapping

<Adam_Page> ... memory

<Adam_Page> ... memory would be optional

<Adam_Page> ... (returning focus to last focused thing in focusgroup, a la radio group)

<Adam_Page> ... and descendants of focus group may declaratively opt out of being part of focusgroup

<Adam_Page> ... e.g., rich stuff

<Adam_Page> ... that has inner buttons, like a chat list

<Adam_Page> ... inner buttons should not be part of focus group

<Adam_Page> ... focusable descendants may opt out

<Adam_Page> ZoeBijl: example?

<Adam_Page> sarah: chat list

<Adam_Page> ... of messages

<Adam_Page> ... messages can contain focusable children

<Adam_Page> jcraig: this will be very difficult to make work

<Adam_Page> sarah: tabindex higher than 0 is ignored

<Adam_Page> jcraig: treated like 0?

<Adam_Page> Jacques: yes

<Adam_Page> s/ia higher than 0/higher than 0 is ignored/

<Adam_Page> Jacques: if you can’t typically tab to a button, focusgroup shouldn’t be able to manage

<Adam_Page> sarah: focusgroup has one tabbable item

<Adam_Page> Jamie: focusable descendants can opt out

<Zakim> Jamie, you wanted to ask how opting out impacts sequential focus order

<Adam_Page> ... when you cursor onto one of the focus group items, it does change the sequential focus order?

<Adam_Page> ... if there’s a focusgroup that contains 5 chatlist items

<Adam_Page> ... and you tab into that group and down arrow to 4

<Adam_Page> ... pressing tab should move to the descendants of 4, not 1

<Adam_Page> Jacques: yes, this is explicitly called out

<Adam_Page> ... as written, you will never skip content

<Adam_Page> Jamie: let’s say you have a list of 87 languages

<Adam_Page> ... each has buttons

<Adam_Page> ... and that means you have to tab a ton

<Adam_Page> jcraig: is there any scenario where a sibling of the item in the tabgroup?

<Adam_Page> sarah: there could be siblings

<Adam_Page> jcraig: any leaf node should be able to participate

<Adam_Page> Matt_King: how does the focusgroup know that the sibling is not part of the focusgroup

<Adam_Page> sarah: an author would put on an attribute to opt out

<Adam_Page> jcraig: does autofocus work

<Adam_Page> Jacques: for native elements, the browser will provide an escape mechanism

<Adam_Page> Matt_King: as a SR user, I never turn on full keyboard access

<Adam_Page> ... but I’d expect it to work in iOS and Safari

<Adam_Page> ... and I’ve noticed that Safari doesn’t seen to respond as I’d expect

<Adam_Page> ... with VO in Safari you have to tab through

<Adam_Page> sarah: tabbing on iOS doesn’t send keyboard events

<Adam_Page> ... or arrowing

<Adam_Page> ... it’s fully different

<Adam_Page> Jacques: let’s say an author had made this example with custom JS

<Adam_Page> ... a SR user could still focus and select and all normal SR operations

<Adam_Page> ... focusgroup doesn’t change that

<Adam_Page> jcraig: many intersections with other settings

<Adam_Page> Matt_King: is Safari on iOS ever going to work?

Adam_Page: Is there any interaction with autofocus update?

<Adam_Page> Jacques: haven’t considered autofocus

<Adam_Page> sarah: I imagine autofocus would act similarly to using virtual cursor

<jcraig> <containerized-item-in-focusgroup>

<jcraig> <button autofocus>

<jcraig> <button optout-whatever-as-if-it-were-a-focusable-child-of-the-first-button>

<jcraig> </containerized-item-in-focusgroup>

<Adam_Page> sarah: other things coming out

<Adam_Page> ... double-handled range input

<Jacques> Feel free to reach out to me for all your focusgroup thoughts!

<Adam_Page> ... toolbar element

<Adam_Page> ... and menubar / menulist

OpenUSD Accessibility API, <model> element, and other accessible format types like SVG+ARIA

jcraig: The main goal is to let you all know about another project that I've been working on with others

jcraig: This is beyond the current standards organization, but you are all welcome to join

jcraig: I also want to tie this into other types of content that has accessibility embedded

jcraig: This is the USD or universal scene description, format

jcraig: Things like SVG that can be loaded remotely. Even canvas, if we can figure out a way to make that accessible

jcraig: Apple, Pixar, and others are collaborating

jcraig: Pixar uses this in-house. You could, in theory, have a single USD that has an entire Pixar movie

jcraig: This was initially managed by the Academy Software organization

jcraig: It's since broken into AOUSD

jcraig: founders are Apple, Pixar, Adobe, Autodesk, and Nvidia

jcraig: Other players include Sony, Microsoft, and Meta

jcraig: There's a lot of movement behind this in the industry, but there hasn't been a lot of movement within the W3C

jcraig: As of earlier this year, there has been a version of the accessibility API in USD

jcraig: A pull request on Maya and Blender (digital sculpting apps) allowed both the label and description as part of the UI and write it into the USD format

jcraig: [shares an example of the AutoDesk source to add an accessibility string as a label]

jcraig: [shares an example to encode time samples]

jcraig: OpenUSD is at openusd.org

jcraig: I'll share a link to the Accessibility API

<jcraig> https://openusd.org/release/user_guides/schemas/usdUI/AccessibilityAPI.html

<jcraig> https://aousd.org

jcraig: The Alliance for OpenUSD:

<jcraig> https://usd-assets.needle.tools/full_assets/Teapot/Teapot/

jcraig: The Teapot demo that I'm reviewing ^

jcraig: There's a page where you can download things like a chess set, etc.

jcraig: This demo just uses JavaScript and "div" elements

jcraig: If anyone is familiar with MasterCar [sp?], they have this massive liibrary from which you can download

jcraig: The three properties for the accessibility API so far are: label, description, and priority

jcraig: The latter two are optional

jcraig: So, if the camera is in a virtual space, as you approach an item, its priority can increase or decrease

jcraig: Or perhaps the label of an alarm could read "red alert", and its priority could be adjusted based on proximity to the user

jcraig: There is some utility to having something like "role", but that is very much an open discussion

jcraig: The HTML "model" element is a proposal from Apple. I don't recall the state/interest in other browsers

jcraig: In this simple usage, there are two sources in different model formats. In this case, you might have an animated model that is a reaction to a message.

jcraig: The animated version of a gif could also be in there if the models didn't load

jcraig: Depending on the complexity of your model, you might want to have a video element as fallback content--which itself has its own fallback content

jcraig: This is the structure of the baseline of how HTML fallback content could be made accessible in simple and more complicated uses of the model element

jcraig: The end goal is for the "model" element to have its own accessibility tree

jcraig: All of the accessible alternatives behind "model" is the fallback content

<jcraig> https://github.com/immersive-web/model-element/blob/main/explainer.md

<jcraig> https://immersive-web.github.io/model-element/explainer_demo.html

jcraig: This is the demo explainer, above

jcraig: This is a demonstration of how the "model" element might be used within a webpage

jcraig: It simulates the user wearing a VR headset

jcraig: You'll note that the viewport for the model is not something that is floating in front of the page

jcraig: This is the view of how I would expect someone wearing a headset to work using this

Matt_King: What is the "model" element itself doing here? In my mind, an element is a static representation of something, but everything you're describing here is super-dynamic. Does the "model" element model the perspective?

jcraig: Right now, people are already loading models into web pages using "canvas" or similar

jcraig: The goal is to make loading models as easy as loading images with the "img" element

jcraig: You have a model authored in a number of software packages, and you don't want to write JS to load it. You can't make that work with canvas or other JS-controlled interfaces

jcraig: It's a way to easily load the model and offload work to the browser

Matt_King: Does the model contain the things that you can do with the model? Or is it a 360-degree equivalent of a 2D image?

jcraig: The examples that I'm using here are a fairly simple "teapot" model. There is a square on this page that has a viewpot for the model viewer, and there is a three-dimensional teapot inside

jcraig: That said, USD is quite robust. Pixar is using it in their tool chains

jcraig: The simple use-case will be simple, but in theory it can get much more complicated

Matt_King: It sounds like the model is a replacement for the HTML body iself

<jugglinmike> s/iselt/itself/

jcraig: Maybe more like an iframe

lucasradaelli: The model is not only for display purposes, but it's also interactable?

lucasradaelli: And do you expect a model that is in a webpage to have its own accessibility tree? It feels like it could be represented with just one node. Do you see it growing into a tree?

jcraig: It is already similar to a tree in that regard. I could label the spout individually from the teapot in this example, for example

jcraig: Although the interactive portions of this aren't there, we know that authors will figure out solutions for interactivity when they begin working with it

jcraig: Controllable sprites, interactive animations, etc.

jcraig: In theory, you could use one of these timeline-based models to hop back-and-forth within a timeline

jcraig: I expect those usages to become prevalent as this is deployed more widely

jcraig: Certain aspects could be generated on the fly. You could generate new models and switch them in based on user interaction

jcraig: The sky's the limit, and I couldn't anticipate them all

jamesn: For each obect in the model, there is an accessible name and description. When there are multiple objects in the model, how will we expose that interaction? How will people navigate through to get that information?

jcraig: In theory, the "drilling in", if its used in a timeline scenario, then it would be a passive operation

jcraig: It would be more of a user-agent decision, e.g. "when is it appropriate to mention the label?"

jamesn: sounds like there's a lot of opportunity for design here, still

jcraig: Yes. The sky's the limit in terms of what could potentially be done

front-endian-jane: Has there been any consideration for making this accessibility API portable to other formats? Or will it be specific to USD?

jcraig: I am not aware of other standards bodies that work on the other formats expressing interest in such a format

jcraig: I think a standard would be ideal, though

jcraig: The focus is on USD because the Academy Software Foundation is prioritizing accessibility. Pixar itself is a leader on accessibility. They are trying to push the boundaries in this regard

jcraig: I don't know what the IP implications are for that given that there are different standards bodies with different legal relationships.

front-endian-jane: How is USD licensed?

jcraig: Good question. I'm sure the details are on the USD's home page (which I shared above)

jcraig: As for next steps...

jcraig: Again, this is an open call for participation. I would love more reviewers within the W3C to look at the "model" element proposal

jcraig: I would love for people to install Safari Technical Preview and turn on these experiemental features

jcraig: There are a number of other model formats. SVG has accessibility. MathML does, too. I would love to see "canvas" join that group. And there are more

<lucasradaelli> canvas a11y is being worked on

jcraig: I want to show an example of SVG (apologies for the dark subject matter)

jcraig: This SVG map has average lifespans in African countries

jcraig: I want to demo how this works with VoiceOver

jcraig: I'm going to walk through this SVG. It's a map of Africa with all of its countries

jcraig: There is a value key of different age ranges

jcraig: I'm jumping into a few countries

[jcraig's computer: "Tunisia", "Uganda", "Zambia", etc]

jcraig: I'm touching over the different ranges. This is accessible SVG. It works if you use the SVG element embedded directly in HTML source

jcraig: Right now, we don't support this if you load the SVG via the "img" element. It wouldn't be difficult to do so, but none of the other browsers have adopted the accessibility tree in the same way that WebKit has, so we haven't prioritized this work

Jamie: The capability is there in Gecko as I understand

jcraig: That's great! If there are two implementations, then we could move forward

cyns: It didn't work in Chrome as of six months ago

jcraig: It would be nice to have some kind of hint to the user that, "hey, in most scenarios, you might not want to delve into this, but if you wanted to, there is more information available here"

jcraig: Or you can get into the numerator and denominator within the square root of a MathML expression, etc.

jcraig: Thanks for your time! Join OpenUSD! Let's make interactive content more deeply interactive!

Purpose and priorities of the ARIA WG, including review of new web features?

Purpose and priorities of the ARIA WG, including review of new web features?

JamesN: When putting new ARIA features, they haven't landed well
… Browser implementations we can get, but AT is the challenging part
… Fixing bugs is a priority for AT
… Open discussion on where we should put our efforts
… Two major areas: testing (fixing some compatibility issues) and OpenUI features and support to either existing ARIA features or potentially adding new things in ARIA to better support OpenUI efforts
… We've also talked with the CSS Chair
… Ideally we can work ahead of the HR process to avoid accessibility issues
… When they have accessibility questions about a spec they'll bring them to us, details to be decided

spectranaut: There is a time when a specifications becomes an "official spec" of the CSS Working Group, that is FPWD. First CSS discusses the idea. Accessibility should be part of these discussions at that stage.

JamesN: Supporting other web features was discussed as well

spectranaut: This is a brainstorming session

Sarah: Is there any discussesion about what happens after CSS discuss with us?

JamesC: We also shouldn't do the inverse, we should consider what we put as blocking issues

<Zakim> Jamie, you wanted to talk about CSS AAM and how its lack contributed to the CSS anchor positioning fiasco

JamesT: Situations where browsers ship things that are not wanted. We still don't have a mechanism to talk about CSS mappings in HTML-AAM. Maybe we should try with a tiny little CSS feature to see what kind of a process we could implement

JamesN: Nobody has done it. Would be good to try this out

JamesN: Maybe a PR under html-aam

<bkardell> why is it just editor tbd https://w3c.github.io/css-aam/

<Zakim> ZoeBijl, you wanted to ask why CSS-AAM hasn’t happened, what are the pain points?

ZoeBijl: What is the next action point?

JamesN: Originally that was a CSS-AAM, but we couldn't find editors

ZoeBijl: I'd be interested, just not sure what the first action would be

spectranaut: We can figure this out
… HTML-AAM editors are quite busy, if someone else wants to try CSS-AAM, then we could figure this out

<bkardell> But is it actually possible to create a totally independent CSS-AAM? Would it inevitably end up somehow intertwined with the other AAMs?

ZoeBijl: Happy to start the setup work

JamesT: CSS custom highlights is something we could start with

JAmesC: Not sure. There is specific platform APIs. There are aspects where the information is already on the CSS spec, wouldn't want to duplicate info

JamesT: Also wondering what the responsibilities are about the accessibility of CSS features

spectranaut: Are you saying that in the CSS specs there is already info?

JamesC: There is info about accessibility of specific features. Alt text for generated content being an example
… There is value to having that info in the main spec
… Otherwise we risk getting silos

JamesT: Then it would be their responsibility and we should provide feedback on time

JamesC: Some hard problems need to be in an AAM still

JamesN: It's similar with HTML

JamesT: Specific mappings should still probably go in the AAM

JamesC: We shouldn't duplicate, that's my main point

<Zakim> jcraig, you wanted to ask if our primary goal for this meeting is to decide future priorities, or decide what ARIA WG is going to propose to APA on Thursday re: what is currently THEIR horizontal review process.

JamesC: New APA HR process -- When the PRFWG split, we had a joint meeting with this group on Thursday, would be good to have a position

JamesN: We'd provide input becauase we also have expertise on browser APIs

JamesC: Would this be a joint WG process then?

JamesN: It's not really quite the same, different groups have different perspectives

JamesC: I gave feedback in the past and some stuff ended up in the CSS anyways

Spectranaut: We are brainstorming for now. We cannot talk about this as a formal process yet, rather as an experiment for how we could be doing things in the future

JamesC: If we spin up a new process, it may be difficult to know who to ask for accessibility review

JamesC: Is the scope intended to be CSS+ARIA?

spectranaut: Yes, probably there are other areas

Cynthia: APA was asking for help, we could funnel some of our expertise into their group
… ~~Maybe it's time to unsplit the groups~~
… Interested how the reordering impacts accessibility
… Handling incubation well is key as well

JamesN: I don't think we have the bandwidth to do that, we should limit us to things that are likely to happen

Cynthia: Something may be done with templating

JamesN: FAST?

Cynthia: That you need to "look for". I am thinking more like a push model rather than a pull model

Spectranaut: This is probably more for W3C Process itself

Sarah: This is gotten better in OpenUI, there are people now working together, we may need the same for CSS
… But these people need to be familiar with terminology and have technical expertise

JamesC: There are people in the CSS Working Group that know about accessibility
… Participating in the github threads is also helpful
… What's the most efficient way to manage feedback from subjectmatter experts is the thing we should get clarity about

ZoeBijl: Earlier review may solve it

JamesC: Maybe it's a list of all the people within our group collecting expertise. There might be surprising ones, and we need to know in order to assign the right people

<bkardell> Just want to note that its possible sometimes what you think is negative feedback maybe doesn't sound negative enough to cause the brakes to be hit too

MattK: This is very reactive. I wonder about the proactive side of things. I think the testing space is where we could do more of this. Catching up with all of the work that was done before 2014. Have you brainstormed some ideas about how we could approach testing?
… Most importantly, things that still don't work in the real world. This goes for implicit ARIA as well

<Zakim> cyns, you wanted to ask if CSS has an a11y task force? should it?

<Zakim> Jamie, you wanted to comment on CSS approaching us

JamesT: Agree with James that this is more a process thing. But sometimes thre was discussion but features ship without accessibility

<Zakim> jcraig, you wanted to suggest, related to Matt's WPT topic, that the CSS spec editor start with basic WPT Accessibility Tests like: this layout change does not cause the element to become entirely hidden or crash the accessibility runtime. and to say… or to document some base level process requirements like baseline accessibility tests

JamesT: Standards position -- Getting more involvement as a browser vendor with accessibility perspectives may help move this forward
… There are labels we could use for this
… I am trying for us to push harder on this

JamesC: WPT could be used to test some baseline accessibility features of CSS, even before they request for feedback

<alice> Will it be possible to check for ignored status of accessibility nodes in the bag of properties API? I seem to recall that being an open question last time I looked

JamesC: This could be extended for any new feature

Alice: Is it possible to test all ignored accessibility nodes?

JamesT: Ignored is something not specifically well defined across APIs

JamesT: We'd want some way to expose anything that's in the tree through WPT
… If we could make it consistent we should

JamesC: Something is rendered, I think Geko exposes it but has a hidden property

JamesT: Not anymore

JamesT: We should test as much as possible

Sarah: Suggested process for figuring out what needs to come to ARIA. Is this talked with the Chairs?

Spectranaut: They have accessibility specifics

Sarah: We could use GitHub queries for this

MattK: We have all these different testing projects that we talked about. Most of that was FYI, we need to generate next steps. In the case of ARIA-AT we do have next steps for the CG status and where to go

Spectranaut: Should be continued in the ARIA WG meetings

<Zakim> alice, you wanted to talk about the need to sometimes tell CSSWG no (both "no, you can't do this feature" but also "no, this problem is not well defined enough for us to opine on")

Alice: We should give clear guidance in reviews about what are the work expectations and how to prevent failures

daniel-mac: The rechartering process is going to have to start early next year

daniel-mac: that's the perfect timing for that

daniel-mac: There's still a joint meeting on Friday, but I don't expect we will get into that on Friday

daniel-mac: So plus 1 to that, but I think it's more about starting a "reach out" conversation at this point

Daniel: ARIA-AT is more a rechartering conversation I think based on how these meetings have gone

House Keeping

Spectranaut: 5:30 -- 6:30 there are three accessibility breakout sessions, and there are others throughout the day
… Look at the rest of the sessions
… On Thursday there is a joint meeting with APA

JamesC: Should we split to have coverage on these three?

Spetranaut: Friday morning we have a joint meeting with AGWG

Spectranaut: Feel free to have conversations and sue the available time on Thursday and Friday

<jcraig> Media and Entertainment Interest Group, Timed Text Working Group, Accessible Platform Architectures WG joint meeting https://www.w3.org/events/meetings/77e2d0cf-aa11-434e-bb56-fa303759ff4d/