Heather Buchel

Accessibility progress and healthy engineering teams

2026-02-02T00:00:00Z

Something I've been stewing on lately, as someone introduced to teams as an "accessibility specialist", is how much I am actually able to influence teams to improve their practices around web accessibility. Or how much I'm not able to.

This isn't really a revelation or a surprise, but I've found that teams and orgs that struggle with accessibility, are already struggling with a multitude of other issues:

Technical debt
Lack of front-end expertise
Lack of respect for the web as a platform (example: poorly recreating native web elements, which is usually related to the previous bullet point)
a constant race to release new features (usually a lack of engineering leadership who can pump the brakes on overly eager product folk)
a disconnect between engineering, product and design

More and more I am alarmed at how easily these issues accumulate; especially now that we are pressuring engineering teams to adopt AI. We've added this additional stress point. "See if you can make AI work somewhere, ANYWHERE." This is not the same as asking your team "Hey, have you heard of React? Should we implement that?" or "What about this new design tool? Do you think the designers will like it?" There aren't reasonable discussions being had beforehand, that healthy engineering teams would usually take part in.

"Everyone is asking for it, without actually defining what it is, so we just have to do it." is not indicative of a healthy organization.

Like most technical debt, accessibility issues will likely one day force you to address them through some means or another (an angry customer, a lawsuit, a deeper issue that is obfuscated by poor UI, etc). So when I see the results of an audit, or the picture starts to come into focus concerning the type and number of accessibility violations a piece of software has, it raises the alarm bell for these other issues. Those I can't fix.

Also, something something about "capitalism going to capitalism".

A reset

2026-01-12T00:00:00Z

Every so often the creative things in my life become a burden that I overthink. Which means, this blog needs a small reset. I would love a huge beautiful redesign but the creative juices aren't quite flowing. In the meantime, there are some technical things I want to work on (automating some workflows, webmentions, etc) that I don't want to feel blocked because I'm agonizing over font choices.

So, things will be wonderfully messy for a bit, giving me the space I need to tend things here and there in my small digital home. I reset the styles and markup to the barest minimum I could stand while still hopefully readable.

If there is anything egregiously broken, feel free to reach out on Github

The trash pile is on fire

2025-06-02T00:00:00Z

I was thinking about parts of the web community/industry that we've lost in the past 5 years or so and speculating on some of the reasons why. No right answers nor thoroughly thought out, and I'll definitely miss some, but wanted to throw these thoughts into my own little space before I forget them. We haven't completely lost everything in this list, for better or worse. Some have been pretty top of mind as of late with some discussions around "AI taking our jobs" and whatnot.

Enjoy me rambling instead of making a 20 post long Bluesky thread. I'm going to go back about 5 years. Or, just before and at the start of the pandemic, more or less. Here are some things we had that are either greatly diminished or probably gone:

Twitter

I think a lot of folks found the web community via Twitter. I certainly did. Losing it (and yes, it is lost) was a pretty big blow to an intersection of communities; for myself, web and accessibility. Kudos to Jack and Elon for burning it to the ground. They got what they wanted. There is no justice, blah blah blah.

Happy to say I reconnected with folks on Mastodon and Bluesky and am pretty fulfilled as far as web community social media goes.

Junior developers

Of course we still have them. But, we had a surge of new developers, coming from other fields or unconventional education pipelines. Bootcamp and Twitch study group grads. Retail turned javascript developer. I liked that. I feel like, especially with the garbage pile Twitter is now, there is less excitement about it. Back to the "happy path" of comp sci degree straight to big-tech intern, I guess, if you want to get ahead. I hate that.

I miss the excitement of new people learning about the web. I hope it is still out there, somewhere, and maybe I just can't see it. I think the bootcamp companies also ran out of ways to take advantage of students so that industry also went quiet.

Developer advocates

Listen, we basically had developer influencers. It was out of control. Twitter was a popularity contest of these people. Sure, there is a time and place for this role to do some real work, but, in my opinion, a lot of companies did not effectively utilize them.

We still have them, definitely less trendy, and it seems like fewer and farther between. It was a pretty glamourized role at the time. Less so, now. Unless you turned into one of those YouTube personality devs (not a knock at everyone that makes developer YouTube content, but you know the type).

Remote work

Whiffs of unionization? Tax breaks from big cities to bring more workers downtown? A facade of collaboration? More people for "that one guy" to talk over in meetings? A reason for me to up my anxiety medication? Putting those tech workers back in their place? There are too many reasons why we lost this and few, if any, of them are pro-worker.

NFTs/web3

If CEOs could have found a way to explain away the pyramid-scheme-ness of NFTs, they probably would have shoved them down our throats more. I don't care what web3 is/was and if any of it remains it has gone quietly into the void where it belongs and I don't have to hear about it every day from the most annoying people. What the fuck is a developer dao.

What happened

The pandemic. Unionization efforts. Racism. Elections. Ableism. Fascism. Probably a lot more to add to the list of what caused all these changes.

Re: broken promises

2025-05-29T00:00:00Z

This article from Salma really resonates with me and honestly explains why I'm so sour about AI code assistant tools. Anytime I scoff at using them, inevitably someone says something along the lines of "But they're coming! They're all getting better!" Sure, I'll wait for that day then.

I am eager for the days where I'm not spending time reminding people to add their missing alt text, or to convert a div to a button where appropriate. The absolute basics. AI is not solving those problems for us. It's either making them worse or just doing them in weirder ways.

Before, I would help engineers of all experience levels learn why their ARIA attributes were misused or why their code would result in a poor experience for keyboard users. Sure, they could have copy and pasted code from Stackoverflow. But usually, there was an intentional act and some scrutiny that came from them, where they could explain why they added that code. This leaves you with something to learn from. Now, from engineers that use these tools, I fear there is less scrutiny and less reflecting on their decisions with code. They will ultimately learn less.

These tools are also not affording me time to write the fun parts of code. Nor are they enabling what I think is truly the driving force behind why I care about web accessibility: that accessibility is at the root of more creative and more-well-loved software and tooling, for everyone. If anything, I find these AI tools are making less space for it. My advocacy is now not just "Here is why you should make accessible software" but ALSO "Here are the dangers of using AI tools to write your software". When do I get to move onto the more creative and fulfilling parts of working in web accessibility? As Salma says, that promise wasn't kept.

Don't make me feel bad

2025-02-12T00:00:00Z

I was just thinking about how people can get very defensive when you bring up accessibility issues that need to be addressed and how it differs depending on your audience.

Individual contributors

In my experience they take it best. Whether it's designers or developers, typically they just want to learn and do better. Usually less defensiveness. Sometimes low confidence about whether or not they are "allowed" to just fix it.

Product owners, or people that control the direction of the feature/product

This is where it usually gets messier. In this case, your stakeholder has to choose whether or not the work you just outlined will actually get done.

I think people tend to get defensive here because they're forced to reflect on the thing you just said, which they will boil down to "There are some customers we should or should not care about", and how that makes them feel as a person. They'll sometimes try to bargain their way out of it or convince you the issue is not "that bad". They don't want to feel bad about their decision and you're making them feel bad.

Tips?

I'm not as gentle as I used to be when talking about accessibility, but I do expect this as a very human reaction. Do I have any good tips to avoid this? Not really (sorry), other than to expect it and redirect the conversation.

As a rule, I generally avoid conversations that involve "percentages of customers" or "x amount of people have a disability". I find it insulting to talk about customers in that way regarding something like disabilities. It feels disrespectful to sum a group of people down to a percentage in order for someone to feel better about not fixing something.

Also, so many accessibility violations are the result of poor design and development practices. Sometimes it's more productive to start there than with the folks that get immediately defensive. An engineer can get better at when to (or not to) use ARIA. But convincing someone to change potentially their world view? In a Wednesday afternoon meeting when I'm out of coffee and I'm pouring through backlog tickets? Yikes.

Sometimes people are best left to work through their feelings on their own, and you'll just have to find a different route. Especially in today's climate, I have less bandwidth to gentle parent people about accessibility.

Accessibility tooling and good intentions

2025-01-30T00:00:00Z

TLDR: Get your accessibility tooling off from your developers' machines and into the CI. This is one of those pieces I would share with folks who are new to advocating for automated accessibility testing in their engineering orgs; especially if you feel stuck at that phase of "I know all the tools we should be using, but now what?"

Since I recently joined a new team (and a new company!), I've been thinking about the churn that many teams (ok, maybe most) go through regarding their accessibility tooling. I feel like it usually goes like this:

The stage is set with engineering teams fragmented across the company, each owning a different part of the UI. Some using their own unique tech stacks.
Engineer: Hey, we should probably be testing all of our changes for accessibility, right?
Accessibility advocate: Yes! I know some tools we can use! I'll show you how to use them locally then maybe you can integrate into your own team's pipelines?

And there the tool sits. In the good intention pile*. Maybe they were used for a little while at first, but then abandoned after that initial push.

*I love talking about good intention piles. They always start off as something that should make you feel good, but the longer they sit in the pile they ultimately become a source of shame or frustration.

It's a great start, and it's a position I've been in countless times, playing the part of the accessibility advocate. This happens for a number of reasons but usually it is a result of two things:

The accessibility advocate or team is too far removed from engineering. They can't give guidance or give better technical advice if they are too far removed; they need to be familiar with the technical details of the stack to know where tooling can actually be added.
The tooling suggested isn't actually made mandatory, it's a nice to have that they run if they remember or have time.

Often, accessibility engineers are too far removed from the tech stack

#1 can be helped by having engineers that are focused on accessibility as part of your actual team. Hiring full-stack engineers often doesn't tick that box and it's silly to expect it might. Sure you can get lucky, but the spectrum of front-end engineering is far too vast now. If you're a manager, aim for more well rounded teams. If you're the accessibility engineer yourself, and you're not directly on the team, ask if you can have access to the existing tools and tech stack. You'll need to know what they are already working with.

Elevate your tooling to CI and make them mandatory

#2 is really the clincher here. Teams have to treat accessibility tooling as they would the rest of their stack. Would you block a PR if it was riddled with broken types? Would you turn off all of your linting rules to let a PR pass through with sloppy code? Would you trust that your engineers all ran their unit tests locally before merging their PR?

In my experience, to make real longlasting progress, accessibility needs to become baked into the engineering process. Lunch and learns will only go so far. It needs at least the same status as the complex type system that your entire codebase relies on. It requires the same thoughtfulness as the end to end tests you run automatically to feel the warm fuzzies before releasing a new package.

At best, some form of continous integration (CI) is the perfect place to add automated accessibility testing. Right alongside your other end-to-end tests you're already running. It's something that can fail and block; and it's probably one of the more important things to block a user-interface related pull request on.

How to dig your team out of the good intention pile

The difficulty with digging your team out of the good intention pile has to be overcome by earning trust with the team, even moreso if you're not directly on the team. Some things I've found helpful are:

Prototype your accessibility tooling as part of a Github Action (or whatever CI tool you are using) and demonstrate the expected outcomes. It goes a long way to show potentially how many violations you could be finding. Also, people like seeing green checkmarks.
Write a technical design doc, something you can socialize and ask for feedback on.
Integrate piece-meal. Maybe you can't have testing on every component or feature at the beginning, but developing a plan to iterate and improve on that as you go can take away the big "scaries" that engineering teams might have. Additionally, starting smaller can help you find any missing gaps from your prototype.
Sometimes, having the tooling and tests implemented but not blocking is a gentle introduction for the engineering teams and a helpful way for you to identify gaps. This way you can monitor what types of violations are commonly occurring, what other changes might need to be made, and you can allow a grace period for the engineers to become accustomed to the tests without introducing a frustration point. Obviously, they should be made blocking sooner rather than later.
Demonstrate to the team how they can unblock themselves. If your tool finds a violation in a piece of code that's actually in use, it'd be great to fix it. But we all have codebases that have that page or component that is either on it's way out or headed towards refactoring. Realistically, you'll need a method or process for determining when it's OK to skip a test.

Accessibility tooling requires the same level of support and maintenance from your team that other major technical decisions merit. Without that support, it will easily fall behind or become a point of frustration for your engineers. Learning to work within your existing technical systems, or at least learning why they exist the way they do, is a great way to make progress for your advocacy.

2024 games review

2025-01-04T00:00:00Z

I recently remembered that early-ish in 2024 I started a thread of games I wanted to play in the upcoming year. I thought it would be fun to look back on what I played (or didn't play) this year and which ones I actually enjoyed! I'll include everything mentioned in that list, and everything else I tried out.

I don't have a ranking system or anything, just a few thoughts here and there. And, there are some I didn't include either because they weren't in that list, or because I really only played it for a day; like books, I have a terrible habit of buying games that end up sitting on the shelf.

May this also serve as a reminder to me to do actual reviews of games as I play them so I can better organize my thoughts for next year!

Returning games

I wasn't sure if I wanted to mention returning games, because they're basically what I play between trying everything else. But, I spent a good amount of time playing them this year so here we are:

World of Warcraft

Obviously, I returned to this. The War Within expansion finally gets the story telling part of this game back on track. Shadowlands felt like too wide of a departure from what we were doing in Legion and BFA. After that, Dragonflight felt like their expansion to clean up technical issues, get gameplay loops on track, and focus on ever green features. So, finally, it feels like we're get some conclusion (or, at least, continuation) of the Titan + Azeroth story. The world design and environment building is absolutely wonderful. Overall, was happy to play a lot of season 1 and have a breather now before season 2 starts early 2025. WoW is essentially, my Star Wars or Lord of the Rings. I love the story and characters so much.

They've also made it a lot more enjoyable for solo players which is generally how I play the game now, even when I do have friends playing. Delves are fun, the world quests are fine, and there are lots of toys/pets/transmogs and lore bits to collect this expansion.

7 Days to Die

I really don't like "scary" games or games with zombies/monsters that chase you. But, something about this one is really fun to play with friends. It finally made it to the 1.0 release so we fired it back up. A lot of good improvements to points of interests. Blood moons were still challenging enough early on. Base building is fun; we usually occupy an existing house and I spend time repairing all the walls or repainting them to look nice. It's not a game I'd play solo, but it's great to add to the list of games to return to with a couple friends.

Minecraft

I love voxel-ey building games so this is one I come back to a lot. I don't play a lot of the base game; instead my friends and I usually play a large modpack like Create. With those, you can usually do a lot of automation, building factories, trains, etc. Lots of nerd stuff! We came back several times in 2024 to play different packs. I'm still surprised at how often we play this.

New (or new to me) in 2024

Enshrouded

I really enjoyed this one. It's a multiplayer RPG with crafting/building. The building is very voxel-ey and detailed. It's the type of game where I'm happier to play with others; they run off and kill everything while I use up all of our materials to build a really large house.

Unfortunately, this game didn't have lasting power with my friend group because, at least originally, all of the progress was shared on the server. So if you came in late, or played at odd hours, there wasn't much for you to do. I think they changed that later in the year, so I'll either urge them to revisit it with me or at least play on my own.

Once Human

I really wish my friends would have liked this more. I kept on with it for a little while after they all stopped playing. It felt like a mix of Secret World and a survival/zombie game. I think some negatives were the in-game shop, lots of confusing menus to claim "rewards" that you would immediately forget how to open again or how you even got those rewards. It was fun driving around on a motor cycle, clearing out camps, and looting boxes. Base building was pretty fun, though a little sad to see all the good decorations were part of the shop.

A Little to the Left

Scratches my brain so good. If you like anything to do with recognizing patterns, play this game.

Abiotic Factor

I don't usually like games that are "scary" but this was so much fun to play with friends. It's a good amount of silly mixed into it. It's a multiplayer survival game where you are working your way through a research lab and fighting the anomalies that have broken through.

Planet Crafter

Really good game to get stuck into and play for hours at a time. You can play multiplayer but I got enough enjoyment out of it solo. I was so excited when my world finally had frogs.

Pantheon: Rise of the Fallen

Look, I think we need to let go of making new games look "retro" or old on purpose. I thought this might be one of those "old looking but just for the aesthetic games but it feels too clunky. It feels "old" clunky. Not good. Give me the quality of life things like, I don't know, a mini map. I don't want to go back, anymore.

Pax Dei

Didn't play. It was a game that looked too good to be true. This was even a thought I had early on when it was announced. When early access rolled around and people started streaming it, I got the vibe it probably wasn't for me. My main issue, is really I feel too old now to play games that require me to be online for large amounts of time AND to play with a huge group of people. That's my issue with most games in the sandbox genre; when the population falls off, there usually isn't much of a game to play on your own or with a smaller group. Which is a shame, because they always SOUND fun, but without other gameplay loops besides grinding materials and pvping in large groups, I'm always dissapointed in the actual fun-ness of them. Maybe it's too early, and I'll give it a little more time to cook.

Ashes of Creation

This is a sandbox game I've stayed interested in, because they've presented it more as an MMORPG than some of the others in the genre. I got a little impatient and bought into the second alpha so I have gotten to play a small bit of it. I think it's still too early to call, but it was in good enough shape that I'm hopeful to see where it goes. I am worried, at least for me, that it won't pan out because of the "be in a huge big guild to succeed" type of requirements these games often have, but it did seem like there was still content for small groups or solo players. I hope they pull it off!

Palworld

I had no intention of playing this, but after Enshrouded didn't really pan out early on for my friend group, they wanted to give this a try. I didn't get the hype for it. The building mechanics seemed very poorly implemented and just generally not enjoyable from a gameplay aspect. Some of the bosses were fun to fight. Instead of an open world/survival, it probably would have been better as a Monster Hunter + Pokemon ripoff. I dont intend to return to this one.

Throne and Liberty

Skipped this one. Honestly, too much RMT and in-game shop stuff from what I saw of others playing. It's such a drag. And, they feel like such a cash grab.

Dune Awakening

Didn't get to play but I will whenever I get the chance. Will it be a re-skinned Conan Exiles? Probably not. But that game was also fun enough multiplayer that I would try out another from Funcom.

ArcheAge 2

LOL. Did not play. Not sure if the game is even being made anymore. Probably shouldn't play anyways or give whoever owns this franchise now any money.

Nightingale

I played this alone right on release into early access. Probably too early to have an opinion on it. I don't feel super inclined to return to it. Honestly, I'm probably spent on the sandbox genre.

I don't have any standouts for this year as for as new games. I originally included Lethal Company, because it's the last game I remember laughing that much in, until I realized I last played that in 2023! The War Within WoW expansion was probably my most anticipated (and most played). Blizzard's world designers deserve far more accolades than they get. What were your favorites this year?

Carving your space

2024-11-12T00:00:00Z

As I'm currently looking for my next role, I've had to do serious reflection on the work I actually want to do. My conclusion from this reflection is that teams generally don't hire for the work I really like, with some rare exceptions. This is why I almost always end up carving out my own space.

Whenever I join a team, regardless of what the job description said, I fall into filling the gaps between design and engineering. It's always where I've loved working. It's the space I seek out even if no one asked me to. The front-of-the-front end work (I'll probably never stop referencing this article) that is always neglected but never hired for specifically to solve. Even when it's painfully obvious it's missing. This usually includes accessibility, UI design, some basic UX consulting, and of course, actual UI development; you know, writing HTML, CSS and JS.

I've written before about why teams don't hire for this role, or at least some of my musings of what's led us here, so I won't rehash all of that now. But I do want to talk about how I try to carve my space on a team to do this work that I deem both important to the web and our users as a whole.

Front-end job descriptions suck

The first thing you notice if you live in this space, that void between design and engineering, is that job descriptions will gloss over their need for someone that actually knows HTML and CSS. It's often accepted as a given that if you call yourself a front-end developer or front-end engineer that you just know these things. My experience is that the spectrum of front-end development is so vast now, that it's certainly not a given anymore. Which is fine! It means we can specialize. And that specialization is still very vast in the amount of knowledge you can obtain. I would argue it doesn't even feel like a specialization, but it's own role. It also means that when teams that don't specifically seek out these people, and they assume it's a given skill that all developers know, they inadvertently create a huge gap in skillsets on their team.

So, when browsing through job descriptions, try to sus out the roles that look like they'll closely align with the gaps. Design technologist, UX engineer, and design engineer are roles that almost always align with these and maybe even mention those gaps in their description. Otherwise, I look for any that mention building components, working on design systems, or building interfaces.

Be honest in the interview

Let's say you've applied and gotten that first introduction phone-call setup. This is definitely a great time for the recruiter, who hopefully is familiar enough with the role, to see if you're a good fit. But it's also your chance to start talking about the space you want to work in. I always mention that I like to do front-of-the-front end work, that I like to work between design and engineering, and that I want to work on teams that acknowledge accessibility is important. I hammer away with that every chance I get. I've found that most teams/managers/recruiters will at least give lip service at this point that they like that. They'll usually say, of course, they care about accessibility, and that it all fits into the role you've applied for.

Sometimes, it is lip service.

Now, I've done this in the past and have joined teams that, during those initial interviews, told me that they really value those gaps. At that point, I'm so excited because I think they've hired me because they want me to do those things. Then, surprise! You're configuring build systems and writing TypeScript every sprint. Those accessibility bugs and layout issues you found? They're backlog items. Forever. Sorry, but you have lambdas to fix and alarms in AWS consoles to configure. That component they wanted you to quickly prototype? It's going into production without being finished, accessibility issues and all.

Leave. If you can. It's not going to change.

At best, you find a role adjacent enough to shine a light on the gaps

Unless you strike gold and you find a role that is exactly what you're looking for, sometimes the role ends up being just close enough that you're working on things adjacent to those gaps. That's when you can really shine a light on them. Some examples:

Were you tasked with building or designing a new component? This is when I gather accessibility requirements and neatly list them in a doc. You can start a new step in your component lifecycle that includes this piece before moving forward.
Did a customer point out a button has poor contrast? Cool. Find the other components that have poor contrast.
Program manager is annoyed the page loads images too slow? Great, let's find more performance issues.
Did you need to add or update some markup to a component? Neat. Point out any of the unsemantic HTML that currently exists in it. Make the case for including that in your update.

These things might be easier said than done. And, there is often some trust gaining needed first before you might have the time allowed to do them. But they are all examples where you can take a task, and start carving it into the actual thing that fills those gaps. If you have one component that ships to production with poor color contrast, that alone would shine the light on various issues:

whoever designed it didn't check contrast, are they missing the tools for that? Is that something you can help with? What other friction points do designers have in their hand off to engineering?
no end to end test caught it, do you have tools to automatically test for color contrast? Is that a test you can add to your CI?
nobody knew to even look for it; is this an opportunity to teach? An opportunity to turn other engineers into accessibility advocates so you're not an island of one?

This is how you carve out the space. Assuming it's not just one of those "lip service" roles, having a good enough base will give you some leeway to fill in the gaps and work on the things you think are important.

A letter to my younger self, as an accessibility advocate

2024-03-12T00:00:00Z

I thought I'd make a list of things I wish I could go back and tell my younger self as a web developer who was just beginning to lean into web accessibility as part of her career path.

For some context, I was a self taught web developer. I learned what I could from the internet. And my early career had me working more with back-end developers than other senior front-end developers. It was a lot of muddling through and finding my way. I think that's not actually that rare, even today, given how common it is to find front-end developers who have little web accessibility experience. So, hopefully this might help someone else. Maybe you, and I really hope you do, can speed run some of my learnings.

I'll also caveat the tone of this post. I probably come off as a little cynical. That's a habit of mine. I think ask anyone that's worked in this space for a long time, and they might be understanding of that. Some of these are even reasons why people retire from this space. At some point, it's exhausting. For me, the cynical parts are still fueling me to do the work.

So here are some things that I wish I knew when I was first starting out:

Blog posts and articles are great, but seek out the experience and opinions of Disabled users.

I first started getting into HTML and building things on the web when web standards were still becoming A Thing. I didn't have any mentors besides the people I looked up to online. But I gobbled up any articles and guides I could find on how to go about making an accessible website.

Advocates are great. I call myself that. I do my best. But I, and the articles you find online, are not going to be a replacement for getting your product in the hands of actual Disabled users and having them test your application.

I will never forget when I watched for the first time a Blind user navigate around a piece of software I made. It was essentially a life changing experience for me as far as my career went. I'm still surprised at how many developers have never watched someone use a screen reader with the thing they've created.

Seek out this experience. You'll probably feel uncomfortable depending on your relationship and experience with disabilities or the Disability community; you might even feel a little ashamed at how well you discover your software can actually be used. But it is the only way things will improve.

Don't fall into the "Well they did it, so its ok if we do, too" trap.

I remember when I first started out in this career thinking anyone that worked at [INSERT FAANG OR BIG TECH COMPANY HERE] had to be the smartest and the best. The most knowledgeable. Truly, the most examplary work.

Wow, I was so wrong. And so naive. Hey, I mean, they hired me. This is so laughable now. None of us know what we're doing. We're all figuring it out. They were really just figuring it out back when I started and we all still are.

If anyone tries to tell you "well they did it this way so it must be accessible", they are looking for an easy way out of doing the work. That's not how accessibility work is validated. And, given the general erosion in tech we're experiencing now, especially from Big Tech with AI type of places, they might be the worst examples to follow.

The "technical" reasons why something can't be accessible are almost always "people" reasons, actually

It might seem like a technical reason on the surface level. It requires a code change. But somewhere along the lines of those code changes being made are the people getting in the way. The people saying the deadline can't move. The people saying "well it was like this before so we're not changing it." The people with no imagination. The people who value the short term over the long.

You'll hear that excuse a lot and it's amazing how quickly those technical challenges can vanish when the people in charge change.

You're going to spend a lot of time trying to influence people.

Ugh. And I hate leading meetings. That never changes. But, it's generally easy to find the accessibility gaps. It's the getting people to understand the organizational changes needed to address them that is the hard part. It's a lot of time convincing people of things that have been documented for years. It's a lot of time spent educating people on things you learned 1, 5, 10 year(s) ago. It's a lot of losing battles and "I told you so's". You'll spend some time fixing actual accessibility defects. You'll spend more time trying to figure out how to get organizations to work in a way that would have let you avoid the defects (or the fallouts from them) in the first place.

The "I told you so" moments are actually going to sting a little.

At some point you're going to make a recommendation for an accessibility requirement, and you're going to get shot down. For whatever reason, someone else is going to make the decision that they know better or that whatever analysis they've done has concluded the thing you've asked for isn't needed or isn't a priority.

And then it's going to backfire. Sometimes spectacularly so. That thing that wasn't a priority is now suddenly deemed very broken and a problem. Higher up people are mad. The word escalation is being used. You're going to be frustrated at the time lost and at the frustrations that were caused to your users because you weren't listened to in the first place.

Maybe keep those in your pocket. Reflect on how you documented the ask; actually, make sure you're documenting accessibility requirements if you're not already because it might protect you. Off hand or informal conversations in person or over Slack aren't as easy to point to as a requirements doc with big red text that says "BLOCKER". See how you can use it to give yourself the advantage next time when trying to influence change. At this point, you can likely just hope to use it as a learning experience.

I'm sorry, but you're going to spend a lot of time teaching people about alt text on images.

Oh, boy. The time I wish I could save from starting back at what always feels like square one with every new team. Unfortunately, this is the state of web development education. People will have senior titles as a front-end engineer, their realm of responsibility will be in the building of user-interfaces, and you'll still be pleading with them to do the basics.

I often think about all of the time for creativity and innovation in the accessibility space that has been squandered by putting our best and brightest on tasks like hounding their fellow developers to use a button instead of a div with an onClick.

I don't have a solution for this, besides to ask a lot of questions during your interview about how accessibility-driven the development practices are on the team you'll be joining.

The business doesn't care about what you think is morally good for society.

Early on, I thought I could get people to care about making our software accessible by appealing to what I thought they would agree felt morally right to do. I was (and am still!) one of those grossly optimistic people who saw the web as this great medium that everyone could utilize and take advantage of for the betterment of our society. I know, disgusting.

That doesn't work. Stakeholders, or whoever it is you need to convince that this work needs to be done, don't hold themselves to the same level of empathy that you might, and will end up spinning on unhelpful questions and conclusions, such as:

Well how many of our users actually use a screen reader?
But how are we supposed to know if anyone has a cognitive impairment?
Well, they can just use a mouse, right?
Well, most of us can see it just fine so that's ok.

The most progress I've felt a team make regarding accessibility is when we hit a really sweet spot of demonstrating a decrease in risk for the business based on changes we made that were rooted in accessibility. It might sound like a robotic methodology, but what I found, is that it forces stakeholders who don't know anything about accessibility or who have not addressed their own bias, to acknowledge the actual improvements or decrease in risk that are the outcome. They don't get caught up in those unhelpful questions, many of which are impossible to know the answers to. It reduces the opportunity they have to become defensive and waste time. It saves you the time of pleading with people to just not be a shit person, because often, that is what you'll feel like you're spending your time doing.

If you can, document accessibility violations before and after work is done. Count issues that could be seen as an accessibility improvement if they were made. Run experiments on accessibility related UI changes. Identify the gaps between your product and competitors. That is data you can provide.

Related to un-caring stakeholders, people are going to get defensive with you and sometimes outright nasty.

The things I've seen in reply to me asking for improvements that are accessibility related have been all over the place. The nicest will be when they give you lip service of "Yes, this is so important!" and then that work sits in a backlog until you leave the team. A little up from that will be people gaslighting you and telling you it's not that big of a deal. Somewhere in the middle will be someone calling you overly sensitive. The worst will be people that say things basically along the lines of "Eugenics is good and chill, actually, I don't see a problem." or that some people just shouldn't be accommodated for.

I can't say this part gets any easier, but I have gotten better at telling people to fuck off and moving on when needed.

The greatest improvements won't come without organizational buy-in

This one sucks, because I really like squirelling away and doing a really good job on my own on a task, then emerging with my shiny results and saying "Look! I fixed it!". You can't move mountains on your own. Start with your team. If they're on board for improving the accessibility of your work, fantastic. You have a start. If not? If you can't even get your manager to prioritize it? Your manager's manager if you have that connection? Is building accessible software important to you? Look for a new job. Unfortunately, some things don't change. If you hit a wall too many times, it's probably time to move on.

Ok, I have to add some things that are more positive, because jfc, Heather. This is a little depressing. My bad.

You'll learn to be a better person because of this work. Just, in general. Because it will force you to look at your own bias. It will force you to acknowledge the things you don't know and need to get better at.
You'll become a life-long learner and be happier for it.
You'll meet a lot of great people along the way. People that make you want to stick around.
You'll finally find value in your work.
You'll shed your imposter syndrome. The work you do is great, and needed, and important, and you belong there doing it.
You'll develop a toolset that you'll still think can be used to stop the bastards from keeping us down.

I genuinely want anything and everything that I've struggled with to come easier to developers that are just entering this space. Anything that you would tell them or your younger self? Let me know on Mastodon.

It's 2023, here is why your web design sucks.

2023-10-24T00:00:00Z

TLDR: At some point, we told design they couldn't sit with us anymore, and surprise! It backfired! Now, not only has the field and profession of web design suffered, but also, we build shitty websites.

Web designers

When I was first considering going into web development as a job, well before 2010, I didn't know what title to use. I spent countless hours in Photoshop, the design tool at the time, and equal amounts of time writing HTML, CSS, and JS. I didn't feel like a programmer; even though I took some Java, SQL, and C++ classes in college. And, the boys in the industry at this time made it known that we were not "real" developers. More on this later.

So, I called myself a web designer. It worked at that time; people generally knew I could mockup a static design to review and also make their website "look nice". This is, of course, a gross simplification of the work we, the people who used this title, were actually doing. We weren't just designing websites to look nice, we were also using our understanding of the web to design things that worked well on the web platform. Using our deeply technical knowledge; something that both designers and engineers do.

The evolution of the front-end developer

At some point, loosely around 2010*, it started to become more acceptable to adopt the title of "developer" if you primarily worked on the front-end. I rarely had to explain myself when I said "web developer" or "front-end developer". But, what I found to be lost, is that I now had to explain that I could also design websites.

Where did all the web designers go?

I don't know how else to answer this, besides: the gendering of design as women's work is why people don't use the title "web designer" anymore. It's been belittled and othered away. It's why we've split that web design role into two; now you're either a UX designer and you can sit at that table over there or you're a front-end developer and you can sit at the table with the people that build websites.

What happened around that time, in 2010 or so, that I mentioned? Well, the area of front-end work, which has been heavily gendered as "feminine" work, was finally being viewed as "serious" or "real" programming* because, to no one's surprise, something that is designed well is good for business. As a "real" career option for developers, now men are interested. You're welcome.

Sorry, building websites is for us serious manly man engineers now who can do very difficult things like making the computers go beep boop.

So at this point, if you were a web designer, you've probably switched over to calling yourself a front-end developer because:

You write code. So it feels natural to adapt this title.
You still want to influence the front-end side of the product.
You want to be able to apply your deeply technical web design knowledge as you were before, in the building of software for the web platform.

This is what I did. I felt that all of my accessibility and knowledge of the UI side of the web platform was going to be lost if I had to trust other engineers to build the website. I learned to write code in the first place because I wanted the thing I designed to also be the thing that was built. And, I learned to design websites, because I wanted to build the right things.

Since the "design" piece of web design is still viewed as a feminine role, that part of being a web designer was largely cut off from the front-end development role, now that men were all in on that role. In a lot of orgs, the people that do design are now UX designers. It's a completely different role with a different budget for head count. They sit on a different team. They're loaned and rotated out to other product teams. They're essentially cut off from their engineering partners.

We all lost when the web design role was split in two

Design is highly technical. Some will view this as a demand that designers who design for the web should learn to code, but I don't necessarily think that's true.* What I think this means is that design requires a deep understanding of a subject.

But, if our design partners are now at a different table, how do we expect them to acquire the deeply technical knowledge they need to know? I think the design role has suffered greatly since the evolution of the front-end role. The people we task with designing websites, I've found, often have huge gaps in their understanding of the technical details of designing for the web. Things like:

An understanding of the DOM and how the positioning of elements visually can be impacted by their position in the DOM (or vice versa)
Accessibility in general, from the basics of color contrast, which has grown more nuanced with the introduction of the APCA to an understanding of common ARIA patterns.
An understanding of native browser controls. It's important to understand when you're designing something that should use a native browser control and is just styled differently, or when you're designing something that requires a completely custom control which can greatly impact engineering complexity. "Just put it in a tooltip" is not always a simple remedy.
An understanding of design systems. How to maintain visual consistency, and create patterns, and when it's ok to break those rules.

These are some, not all, of the core concepts of web design. We don't call it that, anymore, but that's what it is. These are all things I would sum up as deeply technical knowledge and someone needs to know it if you're going to build a good website. If you're a front-end developer, you've probably experienced one of these gaps in a design you've been given. And if you're unfortunate to work in an org that throws design over the wall, you've probably experienced quite a bit of churn trying to rectify those gaps. So now the thing that is built is based on a poor design.

On the other hand, if your engineering team has no front-of-the-front-end engineers, who are more likely to know about these things, those gaps never get pointed out, and they never get fixed. Or, let's say your designer does have this deeply technical knowledge, but the engineer doesn't, then the thing that is built, is just plainly built wrong. We now live in a world where our designers aren't allowed to embed with the product they're building so that they can acquire the technical design knowledge they need to actually do their job and our engineers never learn about the technical design knowledge that they need to build the thing correctly.

Design decisions can only be pushed so far to the left before we realize the system is broken

We often talk about decisions that need to be made further left in the product development cycle. If only we could address accessibility, sooner. If only we could have understood how the API was going to work, sooner. I often feel like I'm ping ponging between these two scenarios:

"We would have caught this sooner if engineering was more involved in the design process".
"We would have designed this differently if we knew engineering couldn't handle it"

At what point do we stop and realize that we are setting our design teams up for failure?

How do we fix it?

Some of the issues I acknowledged are education gaps. We don't teach web design anymore. We rarely even use that term, even though that's explicitly what it is that we're missing. We don't have designers that have the deeply technical knowledge they need to design for the web. We give them a role of UX designer and make do with them having a vague understanding of how the platform works and how to design for it.

But why is there this education gap? I think that's a larger systemic question. I would love to hear folks who have a formal education in UX design chime in; because I think their role is largely misunderstood and misapplied. Having a formal education in neither design nor development, I don't have a great answer to this. On the engineering side, I do know that the recent trend of bootcamps for front-end development largely fail their students; they don't equip them with the technical design knowledge needed for building websites and, instead, often jettison them straight to scaffolding a website via a popular framework.

There is also the larger issue of who we hire for. This is something I think about often when I think about moving teams or companies. Am I going to find a place that will allow me to actually utilize all of this web design knowledge I have? Or, am I going to just be a JS engineer who spends most of my time configuring pipelines or doing ops work? I would say that most larger organizations favor the latter and live with the gaps in design. So, if you're a front-end developer, where do you spend your time developing yourself? To get the roles that companies actually hire for and pay more for?

Anyways, that's why your design sucks.

Here are some other articles that this topic always makes me think of:

Tailwind and the Femininity of CSS by Elaina Natario
front-of-the-front-end and back-of-the-front-end web development by Brad Frost