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.

▲

WhyNotHugo 17 hours ago | parent | next [-]

This is true in other fields too. Wheel-chair ramps are used by people with baby strollers. Subtitles work for deaf people, those who can't understand the spoken language, or simple folks in situations where someone is sleeping next to them. Pretty much every accessibility-oriented feature ends up helping out people beyond the original audience.

▲

tobyjsullivan 12 hours ago | parent | next [-]

I saw a good mental model for this a while ago. Unfortunately I have no idea where.

Three kinds of disability:

1. Permanent (eg, blind)

2. Temporary (eg, pregnant/new parent, recoverable injury)

3. Contextual (eg, holding something with one hand, loud environment)

When people think about accessibility, they often think about 1. But the long-tails for 2 and 3 are huge, and ultimately affect everyone at some point.

▲

sdeframond 15 hours ago | parent | prev [-]

Baby strollers are not accounted for enough !

One might wonder (wrongly) why everyone should care about the special and expensive needs of a few (or old) people when designing public spaces.

But a majority will actually need to use these spaces with a baby stroller. Not a few. Baby strollers are a driving power of our society! Enable them!

▲

tonyarkles 14 hours ago | parent | next [-]

And to keep the loop going, stroller-accessible spaces are also walker-accessible spaces and cart-accessible spaces. Worked at a computer store in the early 00s. Our rented retail space had a wheelchair ramp and there were a few elderly regulars who would show up with a desktop PC in the basket of their rolling walkers for repairs. More than once they thanked us for having the ramp because the computer itself was way too heavy for them to carry from the parking lot.

▲

my-huge-pony 10 hours ago | parent | prev | next [-]

In fact, in a way, basically everyone will use a baby stroller at some point in their life (at least as a passenger).

I personally never noticed this before becoming a parent, but there's a lot of spaces that are "almost" stroller friendly, but for some reason there is a small obstacle that would not be expensive to remove (if accounted for during planning). For example, a few steps that could easily be a ramp, blocks of flats with a lift that is accessible after ascending a few steps, even high shop entrances.

For me it's not a problem, because I can easily carry stroller with a baby inside up, but for most mothers I know this is usually a huge or unsurmountable obstacle.

▲

apothegm 11 hours ago | parent | prev [-]

Not to mention luggage. I find it hard to believe that it’s a coincidence that rolling luggage became common shortly after curb cuts and wheelchair ramps did.

	▲	mhb 10 hours ago \| parent [-]
		Really? Both strollers and wheels on luggage are pretty nice to have even if you have to somehow negotiate curbs. So, I think it is a coincidence.

▲

keerthiko a day ago | parent | prev | next [-]

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

▲

TomatoCo a day ago | parent [-]

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.

▲

gregdeon a day ago | parent [-]

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.

▲

djaro a day ago | parent | next [-]

My touchpad broke and I couldnt download the touchpad driver to fix it on the spot because there was no way to get to the download button with tab and enter, you had to click it.

	▲	opan 20 hours ago \| parent [-]
		That's a funny example, reminds me of how often fresh Windows 7 or older installs were missing the ethernet driver so you had to move stuff over on a flash drive to get started really setting stuff up. In your situation, a couple possible solutions come to mind. 1) turn on "mouse keys" which lets you use the numpad to move the mouse and click, 2) a vim addon for the browser (e.g. vimperator or tridactyl) likely could've clicked the button via the hints mode. It's in the past now so maybe these wouldn't have worked or you didn't know, of course, just fun to think of what I would've done.

▲

apothegm 11 hours ago | parent | prev [-]

Yup. Or people with temporary disabilities — who have simply broken limb or had a surgery. Most places are hellish to navigate on crutches. Heavy doors alone make so many places nearly inaccessible, and that’s before you even get to stairs.

▲

zelphirkalt a day ago | parent | prev | next [-]

Additionally, I found, that simply sticking to web standards, instead of reimplementing everything in JavaScript, goes a long way towards accessibility.

	▲	mghackerlady an hour ago \| parent \| next [-]
		Funny how that works. It's almost as if the web was designed to be a tool for semi-interactive documents instead JVM-esque WODE environment
	▲	userfrie 19 hours ago \| parent \| prev [-]
		[flagged]

▲

Cthulhu_ 20 hours ago | parent | prev | next [-]

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.

▲

madeofpalk a day ago | parent | prev | next [-]

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.

▲

Xirdus a day ago | parent [-]

> 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.

▲

miki123211 21 hours ago | parent | next [-]

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.

▲

Xirdus 17 hours ago | parent | next [-]

Certain types of colorblindness combined with certain colors makes text much harder to read than black-on-white. If you limit yourself to just universally readable colors, you're heavily limiting the number of different categories you can highlight. There's also the matter of screen real estate - duplicating info isn't helpful for people who can deal with colors just fine. I'm not saying it's a srong thing to do, just pointing out accessibility and usability are different things.

▲

wtetzner 13 hours ago | parent [-]

Couldn't you distinguish things by their grayscale value? Then you change the hue on top of that for people who can see color.

	▲	lowercased 12 hours ago \| parent [-]
		May not always be enough contrast to pass WCAG requirements, for example.

▲

17 hours ago | parent | prev [-]

[deleted]

▲

umpalumpaaa a day ago | parent | prev | next [-]

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.

▲

rhdunn a day ago | parent | next [-]

That's why you don't just use colour for identification. E.g. include a warning icon next to a button/element in addition to using a warning colour.

▲

Cthulhu_ 20 hours ago | parent [-]

Nor just shape, so a warning icon + text message.

	▲	mghackerlady an hour ago \| parent [-]
		and, as is being increasingly forgotten, SOUND QUES. Seriously, I get they can be annoying but they make navigating and interacting with things so much easier if you can't see them. Sure, TTS exists but is far more inefficient and objectively less helpful in these kinds of circumstances

▲

xg15 14 hours ago | parent | prev | next [-]

should be, but then you will upset all the marketing folks and their brandings.

▲

OhNoNotAgain_99 15 hours ago | parent | prev [-]

[dead]

▲

ckardaris a day ago | parent | prev | next [-]

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.

▲

Xirdus 17 hours ago | parent [-]

Riddle me this - why would you want to disable something that increases usability of an application? (Yes, this is a loaded question - I never said these features are bad, just that usability and accessibility are sometimes at odds with each other.)

▲

lowercased 12 hours ago | parent | next [-]

unsure this is quite the same thing, but I often swap my phone to gray scale to reduce brightness overall (and 'reduce whitepoint' sometimes) because at night colors are too stimulating.

▲

ckardaris 17 hours ago | parent | prev | next [-]

Sometimes users may prefer to reduce the degree of accessibility of an application in favor of aesthetics.

▲

Xirdus 17 hours ago | parent [-]

I have my opinion on aesthetics of additional ways of repeating information already available by color coding. But to each their own.

Other than that, is enabling/disabling any of the aforementioned features ever a question of aesthetics?

▲

ckardaris 16 hours ago | parent [-]

For example, opting to not enable high-contrast mode is a question of aesthetics. Arguably reading text would become easier for the user, but they prefer to sacrifice a little of the readability in favor of looks.

	▲	Xirdus an hour ago \| parent \| next [-]
		I am a little confused about your response. Do you disagree with me that accessibility features often reduce usability, or do you agree with me and just feel like nitpicking? I'm all for nitpicking, but I'd rather keep it separate from the real debate.
	▲	apothegm 11 hours ago \| parent \| prev [-]
		In fact, for some people high contrast is headache-inducing. I’ve installed a utility on my laptop that supports “sub-zero” display dimming for nighttime use because monitors are now over-optimized for max brightness, with min brightness being retina-searing for eyes adjusted to a dim room.

▲

danaris 11 hours ago | parent | prev | next [-]

There are very few accessibility features that increase usability across the board for everyone.

If they did, they'd just be called "features".

Disabling high-contrast display makes the colors more aesthetically pleasing.

Disabling large-print text allows you to view more text on the screen at one time.

	▲	Xirdus an hour ago \| parent [-]
		My point exactly. Accessibility isn't "just usability" and the great-great-grandparent was wrong to say that.

▲

jasonlotito 14 hours ago | parent | prev [-]

> Riddle me this - why would you want to disable something that increases usability of an application?

Why don't you run your apps/OS with every usability feature enabled? Share your reasons.

	▲	Xirdus an hour ago \| parent [-]
		I think you are mistaken which side I am on in the "accessibility is just usability" debate. For the record, I am on the side that says not at all.

▲

madeofpalk 16 hours ago | parent | prev [-]

> Another is using smaller font size to make more info visible at once

This doesn't sound very usable to me.

	▲	Xirdus 43 minutes ago \| parent \| next [-]
		You might be the kind of person who does benefit from accessibility features such as larger font size. On the other hand, I'm not; I can read 10pt font on 100 DPI display just fine, without glasses. I'd rather have an extra column in table view visible without scrolling than larger letters, but for you the tradeoff might be different. That's why it's accessibility and not usability. Usability would be if the bigger font didn't push anything off screen, then of course it's better to make it bigger.
	▲	mrob 15 hours ago \| parent \| prev [-]
		Everybody has some minimum text size they're comfortable with. If you make the text bigger than that, they're forced to scroll unnecessarily, which is less usable. But the size differs from person to person, so it should be configurable. You get this automatically with web browsers and most GUI frameworks if you don't go out of your way to break it (just stick with the default font).

▲

jaggederest a day ago | parent | prev | next [-]

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.

▲

miki123211 21 hours ago | parent | next [-]

"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.

▲

Velocifyer a day ago | parent | prev [-]

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.

	▲	jaggederest a day ago \| parent \| next [-]
		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.
	▲	miki123211 21 hours ago \| parent \| prev [-]
		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.

▲

phatskat a day ago | parent | prev | next [-]

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

	▲	rhdunn a day ago \| parent [-]
		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.

▲

a day ago | parent | prev | next [-]

[deleted]

▲

PunchyHamster a day ago | parent | prev | next [-]

that's generally the case with many accessibility features, not just for websites

▲

shuwix 19 hours ago | parent | prev [-]

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?