17 ms·

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

by dingus 8y ago

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

warent 8y ago
> "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.
- uberswe 8y ago
  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.
- jitl 8y ago
  >> 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.
- bryanrasmussen 8y ago
  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.
- pure-awesome 8y ago
  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.
ahje 8y ago
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.
quicklime 8y ago
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.
- beaconstudios 8y ago
  > 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.
- dingus 8y ago
  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.
  - FearNotDaniel 8y ago
    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?
leowoo91 8y ago
+ see if browser's readability function works (for long-read pages)
- dingus 8y ago
  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.
beaconstudios 8y ago
> - 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?
- jimktrains2 8y ago
  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.
- acdha 8y ago
  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.
Jemm 8y ago
Many sites break at moderate zoom levels.

by dingus 8y ago

warent 8y ago

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

uberswe 8y ago
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.
jitl 8y ago
>> 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.
bryanrasmussen 8y ago
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.
pure-awesome 8y ago
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.

ahje 8y ago

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.

quicklime 8y ago

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.

beaconstudios 8y ago
> 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.
dingus 8y ago
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.
- FearNotDaniel 8y ago
  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?

leowoo91 8y ago

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

dingus 8y ago
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.

beaconstudios 8y ago

> - 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?

jimktrains2 8y ago
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.
acdha 8y ago
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.

Jemm 8y ago

Many sites break at moderate zoom levels.