Has anyone noticed that Zoom for Windows uses text fields which are technically inaccessible? They work around this by giving screen reader alerts whenever I use the arrow keys, select text, or delete characters.
Naturally, they don't just pass through the punctuation symbol to the screen reader, because they can't predict which punctuation will get spoken by the screen reader otherwise. So the names of symbols probably won't match the ones in a screen reader. It seems to be based partially on the JAWS symbol dictionary.
On a Braille display, the control is borderline unusable, because there's no cursor representation and any navigation or deletion will replace the entire text field with the announcement. If you type the word "potatos" and then discover there is only one potato, pressing the backspace will replace everything on your Braille display with a line that says "s deleted".
And to top things off, the announcer seems to completely ignore emoji characters and they don't seem to show up in the weird limited object navigation either, so there's no way to confirm you've typed them.
I wonder what kind of absurd design choice or company culture problem led to this need to completely reinvent the wheel for a text field of all things. I know QT had cursor tracking issues in text fields, but I thought that was fixed long ago.
Simon Jaeger
npub1ez…qwagq
2025-10-02 00:14:10 UTC
Author Public Key
npub1ezwmkgpt0tlgn2kgz385gph3qfrqcc7z02qgg5xkkcg0dtg2cmfstqwagqPublished at
2025-10-02 00:14:10 UTCEvent JSON
{
"id": "4a7ed2ffb3c126f6986aebcc8a108afd665e2b25c5dfeee5b2e3cef29ebd48cb",
"pubkey": "c89dbb202b7afe89aac8144f4406f102460c63c27a808450d6b610f6ad0ac6d3",
"created_at": 1759364050,
"kind": 1,
"tags": [
[
"proxy",
"https://procrastodon.net/users/simon/statuses/115301682410704936",
"activitypub"
],
[
"client",
"Mostr",
"31990:6be38f8c63df7dbf84db7ec4a6e6fbbd8d19dca3b980efad18585c46f04b26f9:mostr",
"wss://relay.mostr.pub"
]
],
"content": "Has anyone noticed that Zoom for Windows uses text fields which are technically inaccessible? They work around this by giving screen reader alerts whenever I use the arrow keys, select text, or delete characters.\nNaturally, they don't just pass through the punctuation symbol to the screen reader, because they can't predict which punctuation will get spoken by the screen reader otherwise. So the names of symbols probably won't match the ones in a screen reader. It seems to be based partially on the JAWS symbol dictionary.\nOn a Braille display, the control is borderline unusable, because there's no cursor representation and any navigation or deletion will replace the entire text field with the announcement. If you type the word \"potatos\" and then discover there is only one potato, pressing the backspace will replace everything on your Braille display with a line that says \"s deleted\".\nAnd to top things off, the announcer seems to completely ignore emoji characters and they don't seem to show up in the weird limited object navigation either, so there's no way to confirm you've typed them.\nI wonder what kind of absurd design choice or company culture problem led to this need to completely reinvent the wheel for a text field of all things. I know QT had cursor tracking issues in text fields, but I thought that was fixed long ago.",
"sig": "5ad8a93a5e33ada33d793d4f509b298b67106b0565671f4f16edfa5ae5a3a8a16f5a0323828af5f2c9f6a3be6bea22c9d27fbff253493bc113a6c2541c496a7e"
}