Meeting minutes
Update from Open UI, Part 2
SH: one of the things being incubated by OpenUI is interest invokers
… there’s a new interest event
… or declaritively for JS
… the really cool part is that ??
… right now the way you do hover cards etc
… usually when you use your mouse to hover
… this is done with hover and focus events
… and this doesn’t work for everyone
… with interest invokers we have specific events for this
… this means you can in theroy you can make this work for voice control
… by having VC use a custom command
… ??
… lots of possibilities to make this accessibility
… browsers provide the interest event
… devs will have to use that to make the UI functional
… Scott and I have been providing feedback in the group
… but we would like further feedback from the group
… *starts slides*
… open questions
… 1. Does the aria-details for desktops SRs? Compare to aria-actions?
… 2. Should the ::interest-hint pseudo element be excluded from the accessibility tree?
… 3. Voice control contacts?
… 4. Optional: touch access
LR: I want to clarify ??
… the plain ones would be when you have a popover with text content
… the other would be anything besides just text
… the way we implemented this
… with plain text there’s no aria-details
… we use aria-description
… with the other ones we ??
… the name stays the same
… you add an aria-description
… it’s quite nice because the SRs i tested speaks the name + the description and the relationship
… ?? my take would be that an event should happen
… one way to verify this would be to alt+tab and then alt+tab back into the window
… and then ??
… is this splitting that just chrome does?
SH: that is interesting
… i do want to mention that this is not just a relationship for popovers
… this event will fire even if it’s not a popover
… it’s a programmatic event, so you don’t know what it would do
… can you clarify ??
LR: yes
… the case i was describing was just interest for the popover
MF: if it’s not a popover you’re on your own
SH: this is about ?? interest
… what is the mechanism for idnicating interest
LR: so not declaritive?
SH: not neccesarily
… it could be both
… this is more about specifically about this being a new event
… it’s about how do you trigger that event
LR: i agree that from a semantics perspective this should be implemented
… from aria-details, from a SR user persepective, needs some tweaking
… maybe a good outcome from the discussion could be ??
… this is an informal survey of users
… what is the shortcut of going to aria-details
… and nobody knew
JT: for declaritive…
… we have aria-expanded
… it will, or should, fire an event
… when an interst target appears or disappears
… and it also declares aria-details
… your interest is in regard ??
… in which case you would have to ecplicitly set aria-details?
SH: my question is more about how you explicitly trigger interest
… for example if you’re in browse mode
JT: couple of things
… 1. AT sniffing
… 2. i’m not following using the aria-details mechanism
… it’s not an action, it’s a query
… ??
… but even if there were asking for the details relationship, it’s not interest, it’s a programmatic query
… an action might be acceptable
<Zakim> Jamie, you wanted to clarify interestfor vs custom interest events
MK: the way you’re talking about this
… it sounds liek there’s a difference from someone looking at the accessibility tree
… and at an event
… is that correct?
… is that necessary
… i forget if interestfor is limited to popovers?
MF: no
SH: There is a proposal for 2 dimensional select, but there's less consensus on that
… and everything else
… interestfor=popover
MF: essentially there’s only delcaritive ?? attribute
SH: there is the event right?
… that you can listen to?
MF: yea
JT: but the browser won’t trigger it?
… so neither should AT?
SH: oh i thought it would trigger it
MF: no there’s no interest event
… there’s no API
LR: can you clarify what feedback you want?
SH: essentially…
… interestfor pointing at a popover or other elements
… i assume we want the method of indicating interest to be the same between those events
MK: do you mean in the accessibility tree?
… do you mean authors or users?
SH: i mean users
LR: one idea i once had
… right now the aria-details relationship only happens when the intrest target is shown
… what would happen
… the first thing people would say is we can't expose the details relation because the target isn't in the accessibility tree
… could we indicate in the element that there is more content?
… maybe using aria-expanded and collaps?
SH: the problem with that is that you could have interst on an element that has aria-expanded
… say you have an accordian header
… aria-expanded would be for the content, but the interest could be for a separate tooltip
MK: the SR user could request the actions
… which sets focus
… with focus there the actions get exposed
… that’s how we get around the sniffing concern
… but in this case…
… couldn’t you do the same thing with…
SH: you could
MK: you do have a problem in the ations page
… the thing we didn’t address
… stuff that’s not focusable
… does it need to be focusable?
MF,SH: yes
… buttons and links
MK: ??
… ask the AT to set focus?
SH: i think aria-actiosn would work
MK: wondering if we have the same AT requirements
… or would that cause issues for SR users?
siri: you said whenever you hover it shows
SH: yes
siri: the issue i see
… ??
SH: that’s definitely an example
… on wikipedia you get previous if you hover over articles you get a preview
… same with social media
… if you hover a username you could get a preview of the profile
siri: most of the time we’re talk about SR users
… what about voice control users?
SH: that’s the third question on the list
::interst-hit pseudo element
SH: it’s part of the button or link you want interest for
… we discussed this in OpenUI
… my proposal was to not have this in the accessibiltiy tree if we do this with specific AT fucntions (??)
… it would be a pointer target
JC: it would be a pointer target
… so you can click it?
… but you wouldn’t expect an event on it
SH: yes
… but it wouldn’t prevent you from adding it
… i wouldn’t expect AT to have to interact with it
JC: didn’t we talk about this for aria-actions?
… ??
… i would expect that would be the way to invoke it
SH: it’s not just there as a way to show interest
… the element that has `interestfor` still shows the popover/associated element
… so show on focus will already happen
MK: you said that the author could indicate the availability for `interestfor`
… does that mean that the browser is in reposonse to attribute is automatically showing something next to the element
… that’s a tab target?
SH: yes
… the presentation would depent on how you style it
MK: so the author is providing that element in CSS?
SH: yes
… it would be a CSS pseudo element?
MK: and it would appear when?
JT: always visible
MF: with the `content` property or something
MK: that presents a problem with WCAG probably
… having two targets so close to eachotehr
… ??
SH: yea voice control and screen readers would be the two relevant ones
MK: ??
SH: that’s also the other reason i think it shouldn’t be exposed
… the use case driving this
… you can expose this with ??
… and that means if you’re using a SR sometimes there might be an extra button for something that has interest
… and sometimes there isn’t
MF: i think it’s important to remember that it’s auxillary
<jamesn> ... ack jcraig
<Zakim> jcraig, you wanted to ask edge cases about invoking events and delays
JC: iOS has a “two tab” behaviour
… specifically on iPad where you have desktop sites
… say a fly out menu
… the two tap will essentially trigger the hover event
… allowing the flyout menu to show
… most of the concerns or open issues
… are related to the mainstream interface
… i’m just trying to pass these along
… there’s no real concern
… the ??
… the descoverability of long press has been logn been discussed
… it’s useful for lots of things
… there was another one that may be dismissed
… there was long, medium, short keyboard delays
… these seem to be gone?
MF: yea these are gone
… it’s no times
… the keywords are gone
… times are there
JC: ah ok
MF: there is an explicit thing in there for user agent overrides
JC: the other thing that hasn’t been fully considered are things like the Apple Vision Pro situation or tmaybe meta glasses
… i think that’s it
… don’t need a response right now
… just so you can think about it
SH: thank you
… yes i want to talk about that with you jamie and maybe matt
… *jokes about having interest for the topic*
*discussion about another meeting*
<Jacques> This is the whatwg schedule: whatwg/
Menu Element
DF: hi
… one of the things we’ve been working on in the OpenUI is menus
… the word menu is brutally overloaded
… we specifically talking about system menus
… like those found in operating systems
… but also web applications
… a word processor for example
… the point of this presentation is to make everyone aware of the proposal
… and have discussion about the accessibility considerations
… the motivation is that this is a common pattern on the web
… we did a survey on n sites
… the wya to trigger these is ??
… hovering works universally
… but keyboard and clicking are sparse
… activating items works mostly with click and keyboard
… but not universally so
… also looping
… so using arrow keys to move between menus and submenus
… implementations vary
… there are a bunch of other weird behaviours
… such as `Tab`
… support varies wildly
… we have a lot of interesting proposals
… such as the Popover API
… *shows test page*
… this is all keyboard navigation
… we have (exclusivity) checkable menu items
… this whole thing is using prototype ??, no JavaScript
… the code is pretty simple
… we have a new `menubar` element
… and `menuitem`
… and `menulist`
… you can make radio menu items with a `fieldset`
… we started by kicking up dust and tryign to handle everything
… 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.
DF: especially with regards to accessibility
… this resulted in us splitting off navigation bars
… which would be a `navigationbar` element
… thank you to all the accessibility people for being patient with us
… Sarah, Scott, other people in the room, and probably others!
… this means we can focus on menubar
LR: when you showed the example you said the `menubar` has `menuitem` in it
… shouldn’t it have `menulist` and then `menuitem`?
DF: the `menubar` first has `menuitem` and these then invoke the `menulist`
… the basic high level thing here is that we have native ARIA role mapping
… `menubar` to `menubar`
… `menulist` to `menu`
… `menuitem` to `menuitem`
… we also have a bunch of discussion around `aria-expanded`, `aria-checked`, and `aria-disabled`
… we were landing on the behaviour of `<menuitem disabled>` has `aria-disabled=true`
… to make them “soft disabled”
… we also discussed `aria-owns`
… and how we shoudl expose the hiarchy
… in the DOM we don’t nest `menulist` inside `menuitem`
… those are siblings
… should they be siblings in the accessibility tree?
… or should they represent the visiaul hiarchy with `aria-owns`
… it was suggested to keep them as siblings
… a big part of this is keyboard support
… ???
… the other thing is orientation
… horizontal/verticle
… which could use `aria-orientation`
… ~Fin~
… let’s open up the floor
Rahim: thank you for the presentation
… question around the implementation like mega menus
… one common pattern that i come across a lot
… if you have a menu
… really you have a trigger to toggle the menu
… sometimes they marked as menus
… sometimes are details
DF: good question
… all design items that would support a mega menu
… everything would go into the `menulist` (??)
… all the difficulty around mega menus is around ??
… i like to think we kinda support it out of the box
ZB: wouldn’t that be more for the `navigationbar` element?
DF: yea ??
… 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
JT: some quick points
… have there been consideration for accesskey
MK: if you type “RE” in a menu it will go to the menuitem that starts with that
JT: do menu items name their submenu? like the menu item "file" should name the submenu that is opened ??
… because it probably should
… i dropped a comment on the aria-owns issue
… i can link to it
… i’m concerned about people doing wacky stuff like sticking iframes, headings, and whatever in menuitems
… 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
JT: we should looka t ocntent model restrictions
JN: in aria we struggle from people using this for navigation menus
<Jamie> My comment regarding aria-owns and tree reparenting: openui/
DF: we knew that people would
… so we want it to work for that from the start
… which led ius to the `navigationbar` proposal
… we hope this will lead to accessible situations
MF: ??
DF: one example is
… for restricting cotnent
… display none on nested links
LR: first letter navigation
… this is how SR users navigate menus they arleady know about
… it’s minimising the number of keystrokes
… second
… you talked about menu types
… like checkbox and radiobutton
… example from google docs
… is alt+/
… you type the menu item you think you know
… and it’ll show where that is
DF: we have an issue open about this
… filterable menu item on top
… there are problems around getting fuzzy search etc just right
MK: three things
… content model stuff that Jamie mentioned
… in the proposal
… are there restrictions on what can be in a menu item
DF: it’s not resolved yet
… we don’t want nested interactive content
… we expect most things to be in menuitems (??)
MK: i see a lot of things that doesn’t fit within the current ARIA menu roles
… putting things like headings in menus
… normally the way around that
… the popover would include
… headings
… it would become a dialog
SH: comments about the type to navigate
… reminded me of select too
… i wanted to make a note that we may want the same behaviour for ??
… i can open an issue about that
… considering them both at once might be relevant
… so developer preferred type ????
*break time till 11:10*
<ZoeBijl> GitHub: w3c/
<dbaron> github: w3c/
snap-to-activate
DB: this is maybe a slighjtly different stage of presenting something
… this is pretty early in the design process
… if the feedback i get from the group today
… is “no you’re doing it completely wrong”
… that ok, this is the right time
… alternative proposals are good at this point
… i want to show some examples
<spectranaut_> a link to the explainer: https://
DB: i don’t want to limit the discussion around the questions
… but i have some questions
… we’re trying to look at building at better gesture driven interface
… it’s fairly common on touch devices where swiping to the side does something
… might be navigating to some other part of the UI
… might be ??
… some example, in order of increasing complexity
… i’ll start with the simpler examples
… one of the simpler examples
… i took most of these from android
… in the photos app on android, if you swipe to the side, you go to the next photo
… if you swipe in the opposite way you go back
… it’s not destructive
… if you do this on the web, you probably expect the URL to change
… on the web this would be a page change in a SPA
… this is the maps app
… i want to see the previous or next traim
<Jamie> s/from Android/from native Android apps/
DB: i can swipe to the sides to do that
… the UI is complicated
… but it’s the google maps app
… where you selected a particular subway station
… and a direction to go
… you’ve chosen a train
… and it shows you a time when the train will leave and when it will arrive
… and if you swipe to side it will show the next train
… it’s kinda like navigating the photos
… but the UI is more complicated
… a slightly more complex action is pull to refresh
… i took this from a web interface
… if you pull down it shows a little error and then a little loading icon
… it will fetch and display new content if any
… it’s a bit more destructive
… requires a bit more care
… the final example is a bit similar
… in concerns anyway
… this is the UI for Gmail on Android
… showing a list of messages
… if you swipe to the side it shows actions for the message
… like delete, archive, move, etc
… this again is even more destructive in action
… i’m of the thinking here that a bunch of these things involve things that are scrollable
… scroll-snapping in CSS
… but how do we hook up ?? to something
… to scroll-snapping
… ??
… a bunch of them are not going to work
… some that seem not dissaturous so far
… the ability to snap to a particular place
… to a button or link elsewhere in your UI
… this has some advantages
… these gesture driven UIs
… are not necessarily the most discoverable
… if there is alternative UI to these gestures, which is not uncommon
… that maybe eleviate some problems with it
… but at the same time we do want the gesture driven UI to be discoverable and accessible as well
… one idea that we have floating
… the things you interact with ??
… and snapping with to ?? activates the button over there
… one question about this
… does this ?? the accessibility at all?
… i’m not asserting that it does
… i’m asking the question
… could we be thinking about the accessibility differently than we are
… another questions
… my understanding about this UI
… there are various ways AT can make announcements about the availability of these things
… if we take an approach like this
… how should the mechanisms like this be ??
… distributed between ?? and AT
… how much can build into the browser engine
… those are some of the questions i have
… at this point i’m mostly interested in…
… feedback both about whether this sorta basic idea of mapping to activate another thing is horrible
… and to the questions i have
LR: all the examples you gave
… and some of the ideas of the solutions
… are of the higher level
… in here’s an action and here’s a ??
… it feels like it was very abstract
… as a user
… when you’re describing the use cases
… the best example we have is voice over with the actions rotor
… VO for iOS/iPadOS has the actions rotor
… authors can create this idea that there are actions for elements
… my question is
… why a possible solution couldn’t involve a semantic pairing
… if the solution couldn’t be one step higher in the hiarchy
DB: i think it’s clear
… some of the questions that’s
… it’s sort of a larger solution
… that isn’t just about this space
… it seems some of the questions
… it’s an interesting thing to think about
… how it fits in with other pieces of work
<Zakim> alice, you wanted to ask about the distinction between non-destructive and destructive actions
AB: i thought that the distinction you made between non-destructive and desctructive actions was interesting
… the first just looked like a scroll
… same with the train example
… the ones you described as destructable look like actions
… the pull to refresh is like activating a button
… it activates a button to delete and then repopulate
… i wonder if those actions need a specific solutions
… scolling is just scrolling
… but those actions are destructive
… and i was wondering if SR users are interacting with those more destructive actions
… like the pull down to reefresh
MK: the pull down to refresh is the same for SR users
… the equivalant action in most native actions
… is the scroll down gesture
AB: and you get an announcement of what will happen
MK: if there is it’s normally done by the app
… i guess similar to sighter users, you learn about it the usual way
… word of mouth
… or how ever people learn about this…
MF: on touch interface it’s reversable
… you can cancel the actions
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
JT: wanted to echo some of what Lucas was saying
… some of this aligns with aria-actions
… currently there needs to be some kind of DOM element
… that you can use to ?? that element
… might difficult because there is no visible DOM element to use
… and AT sniffing
… is there some way that we can bind ?? to actiosn?
… to Alice’s point
… scorlling to show some UI is not a ?? pattern
… i image a voice control user going “scroll left” to show the menu
… i don’t think that's a good pattern
… i hope we can do better
AB: in my example it wasn’t a toolbar
JT: ??
… we have to be careful
… that scrolling is not a natural fit for destructive
SH: you wouldn’t allow authors to do this via aria-actions
… ??
… but it wouldn’t be AT sniffing because ??
… that could in theory autmated a scroll actions
JT: and then it wouldn’t be AT sniffing
… there’s precedence for that
… we emulated key presses to avoid AT sniffing
<dbaron> (SH talking about browser implicitly wiring something up to aria-actions)
SH: not saying that’s the best solutions
… but i do think that actions would be possible to use
noamr: another example is native apps where you scroll between different parts of the app
… like scroll snapping
… scrolling through the tabs
… it feels more like scroll to activate
VY: David do you want any clarification
… or feedback in the future?
DB: i can follow up individually
… the one other thing is
… to alice’s point one of the things about the photos example
… one of the pieces is
… there’s two things
… one is scrolling
… and the other is it’s changing the URL
… which is different from just scrolling
… thank you all for the feedback
… feel free to file issues on the repo
… WICG/
<Jem> siri
<noamr> Could someone post a link for aria actions? PR or something else?
<Jamie> aria-actions PR: w3c/
<sarah> aria-actions issue as well: w3c/
process discussion with W3C
BZ: hello everyone
… like most newly ellected people i’m excited to make some changes
… i hope to make the process document a bit more readable and accessible
… right now it’s very long and very dry
… very technical
… written like your internal lawyer is supposed to be reading it
… while the AB has some ideas
… we want feedback from WGs
… you are the ones working with it
… as you move docuemtns through the process
… my hope is to get a dump from anyone that has anything to say
*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://
*lunch time!*
*introductions*
Updates from Open UI, Part 3
SH: continuing from earlier today
*emphatically closes door*
SH: next item from openui is
… styleable select updates
… we talked about this last year
<Jacques> ... Is the room intended to be muted?
SH: it’s the same element
… but you use the new version with styleable children
… we won’t talk about the base control
… but there are new controls
… there has been discussion
… with styles you can change more than you can with a list
… what happens with orientation changes
… for arrow key navigation for example
… could it be a grid?
… with 2D arrowing
… don’t know if we get into that today
… but please comment on the issue
… i want opinions on the arrowing based on the orientation
… or allowing authors to choose a horizontal orientation
… because authors will do that
GitHub: w3c/
MK: these things are pretty much always guaranteed to wrap
… i mean the visual presentation
… if you have a horizontal control
… would it wrap?
SH: not necessarily
… it might scroll
GitHub: w3c/
SH: author’s CSS would dicate this behaviour
… the proposal is for authors to switch from vertical to horizontal
MK: ??
… what if they would do both
… would it be up to the author to say both orientations do the same thing?
SH: my question is to switch orientation to match what people do with this control
JT: i don’t see an issue with question 1
… for question 2
… should we change the keyboard orientation
… ??
… aria-orientation keyboard support is sparse
… but let’s assume it will be at some point
… i’m making an assumption without backing
… but i assume most users will use up|down regardless of orientation
SH: i don’t think there is the equivalant now in the base control
JC: and LTR and RTL
<Zakim> cyns, you wanted to ask if these are ever 2D?
CS: just wondering if these might ever be 2 dimensional
… whenever i encouter that in a control it makes me happy
SH: there isn't a lot of consensus for 2d, but there is more consensus for horizontal select
JT: we shouldn’t do the keyboard thing then
CS: *something about a tree*
<lucasradaelli> what is the command to enter in the queue?
JF: i’ve come across plenty of 2D selects
… it would be appear to some users as only one column
MK: there is a solution to that
… you wrap at the bottom of the column
… that’ll allow you to always hit all items
JF: that can cause confusion with many items
*short discussion about colour and emoji pickers*
<Zakim> Jamie, you wanted to note that 2d select could be exposed as a grid instead of a listbox
JT: a 2D select we would probably expose the semantics differently
… maybe say table rather than list
… it would help solve it
MK: it would
SH: ??
MK: if it is possible to wrap a 2D…
… i think i agree with Jamie
… from a discoverability perspective a 2D ??
Joey: it seems like maybe it is the wrong type of primitive?
??
JN: it may be good…
… it would be good for discoverability to ??
SH: this is a thing we’ve run into for non-select grids
… people want to ??
… not everyone is happt about that all of the time
… i do think there’s a mechanism for us to ask authors if this is a declaritive ??
… if we think we can make grids/2D selects accessible
… i will make a non-TPAC issue
General agreement.
AP: for the select element the UI is presented
… the author can’t hijack the role?
… so the wrapper
SH: there is na internal toggle
… but no they can’t the popup at all
SH: ?2
… is the conclusion to built this into select?
… or should be a different element?
MK: wouldn’t it be simpler if its the same element?
SH: yea
JA: i thought some more about ??
… we should have this attribute (??)
… it’s a semantic thing that eblongs in the HTML
… but with auto and base appearance
… understanding saying there’s no native macOS popup that’s a grid
… so we can’t do this
… so i think the best way to do this is to not use select and make your own element
AP: i’m wondering if a third value like mixed or ?? proposed?
JN: it’s been proposed before
… i proposed it for a slider before
MK: a 2D slider
<jarhar> summary of what i was saying: i think that adding an HTML opt in to the select element to make the picker a grid could be tough to get into HTML because the select element supports native appearance and base appearance, and i would expect the response from whatwg to be not to add it because native platforms like macos might not have a grid popup
<jarhar> for that native control
SH: my takeaway is: i will organise a aria issue to discuss arrowing through grid content that is represented as a list
… it could be applicable for styleable select
… for now tentative yes for arrow as a non replacing thing for aria-orientation=horizontal
*everyone laughs at scribe*
can editable combos using input + datalist be accessible outside of desktops?
SH: combos using input + datalist are problematic outside of desktop
… they don’t work well with VO
… often at least
JA: i’m trying to work on this in OpenUI
… it sounds concerning
… if you put a lot of effort into building a combo with ARIA
… does that work with VO?
SH: mostly no
… currently it works with VO and Chrome but not VO and Safari
MK: this is one of the more ambitious things i want to get into aria-at
JC: this goes to show why our automation efforts are so important
… gives us insight into how things regress over time
SH: is this something Apple wants to support
JC: certainly a combobox can be useful
… the general question of can it be accessible outside of Windows, sure
… but we should first look at how can it be useful
… we need implementations to understand of how it is expected to be used
JT: to clarify
<Zakim> Jamie, you wanted to clarify difference with current datalist, autocomplete, combobox, etc.
JT: i’m curious what is the change you’re proposing?
… currently you can type in it, and it will show suggestions
SH: ?3
JT: is there anything beond the open pickup?
SH: all the native experiences open basically a dialog
… but i assume we can hash out all these things to make it accesisble on keyboard
JT: ?4
SH: yes, and also more styleable and customiseable
JT: let’s talk more about that later
SH: let’s move on
<jarhar> here is the openui explainer for combobox: https://
Any concerns with out-of-the-box input within a dialog popup for select?
SH: this is about filterable selects
… i think this is a great idea
… and more usable than a combobox
JN: and it’s done all the time
… so it’s important to get it right
SH: agreed
… i think we should prioritise this over combobox
JC: so you’re talking about aria-actions on options to spport multiple clickables
AP: our combobox has items with a button to remove them
<Zakim> jamesn, you wanted to react to Jamie
sarah: the one thing we’d have to solve is the trigger would have to be both a form element with a value and a label
jarhar: yeah, not sure how to do that in HTML
sarah: even worse, because the role is different across platforms
Matt_King: I thought customizeable select did get mapped to combo box role?
sarah: is that true on all platforms?
jarhar: I’m working on follow-up
Updates from Open UI, Part 4
jarhar: for <select> element, when you put `size` or `multuiple` attribute, it changes role to `listbox`
… so you can roll your own combo box
Matt_King: that’s already the case for the normal <select> if size = 1
… it’s mapped to combo box
jcraig: follow-on from jarhar
… what native control is going to get built that will actually be customizable
… using Hilton recent searches example
… a list with multiple actions
… and headings inside
… presumably some sort of filtering algorithm
sarah: there is a proposal for that
jcraig: that would be author-specified?
jarhar: check out the explainer
jcraig: anne should be involved
jarhar: haven’t brought to WHATWG yet
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?
Jamie: confused between openUI combobox vs datalist proposal
sarah: 2 proposals
Jamie: don’t they solve the same problem?
jamesn: people will want to be able to do both
Jamie: I need to understand that better
sarah: for the datalist combobox, the options exist on the page
… for the ability to put an input into the <select> the input exists in the popup
sarah: search boxes should not be combo boxes, according to my UX research
focusgroup
sarah: let’s move on
… focusgroup
https://
sarah: Jacques did a great thing
… forces authors to choose what type of focusgroup it is
… set list of tokens
… read the gist
… toolbar, tablist, radiogroup, listbox, menu, menubar, grid
… all but grid are linear
… don’t have to guess what people intended; they’re forced to choose from this set
… more likely to get it right this way than building their own
All: bravo!
sarah: can also specify: orientation, wrapping
… memory
… memory would be optional
… (returning focus to last focused thing in focusgroup, a la radio group)
… and descendants of focus group may declaratively opt out of being part of focusgroup
… e.g., rich stuff
… that has inner buttons, like a chat list
… inner buttons should not be part of focus group
… focusable descendants may opt out
ZoeBijl: example?
sarah: chat list
… of messages
… messages can contain focusable children
jcraig: this will be very difficult to make work
sarah: tabindex higher than 0 is ignored
jcraig: treated like 0?
Jacques: yes
<Adam_Page> s/ia higher than 0/higher than 0 is ignored/
Jacques: if you can’t typically tab to a button, focusgroup shouldn’t be able to manage
sarah: focusgroup has one tabbable item
Jamie: focusable descendants can opt out
<Zakim> Jamie, you wanted to ask how opting out impacts sequential focus order
Jamie: when you cursor onto one of the focus group items, it does change the sequential focus order?
… if there’s a focusgroup that contains 5 chatlist items
… and you tab into that group and down arrow to 4
… pressing tab should move to the descendants of 4, not 1
Jacques: yes, this is explicitly called out
… as written, you will never skip content
Jamie: let’s say you have a list of 87 languages
… each has buttons
… and that means you have to tab a ton
jcraig: is there any scenario where a sibling of the item in the tabgroup?
sarah: there could be siblings
jcraig: any leaf node should be able to participate
Matt_King: how does the focusgroup know that the sibling is not part of the focusgroup
sarah: an author would put on an attribute to opt out
jcraig: does autofocus work
Jacques: for native elements, the browser will provide an escape mechanism
Matt_King: as a SR user, I never turn on full keyboard access
… but I’d expect it to work in iOS and Safari
… and I’ve noticed that Safari doesn’t seen to respond as I’d expect
… with VO in Safari you have to tab through
sarah: tabbing on iOS doesn’t send keyboard events
… or arrowing
… it’s fully different
Jacques: let’s say an author had made this example with custom JS
… a SR user could still focus and select and all normal SR operations
… focusgroup doesn’t change that
jcraig: many intersections with other settings
Matt_King: is Safari on iOS ever going to work?
Adam_Page: Is there any interaction with autofocus update?
Jacques: haven’t considered autofocus
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>
sarah: other things coming out
… double-handled range input
<Jacques> Feel free to reach out to me for all your focusgroup thoughts!
sarah: toolbar element
… 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://
<jcraig> https://
jcraig: The Alliance for OpenUSD:
<jcraig> https://
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://
<jcraig> https://
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?
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://
<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://