You can know. Just talk to people who use assistive tech. Don't guess at how to improve what you build. Hire a diverse team who know these problems because they encounter them. Hire consultants. Just reach out to your friends to find someone who'll spare an hour of their time in return for a coffee - I guarantee that they'll be amazed and so damn happy that you want to make your code work better for them.
Also, and this is critical for understanding why accessible software is worth building, you should also realise that making something accessible makes it better for everyone. Accessibility features like enabling keyboard navigation of an app improves the user experience for everyone who chooses to use that feature, not just for people who need that feature. I believe that if you think of adding accessible feature as "enabling powerusers" you stop finding excuses not to bother.
I agree this is far from ideal, but it is better than nothing.
You obviously need to be tactful about it, but if you're genuine and willing to listen to people about the problems they face and you're in a position to solve them, in even just a tiny way, they won't be annoyed. Totally the opposite in fact.
People assuming things like "they'll be annoyed to talk about the problems they face" is really another form of discrimination. It's so much better not to make assumptions about people and let them decide if they'll help you or not.
In addition you can bet not many disabled people want to be a walking survey of the problems they face. To that effect, you can check any disability forums, which are littered by engineers wanting feedback on their products. Hell, just look at the top post of /r/blind written 6 days ago.
FWIW, I did talk to a screen reader user for this article (the accessibility consultant I mention – he is the chair of a local blind union), but indeed I don't know anybody personally and he could have easily brushed me off as random cold emailer, so I'm grateful for his comments.
Mac comes out of the box with VoiceOver (I think iOS does too.) A lot of software either has directly or as an extension colorblindness filters.
Is this real? If this is really the case, it would explain why my observations of UX feel delightfully negative. There's too much focus on themselves and not on the user.
GUIs are discoverable and you can add a lot more features without needing to justify learning them all or Googling every time.
Which means they are are very well suited to true premade software, wheras CLI always seems to imply a more build it yourself approach with simpler primitives, which can take time.
GUIs also don't have to be consistent, CLIs do if they want to be easily scriptable, so you can have a lot more context sensitive stuff, confirmation prompts, etc, which increases safety.
CLIs always seem like they're pretty much digital versions or passive tools, they don't really do anything, the user does.
The usual CLI workflow seems to be "Take an input, do this thing I already thought of in my head to it, and nake this output", wheras GUIs seem to better lend themselves(for better or worse) to actually being the stage on which the thinking happens, the same way you can use a CAD even if you can't see the whole thing you want to make in your head.
Which makes GUIs amazing for occasional tasks, that one might otherwise not want to learn a whole program for, and forget by the time they need it again. I suspect that is key for allowing computers to take over as many tasks as they do.
I almost think that CLI fans seem to not do as many random assorted things on computers, and are more likely to use dedicated devices or analog/mechanical. CLI seems very well suited if a lot of your computer use is real computing, taking an input and making an output.
I've never investigated this functionality before - which is shameful, as my main side project is a JS library targeted at making the HTML canvas element more accessible to users (like the author, I have no need for accessibility enhancements in my daily work or life). So I popped over to my library's test/demo page and followed the instructions for invoking pointer move/press/release/etc actions via the keyboard. From my brief investigation, the actions seem to work as expected in those demos that test/use pointer hover/click interactions.[3]
Reports of shortcomings in my library, when it comes to accessibility issues, are always very welcome!
[1] - Control the mouse pointer using the keyboard in MacOS https://support.apple.com/en-gb/guide/mac-help/mh27469/mac
[2] - Control the mouse pointer using the keyboard in Windows https://support.microsoft.com/en-us/windows/use-mouse-keys-t...
[3] - Scrawl-canvas testing and demo page - https://scrawl-v8.rikweb.org.uk/demonstrations
In a real retail business, what would you do for customers that needed some type of assistance, whether reading labels or navigating the store? Hopefully you would help them out as needed with a customer first ethos and not treat them as 'disabled'. If anything, their money is going to be yours quicker than with those 'able bodied' customers because you have gone out of your way to help them.
Chipping away at the 'accessibility' of a website, there is a long way to go before getting the 'aria' properties right on every link. Text might be below the size Google deems 'accessible'. Making that text big and chunky might upset designers who want the customer to be browsing by pictures not words. If you argue the case from an accessibility viewpoint they are imagining wheelchairs and they don't see their customers that way. However, if you can argue 'putting customers first' floats their boat. "Won't have text too small for Google" and "so the typical customer can read the text" is still about accessibility but you are not using the 'a' word.
For me the fun in accessibility is this word play, to persuade a wider team that has its own inertia and SEO religion to 'put the customer first'.
>a customer first ethos and not treat them as 'disabled'
That's a weird way of phrasing it. It sounds to me like you try to play accessibility and customer focus against each other. I'd argue that speaking about "customers" instead of "humans" is counterproductive and only some kind of commercial websites like online shops could be compared to a retail businesses. Also, "accessibility" is not a buzzword.
Maybe you could get comfortable with the term universal/inclusive design?
https://sayyeah.com/digital-insights/universal-design-access...
>Text might be below the size Google deems 'accessible'
Which Google guidelines you are referring to?
>Making that text big and chunky might upset designers who want the customer to be browsing by pictures not words.
Do you assume good design and accessibility can't go together? Developing an accessible product generally means that ideally everyone involved has some basic knowledge about a11y. I totally agree that using "SEO" to justify certain decisions is (almost always) a bad idea. Referring to detailed guidelines like the WCAG may be helpful in order to get everyone on board. Obviously designers will get frustrated when told without explanation or context that their design needs to be changed in favor of a11y.
I am wondering whether there are similar mechanisms for non-visual, non-mouse contexts. I don't think the solution is to add an endless stream of background noises to our websites. I fear the article is correct when it says:
> This leaves the entire burden of branding on voice & tone alone.
Animations may look like fun, until you're in some slow remote desktop. I don't want to be mesmerized by the way some dots move in response to the pointer; I want to know whether that bill got paid or whatever, or check the status of some application.
Bad accessibility is bad for everyone, not just people who are visually impaired.
But in my experience, accessibility is the 100th bullet point on the to do list and most everyone agree that it's the right place. It's so true that in Europe, there's now a law that force everybody to have accessibility.
Coincidentially that crowd also has looser wallets.
