Hacker News Reader

Comment by dingus | Hacker News Reader

- Use blind accessibility tools with your website. If you're on iOS/macOS enable VoiceOver, figure out how it works, close your eyes and use your website.

- Disable JavaScript and use your website. This may not be relevant for web apps, but regular websites should work normally.

- Try to use your website with only the keyboard.

- Try to use your website with extreme zoom levels and font size overrides.

- Monitor your resource sizes. Anyone with a limited connection (a LOT of people) will abandon your website because it loads slowly, or are paying actual money for the wasted bandwidth.

I'm not aware of automated methods that give better results than using your website with the actual accessibility tools yourself.

View on HN

I'm lucky enough to have a low-vision person who works as a tester on my team, and does our accessibility testing. It's very impressive watching/listening to him use a screen reader - I was really amazed at how fast he has it set to read the screen.

He does suggest all the things you've mentioned above, and it's good advice.

However one thing he also says is: don't assume that low-vision is the only type of disability. You also need to build software for people who are: deaf, have slow motor skills (e.g. avoid putting strict time limits on user actions, or making things jump around on the screen too much while people are trying to hit a target), lack fine motor skills (e.g. don't make a target too small), etc.

> However one thing he also says is: don't assume that low-vision is the only type of disability. You also need to build software for people who are: deaf, have slow motor skills (e.g. avoid putting strict time limits on user actions, or making things jump around on the screen too much while people are trying to hit a target), lack fine motor skills (e.g. don't make a target too small), etc.

These are also good UX guidelines in general.

I had the same reaction when watching blind YouTubers show how they use VoiceOver. It was so fast I couldn't understand or follow along.

A good takeaway was feeling their frustration with improperly labeled items. You want to order keywords first, for instance "March 25, created on" instead of "Created on March 25", because they have to wait through "Created on:" dozens of times, when they already know the label context.

Good points on the other accessibility areas.

Interesting that the en-GB pattern of naming dates ("25 March", not "March 25") would make it that much more efficient, but I imagine that's culturally unacceptable to the average US citizen?

> "Use blind accessibility tools with your website. If you're on iOS/macOS enable VoiceOver, figure out how it works, close your eyes and use your website."

I doubt this is going to be very effective. Sure, it's better than nothing at all, but this is akin to sighted person with zero blindness experience testing the effectiveness of a newly designed white cane, only a website is much more complicated.

You should always find someone with personal experience to test it themselves and provide feedback if you want a clear understanding of how it will actually work for that community.

Even if someone with personal experience is better I would still highly recommend testing these tools as it's not always clear how they work if you haven never used them.

I was really surprised the first time I tested one of these tools and now I know a few dos and don'ts when developing web apps.

>> Use blind accessibility tools with your website. If you're on iOS/macOS enable VoiceOver, figure out how it works, close your eyes and use your website.

> I doubt this is going to be very effective.

You are wrong. The only way for a primarily sighted team to build accessible software is to test and iterate on accessibility as part of day-in, day-out development practices. Think of it the same as localization for RTL languages or cross-browser testing: you should test in each environment you support before merging a change. Training and user-testing with blind community are important, but it doesn’t take a native Arabic speaker to notice broken layout in Arabic, nor does it take an Android device owner to notice usability problems in Android Chrome.

The best front-end engineers I know all have a VoiceOver hotkey on their dev machines and phones, and I regularly see them testing sites they visit for keyboard navigation, focus management, and VoiceOver usability.

I agree that you should find someone who is blind to test your site for problems that a blind person will encounter, however I think you are wrong about a website being more complicated than a white cane - or rather it is not a white cane one tests, it is the accessibility of the world around you with that cane, and the world around you is more complicated to understand with a white cane than a website with voiceover turned on.

With voiceover it will very quickly let you know if you have something important for the user to get to that either takes too long to get to, or is not accessible at all. Voiceover is a useful tool at the development stage, after you have your near MVP then please get someone with personal experience to give it a full test.

The metaphor is slightly off-the-mark. Testing a fancy new white cane would be like testing the accessibility tool itself. If you are developing that, then you definitely need an expert in such tools (probably a blind person).

However, developing the site is more akin to developing... a hallway? You can test whether blind people can navigate your hallway by closing your eyes and walking down it whilst using a cane. This is a bit easier- you just need to make sure there aren't obvious pitfalls and dangerous obstacles, maybe that there's braille on the doors etc.

Having an actual blind person helping you out in the second case is obviously preferable, but if you cannot, I think most blind people would appreciate you putting in the effort and at least trying to make it accessible, as opposed to the alternative of not caring at all. A lot of accessibility is standardized and there are guides to follow. It can sometimes be tricky, to be sure, but it's doable.

> - Disable JavaScript and use your website. This may not be relevant for web apps, but regular websites should work normally.

I'm not sure how this is related to accessibility? Are there tools for visually impaired people that don't work well with JS?

Traditionally screen readers didn't. I'm not sure if that's still the case.

However, with no JavaScript (and modern css) you can't change the randomly after load to indicate state, which may be difficult for a screen readers to get that back to a blind person.

It's less critical now that browsers have standardized on the ARIA interface so it's more likely that JS sites will work, as long as you use ARIA correctly, but also note that many users are on older combinations — e.g. JAWS on IE11 is still fairly common — and you have no easy way to measure screen-reader activity so it's hard to tell whether, say, the 5% of your old IE traffic is a high percentage of your screen reader users.

The other challenge is that many JavaScript-heavy sites have horrible fallback mechanisms and you would want to test to make sure that at least someone with a screen reader would have an idea of why they're not hearing any content.

+ see if browser's readability function works (for long-read pages)

Does anyone else find this to be incredibly inconsistent between browsers? Edge is probably the best, surprisingly. Safari is the worst, it sometimes ignores entire sections of an article, regardless of using correct semantic markup.

I basically gave up on this, and just focus on using the appropriate semantic HTML tags, it's not my problem if a browser mangles it.

That's a nice checklist. I'd like to add "Test with a console browser" too. If the site is usable in Links2/Lynx/w3m then it will most likely work for everyone.

Many sites break at moderate zoom levels.

Reply on news.ycombinator.com