Hi! I've been testing out the app myself as an NVDA user, and it's a really great project. While trying it out, I noticed a tiny, solvable problem for the visually impaired community. Currently, the transcript editor uses custom, word-by-word visual blocks on the timeline. Because it is built this way, screen readers like NVDA can't read the words sequentially, announce cursor placement, or let a blind user edit or delete words using standard keyboard commands.
Just a quick context for developers who might not have experience with screen readers: software like NVDA relies heavily on standard input fields (like native HTML text areas) to read text and navigate. When an interface uses custom visual elements for text words, the screen reader cannot see it. This completely prevent visually impaired creators from using the software
Suggested Approach:
To fix this without changing the layout for sighted users, maybe the app can implement a "bridge" approach:
- Keep the current visual word-blocks on the UI as they are.
- Under the hood or unobvious way, add a standard text field layer that holds the transcript string. Screen readers can easily hook into this standard element to read and navigate.
- Use a listener script to connect the two. When a screen reader user moves their cursor, highlights, or deletes a word in that standard text field, the script "translates" that edit and cuts or modifies the corresponding audio timestamp in the project.
This approach keeps your design intact but opens up the app to a whole new community of visually impaired audio and video editors. Hope you can look into this. Thank you!
Hi! I've been testing out the app myself as an NVDA user, and it's a really great project. While trying it out, I noticed a tiny, solvable problem for the visually impaired community. Currently, the transcript editor uses custom, word-by-word visual blocks on the timeline. Because it is built this way, screen readers like NVDA can't read the words sequentially, announce cursor placement, or let a blind user edit or delete words using standard keyboard commands.
Just a quick context for developers who might not have experience with screen readers: software like NVDA relies heavily on standard input fields (like native HTML text areas) to read text and navigate. When an interface uses custom visual elements for text words, the screen reader cannot see it. This completely prevent visually impaired creators from using the software
Suggested Approach:
To fix this without changing the layout for sighted users, maybe the app can implement a "bridge" approach:
This approach keeps your design intact but opens up the app to a whole new community of visually impaired audio and video editors. Hope you can look into this. Thank you!