W3C

– DRAFT –
ARIA WG

05 December 2024

Attendees

Present
Adam_Page, BGaraventa, filippo-zorzi, Francis_Storr, giacomo-petri, hdv, katez, pkra, Rahim, sarah, scott, smockle
Regrets
-
Chair
-
Scribe
hdv

Meeting minutes

New Issue Triage

jamesn: should the NSAccessibility scroll-bar API be included in mapping for scrollbar role? should probably ask jcraig's input?

Rahim: feel free to assign to me

jamesn: role for aside/section creates infinite loop

spectranaut_: maybe we should move to `html-aam`?

jamesn: ok

spectranaut_: there seem to be some suggestions for fixes

scott: was going to take it on but Anne's comment made me think what people would expect here… do we need an algorithm for this or is it enough to let browsers implement these mappings in their own way?

peterkrautzberger: seems like implementors should chime in

scott: yes all browsers except Ladybird have implemented this

jamesn: maybe we should specify something

peter: seems like nothing is missing in the spec

scott: want to know if this is actually a problem. Implementors would be best to comment on that

spectranaut_: was there a suggestion for a wording change?

scott: to me it seems… these have a default role, are there conditions that would change that role?

scott: seems like the OP is looking at it in a way opposite to how I was looking at it

jamesn: then… 'skip self' req is missing from the embeddable control substep (2389)

jamesn: should.I transfer this to accname?

spectranaut_: +1

bryan: I can look at it this afternoon

jamesn: next issue, two necessary steps for name computation are missing, will also. transfer to accname and you, bryan

jamesn: next, spec for computing accessible name doesn't rsult in traversing into hidden usubtrees… this one might be a duplicate, will put in accname as well

bryan: sounds familiar

jamesn: then there's one on AT/AT-SPI2, can I assign to you spectranaut_ ?

spectranaut_: yes

New PR Triage

jamesn: Sarah opened one re aria-checked support in grid cell

mattking: did we agree to do it?

sarahhigley: we did, it's pretty common

mattking: is it cell and row or just cell?

sarahhigley: just cell

mattking: what's the rationale for that?

sarahhigley: because focus goes between cells on a grid

mattking: but on a tree grid could go either way?

sarahhigley: I did debate also putting it on row, but figured on cell would be fine

jamesn: next one, explicitly state UAs must ignore aria-label for slots

jamesn: (PR 2385)

jamesn: who would like to review this?

keithamus: I can, also had a related issue recently

scott: this probably should be agenda'd as this slot element is messy, it can do different things based on `display` property

jamesn: next one, change default role for custom elements

scott: aaron and I wrote this and I think we've covered all of the use cases that we talked about and some more

scott: we'll need implementor reviews

jamesn: I wonder if this breaks anything that was previously ignored

WPT Open PRs

jamesn: does anyone want to talk about any of these?

jamesn: there's this one… add null for aria-utils checking…  (#49485)

jamesn: does anyone know WPT well and wants to look at it?

spectranaut_: I can

Deep Dive planning

jamesn: the one scheduled for this afternoon was moved to January

jamesn: do we want any more deep dives in December?

[silence]

jamesn: let's presume deep dives in the new year… if someone really wanted to we could still add one in the next week

[html-aam] Make HTML img accname use “title” text if alt is empty

jamesn: there's a longer discussion on this

scott: about two years ago as the WG we resolved to that `alt="" title="whatever"` should continue to be exposed as a role none

scott: not everyone 100% agreed with this, but it matched with what @@@ said back then

scott: TLDR, a WPT was created that had the opposite expectation

scott: all of this discussion is about that

scott: decision now is to undo our previous resolution

scott: and deal with the potential fallout of that

scott: we're now waiting for folks to align on the new file

scott: I think there's probably a lot of docs now that need to be updated

scott: to say alt="" needs role presentation all the time

giacomo-petri: there are instances where CMS allows content editors to enter titles, without knowing what it really means… 

giacomo-petri: I'm in favour of alt="" as a way to set an image as decorative

mario: we have no other ability to set an image alt to be empty

smockle: if you had alt="" with role=none, that's a role that cannot be named, seems in conflict with title

mattking: seems like we'd break the web is alt="" is not always decorative

mattking: we've been teaching people this for decades, to break it now feels like too big of a change for this kind of group to make without consulting the whole world

scott: the original fallout from this issue was… I created an issue for defining a way to make a decorative image role, specifically to account for stuff like this

scott: if someone mark it presentational but went to the effort of adding a title attribute, they give signals it is both decorative and has info available. All instances of title that I've seen on images that are decorative are, anecdotally, filenames or info that's already on the page.

scott: in many cases it would make it garbage

scott: but then others have said that there are instances where people do put useful info in a title attribute

scott: I'd like this to be reverted… it wasn't a decision anyone made, it was a mistake.

sarah: +1 to what other people said about alt=""

jamesn: I'd need to see title on an image with alt="" where the title was beneficial to anyone

jamesn: and even if it was useful, keyboard users wouldn't be able to access it anyway

jamesn: fixing it for a subset of folks doesn't help

scott: I linked to 1746 in the issue

aaron: there's a proposal to have a pseudo element for title that would provide this

jamesn: what's the resolution?

scott: probably would be for someone to remove the test, and add a new one that tests the same

Adam_Page: I can do it

scott: then this PR could be closed as wontfix

jamesn: would agree

Consider allowing aria-valuetext for combobox role

scott: gist of this issue… for the customisable select we talked about calculating the value

scott: there is work that needs to be done on value calculation… I figured this was one of those instances where HTML AAM would need to call something out

scott: idea is … someone can make a customisable select, the default for value is similar to existing select

scott: but there are instances where someone might want to have a label for their option, and also a description for that option… or an aria-label on the option element, that does not get cloned to the selected content element of the customisable select

scott: only the innercontent of that option gets cloned. In that case folks could hide the content they don't want with CSS shenanigans… or… maybe that's a lot of work, if aria-valuetext was allowed on combobox, which is the default role for customisable select

scott: this is for a specific use case where someone has done a lot of customising for selects

scott: where the browser can't properly guess what someone is trying to do. So we need an easy way to make it accessible

jamesn: I support doing that.

mattking: wonder if it creates another scenario when there is content shown visibly… and then this overrides that content

mattking: do screenreaders still expose it?

scott: I understand where you're coming from

scott: but I think we already have that problem for aria-label

sarah: , like, aria-label, with this you can do terrible things, but there are also good use cases. For example,when we show selected information in like tags outside of the combobox

sarah: or visually styled text when you have a file attachment but that's visually styled inside the content editable. Some screenreaders will read a very long string of text, would be great to have aria-valuetext to have it not do that

sarah: obvs with many things, aria-valuetext should not be used, but there are cases where it is genuinely useful

<hdv> +1 to do this, seems the use cases are worth it

smockle: is there no other way to do it?

smockle: can we algorithmically get to the same content?

sarah: a lot of the time, the accname for the selected option is different from what you want displayed in the actual input

sarah: say, you have a combobox of people you're emailing… and each person has the person's name, their role, their out of office status etc… it could show in the popup list of options visually, but once selected, you only need their name

sarah: to that extent that, in our library, we don't even bother to clone

scott: to add to that… yes you probably could get the content… but if aria-valuetext is provided like aria-label, it would be used, but otherwise whatever text that was in there would get exposed

scott: if someone didn't identify a button part and the browser automatically renders one, the value would be calculated from the selected option element itself

scott: since you can calculate it, someone could do a lot of CSS configuration to only display exactly what they want or add additional content in the option element itself

scott: but that's a lot of ridiculous work imo; this seems like a good alternative, and cuts down on the amount of work that authors would have to do

jamesn: to progress this… we would allow aria-valuetext on the combobox in the ARIA apec

scott: if we do that I could write the algorithm

smockle: I can!

WebKit does not fall back to 'nameFrom: contents' on aria-describedby reference when referenced element contains role="status" thus not announcing content via VoiceOver

scott: people have input fields that have error messages displayed after them

scott: marked up as role alert or role status

scott: references to the input element with aria-describedby

scott: but then if the element has no name it is seen as no content

scott: so I have to tell people don't use role alert, have it as a live region so that the aria-describedby relation works across browseres

jamesn: or stick it as a child

scott: seems like more effort

scott: it's beyond this use case though, we've also talked about accname computation for hyperlinks, same thing but description

scott: for name we traverse, we don't for description

jamesn: should we change it?

jamesn: or is it not worth it?

scott: for consistency's sake it makes sense to align what we do with description with what we do with names

scott: not sure of benefit of not doing it

jamesn: chrome does it differerently?

aaron: we suppress it, but would be a one line change for is to update

aaron: for certain roles, like range or slider,we process the value otherwise we don't, is what I saw in the code

jamesn: is that the same issue?

aaron: oh sorry didn't realise we moved on

aaron: am not familiar with this one

james: from bug description seems like chrome does what we're saying in the issue

aaron: just read it now, yes seems Chrome has the behaviour described in the bug

jamesn: so we'll need comments on this from jcraig and probably jteh as well

aaron: what if you do aria-describedby on something that doesn't have a role at all in webkit or firefox? seems like a common thing

scott: if someone didn't provide a name browsers wouldn't even try

aaron: generic prohibits a name

sarah: in firefox, accname doesn't work either

sarah: for something with role status

Rahim: there was some internal discussion on this; consensus was that behaviour like described in the issue would be the right behaviour

Minutes manually created (not a transcript), formatted by scribe.perl version 238 (Fri Oct 18 20:51:13 2024 UTC).

Diagnostics

Succeeded: s/hlep/help

Succeeded: s/like/, like,

Succeeded: s/in our library/to that extent that, in our library

Maybe present: aaron, bryan, james, jamesn, keithamus, mario, mattking, peter, peterkrautzberger, sarahhigley, spectranaut_

All speakers: aaron, Adam_Page, bryan, giacomo-petri, james, jamesn, keithamus, mario, mattking, peter, peterkrautzberger, Rahim, sarah, sarahhigley, scott, smockle, spectranaut_

Active on IRC: Adam_Page, BGaraventa, filippo-zorzi, Francis_Storr, giacomo-petri, hdv, jamesn, katez, pkra, Rahim, sarah, scott, smockle, spectranaut_