An Event Apart en-us Sat, 23 Feb 2019 09:32:29 -0800 Sat, 23 Feb 2019 09:32:29 -0800 “Scenario-Driven Design Systems” by Yesenia Perez-Cruz—An Event Apart video Tue, 19 Feb 2019 12:02:00 -0800 Eric Meyer Design systems aren’t new, but they’ve become incredibly popular in the past few years. They’re essential to building, maintaining, scaling, and evolving our sites and products, but creating a unified system that scales to serve a variety of content and use cases can be challenging. In this hour-long talk filmed live at AEA Orlando 2018, Yesenia Perez-Cruz shares insights from her experience creating a unified design system for eight media brands with eight distinct editorial strategies. See how to approach a design system via a user-centered lens, and learn how being scenario-driven helps you create a scalable design system that responds flexibly to specific contexts.

Yesenia Perez-Cruz is a design director at Vox Media, where she works on the on-platform user experience and design system of The Verge, Vox, SB Nation, Eater, Polygon, Racked, Curbed, and Recode. Earlier in her storied career, she created beautiful, functional design systems for clients like MTV, BBVA Compass, Papa John’s, and Harvard University while at Happy Cog and Intuitive Company, and helped clients improve site performance via asset budgets.

Enjoy all the videos in An Event Apart’s library. There are over 40 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

Paint the Picture, Not the Frame: How Browsers Provide Everything Users Need Tue, 19 Feb 2019 06:56:00 -0800 admin By Eric Bailey

Each month, A List Apart’s editors select an article An Event Apart attendees shouldn’t miss, and we share it here. Enjoy this month’s essential reading!—Ed.

Kip Williams, professor of psychology sciences at Purdue University, conducted a fascinating experiment called “cyberball.” In his experiment, a test subject and two other participants played a computer game of catch. At a predetermined time, the test subject was excluded from the game, forcing them to only observe as the clock ran down.

From the cyberball game, three outlined figures playing catch. Player 1 is mid-throw to Player 3.

The experience showed increases in self-reported levels of anger and sadness, as well as lowering levels of the four needs. The digital version of the experiment created results that matched the results of the original physical one, meaning that these feelings occurred regardless of context.

After the game was concluded, the test subject was told that the other participants were robots, not other human participants. Interestingly, the reveal of automated competitors did not lessen the negative feelings reported. In fact, it increased feelings of anger, while also decreasing participants’ sense of willpower and/or self-regulation.

In other words: people who feel they are rejected by a digital system will feel hurt and have their sense of autonomy reduced, even when they believe there isn’t another human directly responsible.

So, what does this have to with browsers?

Every adjustment to the appearance and behavior of the features browsers let you manipulate is a roll of the dice, gambling on the delight of some at the expense of alienating others.

When using a browser to navigate the web, there’s a lot of sameness, until there isn't. Most of the time we’re hopping from page-to-page and site-to-site, clicking links, pressing buttons, watching videos, filling out forms, writing messages, etc. But every once in awhile we stumble across something new and novel that makes us pause to figure out what’s going on.

Every website and web app is its own self-contained experience, with its own ideas of how things should look and behave. Some are closer to others, but each one requires learning how to operate the interface to a certain degree.

Some browsers can also have parts of their functionality and appearance altered, meaning that as with websites, there can be unexpected discrepancies. We’ll unpack some of the nuance behind some of these features, and more importantly, why most of them are better off left alone.


All the major desktop browsers allow you to hit the Home key on the keyboard to jump to the top of the page. Some scrollbar implementations allow you to click on the top of the scrollbar area to do the same. Some browsers allow you to type Command+Up (macOS) / Ctrl+Up (Windows), as well. People who use assistive technology like screen readers can use things like banner landmarks to navigate the same way (provided they are correctly declared in the site’s HTML).

However, not every device has an easily discoverable way to invoke this functionality: many laptops don’t have a Home key on their keyboard. The tap-the-clock-to-jump-to-the-top functionality on iOS is difficult to discover, and can be surprising and frustrating if accidentally activated. You need specialized browser extensions to recreate screen reader landmark navigation techniques.

One commonly implemented UI solution for longer pages is the scroll-to-top button. It’s often fixed to the bottom-right corner of the screen. Activating this control will take the user to the top of the page, regardless of how far down they’ve scrolled.

If your site features a large amount of content per page, it may be worth investigating this UI pattern. Try looking at analytics and/or conducting user tests to see where and how often this feature is used. The caveat being if it’s used too often, it might be worth taking a long, hard look at your information architecture and content strategy.

Three things I like about the scroll-to-top pattern are:

  • Its functionality is pretty obvious (especially if properly labeled).
  • Provided it is designed well, it can provide a decent-sized touch target in a thumb-friendly area. For motor control considerations, its touch target can be superior to narrow scroll or status bars, which can make for frustratingly small targets to hit.
  • It does not alter or remove existing scroll behavior, augmenting it instead. If somebody is used to one way of scrolling to the top, you’re not overriding it or interrupting it.

If you’re implementing this sort of functionality, I have four requests to help make the experience work for everyone (I find the Smooth Scroll library to be a helpful starting place):

  • Honor user requests for reduced motion. The dramatic scrolling effect of whipping from the bottom of the page to the top may be a vestibular trigger, a situation where the system that controls your body’s sense of physical position and orientation in the world is disrupted, causing things like headaches, nausea, vertigo, migraines, and hearing loss.
  • Ensure keyboard focus is moved to the top of the document, mirroring what occurs visually. Applying this practice will improve all users’ experiences. Otherwise, hitting Tab after scrolling to the top would send the user down to the first interactive element that follows where the focus had been before they activated the scroll button.
  • Ensure the button does not make other content unusable by obscuring it. Be sure to account for when the browser is in a zoomed-in state, not just in its default state.
  • Be mindful of other fixed-position elements. I’ve seen my fair share of websites that also have a chatbot or floating action button competing to live in the same space.
A red chat icon overlaps with a corner of the scroll to top icon, obscuring a portion of the arrow.


If you’re old enough to remember, it was once considered fashionable to style your website scrollbars. Internet Explorer allowed this customization via a series of vendor-specific properties. At best, they looked great! If the designer and developer were both skilled and detail-oriented, you’d get something that looked like a natural extension of the rest of the website.

However, the stakes for a quality design were pretty high: scrollbars are part of an application’s interface, not a website’s. In inclusive design, it’s part of what we call external consistency. External consistency is the idea that an object’s functionality is informed and reinforced by similar implementations elsewhere. It’s why you can flip a wall switch in most houses and be guaranteed the lights come on instead of flushing the toilet.

While scrollbars have some minor visual differences between operating systems (and operating system versions), they’re consistent externally in function. Scrollbars are also consistent internally, in that every window and program on the OS that requires scrolling has the same scrollbar treatment.

If you customize your website's scrollbar colors, for less technologically literate people, yet another aspect of the interface has changed without warning or instruction on how to change it back. If the user is already confused about how things on the screen work, it’s one less familiar thing for them to cling to as stable and reliable.

You might be rolling your eyes reading this, but I’d ask you to check out this incredible article by Jennifer Morrow instead. In it, she describes conducting a guerilla user test at a mall, only to have the session completely derailed when she discovers someone who has never used a computer before.

What she discovers is as important as it is shocking. The gist of it is that some people (even those who have used a computer before) don’t understand the nuance of the various “layers” you navigate through to operate a computer: the hardware, the OS, the browser installed on the OS, the website the browser is displaying, the website’s modals and disclosure statements, etc. To them, the experience is flat.

We should not expect these users to juggle this kind of cognitive overhead. These kinds of abstractions are crafted to be analogous to real-world objects, specifically so people can get what they want from a digital system without having to be programmers. Adding unnecessary complexity weakens these metaphors and gives users one less reference point to rely on.

Remember the cyberball experiment. When a user is already in a distressed emotional state, our poorly-designed custom scrollbar might be the death-by-a-thousand-paper-cuts moment where they give up on trying to get what they want and reject the system entirely.

While Morrow’s article was written in 2011, it’s just as relevant now as it was then. More and more people are using the internet globally, and more and more services integral to living daily life are getting digitized. It’s up to us as responsible designers and developers to be sure we make everyone, regardless of device, circumstance, or ability feel welcome.

In addition to unnecessarily abandoning external consistency, there is the issue of custom scrollbar styling potentially not having sufficient color contrast. The too-light colors can create a situation where a person experiencing low-vision conditions won’t be able to perceive, and therefore operate, a website’s scrolling mechanism.

This article won’t even begin to unpack the issues involved with custom implementations of scrollbars, where instead of theming the OS’s native scrollbars with CSS, one instead replaces them with a JavaScript solution. Trust me when I say I have yet to see one implemented in a way that could successfully and reliably recreate all features and functionality across all devices, OSes, browsers, and browsing modes.

In my opinion? Don’t alter the default appearance of an OS’s scrollbars. Use that time to work on something else instead, say, checking for and fixing color contrast problems.


The main concern about altering scrolling behavior is one of consent: it’s taking an externally consistent, system-wide behavior and suddenly altering it without permission. The term scrolljacking has been coined to describe this practice. It is not to be confused with scrollytelling, a more considerate treatment of scrolling behavior that honors the OS’s scrolling settings.

Altering the scrolling behavior on your website or web app can fly in the face of someone’s specific, expressed preferences. For some people, it’s simply an annoyance. For people with motor control concerns, it could make moving through a site difficult. In some extreme cases, the unannounced discrepancy between the amount of scrolling and the distance traveled can also be vestibular triggers. Another consideration is if your modified scrolling behavior accidentally locks out people who don’t use mice, touch, or trackpads to scroll.

All in all, I think Robin Rendle said it best:

Scrolljacking, as I shall now refer to it both sarcastically and honestly, is a failure of the web designer’s first objective; it attacks a standardised pattern and greedily assumes control over the user’s input.


Another OS feature we’re permitted to style in the browser is highlighted text. Much like scrollbars, this is an interface element that is shared by all apps on the OS, not just the browser.

Breaking the external consistency of the OS’s highlighting color has a lot of the same concerns as styled scrollbars, namely altering the expected behavior of something that functions reliably everywhere else. It’s potentially disorienting and alienating, and may deny someone’s expressed preferences.

Some people highlight text as they read. If your custom highlight style has a low contrast ratio between the highlighted text color and the highlighted text’s background color, the person reading your website or web app may be unable to perceive the text they’re highlighting. The effect will cause the text to seemingly disappear as they try to read.

Other people just may not care for your aesthetic sensibilities. Both macOS and Windows allow you to specify a custom highlight color. In a scenario where someone has deliberately set a preference other than the system default, a styled highlight color may override their stated specifications.

For me, the potential risks far outweigh the vanity of a bespoke highlight style—better to just leave it be.

Text resizing

Lots of people change text size to suit their needs. And that’s a good thing. We want people to be able to read our content and act upon it, regardless of whatever circumstances they may be experiencing.

For the problem of too-small text, some designers turn to text resizing widgets, a custom UI pattern that lets a person cycle through a number of preset CSS font-size values. Commonly found in places with heavy text content, text resizing widgets are often paired with complex, multicolumn designs. News sites are a common example.

Before I dive into my concerns with text resizing widgets, I want to ask: if you find that your site needs a specialized widget to manage your text size, why not just take the simpler route and increase your base text size?

Like many accessibility concerns, a request for a larger font size isn’t necessarily indicative of a permanent disability condition. It’s often circumstantial, such as a situation where you’re showing a website on your office’s crappy projector.

Browsers allow users to change their preferred default font size, resizing text across websites accordingly. Browsers excel at handling this setting when you write CSS that takes advantage of unitless line-height values and relative font-size units.

Some designers may feel that granting this liberty to users somehow detracts from their intended branding. Good designers understand that there’s more to branding than just how something looks. It’s about implementing the initial design in the browser, then working with the browser’s capabilities to best serve the person using it. Even if things like the font size are adjusted, a strong brand will still shine through with the ease of your user flows, quality of your typography and palette, strength of your copywriting, etc.

Unfortunately, custom browser text resizing widgets lack a universal approach. If you rely on browser text settings, it just works—consistently, with the same controls, gestures, and keyboard shortcuts, for every page on every website, even in less-than-ideal conditions. You don’t have to write and maintain extra code, test for regressions, or write copy instructing the user on where to find your site’s text resizing widget and how to use it.

Behavioral consistency is incredibly important. Browser text resizing is applied to all text on the page proportionately every time the setting is changed. These settings are also retained for the next time you visit. Not every custom text resizing widget does this, nor will it resize all content to the degree stipulated by the Web Content Accessibility Guidelines.

High-contrast themes

When I say high-contrast themes, I’m not talking about things like a dark mode. I’m talking about a response to people reporting that they need to change your website or web app’s colors to be more visually accessible to them.

Much like text resizing controls, themes that are designed to provide higher contrast color values are perplexing: if you’re taking the time to make one, why not just fix the insufficient contrast values in your regular CSS? Effectively managing themes in CSS is a complicated, resource-intensive affair, even under ideal situations.

Most site-provided high-contrast themes are static in that the designer or developer made decisions about which color values to use, which can be a problem. Too much contrast has been known to be a trigger for things like migraines, as well as potentially making it difficult to focus for users with some forms of attention-deficit hyperactivity disorder (ADHD).

The contrast conundrum leads us to a difficult thing to come to terms with when it comes to accessibility: what works for one person may actually inhibit another. Because of this, it’s important to make things open and interoperable. Leave ultimate control up to the end user so they may decide how to best interact with content.

If you are going to follow through on providing this kind of feature, some advice: model it after the Windows High Contrast mode. It’s a specialized Windows feature that allows a person to force a high color palette onto all aspects of the OS’s UI, including anything the browser displays. It offers four themes out of the box but also allows a user to suit their individual needs by specifying their own colors.

Your high contrast mode feature should do the same. Offer a range of themes with different palettes, and let the user pick colors that work best for them—it will guarantee that if your offerings fail, people still have the ability to self-select.

Moving focus

Keyboard focus is how people who rely on input such as keyboards, switch controls, voice inputs, eye tracking, and other forms of assistive technology navigate and operate digital interfaces. While you can do things like use the autofocus attribute to move keyboard focus to the first input on a page after it loads, it is not recommended.

For people experiencing low- and no-vision conditions, it is equivalent to being abruptly and instantaneously moved to a new location. It’s a confusing and disorienting experience—there’s a reason why there’s a trope in sci-fi movies of people vomiting after being teleported for the first time.

For people with motor control concerns, moving focus without their permission means they may be transported to a place where they didn’t intend to go. Digging themselves out of this location becomes annoying at best and effort-intensive at worst. Websites without heading elements or document landmarks to serve as navigational aids can worsen this effect.

This is all about consent. Moving focus is fine so long as a person deliberately initiates an action that requires it (shifting focus to an opened modal, for example). I don’t come to your house and force you to click on things, so don’t move my keyboard focus unless I specifically ask you to.

Let the browser handle keyboard focus. Provided you use semantic markup, browsers do this well. Some tips:

The clipboard and browser history

The clipboard is sacred space. Don’t prevent people from copying things to it, and don’t append extra content to what they copy. The same goes for browser history and back and forward buttons. Don’t mess around with time travel, and just let the browser do its job.

Wrapping up

In the game part of cyberball, the fun comes from being able to participate with others, passing the ball back and forth. With the web, fun comes from being able to navigate through it. In both situations, fun stops when people get locked out, forced to watch passively from the sidelines.

Fortunately, the web doesn’t have to be one long cyberball experiment. While altering the powerful, assistive technology-friendly features of browsers can enhance the experience for some users, it carries a great risk of alienating others if changes are made with ignorance about exactly how much will be affected.

Remember that this is all in the service of what ultimately matters: creating robust experiences that allow people to successfully use your website or web app regardless of their ability or circumstance. Sometimes the best strategy is to let things be.

About the author

Eric Bailey is a Boston-based designer who helps create straightforward solutions that address a person’s practical, physical, cognitive, and emotional needs using accessible, performant, device-agnostic technology. He's an inclusive design advocate, A11Y Project maintainer, MDN Web Docs contributor, and recovering curmudgeon.

Illustration by Dougal MacPherson.

For more information every web designer and front-end developer needs, read A List Apart “for people who make websites.”

“Beyond Engagement: the Content Performance Quotient” by Jeffrey Zeldman—An Event Apart video Tue, 05 Feb 2019 10:10:00 -0800 Eric Meyer Our products are tasked with providing ever-higher levels of “engagement,” but should they be? For many sites, analytics demonstrating high levels of “engagement” may actually be signs of failure. In this 60-minute talk filmed live at AEA, Jeffrey Zeldman introduces a new measure of design success: the content performance quotient. Learn how relentlessly trimming content and architecture, honing UX and UI, and shoring up technical performance can create experiences that are better attuned to today’s web. You’ll even find out how to sell this change in design thinking to your bosses, clients, and colleagues.

Dubbed “King of Web Standards” by Business Week, Jeffrey Zeldman co-founded An Event Apart with Eric Meyer; publishes A List Apart and A Book Apart books; teaches in the MFA, Interaction Design program at School of Visual Arts, New York; hosts The Big Web Show (“Everything Web That Matters”) podcast; and runs the studio.zeldman design agency. Jeffrey has written two books, notably the foundational text, Designing With Web Standards, currently in a 3rd Edition. He was the first human inducted in the SXSW Interactive Hall of Fame.

Enjoy all the videos in An Event Apart’s library! There are over 40 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

Have Lunch With <cite>Rams</cite> in 2019 Tue, 29 Jan 2019 11:11:00 -0800 Eric Meyer A legendary industrial designer. An award-winning documentary filmmaker. And today’s leading UX and front-end visionaries. What do they have in common? They’re all part of An Event Apart 2019. Read on to learn how.

Our back (web) pages

One of An Event Apart’s first speakers was Chicago designer Jim Coudal—publisher of, inventor of Layer Tennis, and co-founder of the ever-popular Field Notes Brand. Jim’s not only a web and product designer, advertising art director, and entrepreneur, he’s also a filmmaker… and a close friend of legendary documentarian Gary Hustwit.

You may know Gary from such wonderful movies as Objectified, Urbanized, and Helvetica, the film that made everybody a type nerd. Gary’s latest project, Rams, is a documentary portrait of one of the most influential designers of all time: Dieter Rams, the industrial design giant who made previously humdrum products not only touchable, but downright lovable. Herr Rams’s 10 Principles of Good Design are spoken of reverently by designers from multiple disciplines.

Those ideas, and the aesthetic brilliance of his product design, had a fundamental impact on the first generation of web designers—from Clement Mok, who emulated Rams’ touchable buttons in Photoshop, to Jeffrey Zeldman and Eric Meyer, who tried to achieve the same effects in CSS. (And who later co-founded An Event Apart.)

What goes around

To bring things full circle, folks who attend An Event Apart in 2019 will be treated to a special lunchtime presentation of Rams on the Tuesday of each three-day conference. It’s an overview of a giant’s legacy, influencing everything from the aesthetic of an entire generation to the product design of Apple Computer. But it’s more than that—it’s a rumination on consumerism, sustainability, and how technology is changing human behavior. The film also addresses the question of why, at 86 years old, Herr Rams now regrets being a designer. And it’s all set to an original score by pioneering musician and technologist Brian Eno.

In addition to enjoying this private screening of Rams in the company of a few hundred of your colleagues and peers, attending An Event Apart in 2019 means you’ll also enjoy seventeen superb, live presentations from the visionaries of our industry: influencers like Val Head, Gerry McGovern, Jen Simmons, and so many more. Check the schedule to find the event nearest you—or in the great city you’d most like to visit this year—and make 2019 the year you set yourself Apart.

“The Joy of Optimizing Images” by Una Kravets – An Event Apart video Tue, 08 Jan 2019 11:03:00 -0800 Eric Meyer Images are by far the greatest bottleneck to performance on the web, and with the average web page size now about 2.5MB large—images taking up 65% of that—we need to tame the beast. Running images through a compression program like ImageOptim is a good first step, but what else can we do?

In this engaging talk recorded live at An Event Apart Denver 2017, Una Kravets surveys new image formats and dives deeply into image rendering and performance optimization techniques, demonstrating practical approaches to making your web projects noticeably faster.

Una Kravets is a Senior UI Engineer at DigitalOcean. She’s a technical writer, having written for various online publications such as A List Apart, Smashing Magazine, and Sitepoint. Una also co-hosts the Toolsday podcast and started both the Washington DC and Austin Sass Meetups. Una is involved in the open source community as both an open source design advocate and maintainer of the CSSgram project. She's a performance nerd, travels frequently, and listens to way too many audio books.

Enjoy all the videos in An Event Apart’s library! There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

“Evaluating Technology” by Jeremy Keith – An Event Apart video Tue, 18 Dec 2018 10:16:00 -0800 Eric Meyer We work with technology every day. And every day it seems like there's more and more technology to understand: graphic design tools, build tools, frameworks and libraries, not to mention new HTML,CSS and JavaScript features landing in browsers. How should we best choose which technologies to invest our time in?

In this 60-minute presentation recorded live at An Event Apart Denver 2017, Jeremy Keith helps you learn to evaluate tools and technologies in a way that best benefits the people who use the websites you design and develop. You’ll look at some of the hottest new web technologies like service workers and web components. And dig beneath the hype to find out whether they will really change life on the web for the better.

Jeremy Keith lives in Brighton, England where he makes websites with the splendid design agency Clearleft. You may know him from such books as DOM Scripting, Bulletproof Ajax, HTML5 For Web Designers, Resilient Web Design, and, most recently, Going Offline. He curated the dConstruct conference for a number of years as well as Brighton SF, and he organized the world's first Science Hack Day. He also made the website Huffduffer to allow people to make podcasts of found sounds—it‘s like Instapaper for audio files.

Enjoy all the videos in An Event Apart’s library! There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

“Digital Marketing Strategies for the Busy ‘Web Master’” by Sarah Parmenter – An Event Apart video Tue, 11 Dec 2018 10:30:00 -0800 Eric Meyer Thanks to dwindling attention spans and the pace at which online content refreshes, reaching through the screens of our customers to hold their attention is becoming increasingly difficult. Nowadays the job of the multi-faceted web designer is to not only know the latest techniques for building in Grid, but also know how to get that work seen amid the saturated world of digital marketing.

In this 60-minute presentation recorded live at An Event Apart Denver 2017, Sarah Parmenter discusses the idea of quarterly website design reviews with a “design once use everywhere” mantra, and digs into the ever-changing world of Instagram algorithms, Facebook marketing, and topical social media takeaways for immediate implementation.

Sarah Parmenter owns You Know Who, a small British design studio now in its second decade. She specializes in iOS User Interface design; regularly contributes to various online and printed media; and speaks at related conferences all over the world. Sarah’s straight-talking nature and no-fuss approach to projects have landed her many great contracts over the years, with various well-known brands in the UK, US, and abroad.

Enjoy all the videos in An Event Apart’s library! There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

Articles, Links, and Tools From An Event Apart San Francisco 2018 Sat, 08 Dec 2018 17:00:00 -0800 Eric Meyer Jeffrey Zeldman

Mina Markham

Art Direction, Design & Creativity






Cameron Moll

History & Principles


Rachel Andrew

The code examples can be found in this CodePen Collection.



Logical Properties and Values

Scroll Snap

Subgrid (Grid Level 2)

Paged Media



Eric Meyer

Jen Simmons

Josh Clark

More on this topic from Josh


Example applications

Robot designers: AI for design and code

Machine learning APIs and data sets

Customize or construct your own model

Mental models and opaque logic

Surveillance capitalism

Designing to counter misinformation, error and bias

Manner and language as cues for confidence and interaction

Machine ethics

Laura Martini

Aaron Gustafson

Gerry McGovern

“10 Things You Can and Should Do with SVG” by Chris Coyier – An Event Apart video Tue, 04 Dec 2018 10:02:00 -0800 Eric Meyer You’re already aware of SVG. You already know it’s a vector image format. But how does that affect your daily life as a front-end developer and designer? In this fun, compelling, and information-packed live presentation recorded at An Event Apart Denver 2017, Chris Coyier counts down 10 things you could (and should!) be doing with SVG. It’s one of those technologies that is chock full of possibilities and benefits, yet conspicuously missing from most people’s tool belts. Find out why it deserves a prime spot on yours.

Chris Coyier is a web designer and developer. He writes about all things web at, talks about all things web at conferences around the world and on his podcast ShopTalk, and co-founded the web coding playground CodePen.

Enjoy all the videos in An Event Apart’s library! There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

“Performance as User Experience” by Aaron Gustafson—An Event Apart video Tue, 27 Nov 2018 10:39:00 -0800 Eric Meyer Design is problem solving. Each and every day, we are tasked with finding ways to reduce the friction our users experience on the Web. That means streamlining flows, reducing cognitive load, and writing more appropriate copy, but user experience goes far beyond the interface. Our users’ experiences begin with their first request to our servers.

In this intensely practical 60-minute live presentation recorded at An Event Apart Denver 2017, Adaptive Web Design author Aaron Gustafson explores the ins and outs of page load performance by showing how he made the website of the 10K Apart meet its own contest rules—creating a site that was functional and attractive even without JavaScript, and was less than ten kilobytes at initial load. You’ll finish watching the video with a better understanding of the page load process as well as numerous ways you can improve the projects you’re working on right now.

As would be expected from a former manager of the Web Standards Project, Aaron Gustafson is passionate about web standards and accessibility. In his two decades working on the web, Aaron has worked with a number of companies you’ve probably heard of including Box, Happy Cog, Major League Baseball, McAfee, The New York Times, SAS, StubHub, the U.S. Environmental Protection Agency, Vanguard, Walgreens, and Yahoo. Aaron is a longtime member of Rosenfeld Media’s "experts" group and writes about whatever’s on his mind at He is currently a web standards and accessibility advocate at Microsoft, working closely with the Edge browser team.

Enjoy all the videos in An Event Apart’s library! There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

“Choose Your Animation Adventure” by Val Head—An Event Apart video Tue, 20 Nov 2018 11:20:00 -0800 Eric Meyer Animation has come a long way on the modern web and now we have a long list of choices for how to make something move on screen: CSS, JavaScript, SVG, the Web Animation API. With so many options, how can you be sure which is the best choice for your project?

In this 60-minute video caught live at An Event Apart Denver 2017, web animation expert, author, and Design Evangelist at Adobe Val Head teaches you which animation options are the best fit for common UI design tasks.

With an eye on both the strategy and tactics of animation needs, Val will survey the full spectrum of animation options from CSS to React Motion, and reveal which are best suited for things like state transitions, showing data, animating illustrations, or making animations responsive. You’ll also see how your choice of animation tools can impact performance. By the end of the hour, you’ll know exactly which tools to choose for your animation needs.

Val Head is the author of Designing Interface Animation, published by Rosenfeld Media, and teaches CSS Animation on She shares her passion for web animation as co-host of the Motion and Meaning podcast, and curator of the UI Animation Newsletter. A proud supporter of the web community, she co-founded the Web Design Day conference and co-leads Pittsburgh’s Girl Develop It Chapter. Val leads workshops at companies and conferences around the world on motion design for the web and loves every minute of it.

Enjoy all the videos in An Event Apart’s library! There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

“Prototyping: The Scientific Method of Business” by Daniel Burka—An Event Apart Denver 2017 Tue, 13 Nov 2018 12:33:00 -0800 Eric Meyer For years, designers and developers have adapted prototyping and research to answer the most pressing questions that businesses face. In this 60-minute video, caught live at An Event Apart: Denver Special Edition, designer Daniel Burka shows how you can level up your effectiveness by answering the right questions, working at the right level of fidelity, involving a diverse group of experts, and researching at the right speed. You’ll learn how to use these tools to make yourself indispensable to your organization.

Daniel is director of design at Resolve to Save Lives and a board member of Laboratory. Previously, he was a design partner at GV, Google’s venture capital group, where he worked with the venture funds’ many portfolio companies to solve their design challenges. Daniel’s varied career has included co-founding an agency (silverorange), design directing at startups (Digg and TinySpeck), and founding two startups (Pownce and Milk).

Enjoy all the videos in An Event Apart’s library! There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

Designing for Cognitive Differences Wed, 07 Nov 2018 12:59:00 -0800 Eric Meyer By Brandon Gregory

Each month, A List Apart’s editors select an article An Event Apart attendees shouldn’t miss, and we share it here. Enjoy this month’s essential reading!—Ed.

Inclusive design is designing to be inclusive of as many users as possible, considering all aspects of diversity in users. With increased understanding, compassionate discussions around how to design for disabilities are becoming increasingly common in the web industry. But even with this growth, there are misconceptions: accessibility is still frequently thought of as “design for blind people” when it’s so much more than that. Users with limited motor functions and those who are hearing-impaired require separate considerations, for instance. But accessibility and inclusiveness also mean considering more than just physical symptoms. What about users with cognitive differences like inattention, anxiety, and depression?

Many affective and anxiety disorders qualify as disabilities, with inattention causing challenges on the web as well. Whatever the cause, inattention, anxiety, and depression can have a major impact on internet usage for users dealing with them. The unique issues presented by cognitive differences and the design considerations they require can be tricky to understand for people who have never dealt with them. Through this article, I’ll share some methods to accommodate these users’ unique needs.


Inattention is often regarded as a joke in our industry (and just about everywhere else), but it can be a serious impediment for people who struggle with it. While Attention Deficit Hyperactivity Disorder (ADHD) is a common culprit, affecting 4.4% of adults, it’s not the only source of inattention. Bipolar disorder (estimated at 2.8% of adults), major depression (6.7% of adults), and anxiety disorders (19.1% of adults) can cause occasional inattention. More common conditions such as stress or sleep deprivation can cause inattention in people who don’t experience it as regularly.

I’m quite familiar with inattention because I have bipolar disorder, which frequently causes inattention in manic phases. The term inattention is a bit of a misnomer, because it implies that those suffering from it have trouble paying attention to anything. It’s more accurate to say that we have to pay attention to everything—we have trouble tuning things out, and the more things that are competing for our attention, the harder it is for us to focus on anything.

Designers who are able to focus normally rarely see the things that cause problems for users with inattention, but these things are everywhere, and they can make the web much harder for us to use. Some design considerations we can make to be more inclusive of users with inattention include adding an option to mute notifications at certain times, which is a more obvious solution while others are less so, such as giving users the ability to turn off design features that are distracting them.

Drowning in the ocean of motion

I was recently reading an article on search engine optimization, and the author saw fit to incorporate animated GIFs throughout the article. The GIFs, looped infinitely and placed prominently, didn’t add anything of substance. Worse, as I was already struggling through a manic episode, the GIFs actually prevented me from reading the article—I had to open Chrome DevTools and hide all of the GIFs to get through the content.

Motion is everywhere. This simple fact of the modern internet makes designers smile, while users with inattention issues cringe. Motion distracts people with inattention even when neurotypical people, or those not characterized by neurological patterns, are fine. Most users struggling with inattention won’t use Chrome DevTools to make your site usable for them, they’ll simply leave and probably end up on a competitor’s site. I cringe anytime I see an article with pointless animation, and often just click the back button. Even though I’m sure the designer or author saw the motion as beneficial, it can distract users who struggle with inattention from what they came to your site to do.

Motion isn’t always bad. Sometimes you need to use subtle motion to draw attention to something, such as when a user has to click a button before changes are applied. User-initiated motions, such as hover and click effects, usually don’t distract. Your website or app doesn’t need to be a static, motionless wasteland. But if you’re going to distract your users with motion that they don’t initiate, it had better accomplish something.

Unnecessary motion, like the animated GIFs I mentioned above, are nothing but a barrier for these users. If the motion is actually accomplishing something, you have to ask if what you’re drawing attention to is worth sacrificing other content on the page in return. Designers and content developers tend to use motion—autoplayed videos, animated GIFs, and CSS animations—simply to be cute or expressive. Inclusive design would use motion only to improve clarity so as not to exclude users struggling with inattention. If motion would significantly improve the experience for neurotypical users, but hurt it for users with inattention, you can give users the option to turn off motion, allowing them to choose which would be best for them.

Designing forms for inattention

Forms add layers of interactivity and are often at the center of what we want users to do on our websites or apps; and yet, forms are often hard to use for users who struggle with inattention. Poor design reduces clarity and increases errors; some interactions take so long that they become extremely difficult for those of us with inattention. Rather than slapping on a quick fix or letting ease of implementation define the user experience, we need to fix design issues to be more inclusive of these users.

In my twelve years in the industry, there’s a phrase I hear way too often: “Why can’t the users just follow the directions?” This doesn’t show a problem with the user, but with the site or app. The problem isn’t with the directions—it’s with the design.

If users are making mistakes on a form, our first instinct is to add instructions before it. There are two problems here:

  • Most people will not read the instructions. Stats show that of the $13.8 billion of technical gadgets that were returned to the store by consumers in 20o7, only 5% were due to faulty products. The rest were because users did not understand how to use the products. Users hate reading instructions.
  • Your form is so complicated that it requires instructions. A better solution would be to fix the design of the form itself so you’re not attempting to solve a design problem with content.

If most users are making mistakes on a form, users with inattention will struggle even more. When this happens, figure out exactly where the errors are occurring, and fix the design of the form to target that error. For instance, if you’re receiving the wrong data for a field, it’s a sign that form labels are unclear; if you have inline-only labels, adding regular labels outside of the fields will do more than adding an explanatory note. Taking steps like this will make the process less confusing, reducing the need to have long instructions. If an explanation is needed, add it adjacent to the form field where users are having trouble, not at the top of the form where users will likely ignore it. The best option is to simplify the form so that explanations are not needed.

Inattention also makes sustained concentration considerably more difficult, and the longer your form or process is, the harder it will be for users with inattention to complete in one sitting. If it is more than two steps or pages, add the functionality to save progress and come back later to finish it. Please, please, please don’t have your multi-page form time out quickly—if they come back from a break and find that your form has lost their progress, they probably won’t be starting over.


Anxiety is a fairly common problem for adults. Among adults, 19.1% have an anxiety disorder, but anxiety can also result from other things, like taking certain medications, withdrawal from drugs or alcohol, prolonged stress, or chronic pain. As common as anxiety is, you’d think we’d be better at designing for it than we are.

Anxiety has been described as knowing that you turned off the stove, but having to turn your car around to check anyway. Users with anxiety fear that they will do something wrong when interacting with your site or app. To counteract this, provide reassurance that what they’re doing is the right thing, and make the experience forgiving if they do the wrong thing. Reassuring them reduces stress and helps to retain anxious users who are more likely to leave in the middle of a difficult process.

Let users think like users

Nobody goes to your site not knowing why they’re there. If users go to your site to solve a problem, they need to know where to find the solution. The problem may be common to all users, but users with anxiety will struggle more when they can’t find the answers they need or when the way forward is unclear.

One of the biggest culprits of unclear user flow is basing the user experience on your company’s understanding of the problem. Companies have their own internal terminology and organizational structures to address these problems internally. Users likely won’t understand any of this and shouldn’t require a glossary of industry terms or internal structures in order to use your website or app.

Define clear paths for users to solve common problems, and design them to address the user’s concerns; don’t give a list of the types of data you accept or organize things according to how your company receives them. If you have multiple types of users using your site (for instance, parents applying for school as well as school administrators), define clear user paths for each.

Remember that many of your users will not always start on the homepage of your site. If the user paths are only clear on the homepage, then they’re not clear.

Provide clear wayfinding. Even once anxious users are on the path to their solution, they need to know they’re heading in the right direction. On each step of a process, state not only what step they’re on, but what the end of that path is. Remember, anxious users may have a need to keep checking to make sure they’re in the right spot—don’t make them click the back button to do that.

There’s no anxiety like form anxiety

With a good chunk of anxiety being caused by the fear that you’re doing something wrong, forms are a huge stressor for anxious users. A lack of clarity on forms really harms usability and accessibility for users with anxiety, sometimes causing them to stop the process altogether. Improving clarity and providing reassurance can go a long way in reducing anxiety in these users.

Every form and action should be clearly labeled with a headline that plainly states what the form does. I occasionally struggle with anxiety, and there are times when I have to glance up at the headline to double-check that I’m filling out the right form.

Similarly, submit buttons should clearly state what happens when users click them. Submit buttons should have copy like “send message,” “complete purchase,” “continue to the next step,” or “sign up for our newsletter.” One of the worst things you can do with a submit button is have it just say “submit.”

There’s a trend for designers to get overly clever with form labels: inline-only labels, labels that only appear when their field has focus, or even labels that start inside their field and then animate elsewhere. I’ve never encountered a situation where I was glad these overly clever solutions were in place. A label exists not only to tell users what information to put in the field, but also to confirm to users who have already filled out the form that their information is in the right place. Inline-only form labels make this impossible and cause undue stress to anxious users. Labels that cover up auto-filled text (common with labels that start inside form fields and then move somewhere else) cause similar problems. Form labels are not a medium for creative expression; they’re a tool for users to know how to use a form. This basic functionality should not be hindered.

If you’re asking the user for any personal information, privacy is a huge concern, especially for users suffering from social anxiety who dread getting unexpected phone calls. Include a prominent link to your privacy policy on the form itself so it’s easy to find. Also, if it’s not immediately obvious why a piece of information is needed in your form, like a phone number, add a bit of help text to explain it. (For example, clicking a “Why do we need this?” link displays a “We need your phone number to call you in case of a mix-up with your order” tooltip.) If you don’t have a good reason for asking for a piece of personal information or can’t clearly explain why you need it, get rid of the field.

And your job is not done once the user has submitted the form. Confirmation messages can be either a huge relief or a huge source of stress for anxious users. I can’t tell you how many times I’ve submitted a form online and the confirmation message just says, “Your data was submitted.” For users with anxiety, this can start the stress cycle all over again. What data? Submitted where? What if I messed something up?

Confirmation messages should state:

  • what action was taken (“Thank you for signing up for our newsletter!”);
  • what data was posted (“Your email address,, has been added to our distribution list.”);
  • and what the user should do if they made a mistake (“If you want to stop receiving our newsletter at any time, you can unsubscribe on your user profile.”).

Adding this little bit of reassurance can really help users struggling with anxiety to avoid undue stress.


Depression is not something we think about often in design, but it impacts how a lot of people use the web. About 6.7% of adults have major depression, and 2.8% of adults have bipolar disorder, which involves severe depression at times. Additionally, temporary or even long-term depression can be caused by traumatic events, drug use, or certain medications.

The book Design for Real Life, by Sara Wachter-Boettcher and Eric Meyer (excerpt here), reminds us that we can’t just design for happy users. Some of our users will be in crisis: having their order mishandled, desperately needing information that’s not readily available, or just having an exceptionally bad day. For users with depression, any ordinary day has the potential to be an exceptionally bad day or crisis, and minor annoyances in user experience can become overwhelming.

Keep it easy

Depression is thought of as a psychological condition, but it also has physical side effects. For instance, depression actually impairs contrast perception—the world really does look gray for users dealing with depression. Fatigue and physical pain are common and can be hard to deal with. Everything is harder with depression. If your site or app is hard to use, many depressed users will simply not use it. A lot of the shortcuts we take in the web industry add up to insurmountable challenges for these users.

A great example of this is unnecessary user registrations. Registering for a user account is a lengthy (and, for depressed users, exhausting) process. If it’s not absolutely required for a user task, you’re punishing depressed users (and probably everyone else too). If your site has a checkout process, make sure users can check out as a guest. Forcing a user to register for an account just to look at the content (I’m looking at you, Pinterest) is a great way to make sure depressed users will never look at your content.

Long sign-up processes, unforgiving forms, and loss of data can quickly make depressed users give up altogether. Minor annoyances such as these can slide through the design-and-build process for our sites and apps, and impact depressed users much more than neurotypical ones.

If content requires significant effort to locate, it will also be ignored by depressed users. Large blocks of endless content, like wall-to-wall tiles, force users to sift through it to find what they’re looking for. Long videos without accompanying text (that is searchable) can similarly be a deterrent. Assuming that users are so in love with your content that they will read or view every bit of it is naïve and creates a significant barrier for depressed users (and can also hinder users with inattention).

Chat can be a lifesaver

I get severely depressed three to six months out of the year, and talking to people is one of the hardest things I have to do. The effort required to carry on an actual conversation is immense, and it prevents me from doing a lot of things that I would ordinarily be doing. Add to that stress the stress of a botched order or customer service fiasco, and I sometimes get so stressed out, I can’t make phone calls that I need to. In these situations, any place that lets me contact them via chat instead of a phone call gains my eternal gratitude.

A great example of this is the National Suicide Prevention Hotline (because if anyone knows how to design for depressed users, it’s this group), who opened their online chat in 2013. By 2015, the chat lines were open 24 hours a day. Chat lines are unfortunately frequently clogged, partly due to the influx of users and partly due to a lack of funding, but the number of chat operators is growing each year. Chat lines attract a different demographic: while the phone line is roughly a 50-50 split between male and female, the chat line is 78–80% female (70% of the total were women under 25).

The article linked to in the paragraph above revealed some other interesting stats. The National Suicide Prevention Hotline is not the only crisis center that has caught onto this. The National Domestic Violence Hotline launched chat in 2013 and now receives 1,000–1,500 chats a month. The Rape, Abuse & Incest National Network (RAINN) has implemented a chat on their site, and they’ve found that chat users typically go into more depth about their traumatic issues than callers. And, like the National Suicide Prevention Hotline, both of these organizations are looking to scale up their chat services due to how popular they are.

Businesses that regularly work with users in crisis have realized that chat is a vital tool for their users and are rapidly expanding their chat services to accommodate. Your business may not exclusively deal with crisis users, but with depression affecting a significant portion of the population, any day can be a crisis day for these users. If you have a phone line but not a chat, consider adding one. If you have a chat line and it’s constantly clogged, consider expanding the service.

Disability takes many forms, as should inclusive solutions

Far from being just about impaired vision and wheelchairs, disability takes many forms, and accessibility and inclusive design need to take just as many. In our industry, compassionate discussion around physical disabilities has been a huge benefit, and cognitive differences need to be part of the conversation too. Removing unnecessary distractions, reassuring users that they’re doing the right thing, and keeping things easy for users who are struggling are things we can do to accommodate these users and make them feel like you actually want them to use our sites and apps. As one of these users myself, I can say we would really appreciate your efforts. This can be just as important as including alt text for your images.

About the author

Brandon Gregory is a designer and developer in the Kansas City area, currently working at Sprint as a senior application developer. He’s into cats, music, psychology, writing, and cats. He writes about mental health and other things on Medium and reviews classic films. Also, he’s in a band. One time, he rocked so hard it killed a man.

Illustration by Dougal MacPherson.

For more information every web designer and front-end developer needs, read A List Apart “for people who make websites.”

“The Last Ten Percent” by Cassie McDaniel – An Event Apart video Tue, 06 Nov 2018 13:40:00 -0800 Eric Meyer You’ve been grinding for weeks. You’ve done your due diligence and tested designs with users and colleagues. You’ve spoken to the client, they’re convinced you’re amazing. Everything looks great in every browser, on every popular device. You think you’re done. But you’re not done, you’re just getting started.

In this free 60-minute video, captured live at An Event Apart: Denver Special Edition, Jane & Jury founder Cassie McDaniel talks about what happens after your work goes out into the wild and people start using it. Discover how to use iterative design strategies to increase your work’s impact and ultimately make you more effective at what you do.

Cassie McDaniel runs a small, ambitious, friendly design studio with her husband called Jane & Jury. As previous Design Director at the Mozilla Foundation, she led a team of designers on the organization’s advocacy and digital literacy fronts. She founded the interview series Women&&Tech and runs a creative event and workshop series called Paris Lectures. She grew up in Florida, jumped around in England, and is now based an hour outside Toronto in rural Ontario, where she is deeply invested in the roots she puts down into her community both locally and online. Her design articles have been published in A List Apart, Smashing Magazine, Distance, Offscreen Magazine, and others.

Enjoy all the videos in An Event Apart’s library. There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers: And for your free monthly guide to all things web, design, and developer-y, subscribe to the AEA Digest.

]]> “Measuring the Customer Experience” by Gerry McGovern – An Event Apart video Tue, 30 Oct 2018 13:23:00 -0700 Eric Meyer The best way to understand digital user experience is to measure the time and effort required to complete top tasks. That’s why the most successful digital brands, from Amazon to Google, are relentless in their focus on saving their customers time. To succeed as these companies do, we must discard our organization-centric model of production, and accurately measure task completion and time-on-task.

In this free 60-minute video, captured live at An Event Apart: Denver Special Edition, Customer Carewords CEO Gerry McGovern shares a robust method for accurately measuring the time it takes your customers to complete their top tasks. You will learn a set of management metrics covering the ability of the customer to do what they came to do, how long it took them, what the problems are, and what needs to be done to make things better. Armed with this knowledge, you’ll be ready to continually improve the customer experience to faster and more accurately satisfy your users' fondest desires.

Gerry McGovern helps large organizations become more customer-centric on the web. His clients include Microsoft, Cisco, Google, VMware, IBM, Atlas Copco and Tetra Pak. He has consulted with the European Commission, the US, UK, Canadian, Norwegian and Irish governments. Gerry has written five books on how the web has facilitated the rise of customer power. He has appeared on BBC, CNN and CNBC television, partaken in various radio shows, and featured in numerous print media publications. The Irish Times described him as one of five visionaries who have had a major impact on the development of the web.

Enjoy all the videos in An Event Apart’s library. There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers: And for your free monthly guide to all things web, design, and developer-y, subscribe to the AEA Digest.

Conversational Semantics Fri, 26 Oct 2018 11:10:00 -0700 Eric Meyer By Aaron Gustafson

Each month, A List Apart’s editors select an article An Event Apart attendees shouldn’t miss, and we share it here. Enjoy this month’s essential reading!—Ed.

As Alexa, Cortana, Siri, and even customer support chat bots become the norm, we have to start carefully considering not only how our content looks but how it could sound. We can—and should—use HTML and ARIA to make our content structured, sensible, and most importantly, meaningful.

Content, confined

Most bots and digital assistants work from specially-coded data sets, APIs, and models, but there are more than 4.5 billion pages of content on the web, trapped, in many cases, within our websites. Articles, stories, blog posts, educational materials, books, and marketing messages—all on the web, but in many cases unusable in a non-visual context. A few projects—search spiders most notably—are working to turn our messy, unstructured web pages into something usable. But we can do more—a lot more—to facilitate that and enable our web pages to be more usable by both real people and the computers that power voice-based user experiences.

Let’s release our content from the screen and empower it to go anywhere and everywhere. We can help it find its way into virtual assistants and other voice-response technologies—and even voiceless chat bots—without having to code and re-code that content over and over into multiple, redundant formats. We can even enable our users to actively engage with our content by filling in forms and manipulating widgets on the web purely via voice. It’s all possible, but we need to start by taking a long, hard look at our markup.

Consider this em element:

I’m <em>really</em> happy to see you.

Sure, it is visually rendered as italics, but it also adds emphasis to the content within. HTML is chock full of elements that are useful for conveying meaning, nuance, and relationships. Being aware of them enables us to author more expressive documents. Ignoring them can undermine the usability of the content we’re marking up. When we create a web page, we need to be mindful of the conversation we are creating with our customers in the process, and choose elements with intent and care.

One of the best indicators for how HTML will make it into our virtual assistants is another assistive technology: screen readers. Not only do screen readers do as their name implies, they also enable users to rapidly navigate a page in various ways, and provide mechanisms that translate visual design constructs—proximity, proportion, etc.—into useful information. At least they do when documents are authored thoughtfully.

So, let’s jump in and look at some solid examples of how we can both create more meaningful documents and empower them to be more usable in “headless” UIs.

Powerful phrases

We’ll start by looking at what are called “phrasing” elements. The emphasis you saw earlier is an example of this element type. We used to call them “inline” elements because, by default, they are visibly displayed as inline text. But “phrasing” is a much more accurate description of the role they play in our web pages, because, well, they mark up phrases.

We saw this example earlier:

I’m <em>really</em> happy to see you.

Here, the word “really” is marked for emphasis. I’m unaware of any current speech synthesizer that audibly emphasizes text like we do, but it’s still early days in the grand scheme of things. I’m sure it’ll happen—there’s been a lot of focus on building more human-sounding voices—and it could sound something like this:

Mimicking Emphasis using speechSynthesis

Sometimes emphasis is not enough. When we want to indicate that content is vital for our customers to pay attention to, the strong element is the right way to go. “Strong” means “of strong importance.”

Please fill out the form below to contact us. <strong>All fields are required.</strong>

Visually, em and strong are displayed as italics (as mentioned previously) and bold, respectively.

I’m really happy to see you.

Please fill out the form below to contact us. All fields are required.

Now we also have the i and b elements, which are rendered exactly the same as em and strong, respectively. In the early days of the web, that led many of us—myself included—to believe they were interchangeable. And with b and i being shorter to write, they proliferated on the web. Semantically, however, the i and b elements are quite different from their doppelgängers.

The i element is similar to the emphasis element, but more generic. It is used to indicate an alternate voice or mood. It could be used to indicate sarcasm, idiomatic remarks, and shifts in language.

It's a terrible movie and it made $200 million. <i>Go figure!</i>

She is admired for her energy and <i lang="fr">joie de vivre</i>.

In the latter example, you might also notice that I’ve indicated that the phrase “joie de vivre” is in another language—French—using the lang attribute. This attribute lets the digital assistant know it may want to shift its pronunciation.

Supporting Language Shifts in speechSynthesis

Admittedly, replicating this using the speechSynthesis API is still a little rough, but with time, this too will no doubt improve.

The b element is used for content that should be set apart—or “stylistically offset”—from the surrounding text. It does not indicate that the phrase is of any greater importance though. I like to use it for names of people and products. Keywords would be another option. Books, films, and other media have their own element, which I’ll get to in a moment.

For 12 years and running, over 100,000 companies have adopted the <b>Basecamp</b> way of working. Not just tried, but signed up, said “ah-ha!”, and never looked back. There’s nothing else like <b>Basecamp</b>.

Functionally, the b element is a lot like a span—generic phrasing content albeit with a shorter tag.

Since I mentioned movies and books, I’ll quickly bring up the cite element, which is for the title of cited or referenced works.

I wrote the book <cite>Adaptive Web Design</cite>. If you like this article, you’ll find in-depth information about semantics (and a whole lot more) in there.

Specialized syntax

HTML has other specialized phrasing constructs, such as abbr for abbreviations and acronyms. Traditionally, we’d recommended using title to provide an expansion:

<abbr title="Hypertext Markup Language">HTML</abbr> is the standard markup language for creating web pages and web applications.

Sadly—as with many things on the web—black hat SEO practices involving title spurred screen readers to ignore the attribute altogether. Visual browsers do still provide tooltips, so they’re not completely useless, but given that screen readers don’t pay attention to the title attribute currently, it’s pretty unlikely they will be surfaced by a virtual assistant.

To be honest, it’s best to avoid title altogether. For the purposes of absolute clarity, you should introduce and explain important abbreviations and acronyms the first time they are used. There’s even an element that signals a defining context: dfn.

<dfn id="dfn-html">Hypertext Markup Language (HTML)</dfn> is the standard markup language for creating web pages and web applications.

For more technical writing, the kbd and code elements can be quite useful. They indicate keys a user might need to press and words and phrases that are used in writing software or coding documents:

Press <kbd>Tab</kbd> to move from link to link within a document.

The <code>kbd</code> element is used to indicate keyboard key names.

Then there’s the span element, which is used for generic phrases, as I noted earlier. It’s a meaningless element, so will not be spoken in any way differently by default.

There is <span>nothing particularly interesting</span> in this sentence.

There are more phrasing elements, but these are the ones you’re most likely to want in most projects.

Clear connections

Links are also phrasing elements, but I want to call them out specifically because they provide a much richer set of options for fine-tuning how our users interact with our pages.

The primary way we use links is to connect related content. It’s incredibly important to choose meaningful words and phrases as link text. Links that read generically like “click here” and “read more” are not terribly useful, especially when the text of every link is being read out to you—which is a key way headless UI users skim web pages. Make it clear where you are linking. Restructure sentences if you need to in order to provide good link text.

If you are drawn to “read more” style links for their brevity, you can have your cake and eat it too by including non-visible text within a link. This gives you brief, uniform links from a visual standpoint, but also lets you provide context in headless scenarios. Here’s an example from my site’s navigation. I’ve broken it up across a few lines to make it a little easier to follow:

<a href="/speaking-engagements/">
	<b class="hidden">A List of My</b>
	<b class="hidden">Engagements</b>

Within the link, I have two b elements classified as “hidden.” In my CSS, I hide the content within them from sighted users, but I hide them in a way that they remain available to assistive technology. So a sighted user will only see “speaking,” but a screen reader or digital assistant will read “a list of my speaking engagements.”

You could also offer an expansion with aria-label on the anchor element. If that “aria-” bit in aria-label looks weird to you, it comes from the Accessible Rich Internet Applications (ARIA) spec, an ongoing effort to map complex operating-system-like UI constructs into accessible ones. I chose the hidden text route to give myself the flexibility to display the hidden content in certain scenarios.

Some of you may be wondering why I didn’t bring up aria-label when I mentioned the abbr element. It seems like a good fit, and the aria-label spec currently allows the attribute on abbr elements. The issue isn’t the spec, but rather the reality that the info in aria-label isn’t always exposed by browsers or sought out by assistive technology on elements like abbr. With good reason, they’ve been much more focused on exposing aria-label (and it’s kin) on interactive elements, landmarks, and widgets.

It’s worth noting that hidden text in links can cause issues for folks who rely on a combination of screens and dictation software to interact with their computers. If the link text that’s displayed does not match the actual link text in the markup, a user saying the visible link text—like the word “Speaking” in the case of my site’s navigation—won’t actually activate the link. It’s also worth reiterating the importance of quality link text; don’t use aria-label to paper over poorly-worded links or unnecessary redundancy like “read more.”

We can also use links to reference content within the current document or even at a specifically-identified position in another document:

To illustrate the concept of layering styles, perhaps it’s best to start at the beginning: with no style applied. <a href="#figure-3-3">Figure 3.3</a> shows the lodging article in Safari with only the default browser styles applied.
<figure id="figure-3-3">

At the tail end of this code sample, we have a figure element that is referenced elsewhere in the document. Rather than leaving it up to the reader to find “Figure 3.3,” we can use a fragment identifier to jump the reader directly to the reference. Adding a unique id attribute to each important element in your design makes it easy for you—or others—to link directly to them.

As with the i element example I shared earlier, you can inform your readers about the language of a linked page using hreflang:

<a href="…" hreflang="es"><i lang="es">
	<b class="hidden">Lea esta página en</b> español

That’s Spanish for “read this page in Spanish,” and the link points to a Spanish-language translation of the page. The hidden content approach is in use here, too, with sighted users only seeing “español.”

You can indicate the kind of content being linked to, using the type attribute:

<a href="giant.mp4" type="video/mp4">Download this movie</a>

And we also have the download keyword, which informs the browser that the file in question should be downloaded rather than presented. Again, a simple attribute that makes a simple HTML document capable of doing so much more:

<a href="giant.mp4" type="video/mp4" download>Download this movie</a>

When encountering this type of link in a voice context, your digital assistant could prompt you to save the file to a connected storage account, like Dropbox. That’s pretty cool, but it’s worth noting that browsers will ignore the download attribute on cross-origin links for security purposes. Unfortunately that means you can’t use this approach to download files from your Content Delivery Network (CDN).

Anchor elements also support non-web “pseudo” protocols. Two of the most common examples are “mailto:” for email links and “tel:” for phone numbers, but “sms:” and “webcal:” are also common.

<a href="">Send me an email</a>

<a href="tel:18009346489">Call Comcast Customer Service</a>

Some operating systems (and browsers) allow installed apps to register custom protocols that can provide access to in-app functionality. A word of caution though: unrecognized protocols may prompt the user to search for an application that can use it.

All of this phrasing content is great, but I’ve spent a good deal of time in the weeds. Let’s pull back a bit and look at documents themselves.

Sound structure

As you’re no doubt aware, headless UIs place a greater cognitive load on our users. It’s hard to keep track of where you are in an interface when you can’t see it. It can also be challenging to move around when you can’t gather information about the interface based on visual cues. The more complex an interface is, the more challenging this becomes.

The same is true in visual interfaces, which is why “mobile first” thinking encourages us to focus each page on a single task. This reduces the noise and raises the signal. But most web pages are the antithesis of clear and straightforward. As our screen sizes enlarged, we found more stuff to fill that space. Sharing links, related content, cross-promotions, and so on. Sometimes it’s easy to lose sight of the actual content.

To combat this, screen readers provide numerous mechanisms that enable users to gather information about the UI and move through it efficiently. One of the most common involves moving the focus carat from one interactive element to another. Traditionally that movement is done via the keyboard Tab key, but it’s also possible via voice using keywords like “next” and “previous.” In most documents, users are moving from link to link. This is why it’s so important to offer informative link text.

<p>This twist is what <a href="">John Harsanyi</a>—an early game theorist—refers to as the “<a href="">Veil of Ignorance</a>,” and what Rawls found, time and time again, was that individuals participating in the experiment would gravitate toward creating the most egalitarian societies.</p>

It’s worth noting that form elements—buttons, inputs, etc.—are also part of the default tab order of a web page.

Elements that would not traditionally be focusable can be included in the tab order by adding a tabindex attribute with a value of “0” (zero) to them. This ensures critical interface components are not accidentally bypassed by users who are skimming an interface by tabbing. Incidentally, it can also give sighted users keyboard control over scrollable elements.

Another mode of document traversal is browsing by heading. The various heading levels in HTML create a natural document outline, and assistive technologies can enable users to skim content using these headings:

<h1>This is the title of the page</h1>
<h2>This titles a section</h2>
<h3>This titles a subsection</h3>

Since only the contents of the heading elements are read out in this mode, it’s best to avoid cutesy marketing phrases, and stick to summarizing the contents of a section.

More recently, document “landmarks” have come along, providing quick access to key parts of the page. Landmark elements were first introduced as part of ARIA. Using the role attribute, you can define the function of specific regions of a page. Consider the following:

<div id="nav">
			<a href="/about/"><b class="hidden">A Bit </b>About<b class="hidden"> Me</b></a>

In this example, the navigation list is sitting in a div with an id of “nav.” While that’s a meaningful identifier for the purposes of styling, scripting, and anchoring, the div is not actually exposed to assistive technology as navigation. Adding a role of “navigation”, however, makes that function explicit:

<div id="nav" role="navigation">
			<a href="/about/"><b class="hidden">A Bit </b>About<b class="hidden"> Me</b></a>

There are numerous role values that qualify as landmarks:

  • banner
  • navigation
  • search
  • main
  • complementary
  • contentinfo

Landmarks also give users the opportunity to jump directly to a location within an interface, which is incredibly helpful. In a voice context, a user might be able to ask their digital assistant to “read me the navigation for this page” or “search for wooden baby toys,” and the assistant could use these landmarks to quickly respond to those commands.

It’s worth noting that most of these landmarks have equivalent HTML elements. This is because HTML5 and ARIA were being developed at the same time, and both were looking to address the same limitations of the web. Here’s a rundown of ARIA landmark roles with HTML equivalents:

Each HTML5 element shown here is automatically assigned its corresponding ARIA role by modern browsers and is recognized by modern assistive technologies. However, in older browser and assistive technology combinations, the automatic role assignment may not happen. That’s why it’s not uncommon to see nav elements with a “navigation” role or similar even though validators will flag it as unnecessary.

One last bit I want to touch on before I wrap up is the div element.

	This is simply a generic division of content.

We often employ a div when we want to group some elements together. That’s fine, but div is a meaningless element that adds nothing to the interface in terms of context. By contrast, other organizational elements do add value to a page:

  • p - a paragraph; a voice synthesizer will naturally pause between them
  • ol - a list of items whose order matters
  • ul - a list of items whose order doesn’t matter
  • li - an item in a list
  • dl - a list of terms and their associated descriptions
  • dt - a term described within a description list
  • dd - a description of a term (or terms) in a description list
  • blockquote - a long piece of quoted content
  • figure - referenced content (images, tables, etc.)
  • figcaption - the caption for a figure

Some of these are among the elements categorized as “flow” content. At a higher level, there are numerous organizational elements to choose from:

  • article - a piece of content that can stand on its own
  • section - a section of a document or article
  • header - preamble content for a document, article, or section
  • footer - supplementary information for a document, article, or section
  • main - the primary content of a document
  • nav - navigational content
  • aside - complementary content

There are a ton of meaningful elements out there that can enable our digital assistants to do more for our customers. And the more we use them, the more useful our assistants become, and the more powerful our users feel. For instance, using article and heading elements can enable voice commands like “Read me the top three headlines in the New York Times today” without involving any sort of specialized data feed.

A generic div gets you none of these benefits.

Create conversations

HTML is a truly robust and expressive language that is often overlooked and undervalued, but it has the incredible potential to nurture conversations with our users without requiring a lot of effort on our part. Simply taking the time to code web pages well will enable our sites to speak to our customers like they speak to each other. Thinking about how our sites are experienced as headless interfaces now will set the stage for more natural interactions between the real world and the digital one.

About the author

As would be expected from a former manager of The Web Standards Project, Aaron Gustafson is passionate about web standards and accessibility. He has been working on the web for two decades and currently reps the web at Microsoft, where he works closely with the Edge team. He is Editor-in-Chief at A List Apart. and writes about whatever’s on his mind at

For more information every web designer and front-end developer needs, read A List Apart “for people who make websites.”

“From Research to Redesign” by Jeffrey Zeldman—An Event Apart video Tue, 23 Oct 2018 12:45:00 -0700 Eric Meyer Meaningful redesigns start with research. From competitive surveys to making sense of analytics, and from stakeholder interviews to customer research, every fact we uncover is another step in the direction of a design that solves real problems. In this hour-long presentation captured live at An Event Apart Denver, An Event Apart co-founder Jeffrey Zeldman shows how, the more you learn about your product’s business strategy and its customer’s needs and desires, the better your designs will work.

Dubbed “King of Web Standards” by Business Week, Jeffrey Zeldman (@zeldman) founded and publishes A List Apart “for people who make websites,” co-founded publishing house A Book Apart, and leads studio.zeldman, a design consultancy in New York. Jeffrey teaches interaction design at New York’s School of Visual Arts and has written two books, notably the foundational web standards text Designing With Web Standards, currently in a 3rd Edition translated into 15 languages.

Enjoy all the videos in An Event Apart’s library. There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart, three days of design, code, and content for web, UX, and interaction designers. Our 2019 schedule is now up! And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

“Story First: Crafting Products That Engage” by Donna Lichaw—An Event Apart video Tue, 16 Oct 2018 13:06:00 -0700 Eric Meyer While many of us seek out the newest and shiniest tools, methods, and processes to build more successful products and services, we often overlook one of the oldest, leanest, most effective tools out there: the structurally sound story. In the moment, we humans experience everything as if it were a story. The better the story, the more likely we are to want to use a product, continue to use it, pay to use it, and recommend it to others.

In this presentation captured live at An Event Apart Denver, Donna Lichaw (@dlichaw) brilliantly explains how taking a story-first approach to product design and development helps you build more successful websites, apps, campaigns, and services that excite your customers, draw them in, incite them to action, and keep them engaged over time.

Donna is a certified professional coach, speaker, and author. She has spent 20 years at the forefront of technology helping leaders at places like Google, Apple, Logitech, Capital One, Central Park Conservancy, and WNYC develop successful products and services and now uses that same passion and approach to develop successful people—one story at a time. You can learn more about her process in her book, The User’s Journey: Storymapping Products That People Love.

Enjoy all the videos here in An Event Apart’s library. There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

“Design for Real Life” by Eric Meyer—An Event Apart Denver 2017 Tue, 09 Oct 2018 13:05:00 -0700 Eric Meyer We constantly stress-test our work by subjecting it to a wide variety of devices, by simulating different connection speeds, and by testing it under extreme server load scenarios. But have you ever stress-tested your work for unexamined assumptions, emotional minefields, or usability in situations of extreme distraction?

In this free 60-minute video, captured live at An Event Apart Denver: Special Edition 2017, world-renowned author and consultant Eric Meyer uses real-world examples and interactive exercises showing how to QA your work for real life, enabling it to serve more people, more of the time.

Eric A. Meyer is an internationally recognized expert on the subjects of HTML, CSS, and web standards, and the author of Design For Real Life (A Book Apart), Cascading Style Sheets: The Definitive Guide (O’Reilly & Associates), Smashing CSS (Wiley), Eric Meyer on CSS and More Eric Meyer on CSS (New Riders), CSS2.0 Programmer’s Reference (Osborne/McGraw-Hill), and CSS Web Site Design (Peachpit), as well as numerous articles for A List Apart, Net Magazine, Netscape DevEdge, UX Booth, UX Matters, the O’Reilly Network, Web Techniques, and Web Review.

Enjoy all the videos in An Event Apart’s library. There are over 30 hours of them—all absolutely free! For more insightful presentations by the industry’s best and brightest, come to An Event Apart—three days of design, code, and content for web, UX, and interaction designers. And for your free monthly guide to all things web, design, and developer-y, subscribe to The AEA Digest.

Articles, Links, and Tools From An Event Apart Orlando 2018 Sat, 06 Oct 2018 17:00:00 -0700 Eric Meyer Jeffrey Zeldman

Sarah Parmenter

Rachel Andrew

Eric Meyer

Jen Simmons

Una Kravets

Design Systems



Dan Mall

Kristina Halvorson

Jason Pamental

Fonts In Use

Trent Walton

Aarron Walter

Josh Clark

More on this topic from Josh


Example applications

Robot designers: AI for design and code

Machine learning APIs and data sets

Customize or construct your own model

Open-source data sets

Designing for speech interfaces

Mental models and opaque logic

Surveillance capitalism

Designing to counter misinformation, error and bias

Manner and language as cues for confidence and interaction

Machine ethics