Heather Buchel

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

The JS community on Twitter is dead.

2023-09-17T00:00:00Z

A disclaimer to start this out: If you feel like I'm talking about you and this has you in your feelings, yes, I am.

This weekend's discourse around accessibility validated my decisions to not carry out work there. I largely stopped posting on Twitter many months ago; minus the random check in, to reply to a peer's post, or just throw out a few likes. Since moving to Mastodon and Bluesky, I get my fix of posts and interactions with the web, disabled, and accessibility communities I still love and activists I follow.

I don't want to link specific tweets because I honestly don't care to send people into that. If you saw the announcement of v0.dev, you can probably find them on your own. That is, if Twitter lets you since they seem to mostly surface the scum of the earth verified account replies. I touched on this discourse a little in this post about ai generated UI if you want to go hunting. You'll probably have seen some of the larger tech accounts in the JS world mention it also.

Isn't it curious that the only time the JS community on Twitter rallies around accessibility discussions is when they get to feel the victim for being "shamed" for not caring about accessibility? Strange how that works.

This is the current state of the JS community on Twitter

We're at this point:

Some new alpha tool that impacts user interfaces is announced to the JS community? The accessibility community shows up with respectful feedback. Seems perfectly normal since alpha is the perfect time to get feedback.
Accessibility advocate shows up with reasoned feedback and requests transparency and accountability? Misogynists, and nazis show up.

"Accessibility echo chamber", "accessibility shamers" were some of the nicer terms I saw thrown around amongst people arguing that disabled people were not worth the work of making software accessible and other disgusting replies.

What are you doing?

If you're a member of the JS community on social media, specifically on Twitter, what are you doing? Not only did I not see anyone from this specific company disavow this type of talk (I honestly don't care to check these few days later because I saw enough), others were reaching as far as possible to basically apologize for them.

If you found yourself watching this weekends "drama" as some of you are calling it and saying any of the following:

"Yes, well nothing can be 100% accessible" or
"Gee it is just an alpha software, surely you can let them slide" or
"golly, well look at all these accessibility issues in this OTHER software I found" or
using your verified Twitter account to post your essay on how "accessibility is actually really hard!" when you rarely talk about accessibility except when you feel like somebody is shaming you because you as a white man never learned what it's like to get feedback

Then, yes. You are also a part of the problem in this discourse. Your "well actually" posts are just going to get co-opted by the people that think "well actually ableism is acceptable". Take a hard look at the people that are cheering you on for your well meaning replies.

You're also missing the point entirely and you're jumping through hoops to ignore the fact that an accessibility advocate nicely brought up feedback in a public forum where it is entirely appropriate and expected to do so and a large amount of replies were, at best, incredibly toxic and at worst, espousing nazi rhetoric.

If you find yourself thinking "but I rarely see stuff like this, this is a minority and not indicitave of what it's like here" please understand that you are probably in a position to easily keep your head in the sand.

If you think "But I'm a member of the JS community that is predominantly on Twitter and I'm an accessibility advocate" then why didn't you show up in support of the very normal and reasonable feedback and leave it at that? Why didn't you bring up any of the accessibility features you'd have liked to see included? None of the feedback regarding accessibility that I saw was mean or attacking anybody. It's because somebody had the nerve to even bring up accessibility that people got in their feelings.

Why aren't you using other platforms where a lot of accessibility advocates moved to and also doing your community work there? I've seen lots of folks who I would say are part of the JS community cross post on Mastodon, where I generally feel like there are more web standards and accessibility people consistently posting and having fruitful discussions about how to make the web better, in addition to Twitter, where a large part of the people who want their educational content still live.

The cynic in me understands that the very "bad" people are important to paying your bills at the end of the month. Or, they're who make you feel popular in the web community. Maybe think about that.

This is what is left of the JS community on Twitter.

We're still not innovating with AI-generated UI.

2023-09-14T00:00:00Z

No tool that asserts you can build production-grade UI code from their AI is innovative if it's not driven by accessibility. It's also not production-grade if the code it generates is inaccessible. That is the short and sweet of it.

Not everyone is claiming that their AI tool is particularly innovative. But like most things involving AI right now, we are seeing some pretty wild claims.

We've been here before.

This is where we are and it's where we've been before. We've been in this same scenario with design tools prior to this current AI craze; tools that claimed designers could build responsive, accessible websites straight from the design or WYSIWYG editor. And maybe we got a little close to that, as long as your website was mostly text, images, and links to other pages that were just text and images. Even in those "close" scenarios, you'd probably still be left with out of order headings and unlabelled navigation elements.

And, your developer would wonder how on earth are they going to keep design-generated code maintained and on par with what they actually end up shipping in production.

So here we are again.

tweet source

I'm not even mad at what it does. It looks like it will be a great tool for prototyping. A tool to help developers that don't have experience with CSS and layout to have a starting point. As someone who spent some time building smoke and mirrors prototypes for UX research, I welcome tools like this.

What concerns me is the assertion that this is production-grade code when it simply is not. I won't dig into all of the issues. Lucky for us, amidst all of the blockchain and AI fans foaming at the mouth to use this new toy, senior software engineer Ashlee M Boyer has graciously highlighted some of the accessibility and HTML issues of the generated code. Unlabeled buttons, form elements, and assuming someone will use <button> elements for page navigation, are just some of the very foundational things it gets wrong.

Code that generates an inaccessible UI is not production-grade. Until our tools capture context of what the UI is meant to do, and not just what it should look like, and until it can "know" about other elements in the UI, we are not doing anything innovative with generating UI code. In the end, all we've built is a really high fidelity mockup of what the UI might look like.

How do these AI tools actually fit in the front-end space?

I've mentioned prototyping. But even then, I'd hesitate to put it in the hands of an engineer that doesn't know UI development. It's the same with handing off a design mockup in Figma or Sketch that doesn't spell out the required accessibility needs and interaction states; like focus, disabled, etc. There are a lot of gaps to fill in.

Sometimes, however, tools like this can be yet another tool in the arsenal for design teams to help translate ideas to engineering teams. We don't always speak the same language. It's nice to have things to point at and go "See, like this" and tools that overlap the design and engineering worlds are useful. Why can't this be good enough, a pre-development tool? Is it because it's now a tool that can cater to the UX/design crowd?

Ok, here is the cynical part.

I'm cynical about the web industry these days. I generally feel like companies with poor leadership who make bad business decisions will view these tools as a cost-cutting opportunity. Why hire a UI focused engineer, when we can get the JS engineer with no accessibility experience to throw it in at the end from some generated code?

This isn't a totally new experience for us on the UI side; we're used to getting pulled in at the wrong times to fix interfaces and to address accessibility after it's become a risk. A risk, because customers are frustrated with the clunky UI that didn't take into account keyboard navigation or other normal web things. Or, potentially, a risk, because now they are being sued for not offering an accessible interface. A lot of us have found quite a bit of job security in fixing problems that we created. I would rather, however, spend my time actually building innovative UIs, and that starts with accessibility at its core, not AI.

If we review the past ten years or so of thought leadership (ew) in the web community, we can also see how a very vocal few have had a large sphere of influence. That's why it "feels" like everyone is building single page apps, when that's not true. And that is why I take issue with CEOs like Guillermo Rauch announcing to their fanbase* what is really just an illusion; it's disingenuous to everyone involved.

*Let's be honest, that's really what the web community feels like on Twitter these days. The days of really engaging discussions on that platform seem to be over.

It bothers me to see yet another burden put on the shoulders of people who already spend a lot of time and energy laboring in the areas of accessibility and UI development. We are already left to plead for our space while watching bad things get decided for products we work on. Now, we have to add "talk the stakeholder out of using a text prompt to build the new UI feature" to the list?

This is new technology!

I've seen a number of excuses for these tools being new or in an alpha/beta state and that is the reason why the code generated isn't accessible; which apparently is some magical separate state of being production-ready that is OK to skip over before releasing to people /sarcasm. I've written about this excuse before but heres the gist of what I think this excuse really says:

You didn't consider disabled people using your product.
You don't work with any disabled people.
You haven't hired anyone that focus on accessibility.

Wrapping up, I guess

Honestly, I'm tired. We create problems like good UI being difficult to build because we won't hire people who can build good UI. It's boring and predictable, and nothing new.

How do you see these tools fitting into our front-end space? Let me know on Mastodon.

Just normal web things.

2023-07-06T00:00:00Z

We've let ourselves get away from building websites that can do normal web things. I've noticed this a lot recently due to a surge in new social media platforms springing up. Everyone is building new clients, apps, and in some cases, like React Native, attempting to share code across platforms. It's definitely exciting, and I'm actually thrilled that people are building these things.

What is less thrilling is that, nevermind the basic accessibility requirements that are often missing like alt text on images, we stopped letting people do very normal web things. There are a number of avenues to route the blame to: rushing to release something midly usable for testing protocols in the wild, not having a UI engineer on the project, building things in a mobile "touch first" experience and ignoring other inputs or devices; the list goes on. In the end, it's usually because we've JavaScript'ed our way out of these things.

Here are some things I wish people allowed to continue to work in their web projects:

Let me copy text so I can paste it. Please. This is often cause by removing pointer-events or layering elements on eachother that are meant to be clickable. This happens a lot with clickable "card" components.
If something navigates like a link, let me do link things. Let me right click on the link without it navigating so I can open the context menu that lets me do other link things (like copying link text, copying link address, etc.) Let me use usual link keyboard shortcuts (like ctrl + click on Windows) to open in a new tab. Just normal link things. This is that dreaded thing that us front-end folks are always harping on about: using a div with an on-click to navigate instead of an anchor element.
Let me zoom in on my browser without the website getting all out of whack. I just want to be able to read.
Do responsive things I didn't spend most of my early career convincing clients to let us do a responsive website just for you to serve me up a boring layout that kicks down to your mobile layout as soon as you are less than 1200px. I actually think Mastodon and Twitter do a good job at this. The UI feels familiar if you drag your browser down to a small narrow viewport. The space mostly gets used.
Let me have hover styles I've seen too many React Native ports to the web that have zero :hover or :focus styles beause "you can't hover or tab on mobile, right?" (wrong) or weird disabled looking :active styles. Do normal interaction state things for the web in your web app. This issue in particular almost always makes it glaringly obvious when some poor soul ported their RN app to the web to save time.
If the UI completely changes when I click on something, as if I've navigated to a new page, give me a browser history update and a new url It's annoying not being able to link to a state in the UI that appears to be it's own page and that is lost to the void if I navigate away.
Let me see scroll bars Please don't hide them for the sake of your "slick" ui. Sometimes I want to click on the scrollbar and drag it. Just a normal web thing.
Stop hijacking my typical browser shortcuts for use in your own app I've seen this happen with ctrl + f for opening a custom in-app search bar. I don't want that. It doesn't always search the page as usual.

I stopped myself from adding a lot of things that would usually fall under accessibility violations though there is definitely a lot of crossover in the list above. What did I miss? Let me know on Mastodon.

My CSS reading list roundup (July 2023)

2023-07-05T00:00:00Z

Recently, I took the State of CSS survey and they have this handy feature for each question where you can add that topic to a reading list. After you finish the survey, they send you an e-mail with links to articles about each topic. Wonderful!

The last several years I've felt further and further pulled from the tech I really love: CSS and UI building. So, in addition to gently nudging myself to work on more side projects, I've been trying to get back into looking up new topics. Here is a round up of things I'm looking forward to tinkering with that are new or new-ish to me:

Subgrid

To be honest, I've worked without subgrid for so long now and have typically found some sort of workaround that I'm not sure what immediate use I'll have for this. Still, it will be interesting to see if I can find ways to uncomplicate or remove some div-soup from layouts.

Subgrid on MDN

Container queries

I feel like this is the star item I want to delve into right now. One thing I found working with engineers who consumed design systems is that they often struggled with piecing together responsive layouts from components. If we can bundle more of the "responsiveness" to the component itself, since we don't always know the context they'll be used in (i.e. in a sidebar, in a large content area, in a small popup, etc), that's a win.

Container queries on MDN

Viewport units

I've been using viewport units like vw and vh for sometime now, but I'm excited to revisit some layout quirks that might now be readily addressed by using dynamic viewport units like dvh that take into account things like browser toolbars on mobile; you know, when 100% height gets jumpy or cutoff once the toolbar scrolls away.

Viewport units on web.dev

Anchor position

Wow. I'm so excited to see CSS features that tackle some of the really complex parts of UI development. If, like me, you've ever had to anchor a popup or tooltip to an item and found it incredibly complex or annoying, this is for us. Anchor position will allow you to, essentially, tether an element to another.

Tether elements to each other with CSS anchor positioning

prefers-contrast

This is cool. I've already been testing how some of my work fairs in Window's high contrast mode, but it's neat that there are more options for possible themes to serve users besides just light and dark.

prefers-contrast on MDN

Thoughts on crowd sourcing your accessibility feedback.

2023-07-04T00:00:00Z

Some recent discourse regarding accessibility on BlueSky left me with some feelings about crowd sourcing your accessibility feedback. I'll copy that post here since BlueSky is still invite-only:

I really hope BlueSky is paying the people spending time to collect and relay accessibility feedback that they've reached out to for guidance. Like this isn't just a cute little open source library. You're bankrolled. me, posted on Bluesky

There are two things I've noticed on BlueSky since I joined: 1. BlueSky seems to largely be gathering their feedback on accessibility issues via crowdsourcing. 2. People were excusing why the app and website launched with glaring accessibility issues (this is a link to Bluesky discussing some of the issues; my apologies if you can't access it, it's not really necessary for this discussion).

Relying solely on crowdsourcing for accessibility feedback leads to inconsistent results and excludes contributors

Accessibility consulting is a whole job. Even as a developer who refers to themselves as an advocate and not a full time accessibility engineer, it is work that easily and often leads to burnout. It's worth paying someone to do this work just as much as you think it is to pay someone to re-write your application in Typescript; or whatever other tech problem someone might think is absolutely essential, you get the idea.

When you don't treat it as a job worth paying someone for, you'll get inconsistent results and will probably make poor progress on fixing anything. Crowdsourcing your accessibility work often only attracts people that "have time". That is, they:

Can afford giving up their time to someone else for free
Have fewer responsibilities to other people (spouse, partner, children, family)
have the ability to work extra hours, i.e. after work or on weekends.

This likely excludes parents or caregivers, people who financially cannot afford to work for free, and/or people who may not have the "spoons" to do extra work. You're essentially accepting, by only seeking crowd sourced feedback, that most of your feedback will probably come from folks that are more than financially secure, probably young or lacking responsibilities to other people, and do not have a disability. This excludes so many people.

Additionally, a lot of accessibility issues that are found in a product, are usually not one-offs; they are often systemic. This is where inconsistency comes into play. If you don't have a plan for someone to address issues in an ongoing basis, you're likely to have regressions.

The excuses

There is always this slew of replies given when you bring up that a product opened its door to users in a poor state regarding accessibility. These replies often look like:

"But it's a small team!"
"Gee, it's only in beta. It hasn't even launched yet."
"Well it's open source, why don't you fork it and fix it or make your own client."

Please stop doing this.

But it's a small team!

If you're mantaining an open source product that includes a UI that people use, you need to attract people that build UI to your product. Invite them. Seek them out. Hire them. Show them how they can contribute if they are not code writers or if they don't use your specific framework/tech stack/etc. If you're doing something so ambitious, like creating a product to replace Twitter, it's your responsibility to find the right people.

Twitter and Reddit are examples of apps where open source platforms are springing up to replace them. But it should not be overlooked that these platforms were used for community building. For mutual aid. For activism and raising awareness. We're not talking about replacing your go-to linting library or image minification tool. We're talking about services that some have argued should be a public utility; that is how important they have become.

This excuse has even less weight for a product like BlueSky, which is funded by Jack Dorsey. They are bankrolled. Hire disabled people.

As a side note, R.I.P to the Twitter accessibility team. From the outside, it looked like they were putting in the work and coming up with creative solutions that were rooted in accessibility. Did Jack learn nothing from the very smart people that worked at Twitter? Maybe it's just me, but if I'm fronting $13M for a product where at least the UX largely mimics an existing product I previously owned, I'd probably look to recreate what worked well there.

It's only in beta.

Stop treating accessibility as features or line items that can be tacked onto products at a later date. When you launch a product, or open the door to users, and there are glaring accessibility issues that cause the app to be completely unusable, that says a few things quite loudly:

You didn't consider disabled people using your product.
You don't work with any disabled people.
You haven't hired anyone that focus on accessibility.

If you start with accessibility-driven development, you can launch a mininum viable product that is actually viable for people to use.

It's open source, you do it.

This is another excuse that says a couple things loudly:

You're making an assumption your users are programmers? And that's the only way to have an accessibility issue fixed? Not a great look.
You don't see accessibility as being crucial to your product.

Accepting feedback

The "excuses" discussed in this article are usually the result of someone feeling very defensive. I get it. It feels different to get feedback related to people's frustration using your product than it does for something like a weird browser issue or a critique on how you decided to write a bit of JavaScript. People tend to get very defensive when it comes to accessibility feedback.

One of the best things you can do, especially if you run communication for an open source product, is to learn how to take this feedback. Most of the time people are just happy to hear that you have a plan to address the issue; they don't necessarily think you are a terrible person because you missed labelling a button. Increased frustration comes when this becomes a repeated pattern that goes unacknowledged. Or if, you know, you're funded by a billionaire.

Obligatory post about re-starting my personal site.

2023-07-03T00:00:00Z

I think anyone who has lived on the internet for a long time has had this moment: when you finally decide to re-visit your personal site. If you work on the front-end in the web space, it probably gnaws at you weekly.

Anyways, here is mine. I'm back at this for a few reasons:

We're as of writing this, watching Twitter gut itself from the inside. Twitter was my "space" on the internet. I met and followed a lot of individuals there that had meaningful impact on my life through job offers, sharing their activism, or just general knowledge sharing. I'd like to have a "space" of my own again.
I've been looking into other social platforms lately. I've joined Mastodon, Pixelfed, and Bluesky. Those fulfill the online social space that Twitter left. Still, I'd like to have a place for putting some words to screen that don't fit the format of a thread on those sites.
Work. Companies are laying off people left and right, and that makes me feel uneasy about my job that I feel lucky to still have. Time to get my online space back in shape so I have somewhere to send people to if/when the time comes.

The main reason, though, I miss tinkering on the web. I've been at this web developer thing for a while now, which means my career has taken me from "Person that spends every waking moment experimenting with new web tech and making wonderful things with CSS" to "Person that spends most of their time consulting for other people, writing docs, attending meetings, and for whatever reason, writing A LOT of javascript". I whole heartedly miss being enthusiastic about building things on the web. I think it's a crucial time to get back to that; especially as we watch multiple platforms destroy themselves and the spaces people created with them.