—
"Instead of not being aware about the problematic approach the developer chose, they try to improve accessibility but – unbeknownst to them - create new barriers in the first place doing it." @marcus
@marcus I wonder about the statement “But what ARIA properties do not do is implement anything” since it isn’t exactly true, but maybe it would just cloud the article’s intent to describe that in more detail? @SaraSoueidan
@SaraSoueidan@siblingpastry Changed it to " But what ARIA properties do not do is implement key event handlers or other functionality of this kind. Most of the time, it only announces an element as something,…"
@marcus@SaraSoueidan That works 👍 You've inspired me to write and expand on this tangent, something like "ARIA doesn't do anything ... except when it does".
@siblingpastry@marcus@SaraSoueidan keep meaning to write up how roles determine which keystrokes are passed to the JS in windows SRs ... don't go beating me to the punch :p
@patrick_h_lauke@marcus@SaraSoueidan I wasn't planning to go into that much detail, more just general notes on the fact that ARIA sometimes does shit and that's why you always have to test for real.
But what are your plans? I'm happy to wait for you, then I can just link to you for details :-)
@siblingpastry@marcus@SaraSoueidan thinking a basic "why are my custom key events not working with screen readers (on windows)?" look at windows SRs and how they consume (or just filter) keystrokes before they even reach the page, and how the appropriate role (or, as nuclear option, role=application) can usually solve this. similar to my recent aria-live exploration, with tests and results if needed
Okay we won't conflict, I'm gonna be much more high level. I'll let you know when I'm about to publish and we can compare cross-references as applicable.
Add comment