Web developers and designers,
What are you hoping to see at WWDC next week??
@jensimmons it'd be nice if Webkit would include the same accessibility semantics for popover that Firefox and Chromium have https://hidde.blog/popover-accessibility/
oh and hoping no LLMs will be added to the browser
@hdv @jensimmons What is WebKit missing in this case? Off the top of my head aria-details isn't done but iirc the aam says not to do anything with it for AX API?
It would be nice to get the light dismiss bug on iOS fixed though!
@Lukew @jensimmons last time I checked it doesn't set aria-details (under specific conditions) and doesn't set the group role as a fallback.
the HTML AAM PR is still open (https://github.com/w3c/html-aam/pull/481) and no WPT exist for it yet, but Chromium and Firefox already have this behaviour
@hdv @jensimmons group fallback role is possibly an issue, the aria-details is per spec.
@hdv @jensimmons Fwiw I don't think WPT can even test this stuff, except the role, (yet*). Even the latest additions only cover role and label, which is a tiny subset of the accesibility API surface area. Not to say they're not a big win but we need more. One of my colleagues presented on work they've been doing to try and get testing of the actual accesibility APIs into WPT. That way we're not reliant on the browser to tell us the truth, and we can cover all the specifics of each API mapping.
@Lukew @jensimmons yep that's my understanding too, just roles at the moment! didn't know about labels (names?) that's nice
@hdv @jensimmons Yeah I think it's accessible name but aria refers to it as a label so that's what the function is called. Though again because it's at the browser level it relies on the browser not to "lie".
https://bugzilla.mozilla.org/show_bug.cgi?id=1901324 this bug can't be caught by those tests for example, computation is correct, API call is wrong.
https://bugs.webkit.org/show_bug.cgi?id=275222 this one can be caught because the computation itself is wrong.