Meeting minutes
Update on ARIA-AT
[going over agenda]
MK: to start out with tomorrow at ten we have a breakout session about this very topic
boaz will be giving a presentation there
which will cover the bigger picture more
so if you’re interested in that go to the break out hall tomorrow at ten
let’s start with an introduction today
ARIA-AT, is aria + assistive technology
[zoom being annoying]
goal of the aria-at cg is to found a foundation
you’re going to think about platform tests
and normative requirements
essentially this is test driven development
instead of a set of known requirements
we first characterise what the world does
and then look at what AT do based on expectations
you’ll see a bit more what this means in practice later on
there might be some normative requirements based off of this work
really work from our discussion yesterday
we don’t want to reduce our competitive differentiation
if we have automated testing that can test all the defined baseline expectations
that’ll mean we don’t have to be afraid of breaking things
so obviously interop is intuivily understood by people in this room
for those people that test with screen readers
they have a real problem
they have no idea what the screen reader is supposed to do
they don’t know which sr to test with
they might test an alert and go “oh it doesn’t say alert, i’ll make it say alert”
now another sr might say “alert alert!”
[laughter]
people need some baseline expectations
that brings up this really important scope constraint
some part of our experiences, you can’t test them with all default settings
setting requirements should be clearly stated everywhere
the default experience is what we’re talking about
because i think most people use the default settings
more over people that build websites do so
our current focus in aria-at is that testing using the apg examples as our test cases
and we’re only testing on desktop sr right now
we know essentially that there are more people pulling their hair out over these experiences
currently only speech, not braille
terminology:
Test
Assertion
Assertion Priority
these all defined in aria-at
for each test we have a list of assertions
some are common across the tests
like the role is contained, basic things like that
[matt going over the glosary: https://
There are MUST, SHOULD, and MAY defined
site: https://
the homepage has basic information about the project
good reading for anyone that wants to get a bigger picture
our primary deliverable is the interop report
i mention alert a minute ago
i’ll go over the plan for alert
[showing jaws results]
all tests look to be passing
it’s a simple test plan
it has one action
but has eight assertions
jaws passed all of those
there are four optional test and those passed as well
let’s look at the actual test plan
there are multiple commands for triggering the command
there’s a button to open the test plan
the example is simple, you press a button and it triggers the alert
it’s a little contrived because in the real world the alert would most likely be trigger by something else
for pressing the space bar we have four assertions
the first one is a MUST and says “Convey text 'hello'”
the second one is also a must and reads “Other behaviors that create severe negative impacts are not exhibited”
the third one is a should and reads “Other behaviors that create moderate negative impacts are not exhibited”
the last one is a MAY and reads “Convey role 'alert'”
this is an example of a test plan
let’s look at toggle button
https://
notice in this one that apg example for the toggle button is also very simple
[going over test names]
MUST “Convey role 'toggle button'”
MUST “Convey name 'Mute'”
in this case “Convey state 'not pressed'” is a SHOULD
if it was pressed this would be a MUST
some AT will always announce the pressed state
this is an example of looking at what the default should be
this is the kind of stuff that, what would be the base level expectations
how do we define those now
and just like how we were talking about the whole tc39 thing yesterday
you might want to change the spec when you start testing
aardrian: i want to make sure that when you say AT you mean screen readers?
MK: we want to expand but yes for right now it’s only screen readers
aaronlev: shout out to a11ysupport.io
MK: their definition of what “supported” means is different
AT expectations for aria-actions
<sarah> https://
MK: the beginning part of Sarah’s gist is what we were talking about yesterday
one of the things that we want to align around is that there are essentially two high level expectations
sarah: the first part is browser requirements
[talking about authoring requirements]
there are two levels of screen reader support
the most basic one which is a must would be announcing the availability of actions
if you have like list of email where each email has “flag”, “read”, “other”
you wouldn’t list all of those actions for each item
it won’t read those names
that would be very repetitive
so screen readers should announce that actions exist
using whichever wording they desire
the second requirement is the announcing the number of actions
any interactive element with actions defined, there should be a way to pull up these actions
perhaps in a menu
getting the actions’ accessible names
and there’s a few markup examples in the gist
for that list of emails:
https://
if a user would press that menu they could choose from the actions
all the while focus would remain on the email
i have two open questions
1. Should screen readers sometimes expose actions defined on ancestor elements when focusing child elements?
2. Can nodes focused with aria-activedescendant support actions defined on them?
MK: on the first one i want to add
yesterday we talked
so however
that makes this first question really important
let’s imagine that you have an article in a feed or a cell in a grid
and the screen reader user is reading inside this article or cell
and in the container that item
but the user is reading content inside the container
would that sr user’s reading cursor, on the decending node
should the sr
read up the tree and find out if the nearest ancestor has actions?
we should define that algoritm if anything, clearly
Brett-Lewis: i have a couple things
announcing actions would only happen on focus?
sarah: yes
Brett-Lewis: if i’m in the buffer and i encounter a button
if i want the actions
i have to move up the tree to focus that ancestor with actions
that way you can announce there are actions
maybe an unanticipated consequence
the disconnect between the virtual buffer and the focus
glad you brought it up Matt
MK: you think that’s…
i mean if you were reading a big article
and in the middle
you want to report it the post
do you think it would be bad if you could report and then jumped back to where you were
Brett-Lewis: but what if you don’t activate the action
MK: i think you can program around that because you’re very smart!
[laughter]
you could remember where focus was
Brett-Lewis: that’s harder to do
Jamie: the triggering element should still exist
jcraig: maybe we digress
<Zakim> jcraig, you wanted to mention iOS VoiceOver's current ways to convey actions are a multiple select list of: speak, play sound, change pitch, braille, or do nothing." there are some additional options too. Default is speak + braille. and to suggest :focus-within https://
quick add-in
great points made
maybe what we could do and say is equivelant to css’ focus-within
so maybe not focus on the ancestor
but also when focus within the ancestor
by default voiceover on ios
will say “actions available”
also in braille
and the features available now
you can speak it
you can play a sound
adjust the label of the focusable
or braille it
or do nothing
those are examples
thank you for phrasing it in this way
sarah: i can add “play a sound” etc to our list potential approached
when you’re inside the referencing element
i would be more inclined to drop that for now
to not overcomplicate things for now
because it’s quite specific in scope
like video players
or being in cells
just because i don’t want to overcomplicate things
the focus-within thing is interesting
but it might conflict with things like aria-owns
i don’t know if i want to touch that
jcraig: focus-within wouldn’t work with an aria-owns relationship
MK: you could be reading inside a grid cell when the grid doesn't even have focus
sarah: and i don’t, i lean towards not making specs more complicating than that
aaronlev: so what i want to understand is that the brower engine would only have to expose aria-actions on the focused node
which would make things easier to implement
sarah: Jamie had ??
if you want to share that with me
Jamie: yea
sarah: i have two mappings
??
and the object attributes
that bucket of attributes
i put it in both
because jamie asked me if it was enough
github: w3c/
????
aaronlev: how much value is there to the user for not exposing actions ont he ??
MK: sarah and i talked about
making aria-actions “usable”
we’re not providing those relations until this thing is focusable
aaronlev: i’m ok with that
to indicate that actions are available
make sure there’s targetable ??
Jamie: it will be complicated with ???
jcraig: i think it’ll be ok
Jamie: if those elements are ??
then you into a whole bunch of problems
if the elements don’t have ids
alice: quote quote means that you set it via the idl?
from the browser side you have to check the ???
you have to check that nowhere in you’re ??
Jamie: it means that no where in your code you @@
jcraig: but does it matter?
the only time it differs when you’re not focused on it anyway
Jamie: haha, i’m possibly agreeing
MK: if it’s not resolved
but if it’s focused and not resolved ??
<Zakim> alice, you wanted to ask about name computation
alice: jamie commented he was also thinking about this
i was curious about your example
you have the tree item with all the buttons
how does that affect accname
sarah: there’s a pr against accname
which i made separate because of performance considerations
smockle: if every element with `:focus-within` had its actions exposed, then wouldn’t that bring back inherited actions, which we’d decided against yesterday?
<sarah> accName aria-actions PR: w3c/
would that bring back inherited actions
jcraig: i can explain
i keep hearing people say that
i was never of the opionion that we resolved inherited actions?
like scroll-grou-button
<Jem> Thanks for working on aria - actions, @sarah! I think this can solve one problem I faced with the Medicaid app by the state of Illinois.
i believe we want those actions to work
likewise we want actions to work even when you’re inside a table row
i think focus-within could be a way to achieve that
maybe not with unlimited scope
but to an certain level up the tree
MK: when i said that i thought it was resolved
i thought we said that it would be authors responsibility
like they would have to put it where the actions are exposed
this means it doesn’t have to be on everything
we can avoid some unusual and hard to understand example
so in voice memos
in ios
there’s a set of actions on the voice memo
like play/pause/delete etc
when i’m focused ont he delete button there’s an action to delete
am i deleting the delete button?
same thing in the ios mail app
Jamie: yea if you’re on a message
there’s a reply action
MK: yea those links inside the email have actions too
like are you copying the link or the whole email?
<Jem> is it about "scope of action" discussion?
jcraig: you can also look at it from the opposite perspective
anything with actions it can inherit those from parents
you could aria-actions="" to overwrite this?
essentially unsetting
jamie: maybe it has actions though
but you don’t want the inherited ones
jcraig: yea i’m not saying you want to combine the element’s actions with those of its parents
so if a td has it’s own actions it wouldn’t inherit actions from the row
the author tedium i’m trying to avoid
is that the author will have to put those actions on each element
i’m saying that if you can null it out on items that you don’t want to have actions it would save a lot of hassle/code
Jamie: feels like a follow up item
<sarah> aria-actions="lol nope" < special cased
Brett-Lewis: if you inherit all these actions
say you’re in a td
and you inherit the actiosn from the table
that would effect the focus
jcraig: is that an implementation detail of jaws?
Brett-Lewis: no not at all
???
jcraig: that’s why i suggested focus-within
Brett-Lewis: even with focus-within @@
i now have to move focus to within that container
jcraig: to clarify this is an artifact of the virtual buffer
jamie: it would be the same in voiceover if you didn’t have the focus tracking
MK: can a sr make the current element focus the element?
can you make the sr change focus?
<Zakim> Jem, you wanted to ask what is next step for this proposal
jcraig: only if the element is focusable
voiceover is not going to modify the dom to do that
sarah: i still propose we drop the inherited stuff for now
with some exceptions such as browser-native UI like selectmenu?
i think we don’t have enough information on how people are going to use this for now
<Jem> +1 for making things be simple for now to explore further.
i’ll try to formalise the stuff that’s in the gist
maybe we can convince the chrome? people to implement this
jamesn: step 2.7 right?
[haha yes]
Prohibited name repair (prototype available in Chromium)
aaronlev: role=jamie
[laughter]
i had a bug where someone was complaining where
aria-label was labelling a list item?
aria-label was doing something different in ChromeVox than other srs
<scott> prohibiting name on list item is in the PR for the change in title to not contribute to name on generics
it doesn’t know, my world is confused now
we’ve been trying to work towards a more consistent web
and i spent too much time to fix this
i wrote code in chrome that…
trigger an assertion when you see this pattern because it wrong
and it returned a whole list
i figured out three reasons why people do this
1. people are using text-overflow: ellipsis and using the title attribute to show the full text
i also made a change in chrome, if it’s the same as the content don’t put it in the description
MK: can you explain the ellipsis?
aaronlev: it’s a visual thing
2. the author doesn’t know about the difference between the aria-label and the ??
3. because they put it on a custom element
and that element has an shadow stuff exposing naming
like a custom input with a real input inside exposing some stuff for accname
[some discussion about what accname is for]
what i did was create a vesrion of chrome
brett has played with it
you can run it with command line parameters
what it does
it assumes that when you put aria-label on something
if you put a name on something that’s prohibited
it becomes supplemental information
why not move it to the description?
i gave that out to folks to play with
Brett-Lewis: i played with it, it seemd fine
but maybe i wasn’t the best person to ask
i probably ignore the description a lot of the time
i didn’t notice anything harmful about it
aaronlev: this experiment, if people have questions about it, they can run it
jamesn: i thought i remembered that when tyou put an aria-label on a custom element that you would ignore the aria-label?
aaronlev: authors put all kind of things on custom elements
we can’t tell them to not do that anymore
it’s out there
it’s a natural thing to do
jamesn: the ??
like role you would want to keep
because you want to put the role on the custom element itself
the other thing is the ellipsis usecase
it’s almost as if we’re saying that’s a good thing for people to do
it would fail wcag
<Zakim> Jamie, you wanted to flag that mapping it to description is just kicking the inconsistency can down the road from name to description
Jamie: ?? or is that ??
aaronlev: if you}re willing to use chrome for a while…
Jamie: right but i’m saying i don’t see this problem a lot
i think it would be intersting to look at each use case
i understand the problem, but i don’t think it’s a good solution
to summarise
i’m worried about overloading description
aaronlev: i’m trying to ??
Jamie: ??
aaronlev: that’s the world we’re in
if we decided that would want to prohibit ??
aria-label is one of those attributes that authors know about
<Zakim> jcraig, you wanted to mention the accname text Aaron mentioned: "If the root node's role prohibits naming, return the empty string ("")." https://
jcraig: i was trying to figure out when we added the name prohibited line to the ??
comment from joanie
Add statement allowing for the possibility of naming being prohibited on the root node. Note: This change in and of itself has no implementation impact, but it allows other specifications to optionally prohibit naming for a top-level element. Furthermore, even if this prohibition is made within a specification, that prohibition will not have any impact on calculating name from contents.
aaronlev: If the node's role is "name prohibited " ignore it.
jcraig: no it says if the *root* node it prohibts naming ??
jcraig: but if it's part of a lower-level accname computation, you don't ignore it.
jamesn: correct
MK: maybe this is another topic
one of my biggest concerns
i’m a big fan of the goal
it’s not a criticism
if the browser is doing repairs
it does this thing
now it’s accessible
it’s not really the way…
… it’s a repair
aaronlev: in the experimental thing i did it does explain
like it puts an error in the console
MK: that’s all cool
i wonder if there should be more awareness about browser repairs
should that be specified
since it’s repairing
and since we do want interoperability
should we testing this?
and have more requirements around repairs?
aaronlev: sounds good to me
<Jamie> s/mk: /Matt_King: /g
[break]
<elguerrero> I'm going to drop off for now, got other bits of work to do but will try to rejoin later :)
Interactive Lists
<aardrian> If you're in the IRC and not in the room... we're starting!
sarah: interactive lists
we’ve had a number of issues
there’s a link to the gist in the agenda
https://
there’s a number of issues with interactive lists
like meeting controls in a meeting
for example buttons for muting participants etc
they tend to be one dimensional, a series of repetitive content
lists of participants for example
or like a list of apps in teams
it’s structured and informational
but it can be very long
it can be virtualised
there’s a lot of instances dashboards with cards etc
essentially lots of one dimensional interactive things
definitely on windows and macos
this control is not a new one
it just doesn’t exist on the web
we have grid for two dimensional lists
listbox and option don’t allow nested interactive content
they otherwise have similar behaviour
things like toolbar are much more specialised
this is essentially a proposal for a one dimensional like grid is to table
??
but not explicit ?? for IAA
there’s kind of two possible ways that we could go to
[pause for questions]
<Zakim> smockle, you wanted to ask about additional use cases (e.g. issues in a GitHub issue list? messages in ChatGPT?) and to ask about the relationship with `aria-actions`
smockle:
would this be useful for things like issues in a GitHub issue list? messages in ChatGPT?
sarah: yes
aaronlev: i have a question
is this something that can be vague?
like you can use one kind of list versus another
sarah: can you explain
aaronlev: are people going to be confused by the vagueness?
sarah: i hope it’s not too confusing
you use list when it’s not interactive
you use listbox when you make a combobox
and interactive-list for ??
aaronlev: it’s not a form control?
sarah: correct
jamie: first question is why
i don’t understand why we don’t want implicit ??
sarah: let’s go back to teams
it has a dashboard card
if you look to install an app
there’s no selection
you don’t have to announce the select status
Jamie: but neither would a single select
sarah: selection exists even if you don’t hear it
Jamie: sure but @@
what happens when you click one of the list items?
what would that mean?
sarah: it could do the install
but it could also be toggling a checked state
Jamie: i worry about that ux pattern
we’ve had that in firefox
if you have buttons or list items that aren’t explicit about what happens when you click them
MK: thinking about the differences of
to explore
the stuff isn’t selected when you move through it
maybe under the cover
but certainly focused
you know pressing return opens the email
in explorer it opens the file
in finder it triggers rename
so in that case we don’t actually have any type of selection going on
Jamie: it kinda helps
but with outlook
if you hit del it will delete the message
sarah: take a chat app
if you have a list of recent chats
the current chat is selected
???
MK: it’s just not a focus state
there’s no user value to it
Jamie: this is what i’m trying to query
it seems like that’s a ?? use case
with listbox, if we forget about the selection case
MK: since aaron tried to twist my brain
so i think the primary difference is that you wouldn’t want to reuse listbox
is because listbox works really well as a form control until you render it differently
Jamie: yea we don’t render listbox
MK: right
but in these list views we always want to show all the content
Jamie: i would use role list and allow for interaction
sarah: yes, that’s what this is doing!
but it doesn’t do mode switching
Jamie: that sounds fixable
MK: we had this challenge of not know what states
if it’s differnt roles you can inherit different kind of properties
i got it from two differnt things
i forget what they are
but carefully chosen which roles they inherit from
you don’t have these conditional statements of what’s supported or not
it’s kinda the whole menubutton argument
if it’s aria-popup it changes the role
Jamie: i want to lay into this more
if you’re saying it’s itneractive should it appear in a browser interface
we’re saying we don’t want it to be a form control
but also we do?
MK: no it’s like a grid
with a grid you want to interact with it
and with table you want to read i
and with grid you can do both
cyns: i’m hearing a lot of overlap with the aria-action conversation
are these complementary?
sarah: this is a new semantic structure
this is a supplement ??
this is grid to table, questionmark to list
that is onedimensional
some people use grid to do this
sarah: what would you suggest people do cyns?
cyns: a one dimensional grid sounds reasonable
MK: if you do that you can press the down arrow or right arrow etc to navigate
with a one dimensional list you can’t support that keyboard interaction
and so then you can wrap this list
everyone wants to use ul
and that’s cool
and then you style the ul
Brett-Lewis: my question is what cyns just asked
why isn’t this a grid
i’m not convinced we need a new role
ZoeBijl: Why isn’t this a one-dimensional grid?
<Zakim> ZoeBijl, you wanted to ask what’s the problem with using grid?
ZoeBijl: What’s the issue with keyboard support?
Sarah: One-dimensional grid feels like a hack, since grids are supposed to be 2 dimensional, with column headers, etc.
Sarah: Whereas with interactive lists, it can reflow, be vertical or horizontal. You can hack it with a one-dimensional grid, but conceptually it isn’t two-dimensional.
ZoeBijl: But you could have a table with one column, could you not?
Matt_King: Here’s an example: A list of links, presented as a table with one row…but then, if you resize the screen, it becomes a table with two rows (responsive). Semantically, still a list of 6 links.
Matt_King: The large icons in Windows Explorer are another example: If you press the down arrow, you can navigate from the first item down (vertically) to the item wrapped onto the next line.
aardrian: i want to respond briefly
<Zakim> aardrian, you wanted to ask how to differentiate this to authors from `menu`
when you say that sr users aren’t impacted
I deal with people, sighted sr users, that it does impact
separately
with the list
i feel like that people will now go from navigation with role menu to interactive-list
is that a valid concern?
sarah: ??
MK: why not do that?
aardrian: there are authors that’ll say “well i’m nolonger restricted”
if that’s a valid usecase then don’t mind me
MK: i don’t think that’s a problem
sarah: i think the question should be whether you want to move through that with arrow keys or tabs
and this might be better than the alternatives?
aaronlev: i guess i’m not going to be the person to block this
but it’s going to be hard to understand which list to use
MK: let me write the apg entry and tell me if it’s hard
aaronlev: ok but this or an extra attribute for an existing role is a big difference
i’m not great with the srs, but like with jaws can i use ???
Brett-Lewis: yea you can certainly do that
aaronlev: i’m saying there’s a few other options that we should explore
jamesn: i like to say i fully support this
this is a pattern we have everywhere
at the moment we use single row grids
which is the best thing we have
there are lots of problems and we need to do better
what we have now is unsatisfactory
<Zakim> smockle, you wanted to ask about nesting interactive lists inside interactive lists
smockle: can we nest interactive lists
jamesn: no
we should make it so we can not
[smockle has been sent to jail]
Jamie: the reason is not included in the doc
is because we don’t want to add a thousand items to the list
but now we say we want to expose all of those
why aren’t we changing it for listbox items
why are we differentiating these things?
sarah: is that different from a static list?
Jamie: no it’s the same
sarah: to aaron’s point that we should reuse an existing role
???
it shouild be this
rather than a static list
another was similar to adding another role
i lean more towards using lists than listbox
because with list, if this isn’t supported you don’t get mode switching
but you still get a list
you get the content
you could still navigate
aaronlev: but basicallty making list items that can get focus
sarah: yes
the mappings are very similar
Matt_King: i’m a little surprised there’s people…
we made it a priority to get this done this year
we’re a little late
I appreciate the concerns
<alice> s/people.../people expressing concerns about this/
and it’s not that we can’t change ??
but i’m a little surprised jamie, that either collapsing all the items
with listboxes
i think the difference with the listview is that it’s not the main content of the page
like a list of chat it’s not the main content
the chat would be
the only way to get to the caht is go through the listbox and then search feels like a problem
most people want to navigate by heading
this doesn’t prevent that
this ?? us a way to allow thaat
?? in focus mode
it gives authors and users more flexability
scott: [talks into a muted laptop]
i wanted to just first say that this is definitely a thing that needs to be solved for
there’s a lot of these patterns
of different levels of quality
i’ve seen the single column examples
and it’s been befuttling to our users
so i think this is something that we need
but i’m sympathethic to what aaron said
it’s a role that has a lot of overlap with other things
like listbox, tree, grid
so is this then just another way of making a tree?
i don’t have a solution for that?
but i do want to talk to what aaron was saying
is this something that can be added onto another role
or to adrian’s point, do we know what people are going to use this for?
and how do we define it in such a way that they use it correctly?
like define why you shouldn’t use this for those situations
Brett-Lewis: Matt you said something that made me question
you were talking about a chat app
you could search for a message easily
are you thinking about this dynamically loading?
Matt_King: that wouldn’t change
you would load however much is showing
Brett-Lewis: so with grid you get infinite scroll
Matt_King: yea that would be supported
Brett-Lewis: you can then get unpredictable behavuour when searching the buffer
you would still need to define the search
but it might be confusing to sr users to what is actually loaded
sarah: that might be a separate issue
because it’s not dependent on what role is added
aaronlev: what do people think of sarah’s idea to ??
sarah: there are things on the spec side
certain things that are supported
i had a list of in my proposal
[github grumble]
like haspopup
full list of examples: https://
aaronlev: we don’t have to change the presentational ??
Matt_King: if focusable it’s a widget?
<CurtBellew> I can't hear very well so I might have missed it. Was there conversation around the Open Question - "Should we allow nested listview ..." ?
that’s what we did with the separator
it’s not great
aaronlev: especially since it’s confusing, i won’t remember this next year
i’m just concerned
Matt_King: i know, but we need to be able to create different kind of experiences
<scott> HTML HAS FOUR LISTS WHY NOT ARIA!?!?!?!?!
<aardrian> <menu>
<scott> WE HAVE LISTS OF THINGS TO DO
can you define them?
<aaronlev> https://
jamesn: so i mean i don’t fullty understand between hgaving a new role and having a new attribute
and i don’t really care which one we have
ZoeBijl: We need to provide guidance, e.g. in the APG, for using list roles correctly
jamesn: as long as we have a solution
even an imperfect solution is better
sarah: ?? easier to write
because that’s the same
to the three lists issues
i’m in favour of ??
it has bad usability
if we say you should use ?? inside a ??
would that be better?
aaronlev: i mean…
how does saying not to do it help people from doing it
<scott> people know trash when they interact with it?
[redacted]
aaronlev: I linked some text above listing the different options I heard discussed here a role with great apg adivce
like listing the cons
sarah: yea
MK: there’s an aria-interactive pr
<spectranaut_> Aaron posted this above, repeating so that its in the generated notes, wants feedback on these options:
<spectranaut_> Can we create pros/cons list for different approaches?
<spectranaut_> Options for interactive lists:
<spectranaut_> - New role, but with great spec text and APG content
<spectranaut_> - Single column grid, seems hacky
<spectranaut_> - Single level tree
<spectranaut_> - aria-selected=undefined on focused option + options support non-presentational descendants
<spectranaut_> - What if I shift+I (or AT next/prev list item would just navigate them all)
<spectranaut_> - Reuse list/item but allow focus on listitem, support non-presentational descendants
<spectranaut_> - New property on a different role
<aaronlev> I/Shift+I idea is basically, can we improve screen reader UX to mitigate the issue?
<CurtBellew> I can't hear very well. Was the first question in Open Questions addressed "For screen reader vendors: do you forsee any issues with allowing virtual cursor navigation inside ..."?
sarah: my current list of things to do is
pros and cons
what to do with focus
reusing a role
<scott> i said tree, and i'm still washing my mouth out with soap
aaronlev: is a person looking up lists ??
i was also interested in if the sr ux can be improved
CurtBellew: i think you can hear me but i can’t hear much from the room
i was curious about the open question: "For screen reader vendors: do you forsee any issues with allowing virtual cursor navigation inside ..."?
it causes trouble if people start putting stuff in one cell
aardrian: i think he’s correct
but nobody is serious about the grid
jamie: but now we’d just be cramming more items into a listitem
Matt_King: are you saying it’s a problem when a grid cell contains a lot of content
CurtBellew: yea
to replicate this functionality
the problem is that you can’t navigate between items in that cell
the user just wants to copy one part of the cell
and if you can navigate inside these items
would that be a possibility with this role?
Matt_King: there are solutions out there
that would enable to go into a grid cell
apg grid cell navigation guidance: https://
scott: one other question is about…
and i didn’t see it in the pr
but i couldn’t read all of it
this might be more approriate for reusing a role
because people want to ??
there’s no good author guidance on how people can identify what the accessible name should be
that’s def a problem i see with other interactive list things right now
people don’t know where the accname begins or ends
i don’t see anything in the pr that talks about that
it might be nice to have before we choose a solution
Matt_King: i thought i put it in there
it might be in the listview item spec
when you’re in forms mode
you don’t want to hear all the content inside
not most of the time anyway
scott: the only thing i notice is must specify an accesible name
i was hoping for more guidance
like name from encapsulation
something an author can look up
Matt_King: i thought i added more
there’s some language in article that talks about creating a better experience by using a combination of label and description
sarah: also a potential name from heading?
<CurtBellew> Thanks
Other new HTML features
related explainer: https://
aaronlev: so based on the last helpful conversation
we have a few items left
still some html and css we haven’t talked about
<spectranaut_> https://
i’d like to go over them and go over the status
we’ve not talked about command and ??
or exclusive accordion
then there’s my favourite which is the customisable select
and then there’s text fragments which jamie can talk about
and then there’s css inert
let’s start with the customisable select
we want to have less aria in the world
we want them to use html semantics where possible
everytime someone uses a new widget library these things are implemented differently
creating chaos for users
we want to document this
the rules can no longer say what the default select is
instead it’ll come with default styles that can be adjusted
for example the button can or cannot show the currently selected option
the awesome thing though, which is also scary, you can also put other things in there
you can’t do that right now i think
mason: with the flag in chromium you can do it
aaronlev: i know everyone is excited to put iframes in options
[laughter]
above or below the select there’s real world use cases such as ??
and the other could put anything there as well
for the first type
Matt_King: what does the content model become?
mason: we have a proposal but it’s not final yet
so input is appreciated
aaronlev: then there’s the what can authors now do
to make stuff accessible and look the way they want?
and for the third group we want to put an error in the output
Matt_King: the stuff inside the options is super solvable
but i’m curious about the stuff between the options
that stuff is the scariest part to me
when you’re inside of a select
aaronlev: the plan is if it goes outside of the bound
outside of the usual of can we present this as an option
it’ll switch to a dialog
tab will not close the box
it’ll cycle within it
Matt_King: what is between the options changes the implicit aria semantics?
aaronlev: yes
i don’t know why they would put a table in there for example
but it’ll go into dialog mode
mason: anything other than div will be nonconforming atm
aaronlev: if we can’t make it accessible why tell authors to do something
why would we always tell authors that they’re wrong
if we can just make it work
mason: we’ll start on the conservative side
Matt_King: with opt group
or role group with label
i’m wondeirng if let’s say there’s a heading with options
and you figure it’s a heading with options, oh will it change?
aaronlev: we don’t have a solution yet
but what you propose has been talked about
we need to restructure for that though
which is a big burden on browsers
i would rather just switch to virtual buffer mode
<Zakim> sarah, you wanted to ask about scripting focus and detecting the difference between the old select and the new one
sarah: i wanted to ask, i, was chatting with someone that told me that we would not allow interactive elements in options
my worry is that this will impact keyboard support?
how does that work with focus?
or active element for that matter?
aaronlev: you bring up a good point
we normalise that with our implementation of the accessibility tree
there’s a button that you can put as the first item in a select
and another button that allows you to style when the thing is closed
for actions we reroute that so it looks like the old select
sarah: what are the possibilities for what active element can point to?
aaronlev: ?? we can’t touch
so now you have ??
sarah: how do you tell the difference between this and old select
aaronlev: you could use the computed style
sarah: ah ok
we do a lot of focus management library stuff
where we track document.activeElement
we track how it behaves
we do a lot of focus tracking and management
aaronlev: this is a new dom
this is like a little mini webpage
it’s the thing that you can style
it has a little box that you can style
within it’s all dom elements
the current select could overlap the browser window
the new one can’t do that
sarah: my issue is that you can’t tell the difference
mason: ?? no focusable things
all of those things are now in the user ?? root
and you have your own stuff
sarah: that doesn’t ?? the focus management
aaronlev: we can take it offline and we can discuss the use case to our group
jamie: i’m struggling to understand
if you can put a random element in select
why not use a popover
mason: lot’s of things come with select
form participation which is a big one
you get all of these things with styleable selects
we try to solve the fact that people are making different implementations
jamie: yes, but if you put random stuff in a select you’re breaking those expectations
once you remove the limits of what can go inside you change the clarify of selects
and changing it from a select to a dialog on the go is terrifying
terrifying: from an at or browser perspective, the rule change because someone adds an element that’s not expected, we have to figure out with every mutation if we need to change the role of all those elements
so we need to figure out what needs a recalculation
aaronlev: i don’t see how we can make this work for all cases
we don’t want it to work as a dialog at all times
Jamie: right
they’re using a select because they want form participation
tehy also want to put other stuff
but surely we need to disallow certain things
aaronlev: it’s the web, i think it’s better to just make stuff work
we want people to use this to make it accessible
Jamie: yes but if we don’t know all use cases we can’t make all of those accessible
you’ll at least have infinite-1 of inaccessible cases
one thing we put in the spec
we needed to limit stuff that inert could do
we got agreement on that because otherwise people would use inert on things that break the web
allowing for an infinite amount of use cases would set us up for making things worse
aaronlev: one thing we have in place is the parser
not making it render isn’t a solution that we want
saying “please don’t do this” doesn’t really work either
mason: you can today build a select with javascript that looks like a select
you can build whatever you want
one of the advantages
is that we can detect what people do and what they put inside of it
so we can tell people what they’re doing wrong with these
aardrian: so it’s a form control
the value attribute isn’t going away
do you have rules to accomodate these ?? buttons and values?
mason: It submits the text contents, which yes can be a lot.
Matt_King: when i was thinking about the content model i was thinking of that as the thing that
kinda
one thing that you would expect is for it to describe the user constraints?
i was wondering
if the roles can change dynamically
is the select
is the aria role of the select nolonger a select
does it become a button that opens a dialog?
or is it still a select?
aaronlev: we haven’t worked that out
maybe a button with expanded?
Matt_King: yes so how does that work?
if you can have a select that’s then mutated?
aaronlev: there’s two different things
for 99 percent of the usecases
where people use this legitamately this is pretty cool
we just need to make it so it doesn’t destroy your computer
with the mutate case there might be legit usecases
like if you have a few options
maybe they’re being added dynamically
and a little text field comes up at the top
it’ll work just as if you changed the aria role of the ancestor
you’ll get new events etc
at least in chromium the ids of the elements will stay the same
so srs can keep track of things
aaronlev: i just want to get feedback
i know it’s new, so please think about it
sarah: my question is about when i built the similar thing for our js library
which i want to replace
i had to add an extra attribute for the human readable value
because the value isn’t necessarily the main text
so like text matching
(typing to jump ahead)
is there a way for authors to define that?
aaronlev: i’ve not thought about that yet
sarah: you need to type ahead and if you need the same pattern for editable
aaronlev: i think the editable is important
<Zakim> smockle, you wanted to ask about auto-closing
Matt_King: the type ahead is super important!
smockle: if i have a customisable select with five options
if i have a load more button in the select
does the select close?
mason: that would be a dialog then because it’s not an option
it would leave the popover open
aaronlev: on to exclusive accordion
basically an improvement to details/summary
when you open up one of them it’ll close the others
Matt_King: is it always exclusive
aaronlev: no
jcraig: if you don’t use the name attribute it’s not linked
aardrian: do they have to be next to eachother in the dom?
aaronlev: no, they can be anywhere just like radio buttons
aardrian: how does it work with group label?
do i use an aria-label?
aaronlev: you could use a fieldset with a label
<Zakim> ZoeBijl, you wanted to ask is there a way for the user to overwrite it?
<hdv> ZoeBijl: is there a way for the user to override it?
<aardrian> Group label is still not built into accordion spec.
<hdv> ZoeBijl: where I've seen it, eg Google store has this, there is stuff I want to know and compare and then I can't look at the requirements
aaronlev: i don’t know
jcraig: there’s lots of websites with terrible usability
like horrible colours or always on dark mode
these are tools that web authors or native authors can use
they can already do these things with javascript
so let’s focus on things that we can change
in this case
we shouldn’t put our head in the sand and say "don't do this" because web devs are already doing it in less accessible ways.
if we disallow this we’ll end up with worse usability
jamie: so effectively this’ll be a button with an expanded state
aaronlev: ??
even though it’s essentially a button
so it’s allowed but srs don’t support it
jamie: let me rephrase
the only difference between this and summary/details
is there an intent to expose the posinset and setsize?
aaronlev: yes
jamie: just so the user has some idea that they’re exclusive
??: are those supported on details/summary
jamie: we can take this offline
i was curious about the mappings
Matt_King: just the name feature is making it exclusive
so it’s not an accessibility issue? more a usuability thing
aaronlev: i wanted this group to be aware of it
Matt_King: can they all be collapsed?
aaronlev: yes
Matt_King: and if they don’t have the name attribute
is there a spec for how you would group them?
aaronlev: not right now
aaronlev: there’s gotta be a parent to it
aardrian: He said in a grouping context.
<Zakim> jcraig, you wanted to mention I intended to ask adrian about the non-contiguous concern
Matt_King: just making an assumption i guess
jcraig: i forgot to ask
i have concerns about these non exclusive accordions
??
well that’s weird
but we moved on
so i can see ????
like something other than we saw with radios
aardrian: so what i see is heading, more disclosures, a heading, more disclosures, a heading, a form to fill out, etc
they’re not adjacent but the devs still want them to be exclusive
sometimes they’re another layer down
unlike radiobuttons where you use them in a very specific context
jcraig: so they’re using it to save screen real estate?
aardrian: yes
they see it as a reason to do ?? and all this other stuff
<Zakim> ZoeBijl, you wanted to say i’m not opposed to making things accessible and i think making things accessible easier is good
so yea it’s not adjacent, it has a different dom structure, but they want to ????
<hdv> ZoeBijl: agree with James that we should make this stuff accessible and make making things accessible easier
aaronlev: there’s two pairs of attributes
one is command and commandfor?
mason: those have been bikeshed
aaronlev: the other is interesttarget and interestaction
?? is more about hovers
still has a lot of birth pains
things like touch support
lots of people are working on it
<jcraig> Command/Commandfor deep link https://
just want to let you know that these things exist
command and commandfor
some examples for the different command
dialog
dialogopen
dialogclose
showpopover
hidepopover
etc
eventually it’s going to be a superset of popovertarget
mason: strict supersete
aaronlev: if people want to talk about css
jcraig: command=close
behind the scenes there’s no javascript
mason: correct
all of these commands are not javascript
jcraig: great
[something about the scrub gesture]
from the point of assistive technology ??
this is somewhat similar to the structure of the ui events
kudos
smockle: could we use this for aria actions?
in that there’s controls and you have a container?
aaronlev: i don’t know
jcraig: showmodal etc is a very finite list
actions can be anything
it’s custom
smockle: that makes sense, thanks
jcraig: but don’t dismiss it, let’s keep digging
sarah: maybe this could be a subset -- actions is more flexible, but we could investigate using the same API mappings for commands
or it has the same api mappings maybe
alice: i was interested in picking up what james was saying about the accessibility benefits
that seems true for the buolt in actions
i don’t know how the custom actions benefit
mason: the built in actions have ??
there’s a naming scheme
you can use that to support? the custom actions
alice: still trying to wrap my head around what the custom actions are for
mason: it’s not a ?? it’s a custom element
so it’ll be a 'my-custom-action'
jcraig: the big focus dance that we’re doing is keeping the ?? on stream
if we ant to leverage this new api for aria actions it ??
if it overloads this mainstream api it could ??
<Zakim> Jamie, you wanted to ask about AT sniffing risk
jamie: if we dispatch these events without for example esc
if this close event comes from out of nowhere
doesn’t mean the app can tell it wasn’t from one of its triggers
that sounds like an at sniffing method
like a quite obvious one
jcraig: you can already do that in various ways
Jamie: i wonder about the tag principle here
no leaking AT principle
and whether that’s risky
i don’t have a definitve answer
but i wonder
jcraig: will it prevent fingerprinting?
no
but nothing out there will prevent that anyway
jamie: these actions need a trigger anyway right?
that’s what the command attribute is for
so
normally those would need to come from a certain trigger
now it doesn’t
is that correct?
jcraig: ????
Jamie: ah i thought it was understood that browsers could trigger these in different ways
mason: if you have a button and it has a command button
the event that is fired
the source is the button that triggers it
there’s nothing in the spec that ??
jcraig: google has made some proposals that’s specific to their back button
perhaps they could work that into this api
mason: the back command
sarah: this custom close event ??
jcraig: if it was an android back button you wouldn’t know it was a sr
sarah: yea i need to think about it more
as an author it’s hard to see what the back button does with the command
Acacia AAM automated tests
[everyone’s hiding from the ice cream legislators]
spectranaut_: The idea behind Acacia is to extend WPT with automated AAM tests
alice: Extending WPT infrastructure beyond computed role and computed name
https://
alice: I’ve written an extensive image description
image description: Block diagram illustrating how these new tests fit in to existing infrastructure. Full image description available in RFC.
alice: The browser process is on the right; on the left we have assistive technology and WPT. These talk to the browser via HTTP (web driver). The assistive technology talks to the browser via Platform Accessibility APIs
alice: We want to test the content mapping code, as opposed to the Blink accessibility tree.
alice: Acacia uses the exact same platform APIs
alice: Extends `testdriver` (a wrapper around webdriver). If you include `test driver` to get web driver commands (like clicks), you also get the accessibility API queries
github: Igalia/
The Acacia prototype runs on Linux, Mac, and Windows. It is very minimal right now: You can get the name and role of a node.
alice: You’re getting the role the platform understands.
alice: Not yet implemented for UIA.
RFC: https://
alice: This is a significant change to WPT. It requires an RFC, which is opened, but still in review. There are open technical questions. We’re meeting with the browser testing and tools group this Thursday to work through these questions.
github: web-platform-tests/
https://
spectranaut_: Test design is more up to us.
spectranaut_: I’ll run a demo.
github: Igalia/
spectranaut_: The PR has notes about pre-requisites needed to run the prototype (e.g. python dependencies to install)
spectranaut_: There are 2 example tests, they are running on Linux. They succeeded.
[on-screen: A test was run from the command line, then a browser window opened with the test results]
spectranaut_: Test design assumptions: One test file per entry in AAM. There is one test file that contains assertions for all the mappings, but only mappings supported by the platform where you run the test are tested.
spectranaut_: WPT.fyi doesn’t have the concept of tests that only run on a specific platform.
spectranaut_: Test logic and HTML in the same file
spectranaut_: For now, tests show up as “pass” on WPT.fyi for platforms other than the platform you run on (even though no tests actually run)
example test: https://
spectranaut_: If you expand the “Asserts run” disclosures on the blockquote test page, you’ll see the message that “No asserts ran”
spectranaut_: Two test designs we are considering: “bag of properties” and “testable statements”
spectranaut_: “bag of properties” is the test design in the prototype.
spectranaut_: We have a `get_platform_accessibility_node` function on `test_driver`. It gets every accessibility property the backend knows, then sends it as JSON to the frontend, and it tells you the API it queried (since the frontend doesn’t know which platform was used).
spectranaut_: Moving on to “testable statements”.
spectranaut_: For background, we have manual tests in core-aam.
spectranaut_: The API is a function that takes the name of the test, the id of the element you’re testing, and an object that has a key for each API, and the value is a list of testable statements, e.g. “property role is block quote”)
spectranaut_: Do you all have thoughts about these two test designs? Which do you prefer? Do you have other ideas?
spectranaut_: We could send a python string to the backend, for example.
Jamie: First question: Do we need the `--enable-rendering-accessibility` flag?
Jamie: There are rules in e.g. Gecko, where, if you poke certain APIs, the accessibility tree will be generated (even without manually specifying commandline flags)
Jamie: Context re: the inline python approach to testing: Assertions are great for role and states. But table interfaces or text don’t match well with `is` or `equals`. Testable statements can be restrictive. Declarative frameworks can be more verbose than being able to just specify a few lines of code.
Jamie: Here’s an example of where you’d want that kind of scripting: Events. We have UIAutomation tests in Gecko: Testing that a pattern is available, that doing something on that pattern fires the right event.
spectranaut_: We do want to support testing events too
Jamie: We have thousands of lines of UI Automation tests now.
Jamie: We could explore how one of those could be expressed with testable statements.
<Zakim> jcraig, you wanted to ask if the platform-specific relevance could be stored in wpt-metadata and filtered in wpt.fyi?
jcraig: I had an idea about WPT.fyi: There’s a side repo WPT metadata, where you can add metadata (but maybe not to a subtest). However, if tests were rearchitected (to a file per platform), then those files could be filtered out.
<Zakim> ZoeBijl, you wanted to ask for pros and cons of the different test methods, the testable statements look cleaner but i’m wondering if there are limits to that method
<alice> web-platform-tests/
ZoeBijl: To me, testable statements look clean. I was wondering about limitations; pros/cons?
spectranaut_: It gets us further from the underlying API. Another layer of abstraction/translation. Changing everything into a string, JSON to be passed around.
ZoeBijl: Do you have a preference between bag of properties and testable statements?
spectranaut_: Testable statements is my preference.
Rahim: What is the ultimate ambition for this? Would mobile testing be in-scope? What’s the end goal?
spectranaut_: The first goal is to test the AAMs. As Jamie alluded to, there are many things we can’t test in ARIA, because they aren’t a strict mapping. AAMs have been our focus so far. The AAMs only talk about desktop browsers.
WPT doesn’t run on mobile, either.
<jcraig> Actually alice spectranaut_ maybe subtests are supported now... Example with product-specific bug links... https://
masonf: There’s a certain approachability to getComputedName, getComputedRole that deal with the computed tree. But platform API testing is more complicated. Is there benefit to doing more with the generic computed accessibility tree?
spectranaut_: The WPT accessibility interop group has been exploring ways to test the computed tree more fully.
spectranaut_: Someone not familiar with accessibility would find it easier to test the accessibility tree, vs these per-platform-API tests.
jcraig: Maybe, in these Acacia-style tests, the internal (not platform-specific) role could be tested too, alongside the platform role.
<Zakim> cyns, you wanted to share this old UIA testing project microsoftedge/
jcraig: Let’s talk more offline.
cyns: There’s value in both: computed tree testing and in testing platform APIs
cyns: I could see a test file that has both the computed role and what it would be across the various platform APIs. I want automated testing in both layers.
cyns: I linked to an old C# project (microsoftedge/
<Zakim> jugglinmike, you wanted to learn about expected contributor demographics
jugglinmike: The diagram is very useful.
jugglinmike: Do we expect test contributors would be experts in all the mappings?
jugglinmike: It may be possible for someone to write tests for one mapping, but not all of them. Would partial coverage cause problems?
spectranaut_: Very few people will know much about these APIs, especially *all* of them. We haven’t thought much about people contributing tests for just one API.
spectranaut_: The main goal is to test the AAMs, and AAM tests will be written for all the platforms.
<Zakim> jcraig, you wanted to react to jugglinmike
jcraig: If there’s no mapping, you could send a failure, instead of a pass. To get people to contribute mappings to the AAM.
ksc: The bag of properties resembles existing WPT tests. The other looks radically different.
ksc: Proposal to reduce duplication: You could create a different map. I’ll follow-up.
Jamie: A lot of the time, we could express non-core-aam mapping as core tree tests. We’d only need to deal with edge cases that don’t use ARIA’s mappings.
<Zakim> alice, you wanted to talk abotu the computed tree
alice: Yes, that makes sense.
alice: There are a lot of things in HTML-AAM where the entire table is “Use ARIA mapping”. In that case, we’d only need to test the computed tree.
alice: For the computed tree, there’s only computed name and computed role, so there are a lot of things we can’t test yet.
spectranaut_: There’s the concept of computed role, but there isn’t always a 1:1 mapping with the platform API role. Example: Button.
Jamie: core-aam is going to have thousands of tests. html-aam is going to need some, but only for edge cases.
<alice> https://
Jamie: We do need get computed accessibility node.
<jcraig> https://
<jamesn> AAMUtils.verifyAPI(
<jamesn> 'role=foo',
<jamesn> 'test',
<jamesn> {
<jamesn> "SOME_PLATFORM" : [
<jamesn> [ "property", "WARNING", "is", "NOT_YET_MAPPED, <AAM issue link>" ]
<jamesn> ],
<jamesn> }
<jamesn> );
jcraig: I was exploring how to send a failure that could raise a warning about a missing mapping.
spectranaut_: HTML-AAM has button, and says “See WAI-ARIA button role”, but there are 3 entries in ARIA for button.
<alice> https://
<alice> "A button's mapping will change if the aria-pressed or aria-haspopup attributes are specified."
Jamie: As soon as you get a case like that, then you would need an additional test.
sarah: Is there going to be a way to test that events were fired?
spectranaut_: Yes, eventually.
flackr: Can we convert the tree of computed roles into the platform expectations, and use that as a way to port tests to different platforms?
spectranaut_: That’s related to the convo we just had about skipping platform-specific tests when the computed tree is sufficient.
<kschmi> / Assuming you have an AAM_MAPPINGS JSON object representing the table on https://
<kschmi> / you could have a single statement:
<kschmi> assert_equals(AAM_MAPPINGS[node.role], AAM_MAPPINGS[node.role][node.API]);
<kschmi> / Instead of:
<kschmi> if (node.API == 'atspi') {
<kschmi> assert_equals(node.role, 'block quote', 'Atspi role');
<kschmi> } else if (node.API == 'uia' ) {
<kschmi> assert_equals(node.role, 'block quote', 'Atspi role');
<kschmi> } else if (node.API == 'AX')
flackr: You could have a test helper to automatically generate those tests.
aaronlev: That would be messy, because of differences in implementations.
updated agenda: https://
rfc: web-platform-tests/
alice: Call to action: If you want to follow-up, there’s a link in the presentation to the RFC. We want more comments in the RFC.
Jamie: I linked the Gecko test, if anyone wants to take a look.
RRSAgent: make minutes
td, th naming doesn't align with ARIA
<aardrian> w3c/
aardrian: this is about td/th naming not aligning with ARIA
… this might go deeper than I originally expected
… right now, within tables, cells and headers get their name from content
… aria-label has mixed support
… across browsers + AT
… cumbersome for SR users
… sometimes authors will leave cells blank
… not mentioned in issue, but think back to abbr attribute, not element
… allowed on th to provide name
… not supported
TylerWilcock: might be a heavy lift
aardrian: might be a little more work than just “we should allow this”
… a related issue: WG concluded to add name prohibited for listitems
… broad questions to discuss:
… if we were to allow name from author, how do we deal with columns with sort controls?
… because sort order should contribute to accname
… would it override text? Or augment it?
… my thought is to disallow it
… imitate listitems
… recognize that cells can contain interactive controls
… simplifies a bunch of stuff
jamesn: there are some places where abbr attribute on th *is* supported
… at least one SR and at least one browser in the past
Jamie: when an author naming technique is used, in your experience, is it intended to be primary or secondary content?
aardrian: primary
… because the author tried to visually hide it or abbreviate it
Jamie: if aria-label on a td were secondary, then we’d say we never really want that to override the content
… on the other hand, if it’s being used for primary, that doesn’t work
aardrian: take a calendar pattern
… where days are Mo, Tu, We, etc.
… and then authors give full day names in aria-label
Jamie: that’s tricky, because the abbreviation is visually presented
… SR users might prefer knowing that
sarah: another use case
… when column headers have additional controls that are relevant to the header but not to the cells in its column
… like a “Select all” checkbox
… I’ve tried using aria-label to override the column name
… but it doesn’t work
matt: in some situations, abbr works
… it does great in tables, at least with JAWS
… it does not work in our current datepicker, I do know that
aaronlev: we don’t expose it in Chromium
aardrian: if there’s already some support for the abbr attribute, then it complicates things in terms of knowing what naming technique wins
matt: the only time you hear the abbr is when the cell is being referenced in its role as a column header
aardrian: if there is an abbr, it wouldn’t necessarily conflict with name from author on a column header or cell
… but we do still have the concern of nested interactive controls
matt: if you’re reading the cell that has abbr on it, then you only get name from contents
Jamie: abbr is tricky
aardrian: we can carve it out
… let’s simplify
… consider a th
… it’s got a Sort button, or Check all
… if we throw aria-label on there, what is our expectation?
Jamie: right now, the browser exposes both the name and the control
… the a11y tree is exposing all that information
… that’s what’s currently happening; not correct or incorrect
… so we can ask what the AT *should* do with that
aardrian: the 2 questions: 1) how to handle headers with controls, and 2) does the accname from author overwrite or augment?
Jamie: the second question is AT-specific
… I wrote a blog post about this a few years ago
… this is a hairy subject
Matt_King: I think the fundamental problem is that there are AT behaviors or expectations that aren’t codified anywhere
… right now, AT does legacy things
… and now authors are trying to get AT to do other things
aardrian: we can start by codifying what they do today
Matt_King: the APG’s sortable table is potentially a helpful example for this
Jamie: the general expectation from authors is that aria-label overwrites
… for a region for example, aria-label does not serve as primary content
Matt_King: I encourage everyone to read the “Providing accessible names and descriptions” section of the APG
Jamie: if we assume aria-label is assumed by authors to be primary content, then we should prohibit that where we wouldn’t want that
… and then repair by adding it to accdesc, as aaronlev proposed earlier
smockle: when we do that repair, do we raise an error in DevTools?
aaronlev: yes, that’s in the experiment
aardrian: sounds like there are good resources out there, I’ll check those out, please comment on my issue
<Jamie> https://
<smockle> https://
<aaronlev> Here is Chromium's console error when there's a prohibited name
<aaronlev> error << "An accessible name was placed on a prohibited role. This "
<aaronlev> "causes inconsistent behavior in screen readers. For example, "
<aaronlev> "<div aria-label=\"foo\"> is invalid as it is not accessible in "
<aaronlev> "every screen reader, because they expect only to read the inner "
<aaronlev> "contents of certain types of containers. Please add a valid role "
<aaronlev> "or put the name on a different object. As a repair technique, "
<aaronlev> "the browser will place the prohibited name in the accessible "
<aaronlev> "description field. To learn more, see the section 'Roles which "
<aaronlev> "cannot be named' in the ARIA specification at "
<aaronlev> "https://
<aaronlev> << "\nError details:" << "\n* Element: " << GetElement()
<aaronlev> << "\n* Role: " << InternalRoleName(RoleValue())
<aaronlev> << "\n* Prohibited name: " << prohibited_name
<aaronlev> << "\n* Name from = " << prohibited_name_from << "\n";
<aaronlev> Sorry about the word wrapping
2025 Prioritization
jamesn: this will be open format
… if there’s something you’d love to work on in 2025, please say so
jcraig: focus on testability (WPT, Acacia, etc.)... Other HTML and OpenUI features or existing native HTML features... If there are other ARIA changes requested, I'd like us to be able to test them before we change them.
cyns: do user research
… ask users who are less experienced with AT than people in this room
… about these features we’re considering
Nathan: WPT tests for Firefox that go into common tests
… avoid duplication
… and other browsers could imitate
Jamie: start figuring out how we will map these new HTML/CSS features that don’t fit into elements
… text fragments, for example, is not an element, it’s a concept
… we know what what the mapping should be, but where and how will we put that in the spec
Brett-Lewis: much of my job is fixing bad ARIA
… so it’s helpful to have these abstract conversations about how things should work
jamesn: which leads me to say “how do we better work in collaboration with AT makers”
jcraig: there’s a significant portion of the browsers that has to ask “what did the author intend here?”; it’s more than bad ARIA, it’s bad web
ChrisCuellar: ARIA-AT, particularly buildling out automation
… really curious about user research idea
… accnames and descriptions and how they’re being used
… working with bigger datasets
aaronlev: not everything is ARIA; how do we get people to write better accessible rich internet applications
… focus on HTML/CSS
… reward for effort
… wish this group would spend more time on HTML/CSS
… maybe have joint meetings at some cadence
… DOM as well
… error messages in DevTools are also powerful
jcraig: is there a concept of testing the error log in WPT?
… there should be, especially if we lean into presenting more of those error messages
… there could be some optional tests to look at what went into the console
aaronlev: also want feedback on the DX/usability of the console messages
spectranaut_: besides the acaccia testing, also excited to see better mappings into the a11y APIs
Daniel: getting the new charter up and running
… moving some of our specs to CR
… PDF-AAM
… excited to have them in the room. Will have some impact on how browsers render PDF
Matt_King: last year, the top 3 were: notifications, actions, listview
… so I’d like to follow through on those, get them over the finish line
… also very excited about alignment with HTML
aardrian: more collaboration with HTML/CSS
… they are producing new stuff constantly
… and also things related to tables
sarah: I support aaronle’s cadence of joint meetings
<aardrian> because tables must be tamed
sarah: also aria-actions
… get that over the finish line
… listview (?)
… and probably more stuff around indexing
alisonmaher: ariaNotify
smockle: also ariaNotify
… and expand what can be tested with WPT
… computed tree or otherwise
… ties into many of the new features being proposed
… gives us more confidence in what we’re specifying and delivering
alice: testing
… +1 to more alignment and collaboration with HTML/CSS
… computed a11y tree in addition to AAM tests
jamesn: what I heard is:
… testing
… HTML/CSS collab
… finishing things we started
… and usability
Rahim: +1 to aaronlev, spectranaut_, aardrian
… css-aam
… is another thing I’d like us to tackle
… and a path forward on IDL
Ray: +1 to HTML/CSS integration
jcraig: +1 to PDF-AAM, I will be writing first draft and then handing off to Paul
jamesn: back to conclusions
… have a monthly HTML/CSS call
… we should probably limit new ARIA features to those that support new HTML/CSS features
<ZoeBijl> ZoeBijl: +1 to james
<Zakim> jcraig, you wanted to add another at the end