Looking for people who regularly use screen readers to browse the web.

A dev version of [1] currently has 100% score by [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.


The example provided in the toot is currently misbehaving and will not load most of the time, my apologies for this. Working on it as we speak.

@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 This is soo nice! I'm following @keyoxide for a few months already. Recently I've created my profile at @marcozehe will have clearer suggestions but I can say that you don't need aria-label for controls that already have text content inside e.g. links in the navigation at the top.

@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 From #a11y related standpoint the experience of radio group at is now as I would expect. Arrow keys change the value and screen readers do report the selected radio button. Tested with orca on linux and NVDA on windows. Thank you!

@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 🤔

@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 @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.

I agree with @pitermach. You want fingerprints to be visible. That is the whole point of Keyoxide. While they may sound weird to you, we are more than used to things sounding weird.
There are certainly exceptions, but if at all possible, a website being accessible means that abled and disabled people should be able to access and do the same things on it. Hiding cryptographic fingerprints or changing them when a screen reader is detected would go against that.
Your website is perfectly accessible over here, @keyoxide. There's no need to overthink it. You have already done a lot more than most developers do, and ... thank you for that. A lot. :ms_blue_heart:
@pvagner @picasoft

@Mayana thanks for your advice and helping me make my project more accessible!

@pitermach @pvagner @picasoft

@keyoxide Also when orca is turned on it allows reading the content linearized by default in so called browse mode. If you press either r or shift+r you can navigate by radio buttons and activate by pressing space. To experience the keyboard focus of the page it-self press insert+a to switch to so called focus mode and then use tab or shift+tab to find the radio button and finally arrow keys to change the value.

@pvagner that works indeed. Thanks so much for your guidance, I'm learning a ton here 🤗

@keyoxide Is this still open? I am an NVDA user on windows, does that matter?

@weirdwriter hey there, yes, I still would love to hear feedback 🤗 With the current feedback, I'm planning a release on Monday so there is plenty of time for additional improvements!

The more diverse the platforms, the better. I'm testing all my changes with orca on Linux, so am curious how things work on Windows.

Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.