Introduction
This is not a post about accessibility. This is a true story.
Hi, friend!
You know I wrote an article almost a year ago, saying that "Building accessible websites shows that you care about disabled people.". I've had another thought on that.
Vim.
Accessibility on steroids
"How many people with disabilities use my website?" - it's a common question that you can often hear or ask. You are building a metasearch, database, or management tool. Hands down, we hear this question a lot. But is it actually an accurate question?
Imagine that you, accessibility professional, just heard this question on a meeting. And your product is developer oriented and accessibility is not something that is prioritised.
Usually the conversation goes on, and on and you try to explain that it's not about our "target user" and it's not about a percentage of visually impaired users, and it's not about getting an accessibility overlay and we are done, and it's certainly not about just screen readers vs user agents.
I bet it sounds familiar.
Later you try to do your best to update internal policies to be more inclusive, you create documents on Notion and introduce bullet-proof practices (linters, testing, accessibility specs), try to get investment, conduct workshops and audit the product. And you, more certainly, succeed. After many conversations, many PR's, many Slack conversations "a tab is actually a checkbox?", removing modals, tooltips and disabled buttons and after many user testing sessions you get to something solid.
This is one scenario.
But let's get back to the initial question raised on a meeting: "How many people with disabilities use my website?"
Imagine if we pause here, and we don't gather the data about assistive technologies, we don't talk about temporal or permanent disability, and we don't talk about disability at all (at the moment).
Developer or User Experience
Imagine you are building a product for the user who prefers not to use the mouse. And hasn't been using one for some years. Why? Because, why not?
The question is now: "How many people use my website?"
Imagine you are building a technical, developer (or rather backend developer) oriented product. All of your efforts are on getting the best DX ever and no one yet raised a concert about accessibility, but then you realise that your "target" user may not have any disability at all. They just can't use the product and don't know why exactly. More over, the word accessibility or screen reader is not even in their heads, and they don't use typical accessibility short-cuts that we try so hard to support.
I'm talking about that user that you truly want as a long-term user and they will just silently drop and search for some similar product that has focus ring just because they navigate with the Tab key or Vim extension, like this one: Trydactyl: Vim, but in your browser extension
They don't like User Interfaces, they don't have JS enabled, they don't have complains, they just can't use developer oriented product thinking that something is not ok with their habits.
"It's not about making people adhere to the system, it's about making the system adhere to the habits of people."
Someone who likes plain old websites when the navigation was easy, we didn't have to wait for the site to load, we didn't have fancy smooth scroll. I can tell you more, these users can have JS disabled by default.
All they need is a focus outline and keyboard navigation to be perfect. They, most likely, don't know how to use screen reader and, actually, don't have to learn. Their choice is not to use the mouse. And this is your target user: a person who buys a car only with the keyboard, a person who shops for books, a person who buys flight tickets. How many people are not using a mouse just because they don't want to?
If your website does not have a good enough support for keyboard, which happens to be an accessibility requirement just like many others UX patterns, you would lose the users, and they would never complain.
Thinking out loud
"Can you tell me, what do you do if the website does not show you the focus outline?"
"Well, I just hit the Tab key until I find it, and then I quit. I go to another one. It's ok."
"Hey, and what about sites with animations and smooth scroll? You know, they are quite trendy."
"They are pretty, but you know... 8 years ago Why they keep making these?"
"I can never do grad and drop. Can you move my Trello card?"
"I used to use my keyboard to navigate websites more in the earlier days of the web."
There are tons of websites out there that would make their life easier, not harder, while offering something similar.
If we don't know where our product is going to end up, if it's 3G connection, if it's an old device, if it's not a mobile and not a desktop but something weird, and we implement defensive CSS by default, care about performance, and layout shifts without questioning. Then why do we question sometimes if the accessibility is needed if we don't know where our product is going to end up?
Focus on the essentials
So going back to the question on "how many people use my website?" and should you bring up the conversation about accessibility to the table?
Yes, and you would still need to do your best as an accessibility designer or engineer to get the product to the state where every user benefits from implemented accessibility features, but the conversation about whether your target user needs accessibility is much shorter.
We set high standards for accessibility and, personally, I don't think we should treat it as an extra work for advocacy groups, experts or something like a rabbit hole.
Can we possibly make it simple so our team is not stuck with reading specs all over again, feeling guilty about not passing audits or fail on "simple" things?
Full keyboard access, site consistency, be careful with huge sliders, parallax to name a few. These are users frustrations, all users frustrations.
Weird how many of these map to WCAG Success Criteria.
twitter.com/vitalyf/status…
It is almost like you can improve usability by following the most baseline of accessibility standards.13:04 PM - 20 Aug 2022Vitaly Friedman 🇺🇦🏳️🌈 @vitalyf🧵User frustrations in 2022. Just a few frustrating design patterns that we should be avoiding when designing today: – Tiny scrollable panes. – Tiny click targets. – Unexpected content shifts. – Mega-menus opening on hover. – Country selector dropdown. – Generic error messages. https://t.co/8IchNWQ9Xu
Tell me more
One of the ways I found to simplify the conversation about accessibility is (not bringing it up as a separate conversation) but to break it down to simple down to earth examples:
Keyboard support and focus visible https://www.w3.org/WAI/WCAG21/Understanding/focus-visible
Any people who like Vim in team? For sure!Color contrast https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html
Someone can't tell the difference between blue and turquoise? Yes, and it's a perfect use-caseMeaningful sequence https://www.w3.org/WAI/WCAG21/Understanding/meaningful-sequence.html
You don't like your JS to be enabled, I get itReflow https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
In case you use the website on your fridge's display or a modern toaster
I found it very beneficial to look for these examples in order to build trust and not to overwhelm people in my team with getting JAWS license, build match-media hook or ask for them to incorporate Cypress A11y checks into the CI ASAP.
Build up from something basic up to talking about motor difficulties, a special mouse, speech recognition software or on-screen keyboard emulator.
We can start by translating specs: "This Success Criterion helps anyone who relies on the keyboard to operate the page, by letting them visually determine the component on which keyboard operations will interact at any point in time" to a simple language instead of copy-pasting European Accessibility Act to our Notion page and silently fix the violations on your own.
Make it a conversation about humans, humans that are in your team up until the point where the empathy and trust will grow to cover a variety of background, abilities and interests.
We never know what's normal
The takeaway that I'd like you to get is that there are many ways to plan accessibility strategy for a project, and many ways to bring it up to your team. But the reality is that real world needs are going beyond screen readers announcements and meeting accessibility criteria. Some users don't know they need accessibility, some users know they do.
Maybe, it's not a question about diversity and accessibility, it's not a question about "How many people with disabilities use my website?" or "This target audience is not that big, right?", it's not even a question. It's about making web better by default: taking care about our markup more than we care about selecting the best possible animation framework.
The experience that I got from my article from last year where I said that "what we can do is make sure that all of our users can have similar experiences" I still stand by this idea, but today I'm not looking for % of visually impaired users who rely on a screen reader to explain it to stakeholders.
I'm thinking about a backend developer who doesn't like the mouse. Then it's not about looking for a why making something accessible. Because, why not?
If you like this article, please, share it with your team and reach out to me on Twitter, whether you liked it or have suggestions 💚
Alena Nikolaeva 🦋@alenanik11
Accessible markup patterns and components 🧱 🔗
aria-modal-dialog documentation is just lovely! Saving it for learning
github.com/scottaohara/ac…18:01 PM - 07 Aug 2022
Top comments (0)