Meeting minutes
zakum, next item
<Francis_Storr> here you go: W3C IRC cheat sheet: https://
<spectranaut_> https://
<jcraig> https://
<spectranaut_> w3c/
spectranaut_: clarification aria braille label
jcraig: first one should be a must instead of should
jcraig: couldnt come up with an example where you would want a braille label and not a label
myasonik: aria live wont announce to braille readers
jcraig: lets not jump to a conclusion on this issue
… they didn't make it a must to begin with
… if aria live isn't announced that is a bug
spectranaut_: change this to amust and change it to a link to accessible name?
<scotto> +1 to fix aria-live support for braille (move forward with the notification api) rather than create a loophole for inserting what should be a live announcement into a braille label
<spectranaut_> w3c/
<spectranaut_> respec bug: w3c/
spectranaut_: next issue, examples missing content
jamesn: want to talk about this in editors meeting
… we shouldn't hide the examples
<scotto> +1 to removing the details/summary
<Adam_Page> ditto
New PR Triage
<spectranaut_> w3c/
spectranaut_: first issue, aria controls spec update
scotto: aria-controls should cycle through controlled elements
… this was prompted by nvda
scotto: ... additional logic needs to be spec'ed out
… this pr will add more context to what will be helpful, additional functionally with AT or browser
<spectranaut_> w3c/
spectranaut_: next issume, add mention of image role
WPT Open PRs
spectranaut_: recruit more reviewers?
jamesn: why are these wpt-chrome-dev-stability tests that fail?
jcraig: not sure
Rahim: one common test error: duplicate test names
TPAC 2023
jamesn: there are 20+ issues
StefanS: many of these are circling around uncertainty
jamesn: need more description for these issues
… be prepared to introduce them and drive the discussion
spectranaut_: need to prioritize these issues, some of these can be topics in our regular meetings
… members who are attending should comment on these issues
StefanS: "validator runs punishing devs", this issue is most important for the devs at my company
… you have a label thats not distinguishable from other labels
jamesn: can you make sure you file them against the right spec
<Zakim> jcraig, you wanted to disagree. I think this is an author error and the validators are correct to flag this every time.
jcraig: agree with jamesn that, if this is an issue (not sure it is), then this is a wcag issue
<spectranaut_> discussing: w3c/
<Zakim> jcraig, you wanted to request a more objective issue name too and to suggest ~"unique link names may not be necessary in tables" when you move it to the WCAG repo... "validator punishment" isn't as useful or clear.
Discussion tracking for ARIA Notification proposal
<spectranaut_> https://
spectranaut_: does notification api need to support "labels"
Doug: the goal of aria notify: provide quick strings to give to user
… no context for that string
… give screen reader context for what this label is for
… do we want to provide guidance or "must"s for this
Matt_King: activity id seems like a good name to me
"label" is confusing, doesn't explain the concept well
jcraig: "activities" are a different thing in voiceover btw
… "id" implies uniqueness
… maybe "type"
… "on Windos is is expected a user would have granular control over a per-domain or sub-site? e.g. on Google docs, I want to supress these kinds of ids" -- is this what we want
<jcraig> or notification context
Doug: provide users ui that show all strings, allow users to filter these strings
Doug: ... let the user select what they want to hear for something like "bold on/bold off", either blip sounds or the speech itself
jcraig: would like to see a demo with this potentially
Matt_King: i rarely dive into this type of customization
… on the implementation side, i think the author would come up with the tokens
<pkra_> have to run. bye everyone
jcraig: modern mobile OS don't offer this level of granularity for apps. this onus for this level of granularity is on the app's business logic... used Uber as an example: I want pickup notifications, but not marketing notifications. that level of per-app granularity should be in app settings, not in the AT… especially because the UI would need to be reengineered in every AT on the system. this onus for this level of granularity is on the app's business logic... used Uber as an example: I want pickup notifications, but not marketing notifications. that level of per-app granularity should be in app settings, not in the AT, especially because the UI would need to be reengineering in every AT on the
… if you go to the app, you can control the granularity of the notifications
… similarly, granular selection should be on the web app
… not on the screen reader side
<jcraig> system./