Hacker News Reader

Comment by wouldbecouldbe | Hacker News Reader

Not a joke. If truly you want a properly functioning website for blind/bad sight/ Step 1 would probably be to put on a blindfold and go through your website with a screenreader (cmd + f5 on a mac).

View on HN

I always wonder why this isn't a bigger part of the discussion. None of us would develop a visual UI flow without trying it manually at least once, but for some reason this idea isn't extended to discussions about accessibility. The advice always fits into these three groups:

1. Follow a checklist

2. Buy my software

3. Hire blind people to test your app

I'm not saying that these are bad (although some overlay software is actually worse than nothing), but aren't people even a little bit curious to try the user experience you're shipping?

There are popular, free screen readers out there and using one can teach you a lot.

Can't speak for others... and though visually impaired, I don't think I could handle navigating with a screen reader myself. I've sat through blind testing before and it's definitely impressive and I learned a lot. I will say that I do make an effort to do a lot of keyboard only navigation as part of testing. Just that can help a lot in terms of limiting janky UX.

Especially with flexbox and other more modern layout options.

Perhaps a blindfolded person and a person who has always been blind have very different expectations of how to use software, such that they would give divergent opinions on what makes a good screen reader UI.

In theory this is certainly true. In practice the most common experience is software where UI elements are completely unreachable from the keyboard, and/or have no label at all. If you talk to tech-savvy Blind people for a while you invariably hear things like "the app doesn't have labels but I know the third link is the settings page, so I just count until I hear 'link' 3 times". Most people aren't going to hire an outside person to test their project, and frankly I think that's often reasonable for personal projects and small companies. But if you exercise the UI flow yourself, at least you know it's possible to use it.

Here are notes from last time I tried that: https://tools.simonwillison.net/aria-live-regions

It's not something I'm comfortable enough with to do on a regular basis though.

yeah its a real challenge, but probably the only way to really understand it. It's a completely different way of using the web. GPT can really help understand it while doing it.

Yes, I did this! https://wonger.dev/posts/blindfolded-deployment I navigated GitHub with Windows' default screen reader, and videoed the process and wrote up my learnings. It changed the way I build websites because I'm always thinking about the screen reader routes in the back of my mind. Highly recommend.

MacOS has a VoiceOver tutorial.

It’s pretty eye-opening (heh) to do it and then try to use your websites.

Before you even get to aria labels, you’ll find a lot of things to fix like:

- Add or remove components from tabindex

- Esc should close the modal or the slide-out sidebar

- Closing the sidebar/modal should return focus to the button the user toggled to open it (this one is huge for UX)

I recommend it. These things are useful for keyboard nav in general.

What’s frustrating is you basically are required to use JS when basic css and html would normally work. There’s been some improvements thanks to the dialog and popover apis but it’s still not fully there yet.

Also seems the large companies that have to have compliance only care about it from a legal standpoint and are fine with just making the tests pass from whatever compliance company they use.

Using a good component library goes a long way here... I've yet to see a better overall experience than React+MUI myself. Though you should adjust the default color palette.

I'll add focus the first input field, or the error section at the top, when full-form validation fails. And related, don't allow modals to render buttons off-screen when text/display zooming is maxed out on mobile devices (personally see this a lot).

I would very much like to be better at building websites that handle assistive technologies like screen readers well. I don't have a lot of blind users to worry about because they don't let you be a firefighter if you're blind.

But a lot of firefighters are people who simply did not do well in school, even the very senior ones, and that's because they are often very clever people who are of an age where things like dyslexia were just not diagnosed early or often.

So now I deal with a lot of people who use assistive technologies to help with dyslexia and related comorbidities. I have dyscalculia that wasn't diagnosed until I was 19 and at uni, and even then it was diagnosed initially by my mate's Educational Psychology undergrad girlfriend in the pub one evening. That was in the early 90s and we're better at it now - but not by much.

Yeah i don't think it's worth doing for every web app. But I do think it's fair that for instance government websites try to meet these criteria.

It's funny what you have to do to tick a box on a Government form. A long time ago when I was relatively new in the job I thought I was being pranked (ohoho let's noise up the new guy) because I got asked to take a record when I went to site to repair network stuff, of which sites had a wheelchair-accessible entrance, accessible from the street.

o_O

All of them?

There's a door at the front and the back with a gentle ramp down to street level, flat access into the building, and the door is like twelve feet wide and fourteen feet high which is big enough for even the most impractically large wheelchair, surely?

+1, or simply hire a blind person to run one or more stages of QC on your application.

Adjacently, I cannot state enough how much I wish other toolkits would offer component libraries as cohesive as MUI is for React... the use of Aria is "just right" IMO and is far more broad, complete and cohesive as a whole (aside from some poor default color/contrast choices in Material defaults inherited from Google).

Another thing that bugs me to no end, since I've developed some visual impairments, is sites/apps that don't function on mobile devices with text/display scaling cranked up. Modals where the buttons are off-screen and no way to scroll to them are useless, similarly allowing text to go too big (gmail) to where an 8-letter word gets split and wrapped.

All around, I definitely think that if you're spending 8+ figures on application developers you can afford testing by a few people who are visually impaired and blind.

Earlier in my career, I sat with a blind user through testing a bunch of eLearning content and it was really eye opening back then... the establishment of aria labels helps a lot... but as the article mentions, you need to use them right. I find that more often than not, using the right elements/components, labels, titles, etc in the first place goes a long way.

yeah but at least sit next to the blind person, I've heard so many people talk about aria tags (myself included) without actually trying it once themselves or at least seeing a video how impaired people actually use it.

I say through testing with a blind person for e-learning content a while back. It's definitely eye opening, so to speak.

Keep in mind, this is only one area of accessibility. Neurodiverse users, users with cognitive issues, users that have a hard time using a mouse, low vision users and even deaf users all have specific issues.

Simply testing with a screen reader is missing entire groups of users.

+1 on this one... I've mentioned it a few times in these threads already... but for the love of all that is holy, try your mobile website/app in an actual phone where you have accessibility turned up for text and display.

I cannot tell you how many times I've experienced modals with buttons literally off screen and no navigation option in apps from multi-billion and trillion dollar tech companies. Almost as bad is gmail allowing text to scale so insanely large that it's equally unusable.

I'd argue it's pretty hard on Windows.

NVDA hasn't worked for me since Windows 11.

Narrator + IE and Narrator + Chrome basically work but make ARIA look like vandalism. It will just be reading the text and blurt out "LANDMARK WILL ROBINSON!" in the middle of the text for no obvious reason and doesn't do it the same very time. It's basically possible to use either one of those but Narrator + Firefox is especially spastic and blurts out random landmarks and ARIA junk to the extent that it's really difficult to evaluate.

I mean, that's part of the problem, there is a spec for how HTML is supposed to be rendered, but ARIA is not specific about how ARIA markup is rendered which might means tools could bend to meet users' needs but it also means there is no such thing as "I've convinced myself that my ARIA markup is proper and will work for everyone with mainstream tools"

Sounds like you might have content that’s changing? But what you’re running into is exactly what a user would be running into.

No, I just don't there's a specification for what exactly a screen reader is supposed to with ARIA markup.

For example it could show you or read to you a list of all the nav landmarks on the page, which would be (1) helpful for end users, and (2) sure as hell helpful for me as a dev so I can know how the landmarks work as a system. All screen browsers really seem to do is blurt out "NAVIGATION LANDMARK!" randomly before or in the middle or after the <nav>

Reply on news.ycombinator.com