| Threads | https://threads.net/fongandrew |
| BlueSky | https://bsky.app/profile/aftd.dev |
@siblingpastry Visually, this would look like a list of items, some of which are a different color / styled differently to denote an exception state.
Off the top of my head, I could just denote the error state via a `aria-describedby` and do some autofocus-ing on a bad submit. But I'm not sure if that's enough.
@siblingpastry They do, but if the dialog is closed, then the states are hidden.
Example: Suppose a user fills out a list of contacts and wants to bulk submit all of them at once. For compactness, each address is represented as a single button that opens up a dialog with subfields for name, address, email, etc.
For whatever reason, suppose the user is allowed to close the dialog with incomplete or invalid info (e.g. it's a draft or we have some async process that later marks the contact as invalid). Is there a standard way to say "hey, you need to open and fix items 3 and 6 in this list"?
Hey #a11y folks, suppose I have a form with a button that opens a mini-form in a popover or dialog. Does it make sense to stick things like `aria-required` or `aria-invalid` on that button if things in the mini-form are required / invalid?
On one hand, this feels semantically wrong? The button itself is just a trigger and can't really be "invalid" in anyway. On the other, since the actual invalid elements are in the popover or dialog, there's no other indication of this state (apart from manual descriptions).
I'm a fan of using #Playwright snapshots for visual diff testing but I have a hard time making it work in CI. I develop locally on macOS but the CI job runs in Linux, so there's often a significant mismatch due to font aliasing. How do folks handle this?
I've tried adjusting sensitivity but too much and the tests end up missing things. I'd also prefer to use things I can run entirely on my own (e.g. no Applitools). #webDev #testing
Andrew F
Ricki Yasha Tarr
