@heydon I just went in a delightful circle:

Earlier my feed gave me a Marijke Luttekes post on buttons vs links:
https://marijkeluttekes.dev/blog/articles/2024/11/04/html-link-or-button-that-is-the-question/

Then I got this button article, which made me question a good full approach for lightboxes and similar, so I remembered Adrian Roselli's https://adrianroselli.com/2020/02/block-links-cards-clickable-regions-etc.html

And re-reading that led back to Heydon Pickering's own: https://inclusive-components.design/cards/

Now I want to skip my actual work for the day so I can experiment combining the collective advice into demonstrations.

@ultranurd I haven't seen studies, but my wife has a long commute and has strongly and repeatedly had this view (Seattle)

@risottobias @bascule As I read it, the hashes for any (long) username will collide with any others hashes for that same username even with different (wrong) passwords (as the message was getting truncated before the password in the message). I believe that means you could login as that user using any password - the password check would pass.

The advisory mentioned this also required hitting the (on prem?) cache instead of a live service, but I don't know what that is part of.

Random web #a11y question:

If I have a dropdown menu of links using a button as the main choices to trigger the dropdown, but want to just present the list of links to a screen reader, what do I do with the buttons?

aria-hidden shouldn't be placed on focusable elements, and the button content is relevant text anyway, but a button that doesn't need to be a control for screen readers feels confusing, and requiring the button be focused as for non-screenreaders feels pointless.

@octothorpe @ultranurd Huh, I was thinking the opposite - the only people that consider an informative headline to be a "spoiler" are the ones generating content I don't want to consume.

Others the subject line would be doing its job.