progressive enhancement is not about preventing failure, it’s about defining what must always work.

I also want one of those ”Wat als de JavaScript uit staat?“ stickers.

The incident was caused when a bug in CrowdStrike’s code made it out into production. The results were catastrophic: It caused roughly 8.5 million servers to crash. Hospitals weren’t able to serve the people that needed them. Airline passengers were stranded. People couldn’t access their money in banks. Folks in distress could not get the emergency services they needed. On top of that, the financial fallout is estimated to be somewhere around US$10 billion.

Bugs happen. I’d hate to be the person who was responsible for that particular bug (or the people in the quality assurance team that should have caught it), but the reality is that none of us who write code write perfect code. We all make mistakes and sometimes those mistakes make it into production. Other times, the code we write works perfectly during development and testing, but causes an unexpected issue in production. Sometimes only in very specific “edge case” circumstances that we didn’t have the foresight to consider.

Which brings me to the lesson I took away from the CrowdStrike incident: minimize the impact dependencies can have on your customers’ ability to complete critical tasks. In other words, develop dependency awareness.

The web is a hostile operating environment. Sometimes network connections are slow to resolve or time out completely, which may cause issues with your JavaScript, may result in broken images or videos, or could make it so your user never receives your CSS. Sometimes 3rd party scripts ship bugs that can hose your site completely. Sometimes a customer’s browser plugin can wreak havoc on your site by adjusting markup or injecting code. If any (or all) of those things were to happen, could your customers still accomplish their key tasks? Could they even understand your site at all?

This is why it’s so critical to start with a fully-functional website that relies only on semantic, accessible HTML and regular ol’ links and form submissions. They aren’t sexy, but they’re solid. Then progressively enhance that experience to improve things when the CSS is downloaded. And improve some more when your JavaScript executes properly. Build an awareness for the kinds of dependencies you have in your code so you can ensure there is always a fallback.

When I think about building robust websites like this, I often think of the Chrysler Imperial. The 1964-1966 model is one of the few cars that has been outright banned from entering demolition derby events. It is just too well built. It just takes the hits and keeps on driving. We should aspire to that kind of resilience in the websites we build.

Bugs happen. Can your site withstand them? Or will you let the failure of a single dependency (a.k.a., site fragility) ruin your customers’ day?

https://www.youtube.com/watch?v=-9GGDOUDLhc&start=7&end=17

Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.

Though critical to the project, frontend work will quite often be disregarded by those who consider it beneath them (usually men, and usually only tacitly, never explicitly). It’s not serious enough; not important enough; not real enough. Too squishy. Like soft skills.

Yes, of course, it’s important. It’s work that somebody needs to do, certainly. But probably not the important people, whose valuable attention is focused on other, bigger, more important problems.

It’s been this way for a long time. This attitude doesn’t exist on every team, but it’s pervasive throughout our industry.

# What’s the issue?

Not to pick on anyone in particular, but consider this example from a recent talk I gave:

When CSS fails to load, however, check out what happens:

Yeah, that’s an inline SVG. You see, without any explicit dimensions set, the SVG will naturally grow to become as large as possible. Chances are you’re constraining that growth in CSS somewhere, but when your CSS fails to apply for any reason, every inline SVG on your site will swell like Violet Beauregarde after eating Willy Wonka’s “three-course dinner” chewing gum.

# How do we solve this?

Thankfully, this is a pretty easy situation to avoid: just set an explicit width and height. To use an example from this site, instead of saying

<svgviewBox=“0 0 38 48”version=“1.1”xmlns=“http://www.w3.org/2000/svg”></svg>

You can explicitly set the width and height in the svg element like this:

<svgwidth=“38”height=“48”viewBox=“0 0 38 48”version=“1.1”xmlns=“http://www.w3.org/2000/svg”></svg>

What you set these values to will likely vary depending on how the icon is being used. In a pinch, you could also pull the values directly from the viewbox value. And using that value, you could even make the inline values dynamic within your template, reading in the viewbox values and tweaking them to a ratio specific to the context.

Setting the SVG’s dimensions inline like this doesn’t restrict their flexibility either. You can still use CSS to override these inline values and set the SVG to whatever size you wish:

svg{inline-size: 200px;block-size: 200px;}

I’ve thrown together a quick comparison over on CodePen so you can see the three different states:

And now that you know, please, please, please take a few minutes to make this small, simple change to your websites. While not a catastrophic issue, taking care to control how your sites render in the worst of circumstances goes a long way to demonstrating thoughtful consideration of your users.

Update: For more in-depth info on this topic (and scenarios where CSS isn’t applied to your SVGs), be sure to check out this piece from Sara Soueidan.

I’ve worked on the web for a long time. When I say a long time, I mean a long time. As in my first browser was on the command line old. As in my first back-end development was a CGI script old. With my nearly three decades of building dozens upon dozens of projects for the web, the one skill I’ve found most valuable is the ability to bridge the gaps between the worlds of design, user experience, and development.

Each of these fields attract practitioners from different education and/or hobbyist backgrounds. This can be a point of tension, as folks in each camp tend to see their own field as having the greatest influence on a web project’s success. The reality is that web exists in the nexus of these fields, relying equally on what each of these practices bring to the table. I have found that the most valuable people in any web project are those that understand enough of each field to be able to operate in that nexus, ensuring each team is communicating effectively with the other teams and that everyone is working together toward a shared goal.

Which brings me to Stephanie Stimac’s Design for Developers. This book is an invaluable resource for developers looking to level up in their understanding of what it takes to build for the web today. It provides a crash course in design and user experience in a way that will both improve your fluency with these topics and give you the necessary skills to become productive in these spaces as well. Beyond that superficial perspective, however, this book provides the foundation for leveling up your career and becoming the person who thrives in the space between design, user experience, and development.

Stephanie is the perfect person to provide you with these insights as well. Not only is she an excellent communicator, she also has years of working experience as a designer, developer, user experience practitioner, and an educator. She’s even worked behind the scenes on web browsers and the web standards they implement, giving her an incredible depth of understanding when it comes to the web and the tools we rely on to build it.

Whether you’re a longtime developer looking to grow a new branch on your skill tree or you’re starting out and looking to get a solid foundation in what it takes to build for the web, Design for Developers is sure to provide you with a wealth of knowledge to help you on your way.

This is a great writeup from Kevin Powell.

I have no illusions about being some kind of lone wolf. All the stuff I’m making “by hand”—the way it approaches form, function, and materials—has been informed by philosophies and techniques developed by an amorphous community that spans generations. This work proliferates through byzantine open source projects, yes, but it also proliferates through books, blog posts, and videos with titles like “Custom Styling Form Inputs With Modern CSS Features.” When I’m making things, that’s how I prefer to depend on others and have them depend on me: by sharing strong, simple ideas as a collective, and recombining them in novel ways with rigorous specificity as individuals.

Using progressive enhancement means your users will be able to do what they need to do if any part of the stack fails. Building your service using progressive enhancement will:

• make your service more resilient
• mean your service’s most basic functionality will work and meet the core needs of the user
• improve accessibility by encouraging best practices like writing semantic markup
• help users with device or connectivity limitations to use your service

🥰

He’s posted a text version of the talk on his site as well.

The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

On reading the text of the WS3A, I really appreciated the thought they put into the way it’s structured. In a nutshell, it

1. Affirms that the (ADA) prohibits discrimination against people with disabilities in their use of websites.
2. Tasks the Department of Justice (DOJ) and the Equal Employment Opportunity Commission (EEOC) with establishing, updating, and enforcing accessibility standards for websites and applications.
3. Sets up a committee to work with these government offices to establish the rules that govern digital accessibility. It also establishes a central repository (and governing committee) to provide guidance on how to achieve compliance. Both committees must include representatives from numerous named disability communities as well as digital accessibility experts.
4. Identifies who needs to abide by these standards (e.g., the government, employers, commercial entities).
5. Establishes the legal grounding for litigation (from both the government and citizens) of violations of the established standards.

There’s more to it than that, but it’s a reasonable summary. I suggest reading Senator Duckworth’s summary doc for more detail as well.

# We don’t all need “the same” experience

In Section 3 of the WS3A, a part of the definition for “accessibility” is the requirement for people with disabilities to be able “to engage in the same interactions as” people without disabilities. This sounds good on first blush, but I think “the same” could be misleading.

A number of years back, I was consulting with a financial services firm. Their web team was quite interested in putting accessibility into practice on their website after spending a few days talking about it with me. When I circled back a few months later, things weren’t going so well. The team that was focused on accessibility was two sprints behind “because of accessibility” and management was ready to give up on it. And so I asked them to walk me through what was going on.

The problem was an interactive graph they had built for a page in their company’s marketing site. It allowed users to see how much they’d save in fees over a certain number of years based on an initial investment amount that could be adjusted via a slider control. The slider allowed the initial investment amount to range from a low of $5,000 to something like $5,000,000 in increments of $5,000. They had run into all sorts of delays in getting the slider to work identically for people using either a mouse (the default they’d considered) or a keyboard.

After getting the details, I had them take a step back and look at the big picture. I asked them to consider the goal of the interface: to help people understand the more they invest with this company, the more they will save in fees. Then I asked them if the keyboard experience of that slider was a good one. It wasn’t; no one is going to move the slider potentially several hundred times to get to the exact amount they’re considering investing, nor should they have to. So I asked them to reconsider their approach and come up with other ways to achieve the goal. After all, this was for a marketing site; they weren’t displaying someone’s actual account information, where they would need to be more exacting in their approach.

They realized the same goal could be achieved in two ways. First, they could ensure the copy that came before the visualization offered the same information in textual form. Second, they could simplify the slider interface to have a set number of stops for keyboard users, to give users a sense of how things would change, but without making the interface tedious to use. These were both excellent alternatives and provided a better, some might say more accessible experience for folks who relied on a keyboard to both navigate and interact with he web.

When it comes to accessibility, it’s easy to get hung up while trying to provide an identical experience when that isn’t always the best thing. Everyone should be granted the opportunity to accomplish the core goal of an interface, but they don’t necessarily need to do it in the same way. If we get too caught up in providing the same experience, it’s easy to miss out on providing the right experience.

So, in reflecting on the WS3A’s definition of accessibility, I would prefer to see a little more nuance. I did notice that later, in the Rulemaking section, they use the phrase “equally effective experiences for users with disabilities and users without disabilities.” That’s a much better goal here. The same opportunities need to exist; parity is important, but not everyone requires the same accommodations.

This applies in other contexts too. For example, some images are informational, others are decorative; strict reading of a requirement for “the same” experience might lead folks to believe all images require descriptions, which they don’t. Similarly, users need to have control over how they receive information. They need to be able to adjust font sizes, stop things form moving around on the screen, change the colors of the interface to improve readability, eliminate distractions, and so on. We need to be building interfaces that can adapt to serve our users’ individualized needs across a wide range of intersections encompassing their own capabilities and disabilities as well as those of their device, their network, and the influence of their environment. (Insert shameless plug for my book here.)

# We need to better-define an “undue burden”

The WS3A provides two pathways for an entity to side-step their obligations under the ADA. One seems pretty reasonable: if compliance would “fundamentally alter the nature” of the entity’s offerings, they can be excused from having to comply. The other reason creates a huge loophole, however: if compliance would “impose an undue burden” on the entity in violation.

What exactly is an “undue burden”? According to the ADA, it means “significant difficulty or expense,” which is determined in consideration of:

1. The nature and cost of the action needed under this part;
2. The overall financial resources of the site or sites involved in the action; the number of persons employed at the site; the effect on expenses and resources; legitimate safety requirements that are necessary for safe operation, including crime prevention measures; or the impact otherwise of the action upon the operation of the site;
3. The geographic separateness, and the administrative or fiscal relationship of the site or sites in question to any parent corporation or entity;
4. If applicable, the overall financial resources of any parent corporation or entity; the overall size of the parent corporation or entity with respect to the number of its employees; the number, type, and location of its facilities; and
5. If applicable, the type of operation or operations of any parent corporation or entity, including the composition, structure, and functions of the workforce of the parent corporation or entity.

The exact math is not exactly clear-cut—especially when we’re talking about digital products as opposed to physical structures—and I could see a number of corporations declaring something an “undue burden” when, in fact, it is relatively easy to address. It would be nice to see some guidance around what is considered to be a regular “cost of doing accessible business” in terms of percentage of operating revenue or percentage of staff dedicated to identifying and remediating accessibility issues.

# Other things I hope to see addressed

Below are a some additional questions and thoughts I think the commissions operating under the WS3A should seek to address:

• If we agree accessibility is a journey, not a destination (i.e., we’re never “done”), how can we declare something is “accessible” (or not)? It feels like the Web Content Accessibility Guidelines (WCAG) offer some solid guidance and that will likely set the bar for this effort, especially given that Section 508 of the Rehabilitation Act relies on that set of guidelines as well. I’m encouraged by their recognition that what’s needed is ongoing evaluation of the guidance as well, but it still presents challenges around how we define “accessible enough.” Additionally, digital products are different because they are easily changed, updated, and improved (as opposed to, say, a giant set of concrete stairs).
• We don’t really have clarity around the mechanisms for informing non-compliant entities of their violations. It’s also unclear as to whether there is a reasonable grace period for them to remediate the issue and report back for validation. Having a grace period to address issues will also be key for heading litigation trolls off at the pass.
• We need some guidance around how much of a disruption is grounds for a formal complaint. Many organizations ship code pretty much constantly and may introduce an accessibility bug and then address it within a few minutes, hours, or days. Again, a grace period starting when the entity is made aware of the violation would be key for addressing this.
• Third-party code is not addressed at all in the WS3A. Whose responsibility is it? A huge percentage of the web (and other software projects) are built using open source and commercial codebases that they don’t own or control. If an entity tests a piece of third-party code and determines that it meets their obligations under ADA and then an update to that code introduces an accessibility bug and they are unaware, who is at fault and who is responsible for the remediation? The process seems a little more straightforward with open source code, provided the library maintainer is open to contributions that improve accessibility, but commercial code is a whole other thing.

On the whole, I really appreciate what Senator Duckworth and Representative Sarbanes (and their staff and partners) are trying to do here. I hope it passes and look forward to keeping tabs on the work of the various commissions tasked with providing the necessary guidance and resources that will lead to a more inclusive web.

🤞🏻

<details> and <summary> elements are complicated. Saying don’t use them isn’t really practical and there’s a lot of good things about them. But they do have bugs. … It really just all comes down to what sort of experience you want to provide to people, and how OK you might be knowing that the native elements are going to be exposed differently, have different gaps but also different features to them.