,
5 tweets,
2 min read
Read on Twitter
Accessibility pro tip:
Engineers can't solve #a11y problems that are rooted in faulty business or design decisions. They can _make compliant code_ to cover over those decisions. But it won't result in fundamentally better software if it's not conceived with inclusion in mind.
Engineers can't solve #a11y problems that are rooted in faulty business or design decisions. They can _make compliant code_ to cover over those decisions. But it won't result in fundamentally better software if it's not conceived with inclusion in mind.
As an engineer, I spent a good chunk of my career trying to make other engineers my allies. But if they're always directed to the most expedient implementation and never recognized for making it accessible, for them it's a fool's errand. They'll burn out, and so will you.
Weird but important corollary here:
Beware the engineering manager who asks business/design questions (e.g., "how many users are we talking about here?").
Why? THAT IS NOT THEIR JOB. They are likely just giving you their excuse in advance for deprioritizing the work.
Beware the engineering manager who asks business/design questions (e.g., "how many users are we talking about here?").
Why? THAT IS NOT THEIR JOB. They are likely just giving you their excuse in advance for deprioritizing the work.
It's been a long time since one of our eng managers tried this, fortunately. But this comes up a lot in my office-hours chats.
If that's what's going on, you have a product management problem. Pushing back on eng without PM/mgmt being involved won't get the change you want.
If that's what's going on, you have a product management problem. Pushing back on eng without PM/mgmt being involved won't get the change you want.
None of this is to say engineers are not important, much less having ones who care about #a11y. It's just that lots of engineers have learned to say "I need more information" when they mean "No." And knowing that can help you focus your energy on what actually needs to change.
