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