[mnhnthrow34]

Have you tested this? Often click handlers are on some non-interactive ancestor element, it is not a good heuristic for something being interactive itself or what name it should have. Sometimes the listener is on the body element and we just parse out the triggering element and do something.

[827a]

No I haven't tested it, that's what I'm asking.

This piece of advice, to me, just feels like a piece of advice constantly repeated by a bunch of people, none of whom actually use the software for which the piece of advice is meant to benefit. That scares me; like we've all lost touch with the ground truth on this one; I'd love to re-sync with it, that's what I'm trying to do, I just don't have the first clue how to do it.

[phatskat]

You can start with turning on eg switch controls on your OS, or the built in OS screen reader.

Also, a lot of professional accessibility devices by makers like Dynavox are expensive, so your best bet is seeing what documentation you can dig up.

This like WCAG guide accessibility standards, and coding to be in line with those is probably your best bet at achieving the goals of your website being accessible by assistive technology.

Everyone can guess what screen readers can do, everyone can also get a _basic_ idea of how they’ll actually work, but more often than not the people who will have the most experience are those with the least ability to affect change. Using elements for their intended purposes and coding to accessible standards is probably the most impactful way any of us as engineers can help ensure a smooth experience for the target audience.