Aaron Gustafson's Blog

It���s here! Nearly 900 pages of guidance on how to build web pages, to which I contributed a little over 100 pages: Learning Web Design, 6th Edition.

Congrats to Jennifer on the book and many thanks for bringing me along for the ride!

While working on a recent project I noticed an issue with a canvas-based audio visualization when I toggled between light and dark modes. When I���d originally set it up I was browsing in dark mode and the light visualization stroke showed up perfectly on the dark background, but it was invisible when viewed using the light theme (which I���d neglected to test). I searched around, but didn���t find any articles on easy ways to make canvas respond nicely to user preserences, so I thought I���d share (in brief) how I solved it.

# The CSS Setup

The themeing of this particular project uses CSS custom properties. For simplicty I���m going to set up two named colors and then use two theme-specific custom properties to apply them in the default light theme and the dark theme:

:root{���color-dark: #222;���color-light:rgba(255, 255, 255, 0.5);���color-background:var(���color-light);���color-foreground:var(���color-dark);}@media(prefers-color-scheme: dark){:root{���color-background:var(���color-dark);���color-foreground:var(���color-light);}}# Applying the Theme to Canvas

To get the theme into my canvas-related code, I set up a theme object to hold the values:

const theme ={};

Next, I wrote a function to pull in the theme colors using window.getComputedStyle(). After defining the function, I call it immediately to populate the theme object:

functionimportTheme(){theme.foreground =window.getComputedStyle(document.documentElement).getPropertyValue(������color-foreground���).trim()||���black���;theme.background =window.getComputedStyle(document.documentElement).getPropertyValue(������color-background���).trim()||���white���;}importTheme();

I set this up with just two theme colors, but you can import as many (or few) as you like. Be sure to set a sensible default or fallback for each color though, just in case your theme���s custom property names change.

With this in place, I can set my canvas animation���s colors by referencing them from the theme object. For example:

context.fillStyle = theme.foreground;# Keeping Things in Sync

The final bit of magic comes when you add an event listener to a MediaQueryList:

const mediaQuery = window.matchMedia(���(prefers-color-scheme: dark)���);mediaQuery.addEventListener(���change���, importTheme);

Here I���ve used matchMedia() to get a MediaQueryList object. Typically we use the matches property of this object to establish whether the media query currently matches or not. A lesser-known option, however, is that you can attach an event listener to it that will be triggered whenever the query���s status changes. So cool! With this in place, the canvas contents will update whenever the user���s theme changes. Here���s an example of that:

https://www.youtube.com/watch?v=pALIuO5uHUA

This video demonstrates how a canvas element rendering a dark sine wave against a light background can miraculously transform into a light sine wave against a dark background using CSS custom properties and a bit of JavaScript.

# Demo

I put together a quick demo of this in a fork of Alvin Shaw���s Canvas Sine Wave Experiment:

See the Pen

Hopefully this is helpful to someone out there. Happy themeing!

Earlier this month I joined Jeremy Osborne and Andrew Miller to talk about the benefits and harms of AI as it relates to accessibility. It was livestreamed on a few platforms, but I wanted to drop links to the transcript and archival video in case you���re interested.

https://www.youtube.com/live/7ObB4jM-QXU

View the transcript

Michael F. Buckley posted a somewhat imflamatory piece to the UX Collective blog over on Medium and I had some strong reactions to it I wanted to share. You should read it first before continuing.

First off, I agree with his core message: designers should understand the medium they are working in, be it web or an OS-specific UI. That���s where my agreements end, however.

They pat themselves on the back, believing they���ve mastered digital design. Meanwhile, a developer glances at the file, sighs, and codes the button in five minutes.

Condescention toward designers aside, this also assumes a high degree of competency and understanding of nuance on the engineering side which ��� in my experience ��� is not guaranteed. I cannot tell you how often I���ve designed an interface that calls for a button to submit a form and I get back a div with a click handler that can���t accept focus and has no design considerations for hover, focus, etc. In other words, if I provided a design with a single button on it, I get that button exactly. Sometimes exactly to those explicit dimensions, text overflow be damned.

There needs to be an acknowledgement and appreciation that designers know their craft and (generally) have good reasons for being overly prescriptive. Do some designers stray into realms of self-indulgence��� absolutely! But so do engineers.

I think where we need to get to is a place where handoff provides enough information to inform the engineer of the totality of what���s needed. Sure, to a seasoned engineer that may seem overly detailed, but to a junior engineer it can be incredibly helpful in learning all of the considerations of something as seemingly simple as a button. And even a seasoned engineer might learn a thing (or three) from annotations regarding accessibility and such. Communication is the key to success here.

Also, some prototyping in a tool like Figma can help with catching issues ��� like keyboard traps, for instance ��� before they are codified into code. Making changes in Figma or other design tools is generally a lot cheaper that doing it in code. Back of the napkin math ��� which is generally agreed upon across the industry ��� is that catching & fixing an accessibility issue in design costs about $100. In development, it���s like $1,000. If it sneaks into production, it���s gonna be more like $10,000.

To be clear, I���m not disagreeing with the piece in its entirety ��� designers should learn their medium (which is coding to a degree but also UX expectations) and Figma���s not the medium ��� but I think there���s more nuance to it. I also dislike the us vs. them framing; we���re all in this together.

I���ve been broadly working in the DEI (or DEIA if you like) sphere for decades now. Most of my work has been coming at it from the accessibility side of things, but I got really involved in allyship and more traditional DEI work starting in 2019. Seeing the current U.S. administration taking an axe to DEI programs in the government and bully private businesses to do the same has me incredibly frustrated, confused, and (yes) angry. I want more equality and more opportunity in the world, not less.

And so, when I was listening to the latest episode of The Weekly Show with Jon Stewart, I was struck by how the left and right may actually be more aligned on DEI than the headlines lead us to believe.

In the episode, Stewart was interviewing former New Jersey Governor Chris Christie, a Republican. When the topic of DEI came up, they got into a discussion of merit vs. diversity in the context of the Secretary of Defense role. Both agreed that, in terms of merit, General Lloyd Austin was a much better hire than Fox���s former weekend host Pete Hegseth. The fact that Austin is also Black has no more impact on his being a better candidate than the fact that Pete Hegseth being White makes him a worse candidate. What Austin does bring to the table, however, is first-hand knowledge of what it���s like to rise up the ranks as a Black soldier. That���s a significant knowledge gap when it comes to the U.S. military, whose top brass isn���t representative of the diversity of its personnel.

This is something that Christie actually points out when discussing becoming the U.S. Attorney in New Jersey back in 2002:

When I got there, I just did a lot of walking around the office to see, okay, who���s here? Jon, it was the whitest, malest office I had ever been in in my life. And I was coming from private law practice.

He, rightly, saw this as a problem and wanted to address it. He told his staff

[We need] to go out and recruit candidates who are African-American, Latino, Asian, women. Bring them to me. If they���re not good, I���m not going to hire them. But I���m convinced we���re not seeing them.

His approach to address this was perfectly rational and aligned with the approach Jon had discussed mere moments before:

What I found was hiring has a certain inertia to it, right? Generally, the people that started whatever industry or whatever office did, generally hire close to people that resemble them. So I���m not even talking about White/Black. I���m talking about like��� I���ll just go with late-night comedy, right?

David Letterman revolutionized late-night comedy. He did it with a lot of Harvard, Lampoon, SNL, same way, writers. The comedy writing industry was for a long time ��� not necessarily out of malevolence or prejudice ��� the inertia of it, the status quo of it, was nerdy white dudes from Harvard and the other Ivy Leagues.

But even when we went to like, ���Oh, we���re going to do blind submissions,��� what we didn���t realize is all the agents are also steeped in that same status quo. So all the resumes ��� even when we would get them ��� still predominantly [trails off]. When we went specifically to say ��� now, this is what you would consider DEI ��� ���Give us not that. Open it up to make sure you give us women, people of color, other writers, so that we can at least see what that is.��� And all of a sudden, we found these incredible writers. Now, you could say, ���Oh, you put diversity over competence,��� but that���s the red herring. We didn���t. We opened up what were stagnant pools. Pools that were incestuous. And we opened up those tributaries. Isn���t that what increases competition, not decreases it?

What���s fascinating here is that they are both making the same point. As Christie says later

We then went about this process of hiring a large number of African-American, Latino, and Asian prosecutors, but I would tell you that every one of them checked both boxes. They checked the box of, ���they now look more like the community we represent than we did before.��� And these are really good lawyers.

So these two men from very different political viewpoints totally agree on the importance of representation. So where���s the issue?

# The Issue is Tokenism

When Stewart highlighted how aligned their two perspectives were and Christie pushed back, stating that DEI policies were problematic:

I think there have been a number of areas where there are people who hire certain folks just for their diversity. I���ve seen it happen here in New Jersey, in the government since I left. Where people say, ���I am going to make sure that I have one of every������ It���s almost like a half a Noah���s Ark. ���I���m going to have one of these and one of these and one one of these and one of these.���

Stewart questioned that:

But you just told me that���s what you did in the prosecutor���s office.

But Christie didn���t see it that way:

No, what I did was get them in to interview them. If it turned out, Jon, that they were also really good lawyers, they got hired. I���m talking about something different. I���m talking about predetermining the outcome in the way that you just talked about ��� and I believe that legacy admissions predetermined the outcome ��� that there have been some in charge of government across this country who have predetermined determined outcomes and said, ���I am going to have this many African-Americans, this many Latinos, this many Asians, this many lesbians, this many gay men������ I think that when people see that, they say to themselves, ���That���s not right either.���

What he���s talking about is what I���d call performative DEI. It���s not substantive, but attempts to give off the appearance of being so. It���s the DEI equivalent of greenwashing.

# DEI Cannot be Performative

When people hire folks or celebrate folks for their diversity rather than their diversity plus their competence or talents, it undermines the legitimacy of DEI programs that are attempting to do what they both discussed being important: representation.

As they both said, we need to screen in job applicants who wouldn���t otherwise consider applying for roles in our organizations. Christie talked about this too:

The aha moment for me on that concept and why it was the right way to go was there was a young guy that I hired very early on: African-American, University of Michigan, University of Penn Law School, clerk for Alan Page ��� the former Minnesota Viking, defensive tackle in the Supreme Court of Minnesota��� He���s from New Jersey, grew up in Maplewood. I said to him, ���Why didn���t you ever apply here before?��� He said, ���Because I knew people like me wouldn���t get hired.���

Hiring is just part of the process though. You can widen the applicant funnel and bring in a more representative ��� which is to say diverse ��� applicant pool with relatively little effort. Where things often fall short is retention.

# Is Your Organization Even Ready?

If your organization isn���t excited at the prospect of a more diverse workforce and prepared to support them when they are onboarded, you need to press pause and get prepared. Similarly, if your company is eager, but very homogenous, you���ve also got work to do. No one wants to come into a job and feel like ���the only��� or ���the token��� anything. And even if they were the most qualified applicant for the position, some jackass will say something that implies they are. It���s a tale as old as time and you need to be prepared for that reality.

The first thing you need to do is educate. You need to help folks on your team understand the gaps in your collective knowledge & experience. They need to see that a more diverse team can help fill those gaps. The data that shows that more diverse organizations are more successful. Share that! I���m guessing most of your team is there because they want your organization to be as successful as possible.

And make sure they understand the historical barriers folks from different communities have faced in getting access to jobs at organizations like yours��� even when they were equally or more accomplished than folks from the dominant group. As Stewart said on the show:

It���s not rigging [the system] in a different direction, it���s unrigging it.

It���s also important to note that the process here needs to be inclusive as well��� call people in, don���t call them out. Everyone is on their own journey and deserves the space to fail and learn from their mistakes. If someone says something offensive, let them know that it���s offensive and why. Tell them what they should say ��� if anything ��� instead.

If you approach people with empathy, you���re much more likely to get a positive response. And, Twitter aside, most folks aren���t out in these streets trying to be trolls. People are a product of their own experiences and those experiences can be quite different from yours. Help your colleagues broaden their perspectives with positive reinforcement, not chastising.

That said, you also need the proper mechanisms in place to address non-inclusive behaviors when they become a pattern or reach a certain threshold of severity. Those mechanisms need to outline the consequences for such behavior. The severity of the consequence needs to align with the severity of the harm, but it may need to escalate in severity for repeat offenses. Depending on the size of your organization, coming up with these policies and consequences could be a group activity to ensure both awareness and buy-in.

# Embrace DEI and Pave the Way for Mediocrity

To be clear, neither Jon Stewart nor the progressive left are pushing for diversity quotas like Christie seems to think they are. But there are folks out there who are. These performative DEI programs have got to go. As my colleague and friend Ebele Okoli says ���bake it in, don���t cake it on.���

Don���t hire or promote someone just because you think their headshot would help to melanate your About page. That���s not what DEI is about and it doesn���t help us to reverse the dire course the U.S. government and cowardly companies are taking currently. DEI needs to be a part of every process in your organization on order to give everyone ��� white men like me included ��� an equal chance to succeed.

Cast a wide net. Hire and promote for competence and to address the knowledge gaps your team absolutely has. Foster an inclusive workplace that values the different lived experience and perspectives brought to the table by each and every employee. That is how you succeed with DEI. It���s also how DEI will help your organization succeed in its mission and grow to hire more folks.

And as more of the incredibly talented people out there get hired on at organizations like yours, all boats will rise, creating more jobs and space for mediocre people of all stripes to get hired and rise up the ranks too. But they won���t get there just because or who they know, what they look like, or because they tick a particular box on your diversity bingo card.

A few weeks back I released a web component to enable you to add requirement rules to checkbox groups. Continuing in the form utility space, I���ve created a new web component that allows you to make fields required based on the values of other fields: form-required-if.

The form-required-if web component, which is based on a jQuery plugin I���d written in 2012, looks like this:

<form-required-if
conditions=���email=���
>
<label>Required if there���s an email value
<inputname=���depends-on-email">
label>
form-required-if>

You wrap any field (and its label) in the component and then declare the conditions under which it should be required in the conditions attribute.

# Defining the requirement conditions

Each condition is a key/value pair where the key aligns to the name of the field you need to observe and the value is the value that could trigger the dependency. If any value should trigger the dependency, you use an asterisk () as the value. In the example above, the field will become required when any value is assigned to the field matching [name="email"].

This conditions attribute can be populated with as many or as few dependencies as make sense for your use case. Multiple conditions are separated by double vertical pipes (|| a.k.a. or) as in this example:

<form-required-if
conditions=���email=||test=3���
>
<label>Depends on email or test field
<inputname=���depends-on-email-or-test���>
label>
form-required-if>

Here the field depends on one of the following conditions being true:

the field matching [name="email"] has a value, orthe field matching [name="test"] has a value of ���3���

If the field you reference doesn���t exist, no errors will be thrown, it will just quietly exit.

# Visually indicating a field is required

If you typically use an asterisk or similar to indicate a field is required, this web component can support that through one or both of the following attributes:

indicator - This attribute is where you define the indicator itself. It could be something as simple as a string (e.g., ), or even full-blown HTML.indicator-placement - As you can probably guess, this attribute is used to set the position of the indicator. If you want it at the start of the label text, you give it the value ���before.��� If you want it after the text, you use ���after��� or don���t use the attribute at all. Indicators will be placed after the label text by default.

Here���s an example with a custom indicator that is HTML:

<form-required-if
conditions="email=���
indicator="���
>
<label>Depends on email
<inputname=���dep2">
label>
form-required-if>

If you don���t include markup in your indicator, it will be automatically wrapped in span when injected into the DOM. The hidden and aria-hidden attributes are used to toggle its visibility, relative to the requirement state of the field.

# Demo

I put together a relatively simple demo of the web component over on GitHub:

# Grab It

You can view the entire project (and suggest enhancements) over on the form-required-if component���s Github repo.

I have no opinion on CrowdStrike as a company or service. I���ve never used their products. In fact, prior to the incident last week, I had only a passing familiarity with their name ��� likely from headlines in the tech press I���d scrolled past at some point in time. I now have a vague understanding of what they do, but that���s only based on what I learned about the cause of the incident. In reflecting on this unfortunate incident, I can���t help but think of the lesson it holds for web designers and developers.

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

HTML checkboxes debuted as part of HTML 2.0 in 1995. Our ability to mark an individual checkbox as being required became part of the HTML5 spec that published in 2014. A decade later, we can still only make checkboxes required on a case-by-case basis. To overcome this limitation, I had created a jQuery plugin that allowed me to indicate that a user should choose a specific number of items from within a checkbox group. Yesterday I turned that plugin into a web component: form-required-checkboxes.

# Markup Assumptions

Before I tuck into the details, I���ll start by saying that the web component begins with the assumption that you are following best practices with respect to form markup:

Your checkbox group should be in a fieldset with a legendAll of the checkbox elements must have the same name (e.g., ���foo[]���).

In other words, they should look something like this:

<fieldset>
<legend>Group 1 labellegend>
<ul>
<li><label>
<inputtype=���checkbox���name=���foo[]���value=���1���>
First item
label>li>
<li><label>
<inputtype=���checkbox���name=���foo[]���value=���2���>
Second item
label>li>

ul>
fieldset>

To use the web component, you wrap the group in a form-required-checkboxes element and then include the JavaScript to initialize it.

<form-required-checkboxes>
<fieldset>
<legend>Group 1 labellegend>

fieldset>
form-required-checkboxes>


<scriptsrc=���/js/web-components/form-required-checkboxes.js���async>script>

If you���re following right along, there���s an error waiting for you in the console ��� we need to set the requirement rules.

# The API

The form-required-checkboxes element requires at least one attribute to function, but using some of the others you can more fully customize the experience for users:

required - Represents the range of required values. You can set this up in one of three ways depending on your needs:Single number (e.g., 3) requires exactly that number of choices.Range (e.g., 3-5) requires a minimum of the first number and a max of the second number be chosen.Max (e.g., 0-3) requires a minimum of zero and a max of the second number to be chosen.notice (optional) - This is a string description that explains details of the required value in plan language. If you don���t supply one, the component will create one for you. This description will be added as a small element within the component (as a sibling to the fieldset).error (optional) - This is a string validation error you���d like to be shown when the validation criteria is not met. By default the component will use the notice text, but this gives you more flexibility.# Demo

I put together a relatively simple demo of the web component over on GitHub:

# Grab It

You can view the entire project (and suggest enhancements) over on the component���s Github repo.

At A List Apart, I���m seeing a lot of article pitches that were clearly written by a Large Language Model (LLM) rather than a human being. In many cases, the people making the submission clearly put a lot of through into the prompts they used to get the output they desired, but had zero follow though when it came to taking ownership of the output they were handed. To be clear, the issue I have here is not that they used an LLM as part of their process, but rather how they failed to wield such powerful tool effectively.

# Improv

A while back, I read a great piece from Johnathan May that discussed where LLMS fail us (factual knowledge) and where they excel (conversation). He highlighted how awful they are when it comes to retrieving facts (LLMs are not the reference librarian you think they are), but how useful they can when factuality is not as important. Armed with this knowledge, he did some experimentation and discovered how well LLMs perform as an improv partner��� someone to bounce ideas off of.

It was with that idea in mind that I decided to test out this approach when working on my axe-con keynote last year. I already had an outline for the talk and knew what I wanted to say, but took some time to bounce my ideas off of ChatGPT and see how it responded to them. In most cases it responded with paragraphs of prose clearly demonstrating its lack of reasoning on any subject���not surprising though, LLMs are word prediction engines. In other instances, however, it surprised me with how the words it predicted managed to ���frame���1 particular concepts in novel ways, prompting me to think differently about how I might approach it in my talk.

I feel confident claiming that the talk was entirely a product of my own efforts. At the same time, I���m also appreciative of ChatGPTs role as an improv partner in the process of creating it.

# Hope

I guess I���m hopeful more people will embrace using LLMs in this way. We need to recognize what tools like these are good at and what they aren���t. Hammers are awesome at driving in nails, but they���re only reasonably good at removing them���from wood, yes; from drywall no. Hammers are also the entirely wrong tool if you���re looking to drive or remove a screw.

LLMs are excellent at reworking stuff you���ve written���summarizing content, adjusting it to a particular reading level, helping you craft a suitable conclusion for an article or talk based on your existing content. They are not fact machines. Furthermore, they can���t replicate or replace your unique perspective on a subject and that���s the very humanness that makes your writings, talks, and other forms of communication worthy of our time.

# Parting words

If you find LLMs useful in your process, more power to you. If you don���t, that���s cool too. Just be aware of their limitations while embracing their power to help. And don���t ever try to pass off their writing as your own. Not only can we tell, but it robs us of the chance to hear what you think. And that���s what we really want to read.

P.S. - In case you���re wondering: No, I didn���t use an LLM to help me write this post ����

Footnotes

To be clear, I am not trying to anthropomorphize the LLM here. ������

Today would have been Molly Holzschlag���s 61st birthday. I want to take a moment to remember her by sharing a bit from a post she made way back in 2012 on the new defunct Pastry Box Project.

The post was largely about how the web enables us to be there for one another in times of crisis. Molly shared how she found solace���while reeling from the emergency hospitalization of her mother���in the support of her community through email, Twitter, and Facebook.

Molly recognized the power of the web���and the Open Web in particular���to connect people and communities for the betterment of all humans. Sure, she saw the downsides too and would grumble about them quite often, but she was a firm believer that the web was a net positive for the world.

As I reflected on her life last year when we lost her, this passage really struck me:

Mortality reminds us in very cold, frightening terms how fragile our life and times truly are. The Web, which is a naturally social and interactive communications platform, can help bring us all closer. The fighting, the drama, the debates - they all become irrelevant in these very mortal moments. Let us all reach for the greatness within ourselves and put it into our Web work every day, because even on those days we feel it���s overwhelming or doesn���t matter, it really truly does. One world, one Web, one love, my brothers and sisters.

I cannot think of a better way to remember Molly on this day.

Much love to you and your communities!