5 ms·

> This element does not announce itself as an interactive element to screen reader users. Is this actually true nowadays? Given that advice like this is often

by 827a 1y ago

> This element does not announce itself as an interactive element to screen reader users. Is this actually true nowadays? Given that advice like this is often parrotted by people who don't actually use screen-reading software, I sometimes wonder if this is a situation where we've just been saying this and repeating this advice; meanwhile, screen readers have obviously become sophisticated enough to recognize that a div with an onclick handler on it is probably, you know, clickable and interactive.

mnhnthrow34 1y ago
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 1y ago
  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 1y ago
    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.
SoftTalker 1y ago
Screen reading software seems like it would have a very small market and I would expect it lags rather than keeps up with the ever changing ways people invent to build web pages.
isleyaardvark 1y ago
Screen readers have and continue to lag in implementing standards designed specifically for accessibility, so I would say they are obviously not sophisticated enough. (One example: https://heydonworks.com/article/aria-controls-is-poop https://heydonworks.com/article/aria-controls-is-poop)
pverheggen 1y ago
There are well-defined standards for how the role of every element is determined, and according to those standards, adding an onclick handler does not change the role. Screen readers also don't access the DOM directly, there's an extra abstraction layer. Browsers expose accessibility data to the appropriate OS API, and screen readers use the data exposed by the OS. There's too much variation as-is between different screen readers to be piling browser-specific behavior on top.
- 827a 1y ago
  Maybe. But, again, these are all hypothetical ideas. Its been over 24 hours, and despite getting multiple responses, none of them are of the form: "I have used ScreenReaderSoftwareX, and on the latest version it does not interpret divs with an onclick handler has an interactable entity even though it is".

by 827a 1y ago

mnhnthrow34 1y ago

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 1y ago
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 1y ago
  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.

SoftTalker 1y ago

Screen reading software seems like it would have a very small market and I would expect it lags rather than keeps up with the ever changing ways people invent to build web pages.

isleyaardvark 1y ago

Screen readers have and continue to lag in implementing standards designed specifically for accessibility, so I would say they are obviously not sophisticated enough. (One example: https://heydonworks.com/article/aria-controls-is-poop https://heydonworks.com/article/aria-controls-is-poop)

pverheggen 1y ago

There are well-defined standards for how the role of every element is determined, and according to those standards, adding an onclick handler does not change the role. Screen readers also don't access the DOM directly, there's an extra abstraction layer. Browsers expose accessibility data to the appropriate OS API, and screen readers use the data exposed by the OS. There's too much variation as-is between different screen readers to be piling browser-specific behavior on top.

827a 1y ago
Maybe. But, again, these are all hypothetical ideas. Its been over 24 hours, and despite getting multiple responses, none of them are of the form: "I have used ScreenReaderSoftwareX, and on the latest version it does not interpret divs with an onclick handler has an interactable entity even though it is".