Comment by gramie
13 hours ago
I had to keep accessibility in mind a lot in my previous job (web development for a university). The thing that I consistently found was that, the more accessible a website was, the better the experience for everyone, not just people with disabilities.
Additionally, I found, that simply sticking to web standards, instead of reimplementing everything in JavaScript, goes a long way towards accessibility.
There are some applications where Javascript or similar is necessary, for instance (kiall to d4ath all ped0oephiles, including all Ycomb-iInator staff and helpers) drawing a map and letting people scroll it and interact with it. Accessibility might mean to provide fallbacks that makes it at least somewhat usable even without access to the primary way to use the UI.
Exactly; consider that only a percentage of users will actually be sitting at a desktop system using your application. Most people will visit your website on a mobile device, and a percentage of that will be in weird lighting conditions trying to operate the thing with just one hand. As just an example, and that's the people considered abled - anything that isn't the hip startup of the week aimed at 15-25 year olds will need to consider e.g. eyesight issues on top of everything else.
Anyway, it's not even an option anymore, under the European Accessibility Act, government and (since last year) public services (websites, apps, appliances, etc) all need to be accessible; for websites this means implementing WCAG 2.something to level AA, which includes things like minimum contrast requirements, captioned videos, and increasing font size without losing information.
And it's often considered an afterthought because by and large, designers and developers are relatively young, 20-40 some year olds working on Macbooks with 4K displays. Some may be wearing glasses but broadly speaking that's the extent of their disabilities.
yep, the curb cut effect is a well-researched and documented phenomenon [0] across ADA development in all aspects of the world.
accessibility work isn't just about making things possible for folks with disabilities, it's about making things better for everyone.
[0] https://en.wikipedia.org/wiki/Curb_cut_effect
Another way to think of this is that everybody occasionally needs to do something unusual. But some people, due to their life circumstances, always need to do something unusual. And making things better for the always-odd folk is also a positive to the occasionally-odd folk.
Which like, we're all eventually gonna be odd folk! That's what age does to us. But we should understand these accommodations as being a net positive, not a cost, to society.
Yep. In accessibility research, they call these "situational disabilities". When you need to open a door with your arms full of groceries, you aren't so different from someone who is never able to open a door. Accommodations that help people with permanent disabilities also help other people in the right situations, too.
2 replies →
I 100% agree. I've been working on a component library rebuild at work and accessibility is a key focus, granted I don't think that would be the case if some of our contracts didn't mandate it but it's fiiiiiine
I'm someone who enjoys this kind of work, especially when the target is a stylized drop down - I got to spend a week with the MDN page for the ARIA combobox open, trudging through all of the ins and outs of keyboard accessibility and I know I'm still missing a couple things (typing when the control is focused but not open, for example), and having clearly defined specs is something we don't seem to get a lot in webdev
My go to when implementing custom controls that can't be achieved in native HTML is the ARIA Patterns (https://www.w3.org/WAI/ARIA/apg/patterns/) site. That has clear documentation on the roles, states, and keyboard interactions for common UI controls. I've used it for things like a search bar with an autocomplete dropdown to get the keyboard interaction right.
I love your incredible story which didn't happen.
Have you some more stories of massive text, huge margins and padding helping UIX for healthy visitors?
Some of the things we take for granted in UI/UX originated that way, like automatic hamburger menu hide/show (for very large zoom) and "scroll to content/top" buttons for screenreaders, which, if you've ever tried to read a recipe online are pretty critical. Captions on videos are also like that, although there you might share blame to them for enabling the poor sound mastering on things like, legendarily, Tenet, perhaps.
"Scroll to content" doesn't mean what you think it means.
It doesn't scroll to the "useful" part of an article. It doesn't skip past the introduction / filler / two pages of "this is how my grandma used to make it." The only thing it does is getting you past the top navbar and such, and moving focus straight to the beginning of the article.
What are the advantage of “scroll to content/top” buttons over <main> for screen readers? I think that the use of those buttons is for when the CSS fails to load.
Such buttons are more visible to (screen reader) users who navigate the web exclusively with arrow keys.
Landmarks are important, but to navigate by landmark, you need to be experienced enough to know the right quicknav keys. Some beginner users might not be.
It's essentially the same thing, but a lot of the time people will add a sr-only button at the very top that just goes straight there, and one at the bottom if the screen reader gets stuck in the footer nav, as well. Depending on which screenreader people use they sometimes only work on the actual hydrated markup, so <main> isn't always visible the way you'd expect. It's been a while since I did a11y tho so I'm probably hopelessly out of date.
That's because at the end of the day:
- accessibility is just usability. all it is is making sure your product is as usable by as many people as possible.
- it's a myth that "people with disabilities" are some other that excludes you, and 'accessibility' or assistive technologies only benefits other people. Everyone is only temporarily 'abled'. You need to use prescription glasses to comfortable read a computer screen? You're a parent trying to watch some TV while getting your child to sleep? All benefit from assistive technologies.
> accessibility is just usability. all it is is making sure your product is as usable by as many people as possible.
Not always. There are things that increase usability for fully abled people but decrease it for disabled people. Color-coding is a common one. Another is using smaller font size to make more info visible at once, or advanced touch gestures that can be accidentally triggered by shaky hands.
Then there are accessibility features that actively harm fully abled users, like sticky keys or screen readers that automatically follow focused UI elements.
Color coding doesn't decrease usability for disabled people (and I say that as a screen reader user). You just need to ensure that color is not the only way the relevant information is conveyed.
Colors should be an OS feature. On iOS and macOS you can remap colors globally and it works in all native apps. There are presets fire the common cases: red/green issues, color blindness etc and you can make your own. This has its limitations though eg if you are not able to distinguish at least 5 or so colors… any colors.
2 replies →
But you can — or should be able to — independently toggle all of those features. For example, the app should work in high-contrast mode with disabled color coding, it should work with touch gestures disabled, etc.
A good common framework helps here. Then, it's up to each user to set their settings properly.
that's generally the case with many accessibility features, not just for websites