Looking for people who regularly use screen readers to browse the web.
A dev version of #keyoxide [1] currently has 100% #accessibility score by #lighthouse [2] and 0 errors according to WAVE [3] but still I'd hope to receive some real-world feedback and ensure what I develop can truly be used by all.
Boosts appreciated.
[1] https://dev.keyoxide.org
[2] https://web.dev/measure
[3] https://wave.webaim.org
@keyoxide Awesome to see more people paying attention to this! ☺️ I had a look at the 2 sites, and 2 things stood out. The minor one is that the top navigation menu really doesn't need to be so verbose, just saying "About" instead of "Go to the about page" is totally fine, like the links in the footer do even now.
The more serious issue is, on the first page, the group radio buttons to set the protocol are correctly spoken as a "radio group", but the actual buttons themself are just announced as text, without the screen reader saying it's a radio button and more importantly whether it's checked or not. I checked this both in Safari and Brave on a Mac and Chrome with NVDA on Windows.
@pitermach Thanks a bunch for the feedback!
- I'll fix nav (shorter labels)
- Ow, that is interesting because they are actually inpup[type=radio] elements. So I should fix that with a role=radio maybe? I'll try this later this evening
@keyoxide No problem, and re those radio buttons that should work I would think if it's just a normal radio input... and clearly the testing tools think so too :)
CC @marcozehe if you have some time maybe you could take a look? Perhaps you might see something obvious with your experience. Either that or we just found a bug of some kind
@pitermach @keyoxide @marcozehe Looking at that radio group... radio buttons appear to be hidden with CSS and focus is placed to their labels with tabIndex="0". I think it would be better to style the radio buttons to your liking rather than hiding them and restyling labels to look like radio buttons.
@pvagner thanks again for the feedback. I've done away with the abomination of giving the focus to the label.
It seems to work nicely with keyboard arrows, but the moment I turn orca on, the arrows no longer work as I think they should. Could you confirm the current iteration works better or indeed is still broken? Thx :)
@keyoxide I think most screen reader users are used to it hearing all sorts of identifiers including user names, passwords, pass phrases. Some technical people even uids, fingerprints and similar. Perhaps generating emojis or short phrases might ease comparing them similar to how non screen reader users are doing it. Definatelly I wouldn't like to have these hidden somewhere. @pitermach @picasoft iok@mastodon.social @Mayana would you add something?
@pvagner @keyoxide @picasoft @Mayana The way I'd look at this is, if this is what you see on the screen, then that's what the screen reader should read even if it might sound weird. The fact they might be long isn't really an issue because we can just move on from that line and keep reading the page. I'm personally used to hearing cryptic alphanumeric strings, they're now really common in URL's for example so I don't really find it a problem.
@pvagner if I may ask one more thing, what is your opinion on the screen reader reading cryptographic fingerprints aloud? It's vital information, but at the same time, it takes a lot of time to read and it sounds weird when it reads the digits not as digits but as long numbers 🤔