3 ms·
Off topic and feel free to ignore but here goes: do you know of any low hanging fruit stuff I can do on web/front-end UIs that will help me get my sites/apps mo
by klabb3 5y ago
Off topic and feel free to ignore but here goes: do you know of any low hanging fruit stuff I can do on web/front-end UIs that will help me get my sites/apps more accessible, that many developers miss? And secondly, do you know of a way to quickly simulate the experience a visually impaired person has without learning/using a screen reader? (As a solo developer, I don't have the time to dive too deep)
- cobertos 5y agoTake with a grain of alt b/c I'm not blind and my accessibility training is not formal, just learned from a job. The built in mobile screen readers are not hard to setup. Enable in the settings and you can play around with it to grok how it works and how to navigate the UI tree with it. Lowest hanging fruit always seemed to be making sure all the controls you wanted on your page were reachable with accessibility navigation (ie tabindex/focusable) and that the spoken labels were sufficient without sighted context.
- bryanrasmussen 5y agoIf you're on a mac of course the easiest screenreader to use is voiceover, if on windows NVDA - problem there is not wide consensus among screenreaders about functionality, so you will read about a way to do something and think that is the way to do this but when you actually start doing it you find it isn't going to work the way you thought, if at all. This means if you do anything good you will need to test on different screenreaders, I like https://assistivlabs.com/ https://assistivlabs.com/ for a service to allow you to do screenreader testing also because the developer who runs it is really helpful. It also means the best ways of doing things tend to be the ones that have been around longest because every screenreader / browser combo has implemented different parts of newer specifications - that is to say it will feel like your chosen screenreader is Chrome, but all the other ones are IE11. I personally find that what helps you most about understanding when a site is not accessible enough is, after you have read a bit about problems people with screenreaders have, imagine using your site if you were blind. Because you are blind things happen atomically, you do not have an context clues that you can see about what something is, so actions you can do on stuff should probably say not just what they are doing - like a button that says Delete - but what they are doing it to - like a button that says Delete and has an aria-label that says Delete user account. Really - being willing to sit still for 20 minutes looking at your site and thinking but what if I couldn't see will probably help you find a bunch of obvious problems. Also when you have a sort of good fundament to your sites assistive usage, it means that things will be a lot easier when you do start testing on different screen readers. on edit: obviously when I say because you are blind things happen atomically, I mean that in the context of using a screen reader on a webpage
- klabb3 5y ago> Really - being willing to sit still for 20 minutes looking at your site and thinking but what if I couldn't see will probably help you find a bunch of obvious problems. Yes, I'm hoping to acquire this mindset. What I'm building is quite simple, almost crud like in terms of the UI. The issue is I don't feel I get the mindset just yet. I understand speech is linear, and I assume the order mainly comes from how it's laid out in html (as opposed to position). But how do visually impaired navigate the items in this big list, intuitively and quickly? I assume focusable elements are critical, but how about the the rest of the content hierarchy? A row in a table doesn't tell me anything if I can't see the header simultaneously - for instance.
- bryanrasmussen 5y agoif your table should be a table and is correctly coded as a table pretty much every screen reader will make it usable, in this example https://www.w3.org/TR/wai-aria-practices/examples/table/table.html https://www.w3.org/TR/wai-aria-practices/examples/table/tabl... using voiceover you read the table it tells you the column names, probably in reading a table you would probably first read all the headers so you know what the table is dealing with - here these are first name, last name, company, address. If you know what value in the table you are looking for you would go to that column, for example last name the second column, then navigate down with the voiceover key combination and the down arrow to get to the row you are interested in - row 2 James I'm looking for sara james so let's go to the first name column, then you could use voice over key combination and left arrow to go to the first name column and see it is Sara, then you read all the contents of that row to find out Sara James, Acme, Inc., 123 Broad St. Obviously you need to remember the headers in this way of working, so if your tables are really complicated and have a lot of data in each column it might be nice to put a hidden screenreader only message in there that says Contents for First Name Column or something like that. But in this simple case I think it is reasonable to assume people will remember the column headers. on edit: this is from a developer who is not blind however, so a blind user may have more efficient ways of working than me. Also note, many screen reader users are not completely blind or have some other disability, like dyslexia, which makes using a screen reader useful for them. A dyslexic user may be able to figure out the headers of the table, but if the individual cells have a lot of content the screen reader will be useful for them.
- eru 5y ago> Off topic and feel free to ignore but here goes: do you know of any low hanging fruit stuff I can do on web/front-end UIs that will help me get my sites/apps more accessible, that many developers miss? Not sure if many developers miss this: Look at your UI in black/white. Plenty of folks are colour-blind of one kind or another. If your UI works in black/white, it'll probably work for any kind of colour-blindness. See also https://www.youtube.com/watch?v=-IhQl1CBj9U https://www.youtube.com/watch?v=-IhQl1CBj9U for something focused on games, but with broader applicability.
- mathieuh 5y agoAdd Pa11y to your CI: https://github.com/pa11y/pa11y https://github.com/pa11y/pa11y Another good resource is the GDS accessibility standards: https://www.gov.uk/guidance/guidance-and-tools-for-digital-accessibility https://www.gov.uk/guidance/guidance-and-tools-for-digital-a... It's tailored towards creating services within the GDS portfolio of services but there is good advice in there too
- lproven 5y agoAbsolutely. One is dead easy, quick, and free. Step 1: Use a desktop PC. Step 2: Unplug your mouse. Now learn to use your computer and then your site. Windows is basically 100% usable by keyboard alone, and that basically is how all blind users use it. They can't see a pointer so pointing devices are useless. I am Very Old™ and I learned Windows in the 1980s in a company that sold Macs as well as PCs, so it didn't have any PC mice. So I learned to use Windows with keyboard only. I still can, although it's harder now. But I now run mostly MacOS and Linux. Windows works very well with the keyboard and I sometimes amaze people by how fast I can move around and do stuff, because I don't take my hands off the keyboard or point and click much. I use the keyboard to run programs, move and rearrange windows, close windows, select and copy and paste, navigate forms etc. All standards-compliant Windows programs use the same keystrokes to do this and they work everywhere. Learn them and you'll become faster anyway, _as well_ as improving the accessibility of your sites by becoming familiar with how blind users must access them.