CSS and design systems people - BlogFlock

Joining Shopify - Adam Argyle

2025-09-15T17:00:00.000Z

I'm stoked to share my next role:

Design Engineer at Shopify;
alongside Jason Miller to hack on next-gen admin UI/UX and a new Polaris.

I'm also workin to rejoin the CSSWG via Shopify too 🙂

Thanks for all y'all's support! 💀🤘🏻

Twitter Integrated Again - Adam Argyle

2025-09-13T17:10:45.000Z

Twitter comments, likes and reposts are now integrated.

Ditch those words! - Robin Rendle

2025-09-13T16:18:00.000Z

Over the past couple of years I’ve noticed that 90% of my design feedback comes down to these three things:

Ditch those words!
Ditch those words!
Ditch those words!

It’s the fastest way to make a design more easily understood because almost every interface tries to explain too much at the wrong time and is far too yappy. Modern interface design is made up of sentences and sentences of needless information, over-explaining every detail and presenting too many ideas and concepts at the wrong time.

It’s strange because as an annoying book person I believe in words! I want more and more words. I want fancy words and long-winded words and difficult words. I demand complexity! I want to think and ponder and struggle with a sentence that is trying to drag me along with it on a rip-roaring ride that I can barely comprehend. This, to me, is the textbook definition of fun.

But here’s what modern UI design looks like: There’s always a confusing title; it doesn’t quickly tell me what to do or what it wants me to understand; beneath that there’s a subtitle, explaining the title again; beneath that there’s several sentences that restates the title and subtitle but simply jumbles all the words around to make it justify its existence; then the button—there is always a button—and it asks me to “Confirm” or “Apply” but as to what I’m confirming or applying I have absolutely no idea unless I go back to the text and fight my way through it all again.

Folks will spend so much time adding fancy illustrations and making sure the icons aren’t blurry but when it comes to words and actions in interfaces they seem to gloss right over them. We have learned to scan UIs like robots because the folks who designed them don’t care for the words as much as they cared for the fonts or the colors.

But words in an interface have a different job than they do in a book and behave in a different way. Every word in a UI needs to act like a hammer, with each successive word the interface should become clearer, more easily understood. If you put a word like Explore in an interface it might make sense but now add another navigation item like Discover beneath it and now both words make no sense. The UI has collapsed into meaninglessness and folks are forced to click and think and furrow their brows to understand the difference between the two. This is because words in interfaces have relationships: they all work together to build comprehension. If one button or title or navigation item is confusing then it makes everything else more confusing, too.

The cynic in me worries that the folks who made this interface don’t want me to read the popup or modal or alert or web page or list of settings or whatever and they really just want me to click a button. The words are designed to be longwinded and confusing. They just want the click. The more hopeful designer in me worries that these folks just didn’t spend the time necessary to understand what they want from me. Either way, it sucks.

So this is feedback I give to myself as I’m working on an interface today: Remove that subtitle! Make that title as brief as possible! Kill that second sentence! Make it impossible for users not to read this! Disambiguate! Separate these concepts! Hide the fluff! Say one thing! Ditch those words!

WWW Ep209 - Adam Argyle

2025-09-11T15:42:49.000Z

Ep #209
Is Cracker Barrel a JS Framework?

Robbie and I talk about JavaScript trends, from the overuse of hooks to frameworks chasing sameness, and why Cracker Barrel’s rebrand feels like a frontend metaphor.

⤷ whiskey.fm · youtube · spotify · apple

One List To Rule Them All - Adam Argyle

2025-09-10T23:02:20.000Z

Whether I'm giving a talk or on a podcast, these two things constantly pop up:

how do I find what to study to keep up?
what's new in CSS?

If you've wondered those things before, then this list is for you.

Find something you've never heard of, click the link; and look at you, you're already getting more familiar with what's new!

Selectors #

Pseudo Elements #

Language #

CSS Nesting

@rules #

Color #

Functions #

Properties #

Values #

grid-template-columns: subgrid;
text-align: start | end;
overflow: clip;

Queries: #

Units #

There's a whole lot of units now. In my opinion, each are unique and useful in their own occasions. Super powers, knowing which to use when.

Relative #

Root Relative #

Absolute #

Viewport #

Container #

Have a suggestion? Let me know on Bluesky or Twitter! 🤝

Poverty, By America - Robin Rendle

2025-09-07T16:03:15.000Z

There are books and then there are books. The kind where you can’t put down until they’re finished with you. The kind that captures every atom of your attention and changes something deep down. You walk away altered, the words having not really been words or sentences but something else altogether.

That’s how I felt reading Matthew Desmond’s Poverty, By America. This is no dreamy communist manifesto, no incoherent rant that leads to nothing but sadness and frustration, but a shocking book full of actionable, kind ideas entirely backed by careful study of a complex problem. Desmond makes his argument clear through this complexity though: the reason why poor folks are poor is because rich folks are rich.

Here’s my notes.

Poverty isn't simply the condition of not having enough money. It's the condition of not having enough choice and being taken advantage of because of that.

(I remember being caught in a web of overdraft fees when I struggled with money. There’s still this lingering feeling fifteen years later where I doubt every time a check will clear, a credit card will go through. I still assume that banks have caught me in some great trap beyond my comprehension. There’s a spider lurking behind me, ready and waiting to devour every paycheck that clears my account. This is not a healthy way to run a society, or a healthy way to live. But tens of millions of Americans do.)

When we are preoccupied by poverty, “we have less mind to give to the rest of life.” Poverty does not just deprive people of security and comfort; it siphons off their brainpower, too.

(I remember being shocked by how similar poverty felt like a sickness, as if I had blinkers on, as if a strong vignette had been applied to my vision. Money was all I could think about. I would count the pounds and pennies, counting and counting and counting at night. I couldn’t think straight, I couldn’t think about a 401k or future investments because I was so paralyzed by Today, this big and brutal and terrifying thing. What if someone after work asked me out for a beer? What if we walk passed a shop and my credit card fails when trying to buy water? What if someone finds out how much is in my account?)

(And yet! I was one of the lucky ones to have family to bail me out, as embarrassing as it was to ask them over and over again. Most folks however don’t have people to help them. This is what the government should be. And, currently, what it is not.)

(But we can fix this.)

A higher minimum wage is an antidepressant. It is a sleep aid. A stress reliever. Vocal segments of the American public, those with brain space to spare, seem to believe the poor should change their behavior to escape poverty. Get a better job. Stop having children. Make smarter financial decisions. In truth, it’s the other way around: Economic security leads to better choices.

(I remember my first real paycheck. The one where I didn’t have to struggle. The one where I was lifted out of worrying so much. I could suddenly go out and buy food and start going out for dinner or the pub intermittently without feeling anxious the whole time about embarrassing myself by my card failing. I could make rent. But it wasn’t all these material things that money gifted me: it was sleep. With the sudden turn of a week I could now make predictions about my future. Mere days before my life was broken up into excruciatingly long weeks. Paycheck, no-paycheck, no-paycheck, no-paycheck. This is not a healthy way to run a society, etc. etc.)

Somehow, the United States has the unique distinction of lacking universal healthcare while still having the most expensive healthcare system in the world.

(One time back in the UK I had 40 quid in my bank account but found myself with a serious and embarrassing medical emergency. At midnight I went to the hospital and I suddenly found myself begging a doctor for help in a corridor outside his office. He told me the STD clinic opens in the morning, come back then. In agony I laughed and said “I might not be a doctor my dude but I can GUARANTEE that isn’t the problem here.” A few days later, the embarrassing surgery is over, they tell me to go, and I simply walk out of the hospital. There’s no pay station, no worry about handing out cash or finding myself slammed with debt because the UK has a modern, humane health care system. When I moved to the states I learned that how much money I make doesn’t really matter. One foul move, an uncontrollable accident like the one I had back in the UK, and that’s all it takes to lose your financial footing. And, because of this, poverty haunts everyone in America.)

(But we can fix this.)

(I think this is why I loved this book. It’s angry but not cynical. Desmond argues over and over again that we have fixed the balance of power in this country before and we can do it again. Poverty is not a hex, a curse,a chronic condition or necessary evil. It can be fixed!)

(We just have to make it so.)

Gradient Style Is Out Of Beta - Adam Argyle

2025-08-28T20:39:59.000Z

I'm happy to share that gradient.style is out of beta and:

has been Open Sourced
finally supports multiple background layers

Open to feedback and comments 🙂

The Making of gradient.style - Adam Argyle

2025-08-27T05:45:03.000Z

Found these pics in a drawer and thought it'd be fun to share the journey of creating a CSS spec compliant gradient generator in 2023.

gradient.style
A CSS5 HDR color enabling gradient tool

Can even visualize effects using shorthands and DX tricks.

Gradients and Their Lines #

Here's a sketch of a linear gradient line. The top left image shows a triple color stop gradient, where the 2nd gradient stop uses the double position syntax to spread over more of the line than the other colors.

I'll be calling the colors in a gradient a color stop 🤓

There's also a depiction of transition hints and an inline color adjuster concept. I hadn't quite figured out how the color picker would work yet.

This next concept shows the sketched linear gradient line concept being tested with angles and various syntax.

Putting the concept to the test essentially! Testing how transition hints and double stop positions might work in practice.

Coding was the only way to fully test the solution, but still fun to see how far I could get on paper.

Here's some conic and radial gradient line concepts.

Stops & Hints #

Here are some concepts and depictions of the colors (or stops as I'll start referring to them as) on a gradient line.

Some more concepts of a color picker overlay too.

Stops can have 2 positions on the line, a start and end. Most people don't know this! I chose to visualize it by splitting the cirle into halves, each half representing a stop position.

Any 2 stops also have a transition hint between them, which is a value that indicates how the stop should transition to the next stop.

Here's more sketches of colors and hints. I have no idea what that math calculation means anymore.

These are more sketches testing out various gradients and their estimated visualizations.

GUI Explorations #

The UI needs to show a layers list view (which I still plan to enable more layers!), a gradient canvas preview, a color stops list view and the CSS output for copying.

I think a ✓ meant I liked the overall thumbnail idea.

How it turned out #

Here's a quick video of a basic, responsive, 2 stop gradient line with a custom transition hint; shown on each linear, radial and conic overlay.

Sketches lined up pretty good!

Well, I'm not done with it yet! I do want to add layers and background-image sizing. I think it'd make it the perfect tool for finely crafted gradients. Stay tuned!

Devtools Fm 151 - Adam Argyle

2025-08-25T16:46:37.000Z

Ep #151
DevTools FM

Join Andrew, Justin and I for a chat about some of the developer tools I've worked on.

Listen · Watch · Subscribe

Fix the Signal - Robin Rendle

2025-08-23T17:20:41.000Z

It often feels like optimism is an act of revenge, an act of spite or rebellion, because optimism requires diligence and effort whilst pessimism feels like the default, the thing requiring no energy or effort. Mike Monteiro wrote along similar lines in How to stay hopeful:

The problem with dystopias is that dystopias are easy. You simply stop giving a shit about things or people that you should give a shit about, or things that don’t affect you directly, thinking they’re somebody else’s problem and boom—shit starts getting dystopian real quick.

On the flip side: optimism is utopian. The world can be better! The world is better! Sure, there’s a kind of optimism that makes you blind to the suffering of others, there’s cruelty in it sometimes. But there’s nothing but misery to be found in endless snark, in womp-wompism, in all-things-must-be-sad-all-the-time-ism. I fear recently I’ve slipped into that other way of seeing the world — I worry I’ve become a true bummer — perhaps because I’ve been listening and reading to too much of the wrong things, perhaps encouraging all the wrong signals.

So let’s talk about a few things that make me optimistic about the world right now. Let’s fix the signal!

1. Hummingbirds!

Each morning, just outside my office, two hummingbirds dance and play above the redwoods. They are tiny and oscillating, endlessly wagging their little bodies because I like to believe that they’re happy to see me at work behind the glass. Whilst their wings beat back and forth the stroboscopic effect kicks in, making them look like they’re hovering along the treetops without the help of their wings at all. At just the right angle it looks like these chaps have hacked the video game engine that powers our world and can now move in any direction with arms outstretched, as if they’ve both loaded incorrectly.

These hummingbirds never fail to put me in a good mood, but I’m not entirely sure why. I suppose it’s the stark contrast from the world where I grew up — dreary, grey, pub-filled streets — and now there’s only the eternal blue of Cupertino skies above and the super-saturated trees flanking my office windows and now, here they are, they’ve come back to say hello.

2. Martyr!

I know I’m late to the party but Kaveh Akbar’s Martyr! is great and I couldn’t put it down. The protagonist spends the whole novel fantasizing about a death worth living for, where he confronts and romanticizes his own suicide. Big portions of the book are taken up by his dreams:

...the body offered you dreams. In exchange for a third of your living, you were offered sprawling feasts, exotic adventures, beautiful lovers, wings. Or at least the promise of them, made only slightly less intoxicating by the curious threat of nightmare. How sometimes, at random, your mind would decide to reduce you to a whimper, or a gasp, in the night.

Kaveh snaps words together in a way that I find totally irresistible and un-put-downable. Whilst I was reading this book I had a terrible flu and each night I’d wake up in a cold sweat with the strangest dreams rolling around in my head. So it felt somewhat magic to finish the book and flu on the same day, with my dreams having then reset after the book’s spell had worn off.

3. Close to the Machine!

It’s odd rereading Ellen Ullman’s Close to the Machine fifteen years later. On my first reading I honed in on the talk about computers, about software, about team work. I was lost in the rush of Ullman’s tale about living on the bleeding edge and fighting for great work to be done. I turned every page frantically as I hoped Ullman would find a problem worthy of her programming talents.

Back then I wanted to be Ullman. I wanted to drive a convertible across a golden bridge, illuminated by magical software powers and money and the hard-earned wisdom that comes from struggling to smash computers and people together. I wanted to make something special.

But now, after moving out to the Bay Area and a decade of failed relationships with startups and teams and endless software designs that never went anywhere, I see the underlying sadness of this little book. I see my own loneliness in there in ways I didn’t think could be put into words. I see my own failures and hopes and dreams in Ullman. I point at the book, DiCaprio style, when Ullman sells her soul, when she’s willing to start relationships with bitcoin boys despite knowing better, when she falls into the work in ways that’s difficult to pull herself back out again.

Ullman is fallible in all the ways that I know I am, too. And that’s why I love this little book. It feels like something that shouldn’t be written down, something forbidden, something that upsets the natural order of software-as-a-job. And I still love it.

4. Herdling!

I love this little game. I haven’t finished it yet, but already the music and storytelling-style have permanently etched itself into my noggin’. The game is about finding and traveling with a band of furry companions across a sad, flute-filled landscape. Rather unfortunately you can name each of your creatures and I decided to name them all after long-lost pets. This made the sweetness of this game extra sweet but at one point when we were all coming down a mountain together, all of them wagging their tales and shuffling their ridiculous bodies, I could see Lucy and Bob and Purdy and Crease and Lady again, galloping in formation. For the briefest moment I could see my little guys again.

So: if anyone ever says that they caught me bawling my eyes out on my couch because of some big dumb videogame then I need you to know it’s all fake news, man. I never did any such thing. Now excuse me whilst I go find some big rocks to throw around and do ten thousand push ups. I have MAN things to do.

Post on Sara Soueidan – Blog - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

Imagine you visit a website and you want to browse it for some content. You want to buy something; or maybe book a flight somewhere. And as you move your cursor onto the page, it suddenly disappears. Your hand may be still on the mouse, and you’re moving the mouse across the screen and across the page; but you can’t see where it is. You may or may not be hovering over a link or a button or any other form control at any moment. But if you are hovering over one, you don’t know which one it is. You could try clicking and then finding out, but you can probably already imagine what a nightmare of an experience you’re about to get into.

Unfortunately, keyboard users experience the Web in a similarly frustrating manner too often. Their equivalent of a mouse cursor is usually hidden on too many websites, making it almost impossible for them to navigate those sites. A keyboard user’s cursor equivalent is the focus indicator. By designing and implementing accessible focus indicators, we can make our products accessible to keyboard users, as well as users of assistive technology that works through a keyboard or emulates keyboard functionality, such as voice control, switch controls, mouth sticks, and head wands, to mention a few.

What exactly is a focus indicator?

Keyboard users typically navigate their way through websites by pressing the tab key. This allows them to jump from one interactive element on the page to another.

Just like mouse users, they need to be able to see where they are on a page as they Tab their way through it, otherwise they won’t be able to identify the elements they are interacting with. That’s what focus indicators are for.

A focus indicator is a visual indicator that “highlights” the currently focused element. This visual indicator is commonly presented as an outline around the element. An outline takes the shape of its element, and since every element in CSS is a rectangle, an outline is, therefore, usually a rectangle drawn around an element.

Sorry, your browser doesn't support embedded videos.

Navigating the Mozilla Developer Network (MDN) website using a keyboard. As you tab through the homepage, you can see a rectangular outline highlighting the currently focused element.

So a focus indicator allows a keyboard user to see exactly where they are at any given moment. Without it, they wouldn’t know where they are on a page and they wouldn’t be able to navigate the page and operate its controls.

The focus indicator is to keyboard users what the mouse cursor is to mouse users. And just like you would never want to hide the mouse cursor, you never want to hide the focus indicator.

Laura Carvajal on stage at Fronteers conference 2018.

In fact, a visible focus indicator is a requirement for a site to be considered accessible under the Web Content Accessibility Guidelines (WCAG). Removing or hiding focus indicators is a violation and will therefore fail Success Criterion (SC) 2.4.7: Focus Visible (Level A), which states that:

any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

Browser default focus styles

Browsers provide focus indicators to native interactive elements out of the box, for free. And most of us—if not all—have at some point in time included this CSS snippet in their stylesheets:

:focus {
	outline: none;
}

to remove those focus indicators applied by the browser.

To meet the accessibility requirement, you should avoid removing the focus indicator provided by the browser unless you are replacing it with your own focus indicator. And I do recommend you do that.

By preserving browser focus styles, you may meet the requirement of showing a visible focus indicator, but that may not be enough, because a focus indicator needs to be clearly visible to be considered accessible. And browser focus indicators may not always be.

(What’s the benefit of showing an indicator that many users may not be able to see?)

In order for a focus indicator to be clearly visible it needs to have a color contrast against adjacent colors that is high enough for users with moderately low vision to be able to discern it.

The Web Content Accessibility Guidelines define the minimum color contrast ratio required for interactive components and their states to be accessible in SC 1.4.11 Non-Text Contrast.

Focus indicators on UI controls fall under the “non-text” components category, as they are used to identify a component’s state. To pass this criterion, our focus indicators must have a color contrast ratio of at least 3:1 against adjacent colors.

Default focus indicators provided by browsers may fail this criterion, depending on the colors you’re using on your page. You can end up with a usability problem if the colors of your page clash with the colors of the default focus indicators, making them difficult to see. When that happens, you’ll want to override those focus styles with better, more accessible ones.

Here is a screenshot of how Chrome, Firefox, Microsoft Edge, and Safari style their respective focus indicators (at the time of writing) when applied to a <button>:

Chrome, Edge and Safari apply a 1-pixel solid outline. Firefox applies a 1-pixel dotted outline. As far as color contrast with the white background goes, they all pass the accessibility check. But the dotted outline in Firefox is still very difficult to discern compared to the other outlines, even though its color has enough contrast with the white background. This is because the contrasting area of the outline is not large enough. And that’s because the outline is very thin and dotted. We’ll come back to this shortly.

On a black background, Firefox’s black focus indicator disappears, and Safari’s indicator has a contrast so low it will be extremely difficult to discern by most users.

Chrome and MS Edge, however, have something interesting happening in that they apply what looks like a second outline—a white outline around the first outline, that creates enough contrast on most darker backgrounds.

Chrome and Edge v94 and up provide more visible focus indicators that you can enable in their respective settings panes that you can access like this:

In Chrome, type this into the URL bar: chrome://settings/accessibility
In Edge (v94 and up), type this into the URL bar: edge://settings/accessibility

Then you can enable the more visible focus indicators by enabling the corresponding option in each panel:

In Chrome, enable the “Show a quick highlight on the focused object” option.

In edge, enable the “Show a high visibility outline around the area of focus on the page” option.

When these options are on, you’ll notice an additional border as well as a box shadow around the focused elements.

Firefox does not provide a similar option at the time being. But you can make the default dotted outline more visible by tweaking the style and width options in Firefox’s configuration pane.

You can do that by navigating to about:config. Use the search bar within the config page to search for focus_ring. The search results will show two variables that you can tweak: browser.display.focus_ring_style and browser.display.focus_ring_width.

If you set the style value to 0 and the width value to 4, you’ll get a thicker outline that more resembles the outline provided in Chrome and Safari by default.

So while you may get away with using the default browser focus styles to meet WCAG 2.1 requirements and call it a day, it is generally a good idea that you override the default styles with more accessible ones. In fact, in WCAG 2.2, it becomes necessary to do that, because the requirements get more specific, and as you’ll see in the following sections, browser focus indicators will often fail the new requirements.

In what follows, we’re going to get a little nerdy!

New focus indicator accessibility requirements in WCAG 2.2

In WCAG 2.2, three new success criteria were added to define how accessible a focus indicator is depending on its color, area, and visibility:

SC 2.4.11 Focus Appearance (Level AA),
SC 2.4.12 Focus Not Obscured (Minimum) (Level AA), and
SC 2.4.13 Focus Not Obscured (Enhanced) (level AAA)

These new criteria aim to ensure that a keyboard focus indicator is clearly visible and discernible, and they provide the conditions to ensure that. These criteria specify a minimum area required for the focus indicator to be considered accessible, taking into account its color contrast ratio relative to its initial color, as well as against adjacent colors within the focused component.

We’re going to dive into these requirements and how to meet them in the following sections.

We’ll start with SC 2.4.11 Focus Appearance which states that:

When the keyboard focus indicator is visible, one or both of the following are true:

The entire focus indicator meets all the following:

encloses the user interface component or sub-component that is focused, and

has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states, and

has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors.

An area of the focus indicator meets all the following:

is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component or sub-component, or is at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component, and

has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states, and

has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors, or is no thinner than 2 CSS pixels.

Exceptions:

The focus indicator is determined by the user agent and cannot be adjusted by the author, or

The focus indicator and the indicator’s background color are not modified by the author.

For most of the examples, we’ll be demonstrating and examining the focus indicator requirements when applied to a blue button set on a white background.

To start, we’re going to define two terms that will help us understand these requirements: the focus indication area, and the contrasting area. (These terms were introduced in previous versions of the Success Criteria and have been edited out in the final wording. But I think they are helpful in understanding the requirements.)

1. The focus indication area and the contrasting area

When a component changes on focus to include a focus indicator, that change can always be measured as a change of color contrast.

If you add a black outline around the blue button, the change of color between the unfocused and focused states is from white to black. That’s because the area— the pixels on the screen —that has changed color in the focused state is the area around the button. That area was initially white, and it changed to black when the button received focus. This area is called the focus indication area.

The focus indication area is the area in square CSS pixels where the change in color between the focused and unfocused states of the component happens.

For a focus indicator to be accessible, it is required to have an area of the focus indication area (a subset of the focus indication area) that has a minimum contrast ratio of 3:1 between the colors in the focused and unfocused states. That area is called the contrasting area.

In other words, the contrasting area is the area of the focus indication area that has at least a 3:1 contrast ratio with the colors of the unfocused state. And the contrasting area may or may not be equal to the entire focus indication area.

In the previous example, the color change happens from a solid white to a solid black, and the color contrast ratio between the unfocused and focused state (white and black) is 21:1. So the entire focus indication area meets the minimum contrast requirement. This means that the contrasting area is equal to the entire focus indication area.

Similarly, if you add a black outline that is separated from the button, once again, the area that exhibits the change in color is the contrasting area.

(I like this pattern because it adds some breathing room and helps the focus indicator stand out, making it easier to see.)

If you add an outline inside the button itself, the contrasting area then lies inside the button. The change of color is from blue (the button’s background color) to black. The color contrast ratio between the focused and unfocused state is 4.86:1.

If the button changes its background color from blue to black on focus, then the entire button’s background area is the contrasting area, and the color contrast ratio between the focused and unfocused state is once again 4.86:1.

When the focus indicator is a solid color, measuring the color contrast ratio in the contrasting area is straightforward. But color changes may not always be solid. You may want to indicate focus on the button by applying a gradient drop shadow to it. In this case, only the portion of the gradient with sufficient contrast (larger than 3:1) will be our contrasting area; the remaining portion that fails will not be a part of it. This is an example of when the contrasting area is smaller than the focus indication area.

You may need to take some spot-checks on the gradient area and establish what area meets the contrast requirement.

The greater the change of contrast between the unfocused and focused states, the easier it is for users to see it.

In addition to requiring a minimum contrast in the contrasting area, a focus indicator is required to have a minimum surface area for the contrasting area as well. In other words, the contrasting area needs to be large enough to be considered accessible. But how much is large enough?

2. Minimum contrasting area

Remember how we said that Firefox’s dotted outline was difficult to discern even though its contrasting area had a high contrast ratio with the background? I mentioned that that’s because its area was small, due to the outline being thin and dotted. The main issue here lies in the fact that it is dotted. The gaps in the line decrease the overall area of the focus indicator, making it difficult to see.

The bigger the visible change when the component receives focus, the easier it is to see. And to ensure that focus indicators have good visibility, 2.4.11 requires a minimum surface area for the contrasting area. That is, the contrasting area needs to be larger than a specified minimum.

The SC states that:

The entire focus indicator encloses the user interface component or sub-component that is focused [ or ] An area of the focus indicator is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component or sub-component, or is at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box of the unfocused component or sub-component

To “enclose” a component means to “solidly bound or surround”. Bounding is derived from the “bounding box” of an element. The bounding box of a component is the smallest possible rectangle that entirely encloses it and its descendants. Surrounding is kind of like “wrapping” a shape. The difference between bounding and surrounding is illustrated in the two images of a set of ratings stars.

In the first image, the focus indicator solidly bounds the star. In the second image, the focus indicator (also a solid outline) surrounds the star. (Image Source)

The first point in the criterion is technically a special case of the second condition.

A focus indicator that encloses a component is a focus indicator that solidly bounds or surrounds the component. A solid outline is an example of a focus indicator that solidly bounds an element. And solid 1px outline has an area of at least 1px thick perimeter of the component. (Of course, any outline thicker than 1px will also meet the area requirement.)

If the focus indicator is dotted or dashed (not solid), it no longer ‘solidly bounds or surrounds’ the component and will therefore need to meet the condition defined in the second point.

The second point determines the minimum contrasting area using the perimeter of the component.

The perimeter of a rectangle is equal to a line that’s 2 times the width plus 2 times the height minus the shared corner pixels which are equal to 4 pixels: Perimeter § = 2h + 2w - 4.

The perimeter of a circle is 2𝜋r, where r is the radius of that circle.

Firefox’s focus indicator is equal to the length of the perimeter of the button minus all the gap spaces introduced by using the dotted style. The resulting length is approximately half of the perimeter. To fix it, the outline thickness can be doubled to make up for the area that is lost in the gaps. Here’s what the dotted outline looks like with 2px and 3px thicknesses. The thicker the outline, the larger its surface area, and the easier it is to see.

Now let’s assume, for demonstration purposes, that we’re designing focus styles for a 150px by 75px button. The perimeter of this button is: 150px + 150px + 75px + 75px - 4px = 446px.

When we apply an inner outline to the button, this outline is going to be smaller than the perimeter of the button (because the outline’s width and height are shorter than the button’s width and height). Once again, increasing the thickness of the outline will make up for the area lost by placing the outline inside the button.

A 130px by 55px outline inside the button will have a surface area of 366px, which is smaller than our perimeter's 446px area. By doubling the thickness of the outline, its surface area becomes 732px, which is larger than the perimeter and therefore meets the minimum area requirement.

Similarly, for a contrasting area in a gradient focus indicator, you’ll want to calculate the component’s perimeter and compare the contrasting area to that of the perimeter.

In the following image is a circle with a 22px radius and 138px perimeter.

On the top right, the focus indicator (1) is a 1px solid circular outline. The perimeter of the focus indicator is 172px, which is larger than 138px. With a color contrast change that is higher than the minimum requirement, this indicator passes the accessibility requirement.

On the bottom left, focus indicator (2) is an inner 1px solid outline with enough color contrast change, but an area (113px) smaller than the circle’s perimeter. This indicator does not pass the requirements.

And finally on the bottom right, the focus indicator (3) is an inner 2px thick outline. This outline has a double the area of focus indicator (2) (226px), making it larger than the perimeter of the circle, so it passes the minimum area requirement.

In addition to the minimum area requirement that is based on the component’s perimeter, the success criterion also provides a secondary minimum based on the shortest side of the component:

or is at least as large as the area of a 4px thick line along the shortest side of the component’s minimum bounding box

Instead of aiming for a minimum area of 1px thick perimeter, you could aim for a 4px thick line along the shortest side of the component’s bounding box.

The secondary minimum area can be useful for when you have a list of focusable items stacked on top of each other, such as links in a vertical navigation or a drop-down menu. The focus indicator on a link in the drop-down could be a 4px thick border along the shortest side (typically the height) of the link as shown in the image below.

The thicker the line, the larger the contrasting area, the more visible the focus indicator is. Obviously, the 4px thick line along the shortest side of the element is a minimum. A border along the longest side would also meet the requirement (assuming the thickness ensures a large enough area). My point is that, while I am giving simple and specific examples, my goal is to demonstrate the requirements. But you have the creative freedom to choose any focus indicator style you prefer that meets the accessibility requirements.

The main goal of the minimum area requirement is to ensure that the focus indicator is easier to see. Whetever the style you choose to indicate focus, the important thing is to ensure that the contrasting area meets the minimum area requirement(s), so that it can be easily seen.

3. Contrast with adjacent colors in the component

In addition to requiring a minimum contrast ratio 3:1 and a minimum surface area, the contrasting area also needs to be easily distinguishable from adjacent colors within the focused component.

This is accomplished either by

ensuring at least 3:1 contrast ratio between the contrasting area and adjacent colors, or
ensuring the contrasting area has a thickness no less than 2px.

We’ll start with the blue button again as an example, and apply a simple 1px (external) outline to indicate focus. But this time, I’m changing the color of the outline from black to a darker shade of the blue background.

The button’s background color is: `#314cff`. And the outline color is: `#1100cd`.

The contrasting area’s contrast ratio (dark blue versus the white background) is: 11.02:1. And its area is larger than the button’s perimeter. So the outline color and area pass the minimum contrasting area requirements that we discussed earlier.

But the dark blue color of the outline has a low contrast ratio against the adjacent blue used in the background of the button: 1.89:1. So while this outline meets the first two accessibility requirements, it fails the third one.

To fix it, we can either

choose a different outline color that has at least 3:1 contrast ratio against the button’s background color (like black #000, for example), or
increase the thickness of the outline. Any thickness greater than or equal to 2px will do.

We can also fix the low adjacent contrast by separating the outline from the button, so the outline’s adjacent color becomes white (the page background), and would therefore meet the color contrast requirement.

4. The focused element cannot be fully obscured

The goal of a focus indicator is to allow the user to see and know where they are on a page, by making the currently active element more visible to their eye.

But what good is a focus indicator if the focused element itself is not visible because it’s hidden off-screen or obscured by other elements on the page?

SC 2.4.12 Focus Not Obscured (Minimum) states that:

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

Simply put: you want to make sure the user can actually see the component that they’re focusing on, by making sure it’s not hidden behind other content on the page.

That being said, this criterion requires that the component be not entirely hidden. This does imply that it could be partially hidden, as long as it’s still partially visible.

SC 2.4.13 Focus Not Obscured (Enhanced) (which is the level AAA version of this requirement) states that:

When a user interface component receives keyboard focus, no part of the focus indicator is hidden by author-created content.

When aiming for Level AA conformance, you may get away with partially hiding the focused component, though I can’t imagine where or how that would not be problematic. I recommend that you always make sure focused component is entirely visible and not obscured by other content. It’s just better for usability. SC 2.4.13 is one of the AAA-level criteria that are also fairly easy to meet, even if you’re not aiming to be AAA-compliant.

You may wonder if this requirement makes Skip links inaccessible. It doesn’t. Because Skip links are designed so that they are visible when they receive focus; so the user is able to see what they are focusing on when they focus on the skip link.

A very common pattern that is more likely to fail this criterion on many websites is off-canvas navigation and other drop-down and fly-out components. Links in drop-down or off-canvas navigations are only meant to be interactive when they are visible. If you want to click on a link, you open the navigation, the links become visible, and you can click on the link you need and go where you need to go.

Keyboard users sometimes experience these navigation patterns differently when they are implemented inaccessibly. They’ll navigate through a page and suddenly notice their focus indicator disappear. They may continue tabbing, until at some point the indicator finally re-appears and continues to the next visible link.

This happens because the links that are hidden off-screen or inside dropdowns are only visually hidden, but are still accessible via keyboard. This results in a mismatch between the visual and keyboard experiences of a keyboard user: they’re tabbing through links and components that they are not seeing on screen.

To avoid this happening, make sure that components that are not meant to be visibly interactive are properly hidden, by making them inert, for example.

Recap

So theses are the accessibility requirements for focus indicators to pass WCAG.

There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states. (This is the focus indicator’s contrasting area.)
The contrasting area needs to be at least as large as:
- the area of a 1px thick perimeter of the component, or
- the area of a 4px thick line along the shortest side of the component’s minimum bounding box
The contrasting area has a contrast ratio of at least 3:1 against adjacent colors in the focused component, or the contrasting area has a thickness of at least 2px
The focused element is not obscured by other elements on the page.

With these requirements in mind, we now know that Firefox’s button focus indicator that we saw earlier fails the minimum contrasting area requirement. Chrome and Edge’s current focus indicators would fail the adjacent contrast requirement if your button has a background color that clashes with the outline’s color. And Safari’s focus indicator will also fail the minimum contrast ratio requirements also depending on the colors you use inside and outside the button.

These browsers may also apply different focus indicators to different interactive elements, which may also fail at least one of the accessibility requirements, depending on your color palette.

So I highly recommend overriding the default focus indicators with custom, more accessible ones. This also gives you the creative freedom to design focus indicators that look nicer on your components than the ones provided by the browser.

Knowing what makes a focus indicator accessible, we can examine our own as well as the focus indicators of popular design systems and UI pattern libraries, and determine which ones pass WCAG criteria and which ones don’t…

Examining the accessibility of focus indicators in popular design systems and UI pattern libraries

Material design button focus indicator is a change in background color, in addition to an elevation effect created by extending the box shadow underneath the button. This focus indicator fails the accessibility requirements because of a very low change in contrast (1.53:1) between the focused and unfocused states.

Material Design’s button focus indicators fail WCAG requirements for accessibility.

Bootstrap 4 buttons also fail WCAG requirements because of low change in contrast between the focused and unfocused states. For example, the change in contrast on the blue button is 1.92:1.

Bootstrap 4’s button focus indicators also fail WCAG requirements for accessibility.

Material UI Checkboxes get a large focus indicator area, but the color contrast change is also low (1.58:1).

Material UI’s checkbox focus indicator fails WCAG requirements for accessibility.

GOV.UK is one of the most accessibility-compliant websites I know. So I was curious to see how their focus indicators measure against WCAG 2.2 requirements.

When focused, the links get a thick underline as well as a change in background color from white to yellow. While the yellow does not pass the minimum color contrast requirement, the indicator still passes accessibility requirements with the thick border compensating for that. (Note: A focus indicator that is larger than the minimum area may have parts that do not meet the 3:1 contrast ratio, as long as an area equal to the minimum does meet the contrast ratio.)

GOV.UK’s link focus indicator passes WCAG requirements for accessibility.

The text field on the GOV.UK homepage gets a 3px solid yellow outline as a focus indicator. This yellow outline has a contrast change (3.86:1) that’s higher than the requirement minimum (for a pixel color change from blue to yellow). The yellow color does not contrast with the input’s white background enough (adjacent contrast), but it is 3px thick, which compensates for that. So this focus indicator passes WCAG requirements.

GOV.UK’s text input focus indicator (on the homepage) passes WCAG requirements for accessibility.

Showing the focus indicators only for keyboard users

The main argument I usually hear against focus styles is that they appear even when you don’t want them to, such as when you click on the component with a mouse ot tap on it. Designers and stakeholders are usually not very fond of that. I remember a client once reporting “a bug” and telling me that mouse clicks are “kinda broken” because a thick outline appears when they clicked on links and buttons on the page. When that happens, I usually start a discussion about what focus styles are, why they are important, and why we should keep them. And then I’d always try to make a case for preserving them and “compromising aesthetics” for the sake of usability and accessibility. I didn’t always win those discussions.

Today, I have those arguments far less. While I still find myself asking for focus styles in design specs, I don’t need to argue my way into including them in the final product.

CSS enables us to show focus styles for keyboard users and hide them for all other users. So when you click an interactive element, the focus styles won’t show up and “ruin the aesthestics” anymore. Anyone navigating the page with a keyboard will appreciate the visual aid, and those who aren’t using a keyboard won’t even know they’re there!

Browsers used to show their focus indicators on click (or tap), too. That’s why we used to include the “focus reset” rule in our style sheets:

/* don't do this */
*:focus {
	outline: none;
}

Today, all modern browsers only show focus indicators when they are needed: for keyboard users. The focus outline doesn’t show up when you click or tap an element; it only shows up when you tab to it with a keyboard.

When you create your own custom focus indicators, you probably want to do the same and only show them for users who need them.

You can do that using the :focus-visible pseudo-class.

:focus-visible does exactly the same thing :focus does, except that it only applies the focus indicator styles to an element when that element receives keyboard focus.

/* applies a black outline to links only when focused via keyboard */
a:focus-visible {
 outline: 2px solid black;
}

Browser support for :focus-visible is pretty good — pretty much all modern browsers support it today. So you may want to use the focus-visible polyfill if you need to hide the focus indicator on older browsers. The polyfill works by adding a focus-visible class to the focused element, in situations in which the :focus-visible pseudo-selector should match.

In your CSS, you can then use the class name added by the polyfill to target the focused element and apply the same focus styles you apply using the :focus-visible pseudo-class:

.js-focus-visible :focus:not(.focus-visible) {
  outline: none;
}

You can also skip the polyfill altogether and use :focus-visible as an enhancement on top of :focus.

In his article about :focus-visible and backwards compatibility, Patrick Lauke suggests a clever way to use :focus-visible today as part of a progressive enhancement strategy.

The solution Patrick suggests is to use the :not() negation pseudo-class, and to (paradoxically) define styles not for :focus-visible, but to undo :focus styles when it is absent, and then using :focus-visible if we wanted to provide additional stronger styles for browsers that support it.

button:focus { 
	/* some exciting button focus styles */ 
}

button:focus:not(:focus-visible) {
 /* undo all the above focused button styles

 if the button has focus but the browser wouldn't normally

 show default focus styles */
}

button:focus-visible { 
 /* some even *more* exciting button focus styles */ 
}

button:focus:not(:focus-visible) is CSS for “when the button receives focus that is not focus-visible”. That is, “when the button receives focus that is not keyboard focus”. In other words, “when the button receives focus that is mouse focus, for example”. When that happens, undo all the :focus styles. Then apply keyboard-only focus styles using button:focus-visible.

As Patrick notes, this works even in browsers that don’t support :focus-visible because although :not() supports pseudo-classes as part of its selector list, browsers will ignore the whole thing when using a pseudo-class they don’t understand/support, meaning the entire button:focus:not(:focus-visible) { ... } block is never applied.

I have a VSCode snippet set up that I use to quickly create these rulesets in my stylesheets, with sensible defaults that I find myself repeating across projects most of the time.

I’ll end this section with this paragraph from Patrick’s article (emphasis mine):

If you care about backwards compatibility (and you should, until you can absolutely guarantee without any doubt that all your users will have a browser that supports :focus-visible), you will always have to either polyfill or use the combination of :focus and :not(:focus-visible) (plus optional even stronger :focus-visible).

Tips for styling focus indicators

Focus indicators have a purpose, so do what you can do to ensure that they serve that purpose well. They are meant to improve our users’ experience. The user couldn’t care less about the aesthetics of focus styles as long as they help them do what they are visiting your site to do.

I like to create focus indicators that stand out. The more visible they are, the less the user needs to look for them, the better.

You can get creative and create patterned focus indicators which have that extra benefit of not relying on color alone to convey state. Just remember to make sure they meet the minimum contrast and area requirements.

We can also learn something from the way Edge and Chrome handle focus styles. Maybe create “double outlines” that play well in various color environments, or when you support both light and dark UI user preferences. In the future, the new the CSS color-contrast() function can come in handy to create a sensible default focus style for most components. In fact, color-contrast() will come in handy for a lot of accessible color design in the future.

Avoid relying on background colors and box shadows alone to indicate focus. Forced Color Modes and other accessibility display modes will override and/or remove them. Outlines, on the other hand, will not be removed and would always be visible; and the browser will apply the display mode’s custom colors to style them.

You can use backgrounds, borders and box shadows to style focus states. But if you do, add a transparent outline as a “fallback” for the various display modes:

button:focus-visible {
	/* Default. Will be removed in Forced Color Modes */
	box-shadow: 5px 5px 7px rgba(0, 0, 0, 0.1); 
	/* Fallback. Will be visible with custom system colors in Forced Color Modes */
	outline: 1px solid transparent; 
}

Focus indicators can also be animated. Background colors, borders, box shadows, and outlines can all be animated using CSS transitions and animations. The outline-width and outline-offset properties take numerical values that can be animated. So you can apply a subtle transition to your focus indicators to make them pop. Just make sure to wrap any transitions or animations in a prefers-reduced-motion user query, so users have the option to opt out of the animations if they want to.

When you’re designing and working with a color palette, you can find a color that has enough contrast with the other colors in your palette and use it to style your focus indicators. If there is no one color that meets that criterion, you can add one, or design focus styles that work for different elements and the contexts in which they appear.

You can use a color contrast tool like Stark to quickly check the contrast of two colors without interrupting your workflow — whether you’re designing in a design tool like Figma or in the browser. You can also use the browser devtools to check color contrast where they are available, or an online tool like WebAIM’s color contrast checker, which I used to calculate the color contrasts throughout this article.

Not all elements need to have the same focus style. I personally try to keep focus indicators visually consistent as much as possible. But there are times when some elements could benefit from a different focus style, whether for aesthetic or usability purposes—or maybe even both! Get creative, but do so within the boundaries of accessibility. Creating nice focus indicators is a nice touch that not only shows your attention to detail, but it also shows that you care about all of your user’s experiences enough to spend a bit of time fine-tuning these details.

Outro

Designing accessible focus indicators is easier now that there are specific criteria to measure accessibility against.

If you’re a designer, make a habit to design and include focus indicator styles in your design specs if you don’t already do so.

If you’re a developer, include focus styles in your CSS defaults. If you’re working with designers, strike up a discussion about focus styles with them if they don’t already prioritize them in design specs.

Sometimes, you don’t need permission, extra time, or extra budget to improve the accessibility and usability of your product. Focus indicators are one small yet critical addition to your product that has tremendous usability benefits. Spending a few extra minutes designing and adding them will pay dividends and improve your product for millions of people who will use it.

Resources, references and further reading

CSS Carousels – Revisited - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

Update: Blink: Intent to Ship: CSS counter() and counters() in alt text of ‘content’ property — potentially useful for providing alt text for CSS-generated scroll markers.

Post on Sara Soueidan – Blog - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

Abbreviations can be problematic - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

If the acronym is used once, simply using the words is usually the right approach. […] When an acronym is used multiple times, though, it’s likely it’s being used for practical reasons rather than tone of voice. Reading can be clunky if the words are written in full each time, so all we have to do is define it the first time it’s used on each page; from there on in it can be used freely.

After I tweeted this article on Twitter, Tomas shared a letter by Elon Musk to SpaceX engineers about the same topic.

Excessive use of made up acronyms is a significant impediment to communication and keeping communication good as we grow is incredibly important. Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don’t want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees.

Just use the words.

Accessible design systems - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

A design system is a library of styles, components, and patterns used by product teams to consistently and efficiently launch new pages and features. A good system has accessibility embedded throughout and includes documentation, guidelines and implementation notes for accessibility.

Accessibility in design systems goes beyond code:

Design systems vary, but an accessible design system can include style guides, components, patterns, and accessibility documentation.

Best practices for using third party embeds - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

Beyond WCAG: Losing Spoons Online - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

I’d like to share some of the things online that drain my spoons to help you go beyond WCAG today. For the sake of this scenario, I’ll include how many spoons I can expect to lose when I encounter these blockers. Let’s say that I start my day with twenty spoons.

I haven’t been able to get this article out of my head since I read it. Learning about people’s experiences fundamentally changes how you think about creating for the Web. In the end, you either care; or you don’t.

Body margin 8px - The origin story for a style no one wants - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

All browsers add an 8px margin on the body element – it’s part of the w3c-recommended default stylesheet which browsers generally use as a starting point for their own ‘user agent’ styles. But why 8px? Where does that come from?

I really enjoyed reading Mia’s article. The article starts by explaining the difference between initial values in CSS and browser default styles. I had an ah-ha moment that’s going to finally help me remember the difference between the initial and revert values for good!

Avoiding layout shift by putting the CSS in charge - HTTP 203 - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

I had never considered how CSS Grid and Flexbox compare from a performance standpoint. This is insightful.

The ‘Form’ Element Created the Modern Web. Was It a Big Mistake? - Sara Soueidan – Blog

2025-08-18T08:41:01.000Z

the <form> element was a pivot point for the entire technology industry. It is what changed the web from a read-only medium for physics papers into a read-write medium for anything. But lately I’m not so sure I think that was a good idea. […] What forms enable are transactions. Transactions of all kinds—commercial or social—can be consolidated into platforms, and platforms are where you find your margins. And margins are what yield your fortune, and that’s how you get power.

CSS and design systems people - BlogFlock

Joining Shopify - Adam Argyle

Twitter Integrated Again - Adam Argyle

Ditch those words! - Robin Rendle

WWW Ep209 - Adam Argyle

One List To Rule Them All - Adam Argyle

Selectors #

Pseudo Elements #

Language #

@rules #

Color #

Functions #

Properties #

Values #

Queries: #

Units #

Relative #

Root Relative #

Absolute #

Viewport #

Container #

Poverty, By America - Robin Rendle

Gradient Style Is Out Of Beta - Adam Argyle

The Making of gradient.style - Adam Argyle

Gradients and Their Lines #

Stops & Hints #

GUI Explorations #

How it turned out #

Devtools Fm 151 - Adam Argyle

Fix the Signal - Robin Rendle

1. Hummingbirds! #

2. Martyr! #

3. Close to the Machine! #

4. Herdling! #

Post on Sara Soueidan – Blog - Sara Soueidan – Blog

What exactly is a focus indicator?

Browser default focus styles

New focus indicator accessibility requirements in WCAG 2.2

1. The focus indication area and the contrasting area

2. Minimum contrasting area

3. Contrast with adjacent colors in the component

4. The focused element cannot be fully obscured

Recap

Examining the accessibility of focus indicators in popular design systems and UI pattern libraries

Showing the focus indicators only for keyboard users

Tips for styling focus indicators

Outro

Resources, references and further reading

CSS Carousels – Revisited - Sara Soueidan – Blog

Post on Sara Soueidan – Blog - Sara Soueidan – Blog

Abbreviations can be problematic - Sara Soueidan – Blog

Accessible design systems - Sara Soueidan – Blog

Best practices for using third party embeds - Sara Soueidan – Blog

Beyond WCAG: Losing Spoons Online - Sara Soueidan – Blog

Body margin 8px - The origin story for a style no one wants - Sara Soueidan – Blog

Avoiding layout shift by putting the CSS in charge - HTTP 203 - Sara Soueidan – Blog

The ‘Form’ Element Created the Modern Web. Was It a Big Mistake? - Sara Soueidan – Blog

1. Hummingbirds!

2. Martyr!

3. Close to the Machine!

4. Herdling!