Where's the fun in accessibility?
elisehe.inIt's good that the author is questioning how to make accessible content in ways that make the experience of using a site better for everyone, but it's incredibly disappointing that they scattered the article with points saying (I'm paraphrasing) "I'm not visually impaired so I can't know what this is like!"
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 can sympathize with the author. I try to learn about accessibility in my free time, so I cannot "hire a diverse team/consultants". I also don't want to annoy random people I meet with questions about their disabilities. So instead I read a lot. And when I write something, I am transparent about the fact that I do not have first hand experience (at least not to the point that I was unable to complete a task due to accessibility issues).
I agree this is far from ideal, but it is better than nothing.
I also don't want to annoy random people I meet with questions about their disabilities.
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.
Everything is discrimination by these standards. Disability is a personal thing for a lot of people, it's perfectly reasonable to be hesitant to ask people about it.
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.
I quite often run sites through screenreader software. It certainly helps find egregious problems.
Thanks for raising! I guess I feel it's a necessary disclaimer out of respect to people who do have the first-hand experience. But I can see how it can come off as an excuse for not getting it right, and it certainly shouldn't be.
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.
Also, a big step is just bothering to turn on and use the assistive technologies that come out of the box, or you can do without much difficulty.
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.
Some of those features also can be helpful when hardware starts failing. If a display breaks on a laptop, you can possibly use some screen reader features to save your work. And obviously, things that help the hearing impaired also help those who don't have working speakers at the moment.
> We’ve been taught that UX is not only about function, but about delight, whimsy, wit, and beauty.
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.
I haven't been taught that by programming blogs at least. They all seem to say(although I ignore them) that the ideal UI is the command line.
Are they wrong though? Maybe a tui sometimes, but most of the time anything beyond the command line is wasted effort for a worse experience
I've rarely if ever seen a CLI I'd prefer over it's GUI equivalent.
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.
As user, I would be happy with a certain amount of beauty and whimsy after it was fully functional. So... Yeah, almost never.
For the first example - the Agency homepage with the playful mouse pointer interaction - I managed to get this working with a keyboard-controlled pointer. Controlling mouse via keyboard is a standard accessibility feature in both MacOS[1] and Windows[2].
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
If your website is commercial in nature then it can help to get rid of the buzzwords such as 'SEO' and 'accessibility' to just think of putting the customer first.
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'.
>get rid of the buzzwords such as 'SEO' and 'accessibility' to just think of putting 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.
The author's missing the fundamental tradeoff here. "Alt text is notoriously difficult to get right and heavily dependent on context" precisely because alt text is an assistive technology; you can't rely on context-insensitive tools or your intuition as a sighted person who sees the entire website at a glance to understand whether some fun tweak to the alt text will make things harder for those who are relying on it. Unless you have the resources to focus group it, I don't know how you could possibly be confident that adding a touch of whimsy to your accessible design isn't causing problems.
Something I’ve done sometimes is make the alt-text for images humorous, especially when the image is hard to describe. I’ve worried a bit though that screen-reader users might find these longer descriptions annoying
I guess the issue is that visually we can scan a page and and experience many things at once. Also, there are many ways to move the mouse cursor from one position to the next. There is a lot to work with.
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.
An article[1] from the edbrowse submission a few days ago[2] goes into a lot of detail about this.
I don't want "fun" in an online banking, government or other service website.
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.
I had the opportunity to update an application for a blind person. It's incredibly gratifying to know that after my work, someone who was excluded from using a software can now use it.
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.
I remember when "accessibility" was the buzzword for video game companies to destroy everything challenging and interesting in their games for the crowd who, and I'm phrasing this nicely, needed a much, much lower bar of entry.
Coincidentially that crowd also has looser wallets.
Seems like the author is also the submitter. Shouldn’t it then be prefixed with “Show HN”?
Show HN guidelines[0] states that blog posts are off topic for Show HN.
Oh look, a designer talking about accessibility... while using (on mobile at least) a lightweight, grey font for pull quotes, thus making it innaccesible for anyone who struggles with low contrast text, or is using a phone outside, or just has a shitty screen. Yes, it's good to be able to share "fun" content with all your users, but you should probably cover the absolute basics first.