web.dev

All of Learn Accessibility! is available

2023-01-12T00:00:00Z

All modules in the Learn Accessibility course are now available. Written by Carie Fisher, these courses take you through the essentials for building accessible websites and web apps.

You can read them in whatever order you'd like. The final modules on testing walk you through a culmination of all of your knowledge:

The last new module will teach you how to make your forms more accessible. This is a great complement to Learn Forms.

And that's not all. We had four community spotlights with people working on accessibility:

Melanie Sumner told us about her journey into engineering, accessible design, Ember.js, and the importance of funding these efforts.
Olutimilehin Olushuyi told us about his move from the law to web development, building accessible communities, and creating accessible layouts.
Albert Kim told us about mental health awareness, building for invisible disabilities, the COGA Accessibility Community Group, and more practical wisdom.
Elisa Bandy told us about her work for Google's internal documentation, how to prioritize use cases, and building expertise.

We hope you'll discover some new best practices. These modules are meant to build your expertise, but some accessibility best practices differ, based on the disability you're addressing.

We remain open to your feedback. Open a GitHub issue and give as much information as you can so we can address your questions or concerns.

Our top Core Web Vitals recommendations for 2023

2023-01-10T00:00:00Z

Over the years, we at Google have made a lot of recommendations to web developers on how to improve performance.

While each of these recommendations, individually, may improve performance for many sites, the full set of recommendations is admittedly overwhelming and, realistically, there's no way any one person or site could follow all of them.

Unless web performance is your day job, it's probably not obvious which recommendations are going to have the largest positive impact on your site. For example, you might have read that implementing critical CSS can improve load performance, and you may have also heard that it's important to optimize your images. But, if you don't have time to work on both things, how would you decide which one to pick?

On the Chrome team, we've spent the last year trying to answer this question: what are the most important recommendations we can give to developers to help them improve performance for their users?

To adequately answer this question we have to consider not just the technical merits of any given recommendation, but also human and organizational factors that influence the likelihood that developers will actually be able to adopt these recommendations. In other words, some recommendations may be hugely impactful in theory, but in reality very few sites will have the time or resources to implement them. Similarly, some recommendations are critical, but most websites are already following these practices.

In short, we wanted our list of top web performance recommendations to focus on:

Recommendations we believe will have the largest real-world impact
Recommendations that are relevant and applicable to most sites
Recommendations that are realistic for most developers to implement

Over the past year we've spent a lot of time auditing the full set of performance recommendations we make, and assessing each of them (both qualitatively and quantitatively) against the above three criteria.

This post outlines our top recommendations to improve performance for each of the Core Web Vitals metrics. If you're new to web performance, or if you're trying to decide what will give you the biggest bang for your buck, we think these recommendations are the best place to start.

Largest Contentful Paint (LCP) #

Our first set of recommendations are for Largest Contentful Paint (LCP), which is a measure of load performance. Of the three Core Web Vitals metrics, LCP is the one that the largest number of sites struggle with—only about half of all sites on the web today meet the recommended threshold—so let's start there.

Ensure the LCP resource is discoverable from the HTML source #

According to the 2022 Web Almanac by HTTP Archive, 72% of mobile pages have an image as their LCP element, which means that for most sites to optimize their LCP, they'll need to ensure those images can load quickly.

What may not be obvious to many developers is that the time it takes to load an image is just one part of the challenge. Another critical part is the time before an image starts loading, and HTTP Archive data suggests that's actually where many sites get tripped up.

In fact, of the pages where the LCP element was an image, 39% of those images had source URLs that were not discoverable from the HTML document source. In other words, those URLs were not found in standard HTML attributes (such as <img src="..."> or <link rel="preload" href="...">), which would allow the browser to quickly discover them and start loading them right away.

If a page needs to wait for CSS or JavaScript files to be fully downloaded, parsed, and processed before the image can even start loading, it may already be too late.

As a general rule, if your LCP element is an image, the image's URL should always be discoverable from the HTML source. Some tips to make that possible are:

Load the image using an <img> element with the src or srcset attribute. Do not use non-standard attributes like data-src that require JavaScript in order to render, as that will always be slower. 9% of pages obscure their LCP image behind data-src.
Prefer server-side rendering (SSR) over client-side rendering (CSR), as SSR implies that the full page markup (including the image) is present in the HTML source. CSR solutions require JavaScript to run before the image can be discovered.
If your image needs to be referenced from an external CSS or JS file, you can still include it in the HTML source via a <link rel="preload"> tag. Note that images referenced by inline styles are not discoverable by the browser's preload scanner, so even though they're found in the HTML source, discovery of them might still be blocked on the loading of other resources, so preloading can help in these cases.

To help you understand if your LCP image has discoverability problems, Lighthouse will be releasing a new audit in version 10.0 (expected January 2023).

Ensuring the LCP resource is discoverable from the HTML source can lead to measurable improvements and it also unlocks additional opportunities to prioritize the resource, which is our next recommendation.

Ensure the LCP resource is prioritized #

Making sure the LCP resource can be discovered from the HTML source is a critical first step in ensuring the LCP resource can start loading early, but another important step is ensuring that the loading of that resource is prioritized and doesn't get queued behind a bunch of other, less important resources.

For example, even if your LCP image is present in the HTML source using a standard <img> tag, if your page includes a dozen <script> tags in the <head> of your document before that <img> tag, it may be a while before your image resource starts loading.

The easiest way to solve this problem is to provide a hint to the browser about what resources are the highest priority by setting the new fetchpriority="high" attribute on the <img> or <link> tag that loads your LCP image. This instructs the browser to load it earlier, rather than waiting for those scripts to complete.

According to the Web Almanac, only 0.03% of eligible pages are taking advantage of this new API, meaning there is plenty of opportunity for most sites on the web to improve LCP with very little work. While the fetchpriority attribute is currently only supported in Chromium-based browsers, this API is a progressive enhancement that other browsers just ignore, so we strongly recommend developers use it now.

For non-Chromium browsers, the only way to ensure the LCP resource is prioritized above other resources is to reference it earlier in the document. Using the example again of a site with lots of <script> tags in the <head> of the document, if you wanted to ensure your LCP resource was prioritized ahead of those script resources, you could add a <link rel="preload"> tag before any of those scripts, or you could move those scripts to below the <img> later in the <body>. While this works, it's less ergonomic than using fetchpriority, so we hope other browsers add support soon.

Another critical aspect of prioritizing the LCP resource is to ensure you don't do anything that causes it to be deprioritized, such as adding the loading="lazy" attribute. Today, 10% of pages actually set loading="lazy" on their LCP image. Beware of image optimization solutions that indiscriminately apply lazy-loading behavior to all images. If they provide a way to override that behavior, be sure to use it for the LCP image. If you're not sure which image will be the LCP, try using heuristics to pick a reasonable candidate.

Deferring non-critical resources is another way to effectively boost the relative priority of the LCP resource. For example, scripts that are not powering the user interface (like analytics scripts or social widgets) can be safely postponed until after the load event fires, which ensures they won't compete with other critical resources (such as the LCP resource) for network bandwidth.

To summarize, you should follow these best practices to ensure that the LCP resource is loaded early, and at high priority:

Add fetchpriority="high" to the <img> tag of your LCP image. If the LCP resource is loaded via a <link rel="preload"> tag, fear not because you can also set fetchpriority="high" on that!
Never set loading="lazy" on the <img> tag of your LCP image. Doing this will deprioritize your image and delay when it starts loading.
Defer non-critical resources when possible. Either by moving them to the end of your document, using native lazy-loading for images or iframes, or loading them asynchronously via JavaScript.

Use a CDN to optimize document and resource TTFB #

The previous two recommendations focused on making sure your LCP resource is discovered early and prioritized so it can start loading right away. The final piece to this puzzle is making sure the initial document response arrives as quickly as possible too.

The browser cannot start loading any subresources until it receives the first byte of the initial HTML document response, and the sooner that happens, the sooner everything else can start happening as well.

This time is known as Time to First Byte (TTFB), and the best way to reduce TTFB is to:

Serve your content as geographically close to your users as possible
Cache that content so recently-requested content can be served again quickly.

The best way to do both of these things is to use a CDN. CDNs distribute your resources to edge servers, which are spread across the globe, thus limiting the distance those resources have to travel over the wire to your users. CDNs also usually have fine-grained caching controls that can be customized and optimized for your site's needs.

Many developers are familiar with using a CDN to host static assets, but CDNs can serve and cache HTML documents as well, even those that are dynamically generated.

According to the Web Almanac, only 29% of HTML document requests were served from a CDN, which means there is significant opportunity for sites to claim additional savings.

Some tips for configuring your CDNs are:

Consider increasing how long content is cached for (for example, is it actually critical that content is always fresh? Or can it be a few minutes stale?).
Consider maybe even caching content indefinitely, and then purging the cache if/when you make an update.
Explore whether you can move dynamic logic currently running on your origin server to the edge (a feature of most modern CDNs).

In general, any time you can serve content directly from the edge (avoiding a trip to your origin server) it's a performance win. And even in cases where you do have to make the journey all the way back to your origin server, CDNs are generally optimized to do that much more quickly, so it's a win either way.

Cumulative Layout Shift (CLS) #

The next set of recommendations are for Cumulative Layout Shift (CLS), which is a measure of visual stability on web pages. While CLS has improved a lot on the web since 2020, about a quarter of websites still do not meet the recommended threshold, so there remains a big opportunity for many sites to improve their user experience.

Set explicit sizes on any content loaded from the page #

Layout shifts usually happen when existing content moves after other content finishes loading. Therefore, the primary way to mitigate this is to reserve any required space in advance as much as possible.

The most straightforward way to fix layout shifts caused by unsized images is to explicitly set width and height attributes (or equivalent CSS properties). However, according to HTTP Archive, 72% of pages have at least one unsized image. Without an explicit size, browsers will initially set a default height of 0px and may cause a noticeable layout shift when the image is finally loaded and the dimensions are discovered. This represents both a huge opportunity for the collective web—and that opportunity requires much less effort than some of the other recommendations suggested in this article.

It's also important to keep in mind that images are not the only contributors to CLS. Layout shifts may be caused by other content that typically loads in after the page is initially rendered, including third-party ads or embedded videos. The aspect-ratio property can help combat this. It's a relatively new CSS feature that allows developers to explicitly provide an aspect ratio to images as well as non-image elements. This will allow you to set a dynamic width (for example based on screen size), and have the browser automatically calculate the appropriate height, in much the same way as they do for images with dimensions.

Sometimes it's not possible to know the exact size of dynamic content since it is, by its very nature, dynamic. However, even if you don't know the exact size, you can still take steps to reduce the severity of layout shifts. Setting a sensible min-height is almost always better than allowing the browser to use the default height of 0px for an empty element. Using a min-height is also usually an easy fix as it still allows the container to grow to the final content height if needed—it has just reduced that amount of growth from the full amount to a hopefully more tolerable level.

Ensure pages are eligible for bfcache #

Browsers use a navigation mechanism called the back/forward cache—or bfcache for short—to instantly load a page from earlier or later in the browser history directly from a memory snapshot.

The bfcache is a significant browser-level performance optimization, and it entirely eliminates the layout shifts during page load, which for many sites is where most of their CLS occurs. The introduction of the bfcache caused the biggest improvement in CLS that we saw in 2022.

Despite this, a significant number of websites are ineligible for the bfcache and so are missing out on this free web performance win for a significant number of navigations. Unless your page is loading sensitive information that you don't want to be restored from memory, you'll want to make sure that your pages are eligible.

Site owners should check that their pages are eligible for the bfcache and work on any reasons why they are not. Chrome already has a bfcache tester in DevTools and this year we plan to enhance tooling here with a new Lighthouse audit performing a similar test and an API to measure this in the field.

While we have included the bfcache in the CLS section, as we saw the biggest gains there so far, the bfcache will generally also improve other Core Web Vitals too. It is one of a number of instant navigations available to drastically improve page navigations.

Avoid animations/transitions that use layout-inducing CSS properties #

Another common source of layout shifts is when elements are animated. For example, cookie banners or other notification banners that slide in from the top or bottom are often a contributor to CLS. This is particularly problematic when these banners push other content out of the way, but even when they don't, animating them can still impact CLS.

While HTTP Archive data can't conclusively connect animations to layout shifts, the data does show that pages that animate any CSS property that could affect layout are 15% less likely to have "good" CLS than pages overall. Some properties are associated with worse CLS than others. For instance, pages that animate margin or border widths have "poor" CLS at almost twice the rate that pages overall are assessed as poor.

This is perhaps not surprising, because any time you transition or animate any layout-inducing CSS property, it will result in layout shifts, and if those layout shifts are not within 500 milliseconds of a user interaction, they will impact CLS.

What may be surprising to some developers is that this is true even in cases where the element is taken outside of the normal document flow. For example, absolutely positioned elements that animate top or left will cause layout shifts, even if they aren't pushing other content around. However, if instead of animating top or left you animate transform:translateX() or transform:translateY(), it won't cause the browser to update page layout and thus won't produce any layout shifts.

Preferring animation of CSS properties that can be updated on the browser's compositor thread has long been a performance best practice because it moves that work onto the GPU and off the main thread. And in addition to it being a general performance best practice, it can also help improve CLS.

As a general rule, never animate or transition any CSS property that requires the browser to update the page layout, unless you're doing it in response to a user tap or key press (though not hover). And whenever possible, prefer transitions and animations using the CSS transform property.

The Lighthouse audit Avoid non-composited animations will warn when a page animates potentially slow CSS properties.

First Input Delay (FID) #

Our last set of recommendations are for First Input Delay (FID), which is a measure of a page's responsiveness to user interactions. While most sites on the web currently score very well on FID, we've documented shortcomings of the FID metric in the past, and we believe there is still a lot of opportunity for sites to improve their overall responsiveness to user interactions.

Our new Interaction to Next Paint (INP) metric is a possible successor to FID, and all of the recommendations below apply equally well to both FID and INP. Given that sites perform worse on INP than FID, especially on mobile, we encourage developers to seriously consider these responsiveness recommendations, despite having "good" FID.

Avoid or break up long tasks #

Tasks are any piece of discrete work that the browser does. Tasks include rendering, layout, parsing, and compiling and executing scripts. When tasks become long tasks—that is, 50 milliseconds or longer—they block the main thread from being able to respond quickly to user inputs.

Per the Web Almanac, there's plenty of evidence to suggest that developers could be doing more to avoid or break up long tasks. While breaking up long tasks may not be as low of an effort as other recommendations in this article, it's less effort than other techniques not offered in this article.

While you should always strive to do as little work as possible in JavaScript, you can help the main thread quite a bit by breaking up long tasks into smaller ones. You can accomplish this by yielding to the main thread often so that rendering updates and other user interactions can occur more quickly.

Another option is to consider using APIs such as isInputPending and the Scheduler API. isInputPending is a function that returns a boolean value that indicates whether a user input is pending. If it returns true, you can yield to the main thread so it can handle the pending user input.

The Scheduler API is a more advanced approach, which allows you to schedule work based on a system of priorities that take into account whether the work being done is user-visible or backgrounded.

By breaking up long tasks, you're giving the browser more opportunities to fit in critical user-visible work, such as dealing with interactions and any resulting rendering updates.

Avoid unnecessary JavaScript #

There's no doubt about it: websites are shipping more JavaScript than ever before, and the trend doesn't look like it's changing any time soon. When you ship too much JavaScript, you're creating an environment where tasks are competing for the main thread's attention. This can definitely affect your website's responsiveness, especially during that crucial startup period.

This is not an unsolvable problem, however. You do have some options:

Use the coverage tool in Chrome DevTools to find unused code in your website's resources. By reducing the size of the resources you need during startup, you can ensure your website spends less time parsing and compiling code, which leads to a smoother initial user experience.
Sometimes the unused code you find using the coverage tool is marked "unused" because it wasn't executed during startup, but is still necessary for some functionality in the future. This is code that you can move to a separate bundle via code splitting.
If you're using a tag manager, be sure to periodically check your tags to make sure they are optimized, or even if they're still being used. Older tags with unused code can be cleared out to make your tag manager's JavaScript smaller and more efficient.

Avoid large rendering updates #

JavaScript isn't the only thing that can affect your website's responsiveness. Rendering can be a type of expensive work in its own right—and when large rendering updates happen, they can interfere with your website's ability to respond to user inputs.

Optimizing rendering work isn't a straightforward process, and it often depends on what you're trying to achieve. Even so, there are some things you can do to ensure that your rendering updates are reasonable, and don't sprawl into long tasks:

Avoid using requestAnimationFrame() for doing any non-visual work. requestAnimationFrame() calls are handled during the rendering phase of the event loop, and when too much work is done during this step, rendering updates can be delayed. It's essential that any work you're doing with requestAnimationFrame() is reserved strictly for tasks that involve rendering updates.
Keep your DOM size small. DOM size and the intensity of layout work are correlated. When the renderer has to update the layout for a very large DOM, the work required to recalculate its layout can increase significantly.
Use CSS containment. CSS containment relies on the CSS contain property, which gives instructions to the browser about how to do layout work for the container the contain property is set on, including even isolating the scope of layout and rendering to a specific root in the DOM. It's not always an easy process, but by isolating areas containing complex layouts, you can avoid doing layout and rendering work for them that isn't necessary.

Conclusion #

Improving page performance can seem like a daunting task, especially given that there is a mountain of guidance across the web to consider. By focusing on these recommendations, however, you can approach the problem with focus and purpose, and hopefully move the needle for your website's Core Web Vitals.

While the recommendations listed here are by no means exhaustive, we do believe—based on careful analysis of the state of the web—that these recommendations are the most effective ways that sites can improve their Core Web Vitals performance in 2023.

If you'd like to go beyond the recommendations listed here, check out these optimization guides for more information:

Here's to a new year, and a faster web for all! May your sites be fast for your users in all the ways that matter most.

Photo by Devin Avery

New to the web platform in December

2022-12-28T00:00:00Z

Stable browser releases #

In December, Firefox 108, and Safari 16.2 became stable. Let's take a look at what this means for the web platform.

Support for `height` and `width` attributes of `<source>` #

Firefox 108 supports height and width attributes for the <source> element, when it is a child of a <picture> element. These attributes accept the height or width of the image, in pixels, as an integer without a unit.

Trigonometric CSS functions #

Firefox also now supports trigonometric functions in CSS—sin(), cos(), tan(), asin(), acos(), atan(), and atan2().

Browser support: × 108 × 15.4 Source

Support for last baseline in all three engines #

In addition to a number of CSS fixes, Safari 16.2 includes last baseline alignment for CSS grid and flexbox layout, which means this feature now supported in the three main browser engines.

CSS `font-variant-alternates` #

Safari also adds support for additional values for the font-variant-alternates CSS property: annotation(value-name), character-variant(value-name), ornaments(value-name), styleset(value-name), stylistic(value-name), swash(value-name), along with the associated @font-feature-values at-rule.

Browser support: × 34 × 9.1 Source

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. New betas are Firefox 109, Safari 16.3, and Chrome 109.

The only new feature listed for Safari 16.3 is the addition of the Content-Security-Policy (CSP) prefetch-src directive. There are also a number of fixes in this beta.

Chrome 109 supports MathML Core, a language for describing mathematical notation embeddable in HTML and SVG.

New in Chrome on Android is Secure Payment Confirmation (SPC). This is a proposed web standard that allows customers to authenticate with a credit card issuer, bank, or other payment service provider using a platform authenticator—typically activated with a device's screen unlock feature such as a fingerprint sensor.

Also new for Chrome on Android is the Origin Private File System (OPFS), part of the File System Access API on Android. This includes all of the File System Access API surface, minus the show{OpenFile, SaveFile, Directory}Picker() methods and the Drag and Drop API integration.

For CSS in Chrome we have the lh length unit. This unit is equivalent to the computed value of the line-height property on the element on which it is used. Also, the hyphenate-limit-chars property specifying the minimum number of characters in a hyphenated word.

At the time of writing, and perhaps due to the holiday season, Firefox release notes haven't been updated.

Other news #

This post marks the 12th edition of this blog post series, bringing you a selection of interesting things landing in browsers each month in 2022. I'll be back in 2023 to continue sharing some of the interesting things landing on the web platform each month.

Many of the features landing in browsers over this past year, and lots of those things mentioned as "CSS fixes," were part of Interop 2022. For more information, read the Chrome team's end-of-year report on this cross-browser initiative to improve some of the top interoperability pain points on the web platform.

And finally, of interest to people who read this post, is this list of updates based on the MDN browser compatibility data, released by our friends over at MDN.

Photo by Patrick Hendry.

Interop 2022: end of year update

2022-12-19T00:00:00Z

We've reached the end of another year, and it's time to look at the improvements made by browsers as we work together to improve the interoperability of the web platform. You can check out how things started in our post in March this year, as the initiative was launched.

The scores for experimental browsers in March 2022.

The overall scores at the end of the year show a great improvement across all engines.

The scores for experimental browsers in December 2022.

In this post, learn about the progress made during 2022. In addition to these headline features, there were many smaller improvements made by all engines. Small issues that can cause inconsistencies between engines and trip you up during development, have been fixed. Seeing big features available cross-browser is definitely exciting, but it's sometimes the small things that cause the most problems, and it's great to see how much has been improved.

Cascade layers #

Cascade layers let you manage the cascade by grouping selectors into layers. It's the kind of feature that only becomes useful when it is supported everywhere. All major engines now support cascade layers, and the scores across all browsers reflect how interoperable the feature is, with just a few tests left to pass for Firefox.

Browser support: 99 97 99 15.4 Source

The dialog element #

The dialog element allows the creation of modal dialogs. This is a common pattern on the web, and using this element gives you usability and accessibility that you would otherwise have to develop and test when creating your own components. In the article Building a dialog component, Adam Argyle explains how to build on top of this element to build different types of dialogs.

Browser support: 37 98 79 15.4 Source

Subgrid #

At the beginning of 2022, the only browser supporting the subgrid value for grid-template-rows and grid-template-columns was Firefox. During 2022 Safari has landed support, and the feature is under development in Chrome. It's going to miss the end of year deadline for interoperability, but it's on the way.

Browser support: × 71 × 16 Source

Viewport units #

Viewport units are the only feature that has hit 100% of passing tests across all engines. This includes the concepts of the small and large viewport, that accounts for the changing viewport size on mobile as device UI elements appear and disappear. You can find out more about these units in the post the large, small, and dynamic viewport units.

Browser support: 108 101 108 15.4

Color 4 #

This collection of color work enables CSS to not only specify colors in higher definition gamuts (for example, display p3, rec2020), but also provides new color functions that each have unique utilities for working with color. New color spaces are lch(), oklch(), lab(), oklab(), display-p3, rec2020, a98-rgb, prophoto-rgb, xyz, xyz-d50, xzy-d65: try these in Canary today with this flag enabled. These changes also apply to gradients, allowing authors to specify which colorspace their gradients use. The same flag also enables color-mix() support, allowing you to mix two colors together in a space of your choice. The color-mix() function is also behind a flag in Safari and Firefox. More colors, better colors, better gradients, and better tools.

Interop 2023 #

I hope you'll be happy to know that we aren't intending to stop at the end of 2022, and Interop 2023 is already well through the initial planning stage. In the New Year we'll be able to announce the features that have been selected, and look forward to another year of making it easier to develop for the web.

Hero image by Ian Schneider.

Community highlight: Elisa Bandy

2022-12-13T00:00:00Z

This post highlights a community expert, as a part of Learn Accessibility! Learn more about Google's accessibility initiatives and research.

Alexandra White: I'm lucky to call you a colleague. How would you introduce yourself and your job here?

Elisa Bandy: My name is Elisa, and I write documentation for Google's internal tooling and infrastructure.

Alexandra: That's such cool job. How many people do you work with?

Elisa: Our broader team is about 40 people, and that includes technical writers, instructional designers, and program managers. When I started, six years ago, there were only four people on the team.

Alexandra: What were you up to before Google?

Elisa: During the week, I worked in video game development. And then on the weekends, I worked in shoe repair.

Alexandra: Did you start working in web accessibility once you got to Google?

Elisa: Yes, but not until about a year and a half into it, on the side. I work on accessibility engineering for Google's internal documentation. Before this work, the docs were not designed with accessibility in mind. Any doc feature that was accessible was a happy accident.

There were huge issues, starting with color contrast being entirely inappropriate for links. The tables were an absolute mess—if you zoomed in, everything stayed the same size because it was defined in pixels instead of rem. I volunteered to fix all of those things. And then, I just kept fixing more things. Here we are five years later, and I'm still at it.

Alexandra: You've built yourself to be a person with accessibility expertise and skills, and you've got the resolve to fix the problems that need to be fixed.

Elisa: Yeah, I guess we can say that [laughs]. As a disabled person myself, I know how difficult it is to ask for accessibility considerations. So the fact that we didn't have these accessibility considerations for my co-workers and my colleagues really angered me. And no one else was fixing them. So I went in and I fixed them.

I don't think anyone should have to ask for accessibility. It should be built in from the start.

Prioritize your accessibility use cases #

Alexandra: When you think about web accessibility, there are so many different layers to it, right? There are different, sometimes conflicting needs for various disabilities. How do you prioritize what should be done?

Elisa: A lot of what I do is prioritization. For example, how important is it that some specific use case be 100% totally accessible? I look at a lot of data: what percentage of our population is disabled? How many people have a specific accessibility issue?

For example, there's a subset of users who use ChromeVox, the built-in screen reader for Chromebooks. If something is an issue in ChromeVox, I have to take a look at how many people are using ChromeVox versus Jaws versus NVDA versus VoiceOver.

Externally, not a lot of people use ChromeVox. Because we're Google, a lot of people use Chromebooks as their primary work device, which means ChromeVox is very important for internal documentation. Maybe a ChromeVox bug gets bumped up a little higher than a VoiceOver bug or a NVDA bug.

Generally speaking, I try to fix things for the major screen readers first. Coloration tends to be sort of hit or miss because there's a bunch of extensions that circumnavigate coloration issues, especially for high contrast modes.

Alexandra: You mentioned data, which is incredibly important at Google (of course). We always hear, "Back up your idea with data." How do you collect data for accessibility at Google?

Elisa: I rely a lot on data that's been collected by Google's Disability Alliance. And I'll often cross-check with WebAIM's surveys.

Culture of accessibility #

Alexandra: Tell me about the culture of accessibility at Google.

Elisa: It's grown very, very rapidly into something which has funding and broad-reaching concern. And I have found that almost everyone wants to do the right thing. Our colleagues want educational resources on how to do the right thing, how to prioritize accessibility.

Restructuring an app or a website or anything to be accessible after you've already implemented it incorrectly is hard. So part of my job is getting our engineers to think about incorporating accessibility into the initial designs, before the products are built. People are very receptive to that, even enthusiastic about it!

I've only ever had real resistance to incorporating accessibility once, and even that was fairly easy to resolve.

Alexandra: Can you tell me more about that?

Elisa: When I first joined accessibility engineering, it was only 20% of my time. Some people didn't understand why we were focusing on accessibility. Someone said, "Only 1% of the population is disabled." I stood my ground—we needed to do it because it was the right thing to do. And, it was my time, I'll dedicate it how I see fit.

Of course, it's hard to hear from anyone that disabled people don't matter, that it's too small a group.

Alexandra: Especially when you are a member of that population. Know your audience!

Elisa: I never like to hear, "Oh, this is only 1%." The "only" makes it sound insignificant. But when you think about the global population, that's a lot of people. And that's a lot of people who work at Google. And so many disabilities are under-reported.

Alexandra: We know that far more than 1% of the population are affected by disabilities. WHO reports that over 1 billion people have a disability; and 2.2 billion people have some kind of vision impairment! There's varying severity, of course, and some people with visual impairments wouldn't consider themselves disabled. But these impairments do affect interaction on the web.

Elisa: Exactly.

Build your own set of expertise #

Alexandra: Is there any advice that you wish you had had before you started working in accessibility?

Elisa: It's ok not to know every single thing. Accessibility is a huge, wide expanse of space. I know that there's a lot of stuff that I don't know. I have a very specific set of skills. It just so happens that I know where to find information on what the accessibility best practices are.

Even within my own specialty, screen readers and color contrast, I'm learning new things every day. And I'm deaf, but I'm not an accessibility expert for Closed Captions. I know what works for me, but I don't know what works for everyone else. I'd have to look up best practices if asked.

Alexandra: It's reasonable not to be the absolute expert of every kind of accessibility. How would you help engineers learn accessibility patterns?

Elisa: I work closely with an engineer who's interested in accessibility. I'll hand her a bug and show her how I would fix it. Then, I walk her through the best practice. She may look at other docs and see they recommended one approach, but it doesn't work for XYZ reasons.

The thing about web accessibility is that there's not a lot of concrete code examples, because no two people build the same feature in the same way. So you might jury-rig solutions. Many people don't think about accessibility until everything's been put together. What are you going to do at that point? Are you going to tear it down and put it back together and rewrite all of your tests? No, you're not. You're going to staple something on.

That means you need to understand how a disabled user would expect the application to function, then model your code so it performs that function. It might not look like the perfect code samples or inclusive components, but ultimately, as long as it performs the same function reliably, it's going to be fine.

Alexandra: It sounds to me like you're saying it's more important to get a positive result than to worry too much about how we get there.

Elisa: Yes. Because honestly the ends do justify the means of this case. It's super important to understand how a screen reader user or any other disabled user would expect this to work.

There are a billion ARIA roles, and you cannot possibly know every single one. Further, some don't work with all screen readers! So you need to know the needs of your users to build for them.

Alexandra: Are there common external resources that you rely on when creating internal documentation or offering support to Google engineers?

Elisa: I do rely a lot on the W3C guidelines. They are very good for getting an idea of what you need to do. WebAIM is another extremely good resource that I find to be a little bit better with respect to technical implementation. I also really like the Mozilla docs—nine times out of ten, if I search for something, there's an answer in the MDN Web Docs.

I love inclusive-components.design, which is great if you want a library of accessible components.

Deque University has a lot of best practices. I use it for reference materials, when I'm filing bugs or teaching someone how to follow a specific pattern.

Experience accessibility tools first-hand #

Alexandra: How does one go about learning how a user is affected? Since your expertise is in supporting people who are colorblind and screen readers, let's start there.

Elisa: For color vision deficiency and colorblindness, there are simulators and emulators. You really can't understand how someone else can see until you see it for yourself. If I notice really bad saturation, as soon as I run it through the simulator, I can confirm that it isn't discernible at all.

To support screen reader users, there's no better way to understand it than to actually use a screen reader. Read tutorials first, that's key. Some people get frustrated when they just turn it on and try messing around with it—that's a bad way to learn how to use them. You need more than 5 or 10 or 20 minutes. Use it for an hour at minimum to reveal some of the frustrations users face who rely on this technology.

I'm a firm believer that everyone is going to need accessibility technology at some point in their life. For example, I recently hurt my wrist and couldn't use my mouse, so I used a keyboard for multiple weeks. It was so frustrating. These sorts of exercises can really help put you in the position of a disabled person trying to navigate a world of able-bodied people.

Simulators, while useful, are not equivalent to a disability #

Alexandra: Obviously the experience that I have, or any developer would have, using simulators is not the same as someone with a visual impairment.

Elisa: You can always talk to someone who is disabled, to learn about their experience. And when you're building that empathy, it's important to remember that a person who frequently uses these tools is always going to be better at it than you. Disabled people are always going to be better at navigating their own spaces, because that's the body that that person lives with.

My fear is that people who go through these empathy exercises, for lack of a better term, think that they know precisely what people go through. They suddenly think they're the expert on that experience. You're not the expert on that experience. If you're able-bodied, you're fundamentally not the expert on screen readers. I'm not an expert on being colorblind, even though I work in this space. I'm not an expert on screen readers.

I am an expert in my experience of being hard of hearing. I am an expert on needing a hearing aid and navigating my own experiences every day. But that doesn't mean I'm an expert in other people's experience with deafness

The worst thing you can do in accessibility engineering is have an ego. No matter what you do, you're going to mess something up. That's not something to get discouraged about because no two people have the same disability needs. No two people have the same viewpoint on accessibility and disabilities. You cannot do everything 100%—but that doesn't mean you shouldn't try. You won't ever be perfect, but strive for it anyway.

You may get critical feedback, someone may say, "Hey, your product is not accessible!"

Alexandra: Simulators support a different learning style, demonstrating your product while facing some of the problems that disabled people may experience. But, that's not the same as experiencing your product with the accessibility tools they use every day.

Elisa: Do I get mildly annoyed when people turn the sound off and read captions and then suddenly realize, oh, these automatically generated captions are terrible? Yeah. That's not how I experience captions. Some disabled people see a person emulate their experience and complain about the tools, without actively needing those tools. That's frustrating, I really get that.

But I also don't want to be the person who has to sit there and describe my experience as a deaf person over and over and over and over and over again. Every single time. If we want able-bodied people to understand our experiences, we're going to have to put up with their reaction to the experiences.

That said, the "experiences" like blind restaurant dining and wine tasting, those make me mad. That's like cosplaying a disability. But in the interests of trying to understand how your users use a feature or how readers read the page? That's fine. In fact, that's the minimum. Put yourself in their shoes for an hour and figure out how these things actually work. It really does matter.

Figure out how people navigate on your site. You may wonder, "Why can't I just put a banner warning at the top that all the links open in a new tab?" Well, because someone might not be reading the page starting with the banner. Build your design with disabled people in mind.

Do one thing: stop building infinite scroll #

Alexandra: Is there one thing you wish that engineers would just start doing to make their sites more accessible?

Elisa: Infinite scroll is a blight and no one should ever use it. I can't find things, I need to be able to find things! And, it's so bad for performance.

Also, moving things around visually and within the DOM is really annoying. The tab order matters, especially for keyboard users.

Learn more about Google's accessibility initiatives and research. In addition to the web development resources at Learn Accessibility, Google has created an accessible documentation course: Tech Writing for Accessibility.

Follow Google's Accessibility team on Twitter at @GoogleAccess and the Chrome team at @ChromiumDev.

Optimize Interaction to Next Paint

2022-12-08T00:00:00Z

Interaction to Next Paint (INP) is an experimental metric that assesses a page's overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed, ignoring outliers.

To provide a good user experience, sites should strive to have an Interaction to Next Paint of 200 milliseconds or less. To ensure you're hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

Depending on the website, there may be few to no interactions—such as pages of mostly text and images with few to no interactive elements. Or, in the case of websites such as in-browser text editors or games, there could be hundreds—even thousands—of interactions. In either case, where there's a high INP, the user experience is at risk.

It takes time and effort to improve INP, but the reward is a better user experience. In this guide, a path to improving INP will be explored.

Figure out what's causing poor INP #

Finding ways to fix a poor INP can be difficult. To start, you have to know which interactions tend to be responsible for the page's INP, out of all the interactions users have with the page. To do that, you'll need to first lean on field data, and then test in the lab to figure out what's making an interaction slow.

Find slow interactions in the field #

Field data should be the first place you go to find slow interactions. The web-vitals JavaScript library is one way to find these interactions, thanks in large part to its ability to attribute INP values to specific elements through its attribution build:

// Use the attribution build:
import { onINP } from "web-vitals/attribution";

// Example reporting function that's passed to web-vitals:
const report = ({ name, value, attribution }) => {
  console.log(name);
  console.log(value);
  console.log(attribution.eventType);
  console.log(attribution.eventTarget);
};

// Pass the reporting function to the INP reporter:
onINP(report);

When this code runs and you interact with a page, the console may report something similar to the following:

INP
248
pointerdown
#main-nav>ul>li>button

In this case, you can see that tapping on a navigation menu toggle—which took 248 milliseconds—was responsible for the page's INP. At 248 milliseconds, this page's INP would be in the "needs improvement" category.

Once you've found elements that are responsible for slow interactions in the field, you can go into lab tools to start profiling them.

Reproduce slow interactions in the lab #

Once you have a better idea of what's responsible for slow interactions, you should profile them in the lab with a performance profiler such as the one available in Chrome's DevTools. To do so, take the following steps:

Navigate to the page powering the interaction you want to test.
Open Chrome's DevTools by pressing Cmd+Option+I (Ctrl+Alt+I on Windows and Linux).
Go to the tab labeled Performance in DevTools.
Click the record button at the upper left hand corner of the empty performance profiler to start recording.
Test the desired interaction on the page.
Click the record button again to stop recording.

Once the profiler populates, you'll be able to see what work occurred to drive the interaction.

There are some cues in the profiler you can use to narrow down where the interaction occurred, notably in the interactions track situated above the main thread track:

Figure 2. An interaction profiled in the performance profiler in Chrome's DevTools. The interactions track shows a series of events that amount to a click interaction. The interactions track entries span across the tasks responsible for driving the interaction.

What if you don't have field data? #

Not everyone collects field data from their website's users. While your long term performance optimization plans should include collecting field data (as that will make diagnosing issues significantly easier), if you're not doing that today, it's still possible to profile your pages and look for interactions that might be slow.

The first step is to diagnose common user flows. For example, if you're an online retailer, some common user flows would be to add items to a cart, search for products, and checkout.

When you test these user flows in the lab, consider doing the following:

Throttle the CPU to 4x or 6x speeds to more accurately reflect interaction speeds experienced by users on low-end devices.
Enable mobile emulation and choose a low-end mobile device. When you use mobile emulation in DevTools, the user agent string is changed to that of the emulated device, which can affect how page markup is served.
If you have the ability, consider purchasing a cheaper Android phone (such as a Moto E) with reduced capabilities and profile interactions in the lab using remote debugging.

Once you've evaluated your potential user flows, make a note of the slowest interactions, and then you can begin to figure out where to start optimizing them. Regardless of whether you're collecting field data at this point, it depends on what part of the interaction you need to pay attention to in order to know what to optimize.

Diagnose and deal with long input delay #

The input delay is the first phase of an interaction. This is the period of time from when the user action is first received by the operating system until the browser is able to start processing the first event triggered by that input. The input delay ends right as the event callbacks for the interaction begin to run.

How to identify input delay #

Identifying input delay in Chrome's performance profiler can be done by finding the start of an interaction in the interactions panel, and then finding the beginning of when the event callbacks for that interaction start to run.

You'll always incur at least some input delay, as it takes some time for the operating system to pass the input event to the browser—but you do have some control over how long the input delay is. The key is to figure out if there is work running on the main thread that's preventing your callbacks from running.

Figure 3. Input delay caused by a task fired by a timer from a third-party script.

In the previous figure a task from a third-party script is running as the user attempts to interact with the page, and therefore extends the input delay. The extended input delay affects the interaction's latency, and could therefore affect the page's INP.

How to fix long input delays #

When it comes to solutions for long input delays, it all depends. If you have expensive first-party work that could be affecting an interaction's input delay, the answer is four-fold:

Do as little work as possible in any tasks your code kicks off.
Break up long tasks.
Use the Scheduler API to prioritize critical tasks and defer non-critical tasks.
Consider using isInputPending to check if a user input is pending. If so, you can yield to the main thread so the event callbacks for that input can run sooner than they otherwise would.

If it's third-party code that's causing problems, then you have a lot more to consider:

Do a complete inventory of all your website's third-party scripts.
Figure out if more than one third-party script's functionality overlaps significantly with others.
Cull redundant or low-value third-party scripts.
Maintain whatever third-party scripts are left over so that they impact performance as little as possible.

This is difficult in large part because third-party JavaScript is an issue of work culture. For example (tag managers make it easy for non-technical people in a company to add third-party scripts without the knowledge of the development teams.

Optimize event callbacks #

The input delay is only the first part of what INP measures. You'll also need to make sure that the event callbacks that run in response to a user interaction can complete as quickly as possible.

Figure 4. The event callbacks that run in response to a tap interaction, as shown in the performance profiler in Chrome DevTools.

The best way to ensure your event callbacks run quickly is to limit what gets run to just the logic that is required to apply visual updates for the next frame. Everything else can be deferred to a subsequent task.

For example, imagine a rich text editor that formats text as your type but also updates other aspects of the UI in response to what you've written (such as word count, spelling mistakes, etc.). In addition, the application may also need to save what you've written so that if you leave and return, you haven't lost any work.

In this example, the following four things need to happen in response to characters typed by the user. However, only the first item needs to be done before the next frame is presented.

Update the text box with what the user typed and apply any required formatting.
Update the part of the UI that displays the current word count.
Run logic to check for spelling mistakes.
Save the most recent changes (either locally or to a remote database).

The code to do this might look something like this:

textBox.addEventListener('keydown', (keyboardEvent) => {
  // Update the UI immediately, so the changes the user made
  // are visible as soon as the next frame is presented.
  updateTextBox(keyboardEvent);

  // Defer all other work until at least after the next frame,
  // by queuing a task in a `requestAnimationFrame()` callback.
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

The following visualization should help explain why deferring any non-critical updates until after the next frame can reduce the processing time and thus the overall interaction latency.

Click the above figure to see a high-resolution version.

While admittedly the use of setTimeout() inside of a call to requestAnimationFrame() in the previous code example is a bit esoteric, it is an effective and cross-browser way to ensure that the non-critical code does not block the next frame.

In the future, as new Scheduling APIs like scheduler.postTask() and scheduler.yield() are standardized and implemented, it will be easier for developers to write code that can be automatically prioritized without them needing to have an intimate knowledge of the browser event loop.

Minimize presentation delay #

The last step of an interaction is the presentation delay, which starts when the event callbacks have finished running, and ends when the browser is able to present the next frame to the user's display.

The unfortunate fact is that presentation delays are something you have the least amount of control over. However, here's a few things to look out for if you're noticing that frames are being delayed:

Don't abuse requestAnimationFrame() for work not related to rendering. requestAnimationFrame() callbacks are run during the rendering phase of the event loop, and must complete before the next frame can be presented. If you're using requestAnimationFrame() to do work that doesn't involve changes to the user interface, understand that you could be delaying the next frame.
Be careful with async and await and your assumptions around how they work. Just because you're using these features (or Promises in general) doesn't mean that the work they do won't block rendering. It's entirely possible that an async function—even if it does break the work in a callback into a separate task—can still block rendering if the browser chooses to run it before the next frame is presented. This is why it's important to keep all tasks short.
Be careful with ResizeObserver observer callbacks. Such callbacks are run prior to rendering, and may delay presentation of the next frame if the work in them is expensive, as with event callbacks, defer any logic not needed for the very next frame.

When interactions overlap #

It's also important to understand how interactions can overlap. For example, if there are many interactions within a short period, it's possible that the processing time or presentation delay for one interaction can be a source of input delay for a subsequent interaction.

Figure 6. A visualization of two concurrent interactions in the performance profiler in Chrome's DevTools. The rendering work in the initial click interaction causes an input delay for the subsequent keyboard interaction.

These overlaps are tricky to diagnose in the field, in part because it's difficult to track if the source of a high INP is due to multiple interactions that interfere with one another. The best thing you can do to alleviate poor responsiveness in your interactions is to do as little work as possible in your interaction's event callbacks and always keep your tasks short. This helps to reduce contention between interactions and gives the main thread a bit more breathing room.

Improving INP requires persistence #

Improving your site's INP is an iterative process. When you fix a slow interaction in the field, chances are good that—especially if your website provides tons of interactivity—you'll start to find other slow interactions, and you'll need to optimize them too.

The key to improving INP is persistence. In time, you can get your page's responsiveness in a spot where users are happy with the experience you're providing them. Chances are also good that as you develop new features for your users, you may need to go through the same process in optimizing interactions specific to them. It will take time and effort, but it's time and effort well spent.

New to the web platform in November

2022-11-30T00:00:00Z

Stable browser releases #

In November, Firefox 107, and Chrome 108 became stable. Let's take a look at what this means for the web platform.

A change to Layout Viewport behavior in Chrome on Android #

There's a change to how the Layout Viewport behaves from Chrome 108 on Android when the on-screen keyboard is shown. Read Prepare for viewport resize behavior changes coming to Chrome on Android to learn more.

New viewport units #

Also in Chrome 108 are the new CSS Viewport Units. These include small (svw, svh, svi, svb, svmin, svmax), large (lvw, lvh, lvi, lvb, lvmin, lvmax), dynamic (dvw, dvh, dvi, dvb, dvmin, dvmax), and logical (vi, vb) units. These units are already implemented in Firefox and Safari, meaning that we now have interop across the three main browser engines for these units.

Read The Large, Small, and Dynamic viewport units.

Browser support: 108 101 108 15.4

The contain-intrinsic-size shorthand CSS property is supported in Firefox 107, along with the longhand contain-intrinsic-width, contain-intrinsic-height and logical properties contain-intrinsic-block-size and contain-intrinsic-inline-size.

These are applied to specify the size of a UI element that is subject to size containment. This allows a user agent to determine the size of an element without needing to render its child elements. They are useful when an element is subject to size containment.

Browser support: 83 107 83 × Source

Support for the CSS fragmentation `avoid` keyword #

Chrome 108 includes support for the avoid value of the CSS fragmentation properties break-before, break-after, and break-inside when printing. This value tell the browser to avoid breaking before, after or inside the element it is applied to. For example, the following CSS avoids a figure being broken at a page break.

figure {
    break-inside: avoid;
}

This addition is due to the inclusion of print support using LayoutNG, this brings a modern, lessy buggy experience. Learn more about LayoutNG.

Federated Credential Management API #

The Federated Credential Management API (FedCM) provides an abstraction for federated identity flows on the web. It exposes a browser mediated dialog that allows users to choose accounts from identify providers to login to websites. FedCM is shipping in Chrome 108, find out more about it in the FedCM announcement blog post.

Beta browser releases #

Beta browser versions give you a preview of things that will be in the next stable version of the browser. It's a great time to test new features, or removals, that could impact your site before the world gets that release. Due to where release dates fall, the only new beta this month is Firefox 108, with Safari 16.2 beta still ongoing.

Implementation of container queries is underway in Firefox. Behind the layout.css.container-queries.enabled flag in Firefox 108 beta, you will find the container query length units—cqw, cqh, cqi, cqb, cqmin, cqmax. These are units of length relative to the size of a query container.

Photo by Matt Seymour.

The large, small, and dynamic viewport units

2022-11-29T00:00:00Z

The viewport and its units #

To size something as tall as the viewport, you can use the vw and vh units.

vw = 1% of the width of the viewport size.
vh = 1% of the height of the viewport size.

Give an element a width of 100vw and a height of 100vh, and it will cover the viewport entirely.

A light blue element set to be 100vw by 100vh, covering the entire viewport.
The viewport itself is indicated using a blue dashed border.

The vw and vh units landed in browsers with these additional units

vi = 1% of the size of the viewport’s inline axis.
vb = 1% of the size of the viewport’s block axis.
vmin = the smaller of vw or vh.
vmax = the larger of vw or vh.

These units have good browser support.

Browser support: 20 19 12 6

The need for new viewport units #

While the existing units work well on desktop, it’s a different story on mobile devices. There, the viewport size is influenced by the presence or absence of dynamic toolbars. These are user interfaces such as address bars and tab bars.

Although the viewport size can change, the vw and vh sizes do not. As a result, elements sized to be 100vh tall will bleed out of the viewport.

100vh on mobile is too tall on load.

When scrolling down these dynamic toolbars will retract. In this state, elements sized to be 100vh tall will cover the entire viewport.

100vh on mobile is “correct” when the User-Agent user interfaces are retracted.

To solve this problem, the various states of the viewport have been specified at the CSS Working Group.

Large viewport: The viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be retracted.
Small Viewport: The viewport sized assuming any UA interfaces that are dynamically expanded and retracted to be expanded.

Visualizations of the large and small viewports.

The new viewports also have units assigned to them:

Units representing the large viewport have the lv prefix. The units are lvw, lvh, lvi, lvb, lvmin, and lvmax.
Units representing the small viewport have the sv prefix. The units are svw, svh, svi, svb, svmin, and svmax.

The sizes of these viewport-percentage units are fixed (and therefore stable) unless the viewport itself is resized.

Two mobile browser visualizations positioned next to each other.
One has an element sized to be 100svh and the other 100lvh.

In addition to the large and small viewports, there‘s also a dynamic viewport which has dynamic consideration of the UA UI:

When the dynamic toolbars are expanded, the dynamic viewport is equal to the size of the small viewport.
When the dynamic toolbars are retracted, the dynamic viewport is equal to the size of the large viewport.

Its accompanied units have the dv prefix: dvw, dvh, dvi, dvb, dvmin, and dvmax. Their sizes are clamped between their lv* and sv* counterparts.

100dvh adapts itself to be either the large or small viewport size.

These units ship in Chrome 108, joining Safari and Firefox which already have support.

Browser support: 108 101 108 15.4

Caveats #

There‘s a few caveats to know about Viewport Units:

None of the viewport units take the size of scrollbars into account. On systems that have classic scrollbars enabled, an element sized to 100vw will therefore be a little bit too wide. This is as per specification.
The values for the dynamic viewport do not update at 60fps. In all browsers updating is throttled as the UA UI expands or retracts. Some browsers even debounce updating entirely depending on the gesture (a slow scroll versus a swipe) used.
The on-screen keyboard (also known as the virtual keyboard) is not considered part of the UA UI. Therefore it does not affect the size of the viewport units. In Chrome you can opt-in to a behavior where the presence of the virtual keyboard does affect the viewport units.

Additional resources #

To learn more about viewports and these units check out this episode of HTTP 203. In it, Bramus tells Jake all about the various viewports and explains how exactly the sizes of these units are determined.

Additional reading material:

Accessibility Week

2022-11-18T00:00:00Z

This week we highlighted accessibility resources to help you make your sites and applications usable by everyone.

We're continuing to roll out Learn Accessibility, a brand new course written by Carie Fisher that will take you through the essentials for building accessible websites and web apps.

We've had 3 community spotlights:

Melanie Sumner told us about her journey into engineering, accessible design, Ember.js, and the importance of funding these efforts.
Olutimilehin Olushuyi told us about his move from the law to web development, building accessible community, and creating accessible layouts.
Albert Kim told us about mental health awareness, building for invisible disabilities, the COGA Accessibility Community Group, and more practical wisdom.

Watch us answer your questions #

On Thursday, Alexandra White spoke with Carie Fisher and Melanie Sumner about accessibility, and we answered some of your questions.

Have more questions? Ask us on Twitter, @ChromiumDev.

More resources #

A solid document structure is a great start for accessible development. Find out how to really use HTML in our Learn HTML course. Follow it up with Learn Accessibility's Content structure module for more on semantic HTML, landmarks, and tables for accessible content.

In Testing web design color contrast get an overview of three tools and techniques to ensure your content is readable by everyone.

In Building the main navigation for a website learn how to create accessible navigation using semantic HTML.

On the web #

The W3C hosts a collection of courses, training, and certification on digital accessibility from different providers.
Read Accessibility articles on Smashing Magazine, including <article> vs. <section>: How To Choose The Right One by Olushuyi Olutimilehin.
If you're making a case for accessibility work at your company, check out Melanie Sumner's pleasefunda11y.com.
If you want to support the Cognitive and Learning Disabilities Accessibility Task Force, join the COGA Accessibility Community Group. This group supplies user needs and feedback to the COGA Task Force.

Community highlight: Albert Kim

2022-11-17T00:00:00Z

This post highlights a community expert, as a part of Learn Accessibility!

Alexandra White: How would you introduce yourself? You do so much accessibility work.

Albert Kim: I'm a digital accessibility subject matter expert (SME), a UX design consultant, and a public speaker and coach, raising mental health awareness in the tech community.

I founded Accessibility NextGen, a community for people interested in learning more about accessibility. I'm a Disability:IN NextGen Leader. And currently, I'm a W3C invited expert for the Cognitive and Learning Disabilities Task Force and Mental Health Sub-Group. Lately, I've been researching how to include people with OCD, ADHD, dyslexia, and PTSD into the product development process.

Offline, I'm a DEI community leader, blogger, huge foodie, photographer, and I love traveling—I travel a lot. I'm the first generation in my family to live abroad, the first generation to get any formal education. I was raised by a single mother in a low-income household. I'm a military veteran.

I identify myself as someone who can empathize with a lot of different struggles and life stories.

Alexandra: Did you always think you'd be someone who would have a career or work in accessibility?

Albert: I always wanted my profession to be not just a job, but one with social impact. I've switched careers several times. In college, I tried different majors. I've founded startups, I was a business development manager, I worked in telecommunications in the military. I was an interpreter. I've had many different jobs.

It's important to mention all of these different experiences, as all of the dots began to connect in their own way. I eventually got into digital accessibility because of my personal experience as someone with a disability, but also with a love for digital products. I really, really love a good product. Useful, functional products.

We often use the phrase "assistive technology," but all technologies are assistive. I'm passionate about digital products that help improve my life, that make my life easier. I want to connect consumers with the producers of digital products, and digital accessibility is fundamental to that connection.

Alexandra: Can you expand more on how you create opportunities for direct communication between users and product creators?

Albert: Often, when developers build digital products, they don't make full use of their own product. They aren't aware of how useful their product is for users, especially those with disabilities. That means that they're not thinking about those use cases in the design process. Because of this, they often miss an opportunity to discover disabled users who could become loyal customers.

Designers and developers may or may not find out later that what they built is useful to disabled users.

Connecting product owners and developers to their users with disabilities early in the product development process can lead to full realization of a product's potential. This is in addition to products designed with accessibility as an intentional feature.

As a metaphor, I love sharing good food with my loved ones. The joy is doubled when I can share it. Just like that, I want to share really good products with my friends, but I cannot always share them if they're not accessible. A blog post alone, without a screen reader or other interventions, is not accessible to my blind friend. If digital product makers hear these stories from users, then hopefully they'll make accessible design choices so the users can fully utilize their products.

Build for "invisible" disabilities #

Alexandra: I appreciate that you mentioned your blind friend specifically, because often the first thing that comes to mind when developers and designers do think about disability are the "obvious" ones: visible and often permanent disabilities. But there are so many people impacted by accessible design, such as those with temporary and invisible disabilities, like psychological disabilities.

You're an invited expert to the W3C group, the Cognitive and Learning Disabilities Task Force and Mental Health subgroup. What is COGA?

Albert: The COGA task force is a joint commitment of the Accessible Platform Architecture (APA) Working Group and the Web Content Accessibility Guidelines (WCAG) Working Group. COGA assists these other groups in creating guidance documents, as well as updates to existing W3C accessibility guidelines. For example, we further developed proposed success criteria for WCAG 2.1.

We've built a repository of user research to serve as supplemental guidance and have published issue papers.

Often, companies and developers look at WCAG guidelines as their standard for web accessibility. But, there's supplemental guidance in the form of issue papers. COGA has written some of these papers on different use cases to help describe cognitive disabilities and scenarios where persons with atypical profiles use technology successfully and unsuccessfully. We help these working groups think about cognitive disabilities and learning disabilities.

Alexandra: Have you been with COGA from the start?

Albert: I joined a few years after the group was developed; but after I joined, I strongly advocated for a mental health subgroup. COGA's focus was primarily on cognitive and learning disabilities, but I wanted to start a conversation about mental health.

I happened to know someone in that community who reached out on Twitter. I got in through that connections, and I'm very passionate about bringing invisible disabilities into web accessibility spaces.

Participate in COGA and other W3C initiatives #

Alexandra: Can anyone participate in such a group, and do people attend regularly?

Albert: It's an open group! Anyone can join, as participants of either the APA Working Group or the WCAG Working Group. If your company sponsors the W3C, you can join, or as an independent invited expert. I'm an independent invited expert.

Alexandra: For most of my career, I didn't know that. I didn't realize how much power an individual could have in influencing and even creating standards that make up the web.

Albert: It's definitely a big time commitment and a lot of responsibilities. For some, that may not be feasible.

The easiest way to participate is to join the COGA Accessibility Community Group. The community groups are more flexible and don't have as much responsibility or commitments. This group supplies user needs and feedback to the COGA Task Force.

Alexandra: Here's where I confess my own stakes in this work, in your subgroup. I suffer from anxiety and depression, and have for most of my life. There are times I'm overwhelmed by certain sites and apps, even those which are meant to help us be "productive," as some tasks have long checklist steps before you can move to the next task. Tools which are helpful on my best days can be overwhelming the next day.

In your Accessibility Rules interview, you mentioned the ways in which endless scroll can be traumatic, and how that affects you as a person with OCD and PTSD. Is there guidance out there or sites that are doing a good job of giving people a way to opt-out of an experience that may be triggering.

Albert: There is a COGA issue paper, that has supplemental guidance. As far as websites or resources acting as a good example… that might be hard to find! Addressing mental health in web development is still very new. But I do have a lot of advice and specific best practices that I can recommend as a user with disabilities and as an accessibility SME.

First thing, follow the WCAG guidelines, though most of them were written prior to the mental health subgroup existing, so much of that guidance is helpful beyond those with physical disabilities. It's helpful for users with invisible disabilities and mental health disabilities. Following this, that has to be the beginning. If websites were following these guidelines and did a really good job, even if they didn't think about mental health at all, we probably wouldn't experience many of these problems.

One of the most important design choices that would be helpful is clear, semantic structure. Clear headings can be very helpful for users with OCD, ADHD, or dyslexia. Even for me, and my anxiety as well. All of these illnesses share some pain points, they're interconnected.

Stop creating bad user experiences #

Alexandra: Okay, what about the opposite? What are people building that is against WCAG recommendations that is causing problems for those with mental health issues?

Albert: So many things:

Complex navigation and page layouts that are difficult to navigate and use.
Multi-stage forms that have a lot of imposed requirements, rather than communicating with users why something is important or needed.
Long passages of complex text with a lot of jargon or metaphors that are difficult to understand, which require additional context.
Flickering content or background images that are moving or blinking. Notifications that you can't turn off easily.
Timeouts on complex activities, especially without options to save, such as when you're filling out a form and you're given a warning or a timeout after 30 seconds.
Search on websites that doesn't work well. This may mean there's a lack of filters, and that leads to an endless set of results.
Unexpected behavior, like when you click a button and the page jumps back to the top so you have to figure out where you were and scroll back down.
Hidden actions, like when a cookie popup requires multiple steps in really small print to decline the cookies. Or deliberately making subscriptions that are really hard to cancel.

These aren't just accessibility issues, these are usability issues.

Alexandra: Good product design is accessible design.

Albert: There are so many examples. Make a good product and users will come back. These are just some examples.

Include content warnings #

Alexandra: Something often politicized, at least in the United States, is the idea of content warnings (colloquially known as "trigger warnings").

These warnings may be related to a design choice—flashing images may cause seizures. Those are less controversial, and fairly commonplace. However, content warnings for certain subjects is also critical for many.

Albert: If your content has something sensitive, such as violence or mentions of sexual assault, having warnings can be very helpful for users with PTSD, depression, and anxiety, especially as it may stem from personal experience of traumatic events. Allow for customization and personalization that is obvious, so people can choose what information they are ready to read, see, or hear.

The core meaning of the web is to relay information. Rather than imposing our information, we should be communicating it. We should think about how others will perceive what we have to share. I may write something one way, but it may be interpreted by someone else in a different way. Clear structure helps to avoid some of these miscommunications.

Summaries and tables of content are also very helpful in allowing a user to prepare themselves for what they'll be learning.

Alexandra: I'm personally grateful for these content trigger warnings, so I can decide if I'm in a place where I feel comfortable reading or seeing content which may lead to an emotional reaction. For those who are worried that there may be pushback on including trigger warnings in their content, do you have any advice?

Albert: We must think of it as a public health issue, not a political issue. Trigger warnings are not about censorship, at all. It's about giving users freedom to choose. When we don't provide the option, then we don't give users freedom to protect themselves from something that may cause harm to their mental health.

We shouldn't arbitrarily impose or force information on users. The most common reaction for people with PTSD who encounter trigger content is to leave and never come back. You lose those people. It's a health issue.

Albert: There's some similarity between a trigger warning and a parental control. We don't have any political concerns about letting parents choose what is acceptable to be seen by their children. It's very conventionally understood. This is exactly the same. People deserve to have control for themselves.

Alexandra: Seems reasonable to me!

Do one more thing: communicate clearly #

Alexandra: If you asked developers to change one thing about the way they design and build websites to make them more accessible, what would you ask for?

Albert: Don't forget that the fundamental purpose of a website is to clearly communicate information to the user. To do this, you must think about what information you want to share with your users, and more importantly, how to frame that information so the content and your intentions are understood.

You can succeed by building each page with semantic HTML, use a clear structure and layout of content. Clear structure and layouts help you communicate better with your users, and are more scalable, usable, and accessible. Ensure labels are consistent and instructions are provided correctly. This helps users more easily find the information they seek and better understand the relationships between different parts of the content.

This advice touches upon three WCAG success criteria:

Missing these success criteria is among the most common accessibility issues found on websites. This affects people who use assistive technologies (such as screen readers), but also neurodivergent people who may have cognitive and/or learning disabilities or mental health conditions.

Keep up with Albert's work on Twitter as @djkalbert. Check out Accessibility NextGen.

GDE community highlight: Lars Knudsen

2022-11-09T00:00:00Z

Monika: What inspired you to become a developer? What’s your current professional focus?

Lars: I got my MSc in engineering, but in fact my interest in tech started much earlier. When I was a kid in the 80s, my father owned a computing company working with graphic design. Sometimes, especially during the summer holidays, he would take me to work with him. At times, some of his employees would keep an eye on me. There was this really smart guy who once said to me, “Lars, I need to get some work done, but here's a C manual, and there’s a computer over there. Here’s how you start a C compiler. If you have any questions, come and ask me.” I started to write short texts that were translated into something the computer could understand. It seemed magical to me. I was 11 years old when I started and around seventh grade, I was able to create small applications for my classmates or to be used at school. That’s how it started.

Over the years, I’ve worked for many companies, including Nokia, Maersk, and Openwave. At the beginning, like in many other professions, because you know a little, you feel like you can do everything, but with time you learn each company has a certain way of doing things.

After a few years of working for a medical company, I started my own business in 1999. I worked as a freelance contractor and, thanks to that, had the chance to get to know multiple organizations quickly. After completing the first five contracts, I found out that every company thinks they’ve found the perfect setup, but all of them are completely different. At that time, I was also exposed to a lot of different technologies, operating systems etc. Around my early twenties, my mindset changed. At the beginning, I was strictly focused on one technology and wanted to learn all about it. With time, I started to think about combining technologies as a way of improving our lives. I have a particular interest in narrowing the gap between what we call the A and the B team in the world. I try to transfer as much knowledge as possible to regions where people don’t have the luxury of owning a computer or studying at university free of charge.

I continue to work as a contractor for external partners but, whenever possible, I try to choose projects that have some kind of positive impact on the environment or society. I’m currently working on embedded software for a hearing-aid company called Oticon. Software-wise, I’ve been working on everything from the tiniest microcontrollers to the cloud; a lot of what I do revolves around the web. I’m trying to combine technologies whenever it makes sense.

Monika: Were you involved in developer communities before joining the Google Developer Experts program?

Lars: Yes, I was engaged in meetups and conferences. I first connected with the community while working for Nokia. Around 2010, I met Kenneth Rohde Christiansen, who became a GDE before me. He inspired me to see how web technologies can be useful for aspiring tech professionals in developing countries. Developing and deploying solutions using C++, C# or Java requires some years of experience, but everyone who has access to a computer, browser, and notepad can start developing web-based applications and learn really fast. It’s possible to build a fully functional application with limited resources, and ramp up from nothing. That’s why I call the web a very democratizing technology stack.

But back to the community—after a while I got interested in web standardization and what problems bleeding edge web technologies could solve. I experimented with new capabilities in a browser before release. I was working for Nokia at the time, developing for a Linux-based flagship device, the N9. The browser we built was WebKit based and I got some great experience developing features for a large open source project. In the years after leaving Nokia, I got involved in web conferences and meetups, so it made sense to join the GDE community in 2017.

I really enjoy the community work and everything we’re doing together, especially the pre-pandemic Chrome Developer Summits, where I got to help with booth duty alongside a bunch of awesome Google Engineers and other GDEs.

Monika: What advice would you give to a young developer who’s just starting their professional career and is not sure which path to take?

Lars: I’d say from my own experience—if you can afford it—consider freelancing for a couple of different companies. This way, you’ll be exposed to code in many different forms and stages of development. You’ll get to know a multitude of operating systems and languages, and learn how to resolve problems in many ways. This helped me a lotI gained experience as senior developer in my twenties. This approach will help you achieve your professional goals faster.

Besides that, have fun, explore, play with the hardware and software. Consider building something that solves a real problem—maybe for your friends, family, or a local business. Don’t be afraid to jump into something you’ve never done before.

Monika: What does the future hold for web technologies?

Lars: I think that for a couple of years now the web has been fully capable of providing a platform for large field applications, both for the consumer and for business. On the server side of things, web technologies offer a seamless experience, especially for frontend developers who want to build a backend component. It’s easier for them to get started now. I know people who were using both Firebase and Heroku to get the job done. And this trend will grow—web technologies will be enough to build complex solutions of any kind. I believe that the Web Capabilities - Project Fugu 🐡 really unlocks that potential.

Looking at it from a slightly different point of view, I also think that if we provide full documentation and in-depth articles not only in English but also in other languages (for example, Spanish and Portuguese), we would unlock a lot of potential in Latin America—and other regions, of course. Developers there often don’t know English well enough to fully understand all the relevant articles. We should also give them the opportunity to learn as early as possible, even before they start university, while still in their hometowns. They may use those skills to help local communities and businesses before they leave home and maybe never come back.

Thomas: You came a long way from doing C development on a random computer to hacking on hardware. How did you do that?

Lars: I started taking apart a lot of hardware I had at home. My dad was not always happy when I couldn’t put it back together. With time, I learned how to build some small devices, but it really took off much later, around the time I joined Nokia, where I got my embedded experience. I had the chance to build small screensavers, components for the Series 30 phones. I was really passionate about it and could really think outside the box. They assigned me a task to build a Snake game for those devices. It was a very interesting experience. The main difference between building embedded systems and most other things (including web) is that you leave a small footprint—you don’t have much space or memory to use. While building Snake, the RAM that I had available was less than one-third of the frame buffer (around 120 x 120 pixels). I had to come up with ways to algorithmically rejoin components on screen so they’d look static, as if they were tiles. I learned a lot—that was the move from larger systems to small, embedded solutions.

Thomas: The skill set of a typical frontend developer is very different from the skill set of someone who builds embedded hardware. How would you encourage a frontend developer to look into hardware and to start thinking in binary?

Lars: I think that the first step is to look at some of the Fugu APIs that work in Chrome and Edge, and are built into all the major systems today. That’s all you need at the start.

Another thing is that the toolchains for building embedded solutions have a steep learning curve. If you want to build your own custom hardware, start with Arduino or ESP32—something that is easy to buy and fairly cheap. With the right development environment, you can get your project up and running in no time.

You could also buy a heart rate monitor or a multisensor unit, which are already using Bluetooth GATT services, so you don’t have to build your own hardware or firmware—you can use what’s already there and start experimenting with the Web Bluetooth API to start communicating with it.

There are also devices that use a serial protocol—for these, you can use the Web Serial API (also Fugu). Recently I’ve been looking into using the WebHID API, which enables you to talk to all the human interface devices that everyone has access to. I found some old ones in my basement that had not been supported by any operating system for years, but thanks to reverse engineering it took me a few hours to re-enable them.

There are different approaches depending on what you want to build, but to a web developer I would say, get a solid sensor unit, maybe a Thingy 52 from Nordic Semiconductor; it has a lot of sensors, and you can hook up to your web application with very little effort.

Thomas: Connecting to the device is the first step, but then speaking to it effectively—that’s a whole other thing. How come you did not give up after facing obstacles? What kept you motivated to continue working?

Lars: For me personally the social aspect of solving a problem was the most important. When I started working on my own embedded projects, I had a vision and a desire to build a science lab in a box for developing regions. My wife is from Mexico and I saw some of the schools there; some that are located outside of the big cities are pretty shabby, without access to the materials and equipment that we have in our part of the world.

The passion for building something that can potentially be used to help others—that’s what kept me going. I also really enjoyed the community support. I reached out to some people at Google and all were extremely helpful and patiently answered all of my questions.

Thomas: A lot of people have some sort of hardware at home, but don’t know what to do with it. How do you find inspiration for all your amazing projects, in particular the one under the working name SimpleMouse?

Lars: Well, recently I have been in fact reviving a lot of old hardware, but for this particular project—the name has not been set yet, but let’s call it SimpleMouse—I used my experience. I worked with some accessibility solutions earlier and I saw how some of them just don’t work anymore; you’d need to have an old Windows XP with certain software installed to run them. You can’t really update those, you can only use those at home because you can’t move your setup.

Because of that, I wondered how to combine my skills from the embedded world with project Fugu and what is now possible on the web to create cheap, affordable hardware combined with easy-to-understand software on both sides, so people can build on that.

For that particular project, I took a small USB dongle with a reflexive chip, the nRF52840. It communicates with Bluetooth on one side and USB on the other. You can basically program it to be anything on both sides. And then I thought about the devices that control a computer—a mouse and a keyboard. Some people with disabilities may find it difficult to operate those devices, and I wanted to help them.

The first thing I did was to make sure that any operating system would see the USB dongle as a mouse. You can control it from a native application or a web application—directly into Bluetooth. After that, I built a web application—a simple template that people can extend the way they want using web components. Thanks to that, everyone can control their computer with a web app that I made in just a couple of hours on an Android phone.

Having that set up will enable anyone in the world with some web experience to build, in a matter of days, a very customized solution for anyone with a disability who wants to control their computer. The cool thing is that you can take it with you anywhere you go and use it with other devices as well. It will be the exact same experience. To me, the portability and affordability of the device are very important because people are no longer confined to using their own devices, and are no longer limited to one location.

Thomas: Did you have a chance to test the device in real life?

Lars: Actually during my last trip to Mexico I discussed it with a web professional living there; he’s now looking into the possibilities of using the device locally. Over there the equipment is really expensive, but a USB dongle normally costs around ten US dollars. He’s now checking if we could build local setups there to try it out. But I haven’t done official trials yet here in Denmark.

Thomas: Many devices designed to assist people with disabilities are really expensive. Are you planning on cooperating with any particular company and putting it into production for a fraction of the price of that expensive equipment?

Lars: Yes, definitely! I’ve already been talking to a local hardware manufacturer about that. Of course, the device won’t replace all those highly specialized solutions, but it can be the first step to building something bigger—for example, using voice recognition, already available for web technologies. It’ll be an easy way of controlling devices using your Android phone; it can work with a device of any kind.

Just being able to build whatever you want on the web and to use that to control any host computer opens up a lot of possibilities.

Thomas: Are you releasing your Zephyr project as open source? What kind of license do you use? Are there plans to monetize the project?

Lars: Yes, the solution is open source. I did not put a specific license on it, but I think Apache 2.0 would be the way to go. Many major companies use this license, including Google. When I worked on SimpleMouse, I did not think about monetizing the project—that was not my goal. But I also think it would make sense to try to put it into production in some way, and with this comes cost. The ultimate goal is to make it available. I’d love to see it being implemented at a low cost and on a large scale.

Community highlight: Olutimilehin Olushuyi

2022-11-09T00:00:00Z

This post highlights a community expert, as a part of Learn Accessibility!

Alexandra White: How'd you get started with web accessibility?

Olutimilehin Olushuyi (Shuyi): Okay, so, it's a funny story. I'm a lawyer. I realized in my final year of school, I didn't want to practice law for the rest of my life. So, I tried to drop out of school, but my dean and "school mother," Professor Ayodele Atsenuwa, said, "Let's talk about this. You're in your final year—just finish it."

Ultimately, I'm happy she said that, and I'm happy I finished, because it's been helping me in my accessibility work. Professor Atsenuwa asked me what I wanted to do instead, and I had no idea.

I started to look up new career opportunities, and got in touch with some people who wanted to build a startup and needed a lawyer. That opportunity wasn't the right fit, but that was the first time I knew people wrote code for all of the products we use. I thought, "I can pick this up." I started to teach myself HTML and CSS. Then, I got to JavaScript and … [laughs] JavaScript did JavaScript things, so I went back to focus on my front-end semantic languages.

I came across the work of Andy Bell and Heydon Pickering. I purchased Every Layout, and it changed my life. Andy kept mentioning accessibility, but I didn't know what that meant in this context. I realized I may be able to work in web development without needing to know how to write JavaScript!

I reached out to Heydon and he was very receptive, very responsive. It seems everyone in the accessibility field is that way, and I'm grateful for that.

Alexandra: I'd definitely agree, everyone I've spoken with has been so kind and so helpful.

Shuyi: Absolutely. Currently, I do a lot more work in advocacy. I'm based in Nigeria, a country where web accessibility is not mandated by law. The Discrimination Against Persons with Disabilities Act passed sometime in 2018. But there's no web accessibility law, only law about physical accessibility. It's like the USA's Americans with Disabilities Act (ADA). Our law is poorly structured, but better than nothing.

I realized if I'm going to have any chance to make a difference and become an accessibility focused developer, first I have to make the ecosystem aware of accessibility needs. I started tweeting about accessibility advocacy. I talked to companies and brands, whose buy-in is needed to get accessibility to work.

Alexandra: I bet your legal background is incredibly useful in working with accessibility. You can actually read the new legislation and understand it in a way that the average person won't. That includes an average developer.

Shuyi: I think one of the biggest gifts from my legal background is that I can sit through unending pages of background materials, really lengthy documents, without getting tired. I just fold my legs, put my laptop up, and start to read. And read. And read. It's got advantages,

Alexandra: I mean … I'm jealous, that's a great skill to have. Do you think you'd ever work with the government to get a digital accessibility law passed?

Shuyi: I'll be honest, I don't think so. Engaging with the government is a different ball game. It takes too long to get our government to do something, especially as an individual. That kind of work is better for NGOs and other organizations with staffing and resources to bring about change.

The physical law took so much time to pass, and accessibility needs moved far beyond what ended up in the law years ago. It's like the first draft was passed even though the world has changed.

Ultimately, we're happy there's something to rely on, no matter how outdated it ended up being. There is a law to enforce.

Create accessible layouts #

Alexandra: I read your article, <article> vs. <section>: How To Choose The Right One in Smashing Magazine and the Twitter thread that inspired it. What would you say is one big takeaway, what's the one thing you want from web developers?

Shuyi: Developers must read the content before they begin building layouts.

Originally, for my site design, I had just counted the number of paragraphs and put them in sections and articles, without much thought. But, someone drew my attention to the misuse of sections—it was the first time I thought about it. Reading the content is one thing you can do to make a better product.

Alexandra: When I was a developer, I often had freelance clients say, "Oh, just build something for us and we'll fill the content in later." And sure, there are some pages that have automatic context, like a contact page. But knowing how many pages to build, and what kind of custom support was needed, that could only be answered when I got the content.

Shuyi: Before knowing what I know, my best client would give me general design ideas, and I'd built out a site with a bunch of lorem ipsum. I'll figure all that stuff out. But, when you realize how much the content infrastructure affects users on the web, you realize just how much of the standard process for building things on the web is actually flawed. You must be intentional when you build things.

So much accessibility infrastructure work doesn't get attention at all, and it breaks my heart.

Alexandra: How did you do your research to make sure the advice you gave in the article was correct?

Shuyi: First, I separated the sources of information—that's something you do in law, separating primary and secondary sources. The primary sources are the actual law (like the ADA and Nigeria's laws) and the secondary sources are what experts interpret from the law.

I decided to refer only to the primary sources: the HTML, WCAG, and WAI-ARIA specs. I read other people's works, a lot of good work. But, at the end of the day, the opinions were so divergent, I decided I could only take them as useful context but not rely on them as having the right answers.

Build an accessible community #

Alexandra: You mentioned trying to shape your Twitter feed into a place for accessibility. Have you had many other conversations on Twitter since the Smashing Magazine article's publication about what you learned?

Shuyi: For the first couple of days, I couldn't make good sense of Twitter. So many people followed me, like 200+ people. At first I was excited, but then I was scared. Like, I'm just starting out, don't follow me for a bunch of sage wisdom. I was added to a lot of Twitter lists.

But like, I'm a person. I tweet about a lot of vague, non-accessibility, non-web developer stuff. I don't want to let people down. Don't follow me just because of accessibility! I'll feel like I'll let you down.

Alexandra: [laughs] I mean, I think a lot of people think that. I certainly do about my Twitter persona.

Shuyi: Most responses to the article itself were positive. I got one response to the article which was a bit controversial. Vitaly was my editor, and he reached out directly to share the comment and asked me to investigate. Turns out, the person was referencing the MDN docs which said that all articles should have a heading element. I recommended that the section should have a heading element based on the specs.

The MDN docs recommend including the header but don't really explain what the benefit is.

The spec changes less frequently than user needs, of course, so as long as you can back up your decision to change the way you build something, it's probably okay.

So, let me give an example. Let's say you're building a card component called "Prices," with three elements in it. Hayden Pickering would suggest putting each card into a list element. That way, when someone using assistive technology (AT) gets to that section, it's announced to them that there are three items in the price list. You can style the list so that there are no bullet points, make it look however you want, but it helps AT users get the useful information first. If you wrapped each item in a div, you'd just be focused on the visual aspects, which doesn't help visually impaired users. Think of people before design.

I took that idea, and transposed it for a blog page. The blog posts are actually within a list element. That way, on entry to the page, the user is alerted that they are at one of some number of posts on the page.

So, I stood by my recommendations in the article, and I will until I understand why MDN makes the recommendation.

Alexandra: Since the MDN docs are open source, will you suggest changes and make updates there?

Shuyi: I'll be honest, I haven't yet made any open source contributions. But, this is the kind of work I would like to be doing, certainly more than working with the government.

Spec versus implementation #

Alexandra: It sounds like one big takeaway is that sometimes the spec says one thing, but implementation and other external docs may suggest doing something different. How does someone decide whose advice to follow?

Shuyi: I think about this a lot. I'm not sure I have the required experience to answer that question. We're always trying to future-proof. It's good to make continuous enhancements as the web changes. That way, when the spec is updated, you don't need to retrofit your site. What are the chances that you make a choice and three years from now the spec changes.

Every choice we make now is our best guess of what we think the future of the web will look like, what direction we think the spec writers will go.

Alexandra: The web is constantly changing, one person can't have all of the answers! Did the specs go through changes while you were writing?

Shuyi: I started writing my article before the document outline model was removed from the spec. This model suggested that heading levels should be automatically calculated based on how deep the nesting was. But it was never really implemented and that created a lot of issues for developers. The advice to developers was to manually fix their headings.

If the article had been published before the spec change, I probably would have gone back and made that edit—it is in Smashing Magazine after all. But if it had lived on my personal blog, would I have? Probably not. And that's just talking about updating an article, not updating an entire website that's built based on a changing spec.

Do we expect developers to immediately change their websites when the spec changes? Of course not. They make calculations as to what's best when they're building their sites and live with those choices. The specs will change, the specs may not have the answer.

Accessibility as a career #

Alexandra: How much of your time do you spend thinking about global accessibility standards? Standards and laws are different around the world. I'm sure you've read a lot of them, and I'm sure some laws tell you to do the opposite things. What would you do in those cases?

Shuyi: I thought about launching a business for freelance accessibility work. I went into a global web accessibility chat channel and asked for tips on how to get started. Adrian Roselli reached out and said, "Your clients will be relying on you to keep them compliant with laws which could have major consequences. Before you offer your services, know what region you have expertise in. Know what laws you're familiar with so that, while you're making a living for yourself, you don't leave clients with huge liabilities. They trust you to know the law."

Of course, so many businesses are seeking accessibility help because they are legally required, and not just because it's the right thing. Capitalism is the reason accessibility is being implemented. At the end of the day, it doesn't matter why it happened, it matters that the product is accessible.

I put a pause on freelancing until I have full confidence that I can help clients with the laws of their region. Standardization is critical, the efforts and impact of WCAG cannot be overstated. Having a central framework of how the web should work makes it easier for governments to rely on the same standard. But of course, not every government will accept those standards.

Alexandra: You've gotten a lot of great advice from great people in your journey into accessibility. Is there any other advice you wish you'd gotten before you decided to pursue this as a career?

Shuyi: While it wouldn't have changed my career path, it would have been nice to know that as noble as accessibility work is, it's greatly affected by capitalism.

Alexandra: [laughs] Oh yes.

Shuyi: And I'm a junior. I have a year of experience in accessibility. Especially if you're based in Africa, like I am, there's a limited availability of positions in accessibility. Companies are hiring managers, one person to meet whatever legal requirements are needed. But I want to work on a team, where I can learn and build skills.

I was so excited to get to work without learning JavaScript—that I could just learn the rules and help my team apply them. But the developer positions at agencies require that I have JavaScript experience. I moved to a new city and joined a JavaScript bootcamp so I can meet those requirements. For anyone else on their accessibility journey, know that you must focus on building your development skills first.

I'm not going to lie, I still don't like JavaScript.

Do one thing: add keyboard focus #

Alexandra: [laughs] Is JavaScript the reason I'm now a tech writer instead of a developer? Yes. Yes, it is. I hate it so much. I wish you the best of luck in your boot camp.

What's one thing you want developers to do to make their site accessible?

Shuyi: Keyboard focus. I am begging from the bottom of my heart. My trackpad currently doesn't work, so when I'm on the go, I rely on my keyboard to navigate the web, and almost every website is horrible. Keyboard focus doesn't just benefit disabled people.

Building accessible platforms benefits everyone.

Keep up with Shuyi's work on Twitter @shuyiolutimi.

Speedy CSS Tip! Animated Gradient Text

2022-11-03T00:00:00Z

Hop over to CodePen and create a new pen.

Create the markup for your text. Let's use a header with the word "Speedy":

<h1 class="boujee-text">Hello!</h1>

Then, let's give our body a darker background-color:

body {
  display: grid;
  place-items: center;
  min-height: 100vh;
  background: hsl(0 0% 20%);
}

Bump up the font-size on our text. Use clamp to make it responsive:

.boujee-text {
  font-size: clamp(3rem, 25vmin, 8rem);
}

Create two custom properties for the colors we're going to use. Apply a linear-gradient to the background using those colors and rotate it by 90 degrees:

.boujee-text {
  --color-one: hsl(15 90% 55%);
  --color-two: hsl(40 95% 55%);
  font-size: clamp(3rem, 25vmin, 8rem);
  background: linear-gradient(
                90deg,
                var(--color-one),
                var(--color-two),
                var(--color-one)
              ) 0 0 / 100% 100%;
}

Create a custom property that you can use for the horizontal background size. Use it for background-size-x:

.boujee-text {
  --bg-size: 400%;
  --color-one: hsl(15 90% 55%);
  --color-two: hsl(40 95% 55%);
  font-size: clamp(3rem, 25vmin, 8rem);
  background: linear-gradient(
                90deg,
                var(--color-one),
                var(--color-two),
                var(--color-one)
              ) 0 0 / var(--bg-size) 100%;
}

To clip the background to the text set the color to transparent, and set background-clip: text:

.boujee-text {
  --bg-size: 400%;
  --color-one: hsl(15 90% 55%);
  --color-two: hsl(40 95% 55%);
  font-size: clamp(3rem, 25vmin, 8rem);
  background: linear-gradient(
                90deg,
                var(--color-one),
                var(--color-two),
                var(--color-one)
              ) 0 0 / var(--bg-size) 100%;
  color: transparent;
  -webkit-background-clip: text;
  background-clip: text;
}

At this point, you could leave it there and experiment with the background-position and the gradient used in the background-image. Or, you could animate that gradient across your text. First, define a keyframe for the animation. This will use the --bg-size custom property you defined earlier. A good example of scoped custom properties making maintenance easier for you.

@keyframes move-bg {
  to {
    background-position: var(--bg-size) 0;
  }
}

Then apply the animation using animation:

.boujee-text {
  --bg-size: 400%;
  --color-one: hsl(15 90% 55%);
  --color-two: hsl(40 95% 55%);
  font-size: clamp(3rem, 25vmin, 8rem);
  background: linear-gradient(
                90deg,
                var(--color-one),
                var(--color-two),
                var(--color-one)
              ) 0 0 / var(--bg-size) 100%;
  color: transparent;
  background-clip: text;
  -webkit-background-clip: text;
  animation: move-bg 8s infinite linear;
}

To take this further, you can wrap your animation code in a media query to respect your user's preferences for motion:

@media (prefers-reduced-motion: no-preference) {
  .boujee-text {
    animation: move-bg 8s linear infinite;
  }
  @keyframes move-bg {
    to {
      background-position: var(--bg-size) 0;
    }
  }
}

Done! 🎉 You've created some animated gradient text with CSS using scoped custom properties and background-clip.

Here's this tip in its speedy video form! ⚡️

Prefer this in tweet form? 🐦

Stay Awesome! ʕ •ᴥ•ʔ

Hero image by Vladislav Klapin on Unsplash

New patterns for media apps

2022-11-03T00:00:00Z

Let's welcome our new collection of media patterns to help you create modern media experiences on the web for great audio and video playback:

We hope these patterns will help you build amazing apps, and we're looking forward to your feedback! You can provide feedback by tweeting at @ChromiumDev or filing an Issue.

Photo by Kenny Eliason.

New to the web platform in October

2022-10-31T00:00:00Z

Stable browser releases #

In October, Firefox 106, Chrome 107, and Safari 16.1 became stable. Let's take a look at what this means for the web platform.

Animation of grid tracks #

Thanks to the work of our contributors at Microsoft, Chrome is now able to interpolate grid-template-columns and grid-template-rows values. This means that grid layouts can smoothly transition between states, instead of snapping at the halfway point of an animation or transition.

Hover over the avatars to see the animation. This example is from the article CSS animated grid layouts, where you can find out more.

Browser support: 107 66 107 16

Additions to `getDisplayMedia()` #

Also in Chrome are some additions to getDisplayMedia() that aim to prevent accidental oversharing when screen sharing.

The displaySurface option can indicate that the web app prefers to offer a specific display surface type (tabs, windows, or screens).
The surfaceSwitching option indicates whether Chrome should allow the user to dynamically switch between shared tabs.
The selfBrowserSurface option can be used to prevent the user from sharing the current tab. This avoids the "hall of mirrors" effect.
The systemAudio option ensures Chrome only offers relevant audio-capture to the user.

Safari 16.1 also includes support for getDisplayMedia, adding support for capturing a specific Safari window.

Testing for support of font technology and features from CSS #

Firefox has added the font-tech() and font-format() functions to feature queries with @supports. The following example tests for support of COLRv1 fonts.

@supports font-tech(color-COLRv1) {

}

You can find more examples on MDN.

Scroll to text fragment #

Safari 16.1 includes support for scroll to text fragment which adds support for navigating to a URL with a particular text fragment specified.

AVIF support #

Safari 16 included support for still AVIF images, Safari 16.1 includes support for animated AVIF images on macOS Ventura, iOS 16, and iPadOS 16.

Web Push for Safari #

Safari 16.1 brings Web Push support to Safari on macOS Ventura. This uses the Push API and Notifications API, you can read more about this in the article Meet Web Push. Web Push landing in Safari means that it is now available across all three major engines.

Beta browser releases #

figure {
    break-inside: avoid;
}

Chrome 108 starts to roll out a change to the way overflow behaves on replaced elements, which may cause visual changes in some circumstances. Read the article A change to overflow on replaced elements in CSS for more details and to see how to address any issues you see.

There's a change to how the Layout Viewport behaves in Chrome on Android when the on-screen keyboard is shown. Read Prepare for viewport resize behavior changes coming to Chrome on Android to learn more and find out how to prepare for this shipping to stable next month.

Also in Chrome are the new CSS Viewport Units. These include small (svw, svh, svi, svb, svmin, svmax), large (lvw, lvh, lvi, lvb, lvmin, lvmax), dynamic (dvw, dvh, dvi, dvb, dvmin, dvmax), and logical (vi, vb) units. These units are already implemented in Firefox and Safari.

Firefox 107 enables COLRv1 font support, joining Chrome in supporting this font technology. Also in fonts, Chrome 108 adds support for the font-tech() and font-format() functions to feature queries with @supports.

Firefox also adds contain-intrinsic-size support, joining Chrome to make two browsers with support for this feature.

Safari 16.2 Beta includes a bunch of CSS fixes including sizing and scroll snap.

Photo by ahmed zid.

Building Chrometober!

2022-10-31T00:00:00Z

Following on from Designcember, we wanted to build Chrometober for you this year as a way to highlight and share web content from the community and Chrome team. Designcember showcased the use of Container Queries, but this year we're showcasing the CSS scroll-linked animations API.

Check out the scrolling book experience at web.dev/chrometober-2022.

Overview #

The goal of the project was to deliver a whimsical experience highlighting the scroll-linked animations API. But, whilst being whimsical, the experience needed to be responsive and accessible too. The project has also been a great way to test drive the API polyfill that is in active development; that, as well as trying different techniques and tools in combination. And all with a festive Halloween theme!

Our team structure looked like this:

Tyler Reed: Illustration and design
Jhey Tompkins: Architectural and creative lead
Una Kravets: Project lead
Bramus Van Damme: Site contributor
Adam Argyle: Accessibility review
Aaron Forinton: Copywriting

Drafting a scrollytelling experience #

The ideas for Chrometober started flowing at our first team offsite back in May 2022. A collection of scribbles had us thinking of ways in which a user could scroll their way along some form of storyboard. Inspired by video games, we considered a scrolling experience through scenes such as graveyards and a haunted house.

It was exciting to have the creative freedom to take my first Google project in an unexpected direction. This was an early prototype of how a user might navigate through the content.

As the user scrolls sideways, the blocks rotate and scale in. But I decided to move away from this idea out of concern for how we could make this experience great for users on devices of all sizes. Instead, I leaned towards the design of something I'd made in the past. In 2020, I was fortunate to have access to GreenSock's ScrollTrigger to build release demos.

One of the demos I’d built was a 3D-CSS book where the pages turned as you scrolled, and this felt much more appropriate for what we wanted for Chrometober. The scroll-linked animations API is a perfect swap for that functionality. It also works well with scroll-snap, as you'll see!

Our illustrator for the project, Tyler Reed, was great at altering the design as we changed ideas. Tyler did a fantastic job of taking all the creative ideas thrown at him and bringing them to life. It was a lot of fun brainstorming ideas together. A big part of how we wanted this to work was having features broken up into isolated blocks. That way, we could compose them into scenes and then pick and choose what we brought to life.

The main idea was that, as the user made their way through the book, they could access blocks of content. They could also interact with dashes of whimsy, including the Easter eggs we had built into the experience; for example, a portrait in a haunted house, whose eyes followed your pointer, or subtle animations triggered by media queries. These ideas and features would be animated on scroll. An early idea was a zombie bunny that would rise and translate along the x-axis on user scroll.

Getting familiar with the API #

Before we could start playing with individual features and Easter eggs, we needed a book. So we decided to turn this into a chance to test the featureset for the emerging, CSS scroll-linked animations API. The scroll-linked animations API is not currently supported in any browsers. However, while developing the API, the engineers on the interactions team have been working on a polyfill. This provides a way to test out the shape of the API as it develops. That means we could use this API today, and fun projects like this are often a great place to try out experimental features, and to provide feedback. Find out what we learned and the feedback we were able to provide, later in the article.

At a high level, you can use this API to link animations to scroll. It's important to note that you can't trigger an animation on scroll—this is something that could come later. Scroll-linked animations also fall into two main categories:

Those that react to scroll position.
Those that react to an element's position in its scrolling container.

To create the latter, we use a ViewTimeline applied via an animation-timeline property.

Here's an example of what using ViewTimeline looks like in CSS:

.element-moving-in-viewport {
  view-timeline-name: foo;
  view-timeline-axis: block;
}

.element-scroll-linked {
  animation: rotate both linear;
  animation-timeline: foo;
  animation-delay: enter 0%;
  animation-end-delay: cover 50%;
}

@keyframes rotate {
 to {
   rotate: 360deg;
 }
}

We create a ViewTimeline with view-timeline-name and define the axis for it. In this example, block refers to logical block. The animation gets linked to scroll with the animation-timeline property. animation-delay and animation-end-delay (at the time of writing) are how we define phases.

These phases define the points at which the animation should get linked in relation to an element's position in its scrolling container. In our example, we're saying start the animation when the element enters (enter 0%) the scrolling container. And finish when it has covered 50% (cover 50%) of the scrolling container.

Here's our demo in action:

You could also link an animation to the element that is moving in the viewport. You can do this by setting the animation-timeline to be the element's view-timeline. This is good for scenarios such as list animations. The behavior is similar to how you might animate elements upon entry using IntersectionObserver.

element-moving-in-viewport {
  view-timeline-name: foo;
  view-timeline-axis: block;
  animation: scale both linear;
  animation-delay: enter 0%;
  animation-end-delay: cover 50%;
  animation-timeline: foo;
}

@keyframes scale {
  0% {
    scale: 0;
  }
}

With this,"Mover" scales up as it enters the viewport, triggering the rotation of "Spinner".

What I found from experimenting was that the API works very well with scroll-snap. Scroll-snap combined with ViewTimeline would be a great fit for snapping page turns in a book.

Prototyping the mechanics #

After some experimenting, I was able to get a book prototype working. You scroll horizontally to turn the pages of the book.

In the demo, you can see the different triggers highlighted with dashed borders.

The markup looks a little like this:

<body>
  <div class="book-placeholder">
    <ul class="book" style="--count: 7;">
      <li
        class="page page--cover page--cover-front"
        data-scroll-target="1"
        style="--index: 0;"
      >
        <div class="page__paper">
          <div class="page__side page__side--front"></div>
          <div class="page__side page__side--back"></div>
        </div>
      </li>
      <!-- Markup for other pages here -->
    </ul>
  </div>
  <div>
    <p>intro spacer</p>
  </div>
  <div data-scroll-intro>
    <p>scale trigger</p>
  </div>
  <div data-scroll-trigger="1">
    <p>page trigger</p>
  </div>
  <!-- Markup for other triggers here -->
</body>

As you scroll, the pages of the book turn, but snap open or closed. This is dependent on the scroll-snap alignment of the triggers.

html {
  scroll-snap-type: x mandatory;
}

body {
  grid-template-columns: repeat(var(--trigger-count), auto);
  overflow-y: hidden;
  overflow-x: scroll;
  display: grid;
}

body > [data-scroll-trigger] {
  height: 100vh;
  width: clamp(10rem, 10vw, 300px);
}

body > [data-scroll-trigger] {
  scroll-snap-align: end;
}

This time, we do not connect the ViewTimeline in CSS, but use the Web Animations API in JavaScript. This has the added benefit of being able to loop over a set of elements and generate the ViewTimeline we need, instead of creating them each by hand.

const triggers = document.querySelectorAll("[data-scroll-trigger]")

const commonProps = {
  delay: { phase: "enter", percent: CSS.percent(0) },
  endDelay: { phase: "enter", percent: CSS.percent(100) },
  fill: "both"
}

const setupPage = (trigger, index) => {
  const target = document.querySelector(
    `[data-scroll-target="${trigger.getAttribute("data-scroll-trigger")}"]`
  );

  const viewTimeline = new ViewTimeline({
    subject: trigger,
    axis: 'inline',
  });

  target.animate(
    [
      {
        transform: `translateZ(${(triggers.length - index) * 2}px)`
      },
      {
        transform: `translateZ(${(triggers.length - index) * 2}px)`,
        offset: 0.75
      },
      {
        transform: `translateZ(${(triggers.length - index) * -1}px)`
      }
    ],
    {
      timeline: viewTimeline,
      …commonProps,
    }
  );
  target.querySelector(".page__paper").animate(
    [
      {
        transform: "rotateY(0deg)"
      },
      {
        transform: "rotateY(-180deg)"
      }
    ],
    {
      timeline: viewTimeline,
      …commonProps,
    }
  );
};

const triggers = document.querySelectorAll('[data-scroll-trigger]')
triggers.forEach(setupPage);

For each trigger, we generate a ViewTimeline. Then we animate the trigger's associated page using that ViewTimeline. That links the page's animation to scroll. For our animation, we are rotating an element of the page on the y-axis to turn the page. We also translate the page itself on the z-axis so it behaves like a book.

Putting it all together #

Once I'd worked out the mechanism for the book, I could focus on bringing Tyler's illustrations to life.

Astro #

The team used Astro for Designcember in 2021 and I was keen to use it again for Chrometober. The developer experience of being able to break things up into components is well suited to this project.

The book itself is a component. It is also a collection of page components. Each page has two sides and they have backdrops. The children of a page side are components which can be added, removed, and positioned with ease.

Building a book #

It was important for me to make the blocks easy to manage. I also wanted to make it easy for the rest of the team to make contributions.

The pages at a high level are defined by a configuration array. Each page object in the array defines the content, backdrop, and other metadata for a page.

const pages = [
  {
    front: {
      marked: true,
      content: PageTwo,
      backdrop: spreadOne,
      darkBackdrop: spreadOneDark
    },
    back: {
      content: PageThree,
      backdrop: spreadTwo,
      darkBackdrop: spreadTwoDark
    },
    aria: `page 1`
  },
  /* Obfuscated page objects */
]

These get passed to the Book component.

<Book pages={pages} />

The Book component is where the scrolling mechanism is applied and the pages of the book are created. The same mechanism from the prototype is used; but we share multiple instances of ViewTimeline that are created globally.

window.CHROMETOBER_TIMELINES.push(viewTimeline);

This way, we can share the timelines to be used elsewhere instead of recreating them. More on this later.

Page composition #

Each page is a list item inside a list:

<ul class="book">
  {
    pages.map((page, index) => {
      const FrontSlot = page.front.content
      const BackSlot = page.back.content
      return (
        <Page
          index={index}
          cover={page.cover}
          aria={page.aria}
          backdrop={
            {
              front: {
                light: page.front.backdrop,
                dark: page.front.darkBackdrop
              },
              back: {
                light: page.back.backdrop,
                dark: page.back.darkBackdrop
              }
            }
          }>
          {page.front.content && <FrontSlot slot="front" />}    
          {page.back.content && <BackSlot slot="back" />}    
        </Page>
      )
    })
  }
</ul>

And the defined configuration gets passed to each Page instance. The pages use Astro's slot feature to insert content into each page.

<li
  class={className}
  data-scroll-target={target}
  style={`--index:${index};`}
  aria-label={aria}
>
  <div class="page__paper">
    <div
      class="page__side page__side--front"
      aria-label={`Right page of ${index}`}
    >
      <picture>
        <source
          srcset={darkFront}
          media="(prefers-color-scheme: dark)"
          height="214"
          width="150"
        >
        <img
          src={lightFront}
          class="page__background page__background--right"
          alt=""
          aria-hidden="true"
          height="214"
          width="150"
        >
      </picture>
      <div class="page__content">
        <slot name="front" />
      </div>
    </div>
    <!-- Markup for back page -->
  </div>
</li>

This code is mostly for setting up structure. Contributors can work on the book’s content for the most part without having to touch this code.

Backdrops #

The creative shift towards a book made splitting up the sections much easier, and each spread of the book is a scene taken from the original design.

As we had decided on an aspect ratio for the book, the backdrop for each page could have a picture element. Setting that element to 200% width and using object-position based on page side does the trick.

.page__background {
  height: 100%;
  width: 200%;
  object-fit: cover;
  object-position: 0 0;
  position: absolute;
  top: 0;
  left: 0;
}

.page__background--right {
  object-position: 100% 0;
}

Page content #

Let's look at building out one of the pages. Page three features an owl that pops up in a tree.

It gets populated with a PageThree component, as defined in the configuration. It’s an Astro component (PageThree.astro). These components look like HTML files but they have a code fence at the top similar to frontmatter. This enables us to do things like import other components. The component for page three looks like this:

---
import TreeOwl from '../TreeOwl/TreeOwl.astro'
import { contentBlocks } from '../../assets/content-blocks.json'
import ContentBlock from '../ContentBlock/ContentBlock.astro'
---
<TreeOwl/>
<ContentBlock {...contentBlocks[3]} id="four" />

<style is:global>
  .content-block--four {
    left: 30%;
    bottom: 10%;
  }
</style>

Again, pages are atomic in nature. They are built from a collection of features. Page three features a content block and the interactive owl, so there is a component for each.

Content blocks are the links to content seen within the book. These are also driven by a configuration object.

{
 "contentBlocks": [
    {
      "id": "one",
      "title": "New in Chrome",
      "blurb": "Lift your spirits with a round up of all the tools and features in Chrome.",
      "link": "https://www.youtube.com/watch?v=qwdN1fJA_d8&list=PLNYkxOF6rcIDfz8XEA3loxY32tYh7CI3m"
    },
    …otherBlocks
  ]
}

This configuration gets imported where content blocks are required. Then the relevant block configuration gets passed to the ContentBlock component.

<ContentBlock {...contentBlocks[3]} id="four" />

There is also an example here of how we use the page's component as a place to position the content. Here, a content block gets positioned.

<style is:global>
  .content-block--four {
    left: 30%;
    bottom: 10%;
  }
</style>

But, the general styles for a content block are co-located with the component code.

.content-block {
  background: hsl(0deg 0% 0% / 70%);
  color: var(--gray-0);
  border-radius:  min(3vh, var(--size-4));
  padding: clamp(0.75rem, 2vw, 1.25rem);
  display: grid;
  gap: var(--size-2);
  position: absolute;
  cursor: pointer;
  width: 50%;
}

As for our owl, it's an interactive feature—one of many in this project. This is a nice small example to go through that shows how we used the shared ViewTimeline that we created.

At a high level, our owl component imports some SVG and inlines it using Astro's Fragment.

---
import { default as Owl } from '../Features/Owl.svg?raw'
---
<Fragment set:html={Owl} />

And the styles for positioning our owl are co-located with the component code.

.owl {
  width: 34%;
  left: 10%;
  bottom: 34%;
}

There is one extra piece of styling that defines the transform behavior for the owl.

.owl__owl {
  transform-origin: 50% 100%;
  transform-box: fill-box;
}

The use of transform-box affects the transform-origin. It makes it relative to the object’s bounding box within the SVG. The owl scales up from the bottom center, hence the use of transform-origin: 50% 100%.

The fun part is when we link the owl up to one of our generated ViewTimelines:

const setUpOwl = () => {
   const owl = document.querySelector('.owl__owl');

   owl.animate([
     {
       translate: '0% 110%',
     },
     {
       translate: '0% 10%',
     },
   ], {
     timeline: CHROMETOBER_TIMELINES[1],
     delay: { phase: "enter", percent: CSS.percent(80) },
     endDelay: { phase: "enter", percent: CSS.percent(90) },
     fill: 'both' 
   });
 }

 if (window.matchMedia('(prefers-reduced-motion: no-preference)').matches)
   setUpOwl()

In this block of code, we do two things:

Check for the user’s motion preferences.
If they have no preference, link an animation of the owl to scroll.

For the second part, the owl animates on the y-axis using the Web Animations API. Individual transform property translate is used, and is linked to one ViewTimeline. It's linked to CHROMETOBER_TIMELINES[1] via the timeline property. This is a ViewTimeline that is generated for the page turns. This links the owl's animation to the page turn using the enter phase. It defines that, when the page is 80% turned, start moving the owl. At 90%, the owl should finish its translation.

Book features #

Now you've seen the approach for building a page and how the project architecture works. You can see how it allows contributors to jump in and work on a page or feature of their choosing. Various features in the book have their animations linked to the book's page turning; for example, the bat that flies in and out on page turns.

It also has elements that are powered by CSS animations.

Once the content blocks were in the book, there was time to get creative with other features. This provided an opportunity to generate some different interactions, and try different ways to implement things.

Keeping things responsive #

Responsive viewport units size the book and its features. However, keeping fonts responsive was an interesting challenge. Container query units are a good fit here. They aren't supported everywhere yet, though. The size of the book is set, so we don't need a container query. An inline container query unit can be generated with CSS calc() and used for font sizing.


.book-placeholder {
  --size: clamp(12rem, 72vw, 80vmin);
  --aspect-ratio: 360 / 504;
  --cqi: calc(0.01 * (var(--size) * (var(--aspect-ratio))));
}

.content-block h2 {
  color: var(--gray-0);
  font-size: clamp(0.6rem, var(--cqi) * 4, 1.5rem);
}

.content-block :is(p, a) {
  font-size: clamp(0.6rem, var(--cqi) * 3, 1.5rem);
}

Pumpkins shine at night #

Those with a keen eye may have noticed the use of <source> elements when discussing the page backdrops earlier. Una was keen to have an interaction that reacted to color scheme preference. As a result, the backdrops support both light and dark modes with different variants. Because you can use media queries with the <picture> element, it's a great way to provide two backdrop styles. The <source> element queries for color scheme preference, and shows the appropriate backdrop.

<picture>
  <source srcset={darkFront} media="(prefers-color-scheme: dark)" height="214" width="150">
  <img src={lightFront} class="page__background page__background--right" alt="" aria-hidden="true" height="214" width="150">
</picture>

You could introduce other changes based on that color scheme preference. The pumpkins on page two react to a user's color scheme preference. The SVG used has circles that represent flames, which scale up and animate in dark mode.

.pumpkin__flame,
 .pumpkin__flame circle {
   transform-box: fill-box;
   transform-origin: 50% 100%;
 }

 .pumpkin__flame {
   scale: 0.8;
 }

 .pumpkin__flame circle {
   transition: scale 0.2s;
   scale: 0;
 }

@media(prefers-color-scheme: dark) {
   .pumpkin__flame {
     animation: pumpkin-flicker 3s calc(var(--index, 0) * -1s) infinite linear;
   }

   .pumpkin__flame circle {
     scale: 1;
   }

   @keyframes pumpkin-flicker {
     50% {
       scale: 1;
     }
   }
 }

Is this portrait watching you? #

If you check out page 10, you might notice something. You're being watched! The eyes of the portrait will follow your pointer as you move around the page. The trick here is to map the pointer location to a translate value, and pass it through to CSS.

const mapRange = (inputLower, inputUpper, outputLower, outputUpper, value) => {
   const INPUT_RANGE = inputUpper - inputLower
   const OUTPUT_RANGE = outputUpper - outputLower
   return outputLower + (((value - inputLower) / INPUT_RANGE) * OUTPUT_RANGE || 0)
 }

This code takes input and output ranges, and maps the given values. For example, this usage would give the value 625.

mapRange(0, 100, 250, 1000, 50) // 625

For the portrait, the input value is the center point of each eye, plus or minus some pixel distance. The output range is how much the eyes can translate in pixels. And then the pointer position on the x or y axis gets passed as the value. To get the center point of the eyes while moving them, the eyes are duplicated. The originals don't move, are transparent, and used for reference.

Then it's a case of tying it together and updating the CSS custom property values on the eyes so the eyes can move. A function is bound to the pointermove event against the window. As this fires, the bounds of each eye get used to calculate the center points. Then the pointer position is mapped to values that are set as custom property values on the eyes.

const RANGE = 15
const LIMIT = 80
const interact = ({ x, y }) => {
   // map a range against the eyes and pass in via custom properties
   const LEFT_EYE_BOUNDS = LEFT_EYE.getBoundingClientRect()
   const RIGHT_EYE_BOUNDS = RIGHT_EYE.getBoundingClientRect()

   const CENTERS = {
     lx: LEFT_EYE_BOUNDS.left + LEFT_EYE_BOUNDS.width * 0.5,
     rx: RIGHT_EYE_BOUNDS.left + RIGHT_EYE_BOUNDS.width * 0.5,
     ly: LEFT_EYE_BOUNDS.top + LEFT_EYE_BOUNDS.height * 0.5,
     ry: RIGHT_EYE_BOUNDS.top + RIGHT_EYE_BOUNDS.height * 0.5,
   }

   Object.entries(CENTERS)
     .forEach(([key, value]) => {
       const result = mapRange(value - LIMIT, value + LIMIT, -RANGE, RANGE)(key.indexOf('x') !== -1 ? x : y)
       EYES.style.setProperty(`--${key}`, result)
     })
 }

Once the values are passed to CSS, the styles can do what they want with them. The great part here is using CSS clamp() to make the behavior different for each eye, so you can make each eye behave differently without touching the JavaScript again.

.portrait__eye--mover {
   transition: translate 0.2s;
 }

 .portrait__eye--mover.portrait__eye--left {
   translate:
     clamp(-10px, var(--lx, 0) * 1px, 4px)
     clamp(-4px, var(--ly, 0) * 0.5px, 10px);
 }

 .portrait__eye--mover.portrait__eye--right {
   translate:
     clamp(-4px, var(--rx, 0) * 1px, 10px)
     clamp(-4px, var(--ry, 0) * 0.5px, 10px);
 }

Casting spells #

If you check out page six, do you feel spellbound? This page embraces the design of our fantastic magical fox. If you move your pointer around, you may see a custom cursor trail effect. This uses canvas animation. A <canvas> element sits above the rest of the page content with pointer-events: none. This means users can still click the content blocks underneath.

.wand-canvas {
  height: 100%;
  width: 200%;
  pointer-events: none;
  right: 0;
  position: fixed;
}

Much like how our portrait listens for a pointermove event on window, so does our <canvas> element. Yet each time the event fires, we're creating an object to animate on the <canvas> element. These objects represent shapes used in the cursor trail. They have coordinates and a random hue.

Our mapRange function from earlier is used again, as we can use it to map the pointer delta to size and rate. The objects are stored in an array that gets looped over when the objects are drawn to the <canvas> element. The properties for each object tell our <canvas> element where things should be drawn.

const blocks = []
  const createBlock = ({ x, y, movementX, movementY }) => {
    const LOWER_SIZE = CANVAS.height * 0.05
    const UPPER_SIZE = CANVAS.height * 0.25
    const size = mapRange(0, 100, LOWER_SIZE, UPPER_SIZE, Math.max(Math.abs(movementX), Math.abs(movementY)))
    const rate = mapRange(LOWER_SIZE, UPPER_SIZE, 1, 5, size)
    const { left, top, width, height } = CANVAS.getBoundingClientRect()
    
    const block = {
      hue: Math.random() * 359,
      x: x - left,
      y: y - top,
      size,
      rate,
    }
    
    blocks.push(block)
  }
window.addEventListener('pointermove', createBlock)

For drawing to the canvas, a loop is created with requestAnimationFrame. The cursor trail should only render when the page is in view. We have an IntersectionObserver that updates and determines which pages are in view. If a page is in view, the objects are rendered as circles on the canvas.

We then loop over the blocks array and draw each part of the trail. Each frame reduces the size and alters the position of the object by the rate. This produces that falling and scaling effect. If the object shrinks completely, the object is removed from the blocks array.

let wandFrame
const drawBlocks = () => {
   ctx.clearRect(0, 0, CANVAS.width, CANVAS.height)
  
   if (PAGE_SIX.className.indexOf('in-view') === -1 && wandFrame) {
     blocks.length = 0
     cancelAnimationFrame(wandFrame)
     document.body.removeEventListener('pointermove', createBlock)
     document.removeEventListener('resize', init)
   }
  
   for (let b = 0; b < blocks.length; b++) {
     const block = blocks[b]
     ctx.strokeStyle = ctx.fillStyle = `hsla(${block.hue}, 80%, 80%, 0.5)`
     ctx.beginPath()
     ctx.arc(block.x, block.y, block.size * 0.5, 0, 2 * Math.PI)
     ctx.stroke()
     ctx.fill()

     block.size -= block.rate
     block.y += block.rate

     if (block.size <= 0) {
       blocks.splice(b, 1)
     }

   }
   wandFrame = requestAnimationFrame(drawBlocks)
 }

If the page goes out of view, event listeners are removed and the animation frame loop is canceled. The blocks array is also cleared.

Here's the cursor trail in action!

Accessibility review #

It's all good creating a fun experience to explore, but it's no good if it isn't accessible to users. Adam's expertise in this area proved invaluable in getting Chrometober prepared for an accessibility review before release.

Some of the notable areas covered:

Ensuring that the HTML used was semantic. This included things like appropriate landmark elements such as <main> for the book; aso the use of the <article> element for each content block, and <abbr> elements where acronyms are introduced. Thinking ahead as the book was built made things more accessible. The use of headings and links makes it easier for a user to navigate. The use of a list for the pages also means the number of pages is announced by assistive technology.
Ensuring that all images use appropriate alt attributes. For inline SVGs, the title element is present where necessary.
Using aria attributes where they improve the experience. The use of aria-label for pages and their sides communicates to the user which page they are on. The use of aria-describedBy on the "Read more" links communicates the text of the content block. This removes ambiguity about where the link will take the user.
On the subject of content blocks, the ability to click the whole card and not only the "Read more" link is available.
The use of an IntersectionObserver to track which pages are in view came up earlier. This has many benefits that aren't just performance related. Pages not in view will have any animation or interaction paused. But these pages also have the inert attribute applied. This means that users using a screen reader can explore the same content as sighted users. Focus remains within the page that's in view and users can't tab to another page.
Last but not least, we make use of media queries to respect a user's preference for motion.

Here's a screenshot from the review highlighting some of the measures in place.

What we learned #

The motivation behind Chrometober was not only to highlight web content from the community, but was also a way for us to test drive the scroll-linked animations API polyfill that's in development.

We set aside a session while on our team summit in New York to test the project and tackle issues that arose. The team's contribution was invaluable. It was also a great opportunity to list all the things that needed tackling before we could go live.

For example, testing out the book on devices raised a rendering issue. Our book wouldn't render as expected on iOS devices. Viewport units size the page, but when a notch was present, it affected the book. The solution was to use viewport-fit=cover in the meta viewport:

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover" />

This session also raised some issues with the API polyfill. Bramus raised these issues in the polyfill repository. He subsequently found solutions to those issues and got them merged into the polyfill. For example, this pull request made a performance gain by adding caching to part of the polyfill.

That's it! #

This has been a real fun project to work on, resulting in a whimsical scrolling experience that highlights amazing content from the community. Not only that, it's been great for testing the polyfill, as well as providing feedback to the engineering team to help improve the polyfill.

Chrometober 2022 is a wrap.

We hope you enjoyed it! What's your favorite feature? Tweet me and let us know!

You might even be able to grab some stickers from one of the team if you see us at an event.

Hero Photo by David Menidrey on Unsplash

CSS Animated Grid Layouts

2022-10-25T00:00:00Z

Browser support: 107 66 107 16

Value Interpolation in CSS #

In CSS you can smoothly transition properties from one value to the other using the transition property.

#target {
  opacity: 0.5;
  transition: opacity ease-in-out 0.25s;
}

#target:hover {
  opacity: 1;
}

The rendering engine will automatically detect the type of the targeted property’s value, and use that information to smoothly transition to the new value.

For example:

Transitioning opacity from 0 to 1? That’s a numerical interpolation.
Transitioning background-color from white to black? Fade between the source and target colors.
Transitioning width? Interpolate numerically, converting units along the way if needed.

The same applies to CSS animations, where the browser will do value interpolation between keyframes.

Interpolating `grid-template-columns` and `grid-template-rows` #

Thanks to our contributors at Microsoft, Chrome–as of version 107–is able to interpolate grid-template-columns and grid-template-rows values.

Grid layouts can smoothly transition between states, instead of snapping at the halfway point of an animation or transition.

In the demo below a grid is showing several avatars. To conserve space, the avatars are laid out on top of each other by limiting the width of each column using grid-template-columns. On hover, each column is given more space.

.avatars {
  display: grid;
  gap: 0.35em;

  grid-auto-flow: column;
  grid-template-columns: repeat(4, 2em);
  transition: all ease-in-out 0.25s;
}

.avatars:hover {
  grid-template-columns: repeat(4, 4em);
}

With the transition property in place, the grid smoothly interpolates between values.

The effect also applies to animations that change the grid-template-columns or grid-template-rows values.

Photo by Ernest Ojeh on Unsplash

Building a tooltip component

2022-10-25T00:00:00Z

In this post I want to share my thoughts on how to build a color-adaptive and accessible <tool-tip> custom element. Try the demo and view the source!

A tooltip is shown working across a variety of examples and color schemes

If you prefer video, here's a YouTube version of this post:

Overview #

A tooltip is a non-modal, non-blocking, non-interactive overlay containing supplemental information to user interfaces. It is hidden by default and becomes unhidden when an associated element is hovered or focused. A tooltip can't be selected or interacted with directly. Tooltips are not replacements for labels or other high value information, a user should be able to fully complete their task without a tooltip.

Do: always label your inputs.
Don't: rely on tooltips instead of labels

Like many components, there are varying descriptions of what a tooltip is, for example in MDN, WAI ARIA, Sarah Higley, and Inclusive Components. I like the separation between tooltips and toggletips. A tooltip should contain non-interactive supplemental information, while a toggletip can contain interactivity and important information. The primary reason for the divide is accessibility, how are users expected to navigate to the popup and have access to the information and buttons within. Toggletips get complex quickly.

Here's a video of a toggletip from the Designcember site; an overlay with interactivity that a user can pin open and explore, then close with light dismiss or the escape key:

This GUI Challenge went the route of a tooltip, looking to do almost everything with CSS, and here's how to build it.

Markup #

I chose to use a custom element <tool-tip>. Authors don't need to make custom elements into web components if they don't want to. The browser will treat <foo-bar> just like a <div>. You could think of a custom element like a classname with less specificity. There's no JavaScript involved.

<tool-tip>A tooltip</tool-tip>

This is like a div with some text inside. We can tie into the accessibility tree of capable screen readers by adding [role="tooltip"].

<tool-tip role="tooltip">A tooltip</tool-tip>

Now, to screen readers, it's recognized as a tooltip. See in the following example how the first link element has a recognized tooltip element in its tree and the second does not? The second one doesn't have the role. In the styles section we'll improve upon this tree view.

Next we need the tooltip to not be focusable. If a screen reader doesn't understand the tooltip role it will allow users to focus the <tool-tip> to read the contents, and the user experience doesn't need this. Screen readers will append the content to the parent element and as such, it doesn't need focus to be made accessible. Here we can use inert to ensure no users will accidentally find this tooltip content in their tab flow:

<tool-tip inert role="tooltip">A tooltip</tool-tip>

I then chose to use attributes as the interface to specify the position of the tooltip. By default all the <tool-tip>s will assume a "top" position, but the position can be customized on an element by adding tip-position:

<tool-tip role="tooltip" tip-position="right ">A tooltip</tool-tip>

I tend to use attributes instead of classes for things like this so that the <tool-tip> can't have multiple positions assigned to it at the same time. There can be only one or none.

Finally, place <tool-tip> elements inside of the element you wish to provide a tooltip for. Here I share the alt text with sighted users by placing an image and a <tool-tip> inside of a <picture> element:

<picture>
  <img alt="The GUI Challenges skull logo" width="100" src="...">
  <tool-tip role="tooltip" tip-position="bottom">
    The <b>GUI Challenges</b> skull logo
  </tool-tip>
</picture>

Here I place a <tool-tip> inside of an <abbr> element:

<p>
  The <abbr>HTML <tool-tip role="tooltip" tip-position="top">Hyper Text Markup Language</tool-tip></abbr> abbr element.
</p>

Accessibility #

Since I've chosen to build tooltips and not toggletips, this section is much simpler. First, let me outline what our desired user experience:

In constrained spaces or cluttered interfaces, hide supplemental messages.
When a user hovers, focuses or uses touch to interact with an element, reveal the message.
When hover, focus or touch ends, hide the message again.
Lastly, ensure any motion is reduced if a user has specified a preference for reduced motion.

Our goal is on demand supplemental messaging. A sighted mouse or keyboard user can hover to reveal the message, reading it with their eyes. A non-sighted screen reader user can focus to reveal the message, audibly receiving it through their tool.

Screenshot of MacOS VoiceOver reading a link with a tooltip

In the previous section we covered the accessibility tree, the tooltip role and inert, what's left is to test it and verify the user experience appropriately reveals the tooltip message to the user. Upon testing, it's unclear as to which part of the audible message is a tooltip. It can be seen while debugging in the accessibility tree too, the link text of "top" is run together, without hesitation, with "Look, tooltips!". The screen reader doesn't break or identify the text as tooltip content.

Add a screen reader only pseudo-element to the <tool-tip> and we can add our own prompt text for non-sighted users.

&::before {
  content: "; Has tooltip: ";
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  height: 1px;
  width: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
}

Below you can see the updated accessibility tree, which now has a semicolon after the link text and a prompt for the tooltip "Has tooltip: ".

Now, when a screen reader user focuses the link, it says "top" and takes a small pause, then announces "has tooltip: look, tooltips". This gives a screen reader user a couple nice UX hints. The hesitation gives a nice separation between the link text and the tooltip. Plus, when "has tooltip" is announced, a screen reader user can easily cancel it if they've already heard it before. It's very reminiscent to hovering and unhovering quickly, as you've already seen the supplemental message. This felt like nice UX parity.

Styles #

The <tool-tip> element will be a child of the element it's representing supplemental messaging for, so let's first start with the essentials for the overlay effect. Take it out of document flow with position absolute:

tool-tip {
  position: absolute;
  z-index: 1;
}

If the parent is not a stacking context, the tooltip will position itself to the nearest one that is, which isn't what we want. There's a new selector on the block that can help, :has():

Browser support: 105 ⚑ 105 15.4 Source

:has(> tool-tip) {
  position: relative;
}

Don't worry too much about the browser support. First, remember these tooltips are supplementary. If they don't work it should be fine. Second, in the JavaScript section we'll deploy a script to polyfill the functionality we need for browsers without :has() support.

Next, let's make the tooltips non-interactive so they don’t steal pointer events from their parent element:

tool-tip {
  …
  pointer-events: none;
  user-select: none;
}

Then, hide the tooltip with opacity so we can transition the tooltip with a crossfade:

tool-tip {
  opacity: 0;
}

:has(> tool-tip):is(:hover, :focus-visible, :active) > tool-tip {
  opacity: 1;
}

:is() and :has() do the heavy lifting here, making tool-tip containing parent elements aware of user interactivity as to toggle the visibility of a child tooltip. Mouse users can hover, keyboard and screen reader users can focus, and touch users can tap.

With the show and hide overlay working for sighted users, it's time to add some styles for theming, positioning and adding the triangle shape to the bubble. The following styles begin using custom properties, building upon where we are so far but also adding shadows, typography and colors so it looks like a floating tooltip:

tool-tip {
  --_p-inline: 1.5ch;
  --_p-block: .75ch;
  --_triangle-size: 7px;
  --_bg: hsl(0 0% 20%);
  --_shadow-alpha: 50%;

  --_bottom-tip: conic-gradient(from -30deg at bottom, rgba(0,0,0,0), #000 1deg 60deg, rgba(0,0,0,0) 61deg) bottom / 100% 50% no-repeat;
  --_top-tip: conic-gradient(from 150deg at top, rgba(0,0,0,0), #000 1deg 60deg, rgba(0,0,0,0) 61deg) top / 100% 50% no-repeat;
  --_right-tip: conic-gradient(from -120deg at right, rgba(0,0,0,0), #000 1deg 60deg, rgba(0,0,0,0) 61deg) right / 50% 100% no-repeat;
  --_left-tip: conic-gradient(from 60deg at left, rgba(0,0,0,0), #000 1deg 60deg, rgba(0,0,0,0) 61deg) left / 50% 100% no-repeat;

  pointer-events: none;
  user-select: none;

  opacity: 0;
  transform: translateX(var(--_x, 0)) translateY(var(--_y, 0));
  transition: opacity .2s ease, transform .2s ease;

  position: absolute;
  z-index: 1;
  inline-size: max-content;
  max-inline-size: 25ch;
  text-align: start;
  font-size: 1rem;
  font-weight: normal;
  line-height: normal;
  line-height: initial;
  padding: var(--_p-block) var(--_p-inline);
  margin: 0;
  border-radius: 5px;
  background: var(--_bg);
  color: CanvasText;
  will-change: filter;
  filter:
    drop-shadow(0 3px 3px hsl(0 0% 0% / var(--_shadow-alpha)))
    drop-shadow(0 12px 12px hsl(0 0% 0% / var(--_shadow-alpha)));
}

/* create a stacking context for elements with > tool-tips */
:has(> tool-tip) {
  position: relative;
}

/* when those parent elements have focus, hover, etc */
:has(> tool-tip):is(:hover, :focus-visible, :active) > tool-tip {
  opacity: 1;
  transition-delay: 200ms;
}

/* prepend some prose for screen readers only */
tool-tip::before {
  content: "; Has tooltip: ";
  clip: rect(1px, 1px, 1px, 1px);
  clip-path: inset(50%);
  height: 1px;
  width: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
}

/* tooltip shape is a pseudo element so we can cast a shadow */
tool-tip::after {
  content: "";
  background: var(--_bg);
  position: absolute;
  z-index: -1;
  inset: 0;
  mask: var(--_tip);
}

/* top tooltip styles */
tool-tip:is(
  [tip-position="top"],
  [tip-position="block-start"],
  :not([tip-position]),
  [tip-position="bottom"],
  [tip-position="block-end"]
) {
  text-align: center;
}

Theme adjustments #

The tooltip only has a few colors to manage as the text color is inherited from the page via the system keyword CanvasText. Also, since we've made custom properties to store the values, we can update only those custom properties and let the theme handle the rest:

@media (prefers-color-scheme: light) {
  tool-tip {
    --_bg: white;
    --_shadow-alpha: 15%;
  }
}

For the light theme, we adapt the background to white and make the shadows much less strong by adjusting their opacity.

Right to left #

In order to support right to left reading modes, a custom property will store the value of the document direction into a value of -1 or 1 respectively.

tool-tip {
  --isRTL: -1;
}

tool-tip:dir(rtl) {
  --isRTL: 1;
}

This can be used to assist in positioning the tooltip:

tool-tip[tip-position="top"]) {
  --_x: calc(50% * var(--isRTL));
}

As well as assist in where the triangle is:

tool-tip[tip-position="right"]::after {
  --_tip: var(--_left-tip);
}

tool-tip[tip-position="right"]:dir(rtl)::after {
  --_tip: var(--_right-tip);
}

Lastly, can also be used for logical transforms on translateX():

--_x: calc(var(--isRTL) * -3px * -1);

Position the tooltip logically with the inset-block or inset-inline properties to handle both the physical and logical tooltip positions. The following code shows how each of the four positions are styled for both left-to-right and right-to-left directions.

Top and block-start alignment #

tool-tip:is([tip-position="top"], [tip-position="block-start"], :not([tip-position])) {
  inset-inline-start: 50%;
  inset-block-end: calc(100% + var(--_p-block) + var(--_triangle-size));
  --_x: calc(50% * var(--isRTL));
}

tool-tip:is([tip-position="top"], [tip-position="block-start"], :not([tip-position]))::after {
  --_tip: var(--_bottom-tip);
  inset-block-end: calc(var(--_triangle-size) * -1);
  border-block-end: var(--_triangle-size) solid transparent;
}

Right and inline-end alignment #

tool-tip:is([tip-position="right"], [tip-position="inline-end"]) {
  inset-inline-start: calc(100% + var(--_p-inline) + var(--_triangle-size));
  inset-block-end: 50%;
  --_y: 50%;
}

tool-tip:is([tip-position="right"], [tip-position="inline-end"])::after {
  --_tip: var(--_left-tip);
  inset-inline-start: calc(var(--_triangle-size) * -1);
  border-inline-start: var(--_triangle-size) solid transparent;
}

tool-tip:is([tip-position="right"], [tip-position="inline-end"]):dir(rtl)::after {
  --_tip: var(--_right-tip);
}

Bottom and block-end alignment #

tool-tip:is([tip-position="bottom"], [tip-position="block-end"]) {
  inset-inline-start: 50%;
  inset-block-start: calc(100% + var(--_p-block) + var(--_triangle-size));
  --_x: calc(50% * var(--isRTL));
}

tool-tip:is([tip-position="bottom"], [tip-position="block-end"])::after {
  --_tip: var(--_top-tip);
  inset-block-start: calc(var(--_triangle-size) * -1);
  border-block-start: var(--_triangle-size) solid transparent;
}

Left and inline-start alignment #

tool-tip:is([tip-position="left"], [tip-position="inline-start"]) {
  inset-inline-end: calc(100% + var(--_p-inline) + var(--_triangle-size));
  inset-block-end: 50%;
  --_y: 50%;
}

tool-tip:is([tip-position="left"], [tip-position="inline-start"])::after {
  --_tip: var(--_right-tip);
  inset-inline-end: calc(var(--_triangle-size) * -1);
  border-inline-end: var(--_triangle-size) solid transparent;
}

tool-tip:is([tip-position="left"], [tip-position="inline-start"]):dir(rtl)::after {
  --_tip: var(--_left-tip);
}

Animation #

So far we've only toggled the visibility of the tooltip. In this section we'll first animate opacity for all users, as it's a generally safe reduced motion transition. Then we'll animate the transform position so the tooltip appears to slide out from the parent element.

A safe and meaningful default transition #

Style the tooltip element to transition opacity and transform, like this:

tool-tip {
  opacity: 0;
  transform: translateX(var(--_x, 0)) translateY(var(--_y, 0));
  transition: opacity .2s ease, transform .2s ease;
}

:has(> tool-tip):is(:hover, :focus-visible, :active) > tool-tip {
  opacity: 1;
  transition-delay: 200ms;
}

Adding motion to the transition #

For each of the sides a tooltip can appear on, if the user is ok with motion, slightly position the translateX property by giving it a small distance to travel from:

@media (prefers-reduced-motion: no-preference) {
  :has(> tool-tip:is([tip-position="top"], [tip-position="block-start"], :not([tip-position]))):not(:hover):not(:focus-visible):not(:active) tool-tip {
    --_y: 3px;
  }

  :has(> tool-tip:is([tip-position="right"], [tip-position="inline-end"])):not(:hover):not(:focus-visible):not(:active) tool-tip {
    --_x: -3px;
  }

  :has(> tool-tip:is([tip-position="bottom"], [tip-position="block-end"])):not(:hover):not(:focus-visible):not(:active) tool-tip {
    --_y: -3px;
  }

  :has(> tool-tip:is([tip-position="left"], [tip-position="inline-start"])):not(:hover):not(:focus-visible):not(:active) tool-tip {
    --_x: 3px;
  }
}

Notice this is setting the "out" state, as the "in" state is at translateX(0).

JavaScript #

In my opinion, the JavaScript is optional. This is because none of these tooltips should be required reading to accomplish a task in your UI. So if the tooltips completely fail, it should be no big deal. This also means we can treat the tooltips as progressively enhanced. Eventually all browsers will support :has() and this script can completely go away.

The polyfill script does two things, and does so only if the browser doesn't support :has(). First, check for :has() support:

if (!CSS.supports('selector(:has(*))')) {
  // do work
}

Next, find the parent elements of <tool-tip>s and give them a classname to work with:

if (!CSS.supports('selector(:has(*))')) {
  document.querySelectorAll('tool-tip').forEach(tooltip =>
    tooltip.parentNode.classList.add('has_tool-tip'))
}

Next, inject a set of styles that use that classname, simulating the :has() selector for the exact same behavior:

if (!CSS.supports('selector(:has(*))')) {
  document.querySelectorAll('tool-tip').forEach(tooltip =>
    tooltip.parentNode.classList.add('has_tool-tip'))

  let styles = document.createElement('style')
  styles.textContent = `
    .has_tool-tip {
      position: relative;
    }
    .has_tool-tip:is(:hover, :focus-visible, :active) > tool-tip {
      opacity: 1;
      transition-delay: 200ms;
    }
  `
  document.head.appendChild(styles)
}

That's it, now all browsers will happily show the tooltips if :has() is not supported.

Conclusion #

Now that you know how I did it, how would you‽ 🙂 I'm really looking forward to the popup API for making toggletips easier, top layer for no z-index battles, and the anchor API for positioning things in the window better. Until then, I'll be making tooltips.

Let's diversify our approaches and learn all the ways to build on the web.

Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Nothing to see here yet.

Resources #

Source code on Github

Building a Better Web - Part 1: A faster YouTube on web

2022-10-20T00:00:00Z

The Chrome team often talks about "building a better web", but what does that mean? Web experiences should be fast, accessible, and use device capabilities in the moment when users need it most. Dogfooding is part of Google's culture, so the Chrome team has partnered with YouTube to share lessons learned along the way in a new series called, "Building a better web". The first part of the series will dive into how YouTube built a faster web experience.

The YouTube for mobile web Watch page passing the Core Web Vitals thresholds.

Building a faster web #

At YouTube, performance relates to how fast videos and other content—such as recommendations and comments—load on web pages. Performance is also measured by how quickly YouTube responds to user interactions such as search, player control, likes, and shares.

Growing developing markets, such as Brazil, India, and Indonesia are important for YouTube mobile web. Because many users in these regions have slower devices and limited network bandwidth, ensuring a fast and seamless experience is a critical goal.

To provide an inclusive experience for all users, YouTube set out to improve performance metrics such as Core Web Vitals through lazy-loading and code modernization.

Improving Core Web Vitals #

To identify areas of improvement, the YouTube team used the Chrome User Experience Report (CrUX) to see how real users were experiencing video watch and search result pages on mobile in the field. They realized their Core Web Vitals metrics had a lot of room for improvement, with their Largest Contentful Paint (LCP) metric clocking in at 4-6 seconds in some cases. This was substantially higher than their target of 2.5 seconds.

To identify areas for improvement, they turned to Lighthouse to audit the YouTube watch pages, revealing a low Lighthouse (lab) score with a First Contentful Paint (FCP) of 3.5 seconds and a LCP of 8.5 seconds.

Chrome sets a target of 1.8s for FCP and 2.5s for LCP as a gold standard. The FCP and LCP were clearly in the yellow and red at 3.5s and 8.5s, respectively.

To optimize FCP and LCP, the YouTube team dove into several experiments, resulting in two big discoveries.

The first discovery was that they could improve performance by moving the HTML for the Video Player above the script that makes the Video Player interactive. Lab tests indicated that this could improve both FCP and LCP from 4.4 seconds to 1.1 seconds.
The second discovery was that LCP only considers <video> element poster images and not frames from the video stream itself. YouTube has traditionally optimized for the fastest time until the video starts playing, so to improve LCP the team started also optimizing how quickly they could deliver their poster image. They experimented with a few variations of poster images and picked the one that scored the best in user testing. As a result of this work, both FCP and LCP showed marked improvement, with field LCP improving from 4.6 seconds to 2.0 seconds.

In the lab, we observed an improvement in FCP and LCP from 4.4s to 1.1s after this change landed. Experiment A: Using the actual video thumbnail works well on pages where the video starts out paused, but for auto-play video pages like the watch page it performed poorly in user studies. It also resulted in a drop in active users. Experiment B: Using a solid black poster image showed the best results in user studies. Users found the transition from solid black to the first frame of the video to be a less-jarring experience for autoplay videos.

Black thumbnail was deployed in production for all mobile web users July 2021 showing marked improvement in FCP and LCP, as seen in the above RUM analysis.

While bringing these optimizations to all platforms, YouTube also took advantage of the new Priority Hints fetchpriority attribute, which we use with <link rel=preload> to prioritize discovering and loading the poster image early:

<link as="image" rel="preload" href="poster.jpg" fetchpriority="high">

While these optimizations did improve LCP, the team felt that the current definition of the LCP metric wasn't fully capturing, from the user's perspective, when the "main content" of the page had loaded—which is the goal of LCP.

To address these concerns, members of the YouTube team partnered with members of the Chrome team to explore ways that the LCP metric could be improved to address their use case. After considering the feasibility and impact of a few options, the teams landed on a proposal to consider the paint time of the first frame of a video element as an LCP candidate.

Once this change lands in Chrome, the YouTube team is excited to continue their work optimizing for LCP. And the updated version of the metric will mean these optimizations will have a more direct impact on real-user experiences.

Modularization with lazy loading #

YouTube pages contained many modules that were eagerly loaded. To optimize how 50+ components were rendered, the team built a component to JS module map that would tell the client which modules to load. By marking components as lazy, the JS modules would load later, reducing the initial load time of the page and the amount of unused Javascript sent to the client.

However, after lazy loading was implemented, the team noticed a waterfall effect that lazy loaded components and their dependencies would load at suboptimal times.

To solve this problem, the team determined the minimal set of components needed in a view and batched them in a single network request. The results were improved page speed, reduced JavaScript parse time, and, ultimately, better initial rendering times.

State-management across components #

YouTube was experiencing performance issues due to its player controls, especially on older devices. Code analysis showed that the player, which allows users to control features such as playback speed and progress, had become over-componentized over time.

The YouTube video player allows users to control playback speed, follow progress, skip sections, and others. When a user taps on a particular control, the change in the state must be communicated to other controls e.g. a user tap on the progress bar must be shared to controls such as play-head, subtitles etc.

Each progress bar touch-move event triggered two extra style recalculations and took 21.17 ms during performance test runs in the lab. As new controls were added over time, the pattern of decentralized control would often cause circular dependencies and memory leaks, negatively impacting watch page performance.

Chrome DevTools with a 4 times CPU slow-down performance run.

To fix the issues due to decentralized control, the team updated the player UI to synchronize all updates, essentially refactoring the player to one top-level component that would pass down data to its children. This ensured only one UI update (render) cycle for any state change, eliminating chained updates. The new player progress bar touch-move event has no style recalculations during its JavaScript execution and now only requires 25% the time of the old player.

This code modernization also resulted in additional performance improvements such as improved watch load times on old devices, fewer abandoned playbacks, and a reduced number of non-fatal errors.

Conclusion #

As a result of YouTube's investment in performance, watch pages load much faster with 76% of YouTube's mobile website URLs now passing Core Web Vitals metric thresholds in the field. On desktop, lab LCP for the watch page was reduced from approximately 4.6 seconds to 1.6 seconds. Interaction and rendering performance of the site, especially on the YouTube video player, are seeing up to 75% less time spent in JavaScript execution than before.

Improvements to the performance of YouTube web over the last year have also improved business metrics, including watch time and daily active users. Based on the success of these efforts, we plan to continue exploring even more ways to optimize in the future.

In part two of this series, "Building an accessible web", you’ll read how YouTube made their website more accessible for screen-reader users.

With special thanks to Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra and both the YouTube and Chrome teams for their contributions to this work.

Create a passkey for passwordless logins

2022-10-12T00:00:00Z

Using passkeys instead of passwords is a great way for websites to make their user accounts safer, simpler, easier to use and passwordless. With a passkey, a user can sign in to a website or an app just by using their fingerprint, face or device PIN.

A passkey has to be created, associated with a user account and have its public key be stored on your server before a user can sign in with it.

How it works #

A user can be asked to create a passkey in one of the following situations:

When a user signs in using a password, or a passkey from another device (that is, the authenticatorAttachment is cross-platform).
On a dedicated page where users can manage their passkeys.

To create a passkey, you use the WebAuthn API.

The four components of the passkey registration flow are:

Backend: Your backend server that holds the accounts database storing the public key and other metadata about the passkey.
Frontend: Your frontend which communicates with the browser and sends fetch requests to the backend.
Browser: The user's browser which is running your Javascript.
Authenticator: The user's authenticator which creates and stores the passkey. This may be on the same device as the browser (for example, when using Windows Hello) or on another device, like a phone.

The journey to add a new passkey to an existing user account is as follows:

A user signs in to the website.
Once the user is signed in, they request to create a passkey on the frontend, for example, by pressing a "Create a passkey" button.
The frontend requests information from the backend to create a passkey, such as user information, a challenge, and the credential IDs to exclude.
The frontend calls navigator.credentials.create() to create a passkey. This call returns a promise.
A passkey is created after the user consents using the device's screen lock. The promise is resolved and a public key credential is returned to the frontend.
The frontend sends the public key credential to the backend and stores the credential ID and the public key associated with the user account for future authentications.

Compatibilities #

WebAuthn is supported by most browsers, but there are small gaps. Refer to Device Support - passkeys.dev to learn what combination of browsers and an operating systems support creating a passkey.

Create a new passkey #

Here's how a frontend should operate upon a request to create a new passkey.

Feature detection #

Before displaying a "Create a new passkey" button, check if:

The browser supports WebAuthn.
The device supports a platform authenticator (can create a passkey and authenticate with the passkey).
The browser supports WebAuthn conditional UI.

// Availability of `window.PublicKeyCredential` means WebAuthn is usable.  
// `isUserVerifyingPlatformAuthenticatorAvailable` means the feature detection is usable.  
// `isConditionalMediationAvailable` means the feature detection is usable.  
if (window.PublicKeyCredential &&  
    PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable &&  
    PublicKeyCredential.isConditionalMediationAvailable) {  
  // Check if user verifying platform authenticator is available.  
  Promise.all([  
    PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable(),  
    PublicKeyCredential.isConditionalMediationAvailable(),  
  ]).then(results =&gt; {  
    if (results.every(r =&gt; r === true)) {  
      // Display "Create a new passkey" button  
    }  
  });  
}

Until all the conditions have been met, passkeys will not be supported on this browser. The "Create a new passkey" button shouldn't be displayed until then.

Fetch important information from the backend #

When the user clicks the button, fetch important information to call navigator.credentials.create() from the backend:

challenge: A server-generated challenge in ArrayBuffer for this registration. This is required but unused during registration unless doing attestation—an advanced topic not covered here.
user.id: A user's unique ID. This value must be an ArrayBuffer which does not include personally identifying information, for example, e-mail addresses or usernames. A random, 16-byte value generated per account will work well.
user.name: This field should hold a unique identifier for the account that the user will recognise, like their email address or username. This will be displayed in the account selector. (If using a username, use the same value as in password authentication.)
user.displayName: This field is an optional, more user-friendly name for the account. It need not be unique and could be the user's chosen name. If your site does not have a suitable value to include here, pass an empty string. This may be displayed on the account selector depending on the browser.
excludeCredentials: Prevents registering the same device by providing a list of already registered credential IDs. The transports member, if provided, should contain the result of calling getTransports() during the registration of each credential.

Call WebAuthn API to create a passkey #

Call navigator.credentials.create() to create a new passkey. The API returns a promise, waiting for the user's interaction displaying a modal dialog.

const publicKeyCredentialCreationOptions = {  
  challenge: *****,  
  rp: {  
    name: "Example",  
    id: "example.com",  
  },  
  user: {  
    id: *****,  
    name: "john78",  
    displayName: "John",  
  },  
  pubKeyCredParams: [{alg: -7, type: "public-key"},{alg: -257, type: "public-key"}],  
  excludeCredentials: [{  
    id: *****,  
    type: 'public-key',  
    transports: ['internal'],  
  }],  
  authenticatorSelection: {  
    authenticatorAttachment: "platform",  
    requireResidentKey: true,  
  }  
};

const credential = await navigator.credentials.create({  
  publicKey: publicKeyCredentialCreationOptions  
});

// Encode and send the credential to the server for verification.

The parameters not explained above are:

rp.id: An RP ID is a domain and a website can specify either its domain or a registrable suffix. For example, if an RP's origin is https://login.example.com:1337, the RP ID can be either login.example.com or example.com. If the RP ID is specified as example.com, the user can authenticate on login.example.com or on any subdomains on example.com.
rp.name: The RP's name.
pubKeyCredParams: This field specifies the RP's supported public-key algorithms. We recommend setting it to [{alg: -7, type: "public-key"},{alg: -257, type: "public-key"}]. This specifies support for ECDSA with P-256 and RSA PKCS#1 and supporting these gives complete coverage.
authenticatorSelection.authenticatorAttachment: Set it to "platform". This indicates that we want an authenticator that is embedded into the platform device, and the user will not be prompted to insert e.g. a USB security key.
authenticatorSelection.requireResidentKey: Set it to a boolean "true". A discoverable credential (resident key) stores user information to the passkey and lets users select the account upon authentication.

Send the returned public key credential to the backend #

After the user consents using the device's screen lock, a passkey is created and the promise is resolved returning a PublicKeyCredential object to the frontend.

The promise can be rejected for different reasons. You can handle these errors by checking the Error object's name property:

InvalidStateError: A passkey already exists on the device. No error dialog will be shown to the user and the site should not treat this as an error—the user wanted the local device registered and it is.
NotAllowedError: The user has canceled the operation.
Other exceptions: Something unexpected happened. The browser shows an error dialog to the user.

The public key credential object contains the following properties:

id: A Base64URL encoded ID of the created passkey. This ID helps the browser to determine whether a matching passkey is in the device upon authentication. This value needs to be stored in the database on the backend.
rawId: An ArrayBuffer version of the credential ID.
response.clientDataJSON: An ArrayBuffer encoded client data.
response.attestationObject: An ArrayBuffer encoded attestation object. This contains important information such as an RP ID, flags and a public key.
authenticatorAttachment: Returns "platform" when this credential is created on a passkey capable device.
type: This field is always set to "public-key".

If you use a library to handle the public key credential object on the backend, we recommend sending the entire object to the backend after encoding it partially with base64url.

Save the credential #

Upon receiving the public key credential on the backend, pass it to the FIDO library to process the object.

You can then store the information retrieved from the credential to the database for future use. The following list includes some typical properties to save:

Credential ID (Primary key)
User ID
Public key

The public-key credential also includes the following information that you may want to save in the database:

Backup Eligibility flag: true if the device is eligible for passkey synchronization.
Backup State flag: true if the created passkey is actually set to be synchronized.
Transports: A list of transports the device supports: "internal" means the device supports a passkey, "hybrid" means it also supports authentication on another device.

To authenticate the user, read Sign in with a passkey through form autofill.

Resources #

Sign in with a passkey through form autofill

2022-10-12T00:00:00Z

Passkeys replace passwords and make user accounts on the web safer, simpler, easier to use. However, the transition from password-based to passkey-based authentication can complicate the user experience. Using form autofill to suggest passkeys can help create a unified experience.

With a passkey, a user can sign in to a website just by using fingerprint, face, or device PIN.

Ideally, there would be no password users and the authentication flow could be as simple as a single sign-in button. When the user taps the button, an account selector dialog pops up, the user can pick an account, unlock the screen to verify and sign in.

However, the transition from password to passkey-based authentication can be challenging. As users switch to passkeys, there will still be those who use passwords and websites will need to accommodate both types of users. Users themselves should not be expected to remember on which sites they've switched to passkeys, so asking users to select which method to use up front would be poor UX.

Passkeys are also a new technology. Explaining them and making sure users are comfortable using them can be a challenge for websites. We can rely on familiar user experiences for autofilling passwords to solve both problems.

Conditional UI #

To build an efficient user experience for both passkey and password users, you can include passkeys in autofill suggestions. This is called conditional UI and it's a part of the WebAuthn standard.

As soon as the user taps on the username input field, an autofill suggestion dialog pops up which highlights the stored passkeys along with password autofill suggestions. The user can then choose an account and use the device screen lock to sign in.

This way, users can sign in to your website with the existing form as if nothing has changed, but with the added security benefit of passkeys if they have one.

How it works #

To authenticate with a passkey, you use the WebAuthn API.

The four components in a passkey authentication flow are: the user:

Backend: Your backend server that holds the accounts database storing the public key and other metadata about the passkey.
Frontend: Your frontend which communicates with the browser and sends fetch requests to the backend.
Browser: The user's browser which is running your Javascript.
Authenticator: The user's authenticator which creates and stores the passkey. This may be on the same device as the browser (e.g. when using Windows Hello) or on another device, like a phone.

As soon as a user lands on the frontend, it requests a challenge from the backend to authenticate with a passkey and calls navigator.credentials.get() to initiate authenticating with a passkey. This returns a Promise.
When the user puts the cursor in the sign-in field, the browser displays a password autofill dialog including passkeys. An authentication dialog appears if the user selects a passkey.
After the user verifies their identity using the device's screen lock, the promise is resolved and a public key credential is returned to the frontend.
The frontend sends the public key credential to the backend. The backend verifies the signature against the matched account's public key in the database. If it succeeds, the user is signed in.

Prerequisites #

Conditional WebAuthn UI is publicly supported in Safari on iOS 16, iPadOS 16 and macOS Ventura. It's also available on Chrome on Android, macOS and Windows 11 22H2.

Authenticate with a passkey through form autofill #

When a user wants to sign in, you can make a conditional WebAuthn get call to indicate that passkeys may be included in autofill suggestions. A conditional call to WebAuthn's navigator.credentials.get() API does not show UI and remains pending until the user picks an account to sign-in with from the autofill suggestions. If the user picks a passkey the browser will resolve the promise with a credential rather than filling in the sign-in form. It's then the page's responsibility to sign the user in.

Annotate form input field #

Add an autocomplete attribute to the username input field, if needed. Append username and webauthn as its tokens to let it suggest passkeys.

<input type="text" name="username" autocomplete="username webauthn" ...>

Feature detection #

Before invoking a conditional WebAuthn API call, check if:

The browser supports WebAuthn.
The browser supports WebAuthn conditional UI.

// Availability of `window.PublicKeyCredential` means WebAuthn is usable.  
if (window.PublicKeyCredential &&  
    PublicKeyCredential.isConditionalMediationAvailable) {  
  // Check if conditional mediation is available.  
  const isCMA = await PublicKeyCredential.isConditionalMediationAvailable();  
  if (isCMA) {  
    // Call WebAuthn authentication  
  }  
}

Fetch a challenge from the RP server #

Fetch a challenge from the RP server that is required to call navigator.credentials.get():

challenge: A server-generated challenge in an ArrayBuffer. This is required to prevent replay attacks. Make sure to generate a new challenge on every sign-in attempt and disregard it after a certain duration or after a sign-in attempt fails to validate. Consider it like a CSRF token.

Call WebAuthn API with the `conditional` flag to authenticate the user #

Call navigator.credentials.get() to start waiting for the user authentication.

// To abort a WebAuthn call, instantiate an `AbortController`.  
const abortController = new AbortController();

const publicKeyCredentialRequestOptions = {  
  // Server generated challenge  
  challenge: ****,  
  // The same RP ID as used during registration  
  rpId: 'example.com',  
};

const credential = await navigator.credentials.get({  
  publicKey: publicKeyCredentialRequestOptions,  
  signal: abortController.signal,  
  // Specify 'conditional' to activate conditional UI  
  mediation: 'conditional'  
});

rpId: An RP ID is a domain and a website can specify either its domain or a registrable suffix. This value must match the rp.id used when the passkey was created.

Remember to specify mediation: 'conditional' to make the request conditional.

Send the returned public key credential to the RP server #

After the user selects an account and consents using the device's screen lock, the promise is resolved returning a PublicKeyCredential object to the RP frontend.

A promise can be rejected due to several different reasons. You need to handle the errors accordingly, depending on the Error object's name property:

NotAllowedError: The user has canceled the operation.
Other exceptions: Something unexpected happened. The browser shows an error dialog to the user.

The public key credential object contains the following properties:

id: The base64url encoded ID of the authenticated passkey credential.
rawId: An ArrayBuffer version of the credential ID.
response.clientDataJSON: An ArrayBuffer of client data. This field contains information such as the challenge and the origin that the RP server will need to verify.
response.authenticatorData: An ArrayBuffer of authenticator data. This field contains information such as the RP ID.
response.signature: An ArrayBuffer of the signature. This value is the core of the credential and needs to be verified on the server.
response.userHandle: An ArrayBuffer that contained the user ID that was set at creation time. This value can be used, instead of the credential ID, if the server needs to pick the ID values that it uses, or if the backend wishes to avoid creating an index on credential IDs.
authenticatorAttachment: Returns platform when this credential came from the local device. Otherwise cross-platform, notably when the user used a phone to sign in. If the user needed to use a phone to sign-in, consider prompting them to create a passkey on the local device.
type: This field is always set to "public-key".

If you use a library to handle the public-key credential object on the RP server, we recommend that you send the entire object to the server after encoding it partially with base64url.

Verify the signature #

When you receive the public key credential on the server, pass it to the FIDO library to process the object.

Look up the matching credential ID with the id property (If you need to determine the user account, use the userHandle property which is the user.id you specified when creating the credential). See if the credential's signature can be verified with the stored public key. To do so, we recommend using a server side library or a solution instead of writing your own code. You can find open source libraries in the awesome-webauth GitHub repo.

Once the credential is verified with a matching public key, sign the user in.

Resources #

New patterns for amazing apps

2022-10-10T00:00:00Z

No matter what you build—be it a next generation video editing app, an addictive word game, or a future online social networking app—you will always find yourself in need of a few basic building blocks:

The video editing app will probably allow the user to save the edited video.
Your game will maybe allow the user to share game progress with friends.
An online social networking app will highly likely allow the user to paste images into a post.

No universal way to realize these patterns #

These were just a couple of examples of such patterns, and there are many more. But all of these have one thing in common: there is no universal way to realize them.

For example, not all browsers implement the Web Share API, so in some cases you will have to fall back to a different approach, like Twitter's Web Intents, or copying to the clipboard, which is the approach chosen in Wordle when the Web Share API isn't implemented. Phew, barely got this one:

Wordle 471 6/6

⬛⬛⬛⬛🟨
🟩⬛⬛⬛🟨
🟩🟩🟩⬛⬛
🟩🟩🟩⬛⬛
🟩🟩🟩🟩⬛
🟩🟩🟩🟩🟩

Saving files #

When it comes to saving, the go-to approach is to use the File System Access API, so you end up with a FileSystemFileHandle, which allows you to implement a true save, edit, save flow. The next best thing is to fall back to a classic <a download>, which likewise lets the user save data, but has the downside of creating new files on each download, so they end up with my-video.mp4, my-video (1).mp4, my-video (2).mp4, etc.

Pasting images #

To conclude the introductory examples, not all browsers support pasting images into a web app, so you can fall back to using the Drag and Drop API or showing a file picker, which is not as elegant as the Async Clipboard API, but at least it works.

The new patterns #

With this out of the way, the new pattern sections are:

Clipboard patterns #

Clipboard patterns for everything concerned with the system clipboard like copying and pasting of all sorts of things.

Files patterns #

Files patterns for everything concerned with files and directories; be it saving, opening, dragging and dropping, receiving or sharing.

Advanced apps patterns #

Advanced apps patterns for everything concerned with advanced app features like providing app shortcuts, periodically syncing data in the background, showing app badges, and many more.

Feedback #

I hope these patterns will help you build amazing apps, and I'm looking forward to your feedback! You can provide feedback by tweeting at @ChromiumDev or filing an Issue. In both cases, tag @tomayac to make sure I see it.

Acknowledgements #

I'm grateful to Joe Medley for his help with reviewing and editing the patterns. Thanks to Pete LePage, Ewa Gasperowicz, Rachel Andrew, Ken Pascal, and Matthias Rohmer for all their technical and organizational support and encouragements to land this. The entire patterns project would not have been possible without the help of the authors of the individual patterns, namely Harry Theodoulou, Tony Conway, Palances Liao, Cecilia Cong, François Beaufort, and Joe Medley.

Community highlight: Melanie Sumner

2022-10-06T00:00:00Z

This post highlights a community expert, as a part of Learn Accessibility!

Alexandra White: Thanks for joining me! Who you are and what you do?

Melanie Sumner: My name is Melanie Sumner and I am a software engineer specializing in digital accessibility. I've been writing code for the web for 25 years. My first career was… kind of a spy. I was an intelligence analyst in the US Navy, and coding was my hobby.

I didn't really like being a spy. I wasn't fond of death, it turns out. As most people are not, when they have to be closer to it. I had to decide what I wanted to do next, and it was time to turn my hobby into my career. In the last 10 years, I've really focused on software engineering in the accessibility space, specifically.

Alexandra: You don't often hear, "Oh first I was a spy." No big deal. What brought you into accessibility work?

Melanie: I was working at the University of North Carolina [UNC] Chapel Hill at the time, in the Department of Development. They don't mean development like web development, they mean development like fundraising.

My direct manager had a vision impairment, and he had to zoom everything to 400% to see it. He was a fantastic software engineer. Probably the best manager I've ever had, actually. But he was always breaking my stuff, because he would zoom in to look at my work. If I hadn't thought about building things responsively, they would break.

My manager's boss was blue colorblind. I don't know if you know what UNC blue looks like, but it's this light sky blue color. And they loved using it on white.

Alexandra: (laughs) Oh no.

Melanie: His boss was always complaining that he could never see my work! I had to develop a set of complementary colors and a color scheme for our sites. That got me thinking about color contrast and thinking about how people who are colorblind (or otherwise visually impaired) use the web.

Because UNC is a state university, there's a US federal requirement to conform with WCAG accessibility level AA. We aimed for level AAA because it's an education institution.

As I learned more about the state and federal requirements and began reading the W3C Accessibility spec, I thought, "All of this makes sense." Most of the web wasn't compliant, from what I could see. Of course, people have been working on web accessibility for as long as the web has existed. Sometimes JavaScript engineers (in particular) are a little slow on the uptake when it comes to digital accessibility.

I call accessibility the final frontier of the web. Lots of good people work on automation for accessibility—and we need to work on solutions the same way that we've approached other hard problems, such as performance and security.

Alexandra: You've probably read a lot of long complex documents, in the Navy and at UNC. Did you find it was challenging to understand the spec?

Melanie: I had to read it about five times before I understood it—and I'd read other specs before. I always tell people, don't feel bad if you don't understand it, because I had to read the spec five times! I'm not even joking.

It takes a lot of time to get used to spec language. And if you don't interpret it correctly, you might do the wrong thing. Also it's important to understand that a lot of the spec language is meant for browser developers. Look for "authors should," because that's a reference to web developers.

Alexandra: A lot on the web could be better if more developers knew how to decipher the specs.

Melanie: There's a lot to be said for sites that do that interpretation for you. I built a11y-automation.dev and that site is kind of like my baby, my side project. I try to itemize every accessibility violation and link it to the WCAG success criteria in question. If there's automation to prevent the error, I'll offer that solution.

You could familiarize yourself with the list of potential violations, but more important is learning how to fix it. For automated fixes that don't exist, maybe you're inspired to write a linter or a template—maybe you get inspired to write some kind of test.

I prefer to work in open source, because you get to kind of riff off each other, offer an improvement (sometimes an improvement, sometimes not, but we all try our best). We build on each other's stuff, and then we end up with this really great outcome for the web.

How to fund accessibility #

Alexandra: I was really drawn to pleasefunda11y.com. It's really important to get developers to learn how to build accessible sites, but they won't always have the resources without having executive leadership funding and approval. Why did you decide to build this site?

Melanie: I was frustrated because accessibility is so underfunded. All of the open source funding seems to keep going to CSS. And I love CSS, we can do so much with it.

I built the site because Addy Osmani—a Chrome software engineering manager—reached out and said he saw I was asking for accessibility funding, but he wanted advice on what specific work could be funded. That's a big problem: open source funders want to give money to specific projects, not general ideas that have no determined outcome. I took some time to write down some specific initiatives, what's needed and how they'll help make sites accessible.

Even if companies build towards these efforts without me, we could move accessibility on the web forward in a really significant way. It's a very small spend by comparison to other web efforts, and it would have a huge impact on people's lives.

The current way of thinking is often, "Well, how many people have a disability?" It should be: "What is any person's relationship to their technology?"

And some folks have told me, "Well, I don't think color blindness is a disability." You may not identify yourself as having a disability if you're colorblind, but it does affect your relationship with technology.

15 _%

people self-identify as disabled.

_Source

253 _m

people with visual impairments.

_Source

countries with web accessibility law.

_Source

Learn more about the statistics in Learn Accessibility's first module: What is digital accessibility, and why does it matter?

Alexandra: Tell me more about understanding your relationship with technology. How does that relate to accessibility?

Melanie: For example, if you are neurodiverse, maybe you need really simple language and very clear directions. You may be better served navigating through three or four screens in a flow, making a few choices at a time until you get to the end. There's not good guidance for modern technical applications.

We have whole companies that do devops, and if you try to use some of those websites, you're like, "Oh my god," you know? We try to pack the kitchen sink into all of our interfaces these days.

Alexandra: Can you share an example?

Melanie: For example, GitHub has dropdowns with nested tabs. And [exasperated sigh]. I can't get upset (even if I'm frustrated). The modern web has to grow to meet new demands. But we also have a responsibility to build in a way that doesn't leave people behind.

That's what drives me, that's my passion. I don't want somebody to not be able to get a job because the tools they'd have to use at the job are not accessible.

Alexandra: One hundred percent. And people often think about building accessible products for their external users, but not necessarily thinking about their employees.

Melanie: I thought, you know what, this funding advice would probably benefit everyone.

I hear from engineers all the time that they'd love to do accessibility but "my company doesn't care." I bet they do care! You just need to bridge the business logic gap. Show them the beneficial outcome for the business. The site is open source, of course, and I love contributions and edits.

Alexandra: Accessibility is often left to the end of the process, like, "Oh we can just make this accessible later." But it's going to take a lot more time to add it later than it would to integrate accessible practices throughout the project.

Melanie: I often say, "Do you want to pay to build it once or do you want to pay to build it twice?"

Ember.js and the core accessibility team #

Alexandra: I know you're also involved in the Ember.js framework core team. How did you get involved?

Melanie: I was hired to work at JPMorgan Chase, on their corporate investment banking platforms. Ember is a heavy duty JavaScript framework used when you need a really stable (maybe even kind of boring) base, that can help you avoid writing code that loses a lot of bank dollars. Ember has a backwards compatibility guarantee—you can upgrade every time, even if you hit a major version. We really try to do things incrementally, so it doesn't break your app.

Anyway, I showed up to an Ember conference, and I met a bunch of people in the community. Ember folks were so kind. And there's a really strong code of conduct that I just hadn't seen yet in other places.

When I got out of the military, I wanted to go into security. I went to an infosec meetup, and didn't see any other woman there. One of the older guys looked at me and said, "Are you sure you're in the right room, sweetheart?"

Alexandra: [Groans] It hurts. And it's completely unsurprising. I've experienced something similar.

Melanie: I want to say this was 2011, maybe 2012? The landscape has changed a lot. I stayed that night, through that meetup, to prove a point. I wasn't gonna let that comment shut me down. I cracked jokes, took good notes, and participated in the conversation, so people knew I was there. I feel like a lot of my career has been proving men wrong.

But, I don't want women to become software engineers just to prove men wrong. I wanted to be a software engineer to build amazing things, because it's fun to do. Women should have that career option.

Alexandra: Absolutely.

Melanie: I shared what I knew about accessibility with the Ember community, because obviously as a banking platform, you have to conform to the US federal requirements. Yehuda Katz and Tom Dale said, "We have a gap on the team. We have a lot of JavaScript experts, performance experts, people out-of-this-world smart, and we need someone with accessibility knowledge." And they invited me to join the core team.

I'm working on initiatives to help make Ember accessible by default. That means when you say ember new <my-app-name>, you should immediately pass WCAG success criteria.

Alexandra: I saw a long list of accessibility tools for Ember on GitHub. Have you found that people in the Ember community are excited to contribute to those tools?

Melanie: That's been a really exciting part of this work. I wrote accessibility linting rules for Ember while working at LinkedIn. Then I left LinkedIn to work for Hashicorp, and other folks are still contributing to the linter because it's useful for them. That's the part of this work that gives me chills and gets me excited.

We accept that, as a baseline, accessibility is a civil right. That's not up for discussion.

What we discuss is: What can we implement? When? How do we make it? How do we teach this and make it backwards compatible? How do we help developers provide accessibility support without a huge extra feature that they have to build or plan for?

Alexandra: Accessibility is a civil right. That gives me chills! It should just be a thing we all know as truth.

Melanie: I've had people say uninformed things to me, like "I wouldn't use the internet if I was blind." Or, "Why do I have to think about disabilities when it's only 5% of my users, when it's working for 90% of my users?" I won't have those discussions, because they're often used to distract from the work.

When you write accessible code, you're going to get performance boosts because you're thinking about building sites informed by W3C specs. You'll use the semantic HTML instead of just divs, and you'll use headings. You'll choose a <button> instead of adding a click event to a <div>, and you'll get performance enhancements.

Do one thing: automate accessibility #

Alexandra: What's one thing web developers should do to build accessible websites?

Melanie: Add automation. Start with an existing linter for whatever framework you have, whatever kind of code you're using. I don't care which one you use! Your build should break if one of those rules is broken.

Some things can't be automated, because AI can't yet decipher intent. For example, an image's alt text value should be meaningful, but what does that actually mean? Right now, a human needs to discern that, and not automation.

But an automated tool can tell you, "You're not passing color contrast." Just fix it. Don't fight it, don't say, "But I don't want to, I prefer it this way." This is not about you. It's about making what we do available for everyone in the world every day.

Accessibility is a journey, and you're always going to be learning. I've been specializing in accessibility for over a decade, and I'm still learning new things all the time! Don't be defensive, just do it.

Keep up with Melanie's work on her website at melanie.codes and Twitter @a11yMel. Check out her accessibility resources on pleasefunda11y.com, a11y-info.com, and a11y-automation.dev.

Building a floating action button (FAB) component

2022-10-06T00:00:00Z

In this post I want to share my thoughts on how to build color-adaptive, responsive, and accessible FAB components. Try the demo and view the source!

If you prefer video, here's a YouTube version of this post:

Overview #

FABs are more common on mobile than desktop, but they're prevalent in both scenarios. They keep primary actions in view, making them convenient and omnipresent. This user experience style was made famous by Material UI and their suggestions for usage and placement can be found here.

Elements and styles #

The HTML for these controls involves a container element and a set of one or more buttons. The container positions the FABs within the viewport and manages a gap between the buttons. The buttons can be mini or default, giving some nice variety between primary and secondary actions.

FAB container #

This element can be a regular <div> but let's do our unsighted users a favor and tag it with some helpful attributes to explain the purpose and contents of this container.

FABs markup #

Start with a .fabs class for CSS to hook into for style, then add role="group" and aria-label so it's not just a generic container, it's named and purposeful.

<div class="fabs" role="group" aria-label="Floating action buttons">
  <!-- buttons will go here -->
</div>

FABs style #

In order for FABs to be convenient they stick within the viewport at all times. This is a great use case for position fixed. Within this viewport position I chose to use inset-block and inset-inline so the position will compliment the user's document mode, like right-to-left or left-to-right. Custom properties are also used to prevent repetition and ensure equal distance from the bottom and side edges of the viewport:

.fabs {
  --_viewport-margin: 2.5vmin;

  position: fixed;
  z-index: var(--layer-1);

  inset-block: auto var(--_viewport-margin);
  inset-inline: auto var(--_viewport-margin);
}

Next I give the container display flex and change its layout direction to column-reverse. This stacks the children on top of each other (column) and also reverses their visual order. This has the effect of making the first focusable element the bottom element instead of the top, which would be where focus goes normally per the HTML document. Reversing the visual order unites the experience for sighted users and keyboard users, as the styling of the primary action as larger than the mini buttons indicates to sighted users that it's a primary action, and keyboard users will focus it as the first item in the source.

.fabs {
  …

  display: flex;
  flex-direction: column-reverse;
  place-items: center;
  gap: var(--_viewport-margin);
}

Centering is handled with place-items, and gap adds space between any FAB buttons placed in the container.

FAB buttons #

Time to style some buttons to look like they're floating over top of everything.

Default FAB #

The first button to style is the default button. This will serve as the base for all the FAB buttons. Later we'll create a variant that achieves an alternative appearance while modifying as little of these base styles as possible.

FAB markup #

The <button> element is the right choice. We'll start with this as the base because it comes with great mouse, touch, and keyboard user experience. The most crucial aspect of this markup is to hide the icon from screenreader users with aria-hidden="true" and add the necessary label text to the <button> markup itself. When adding labels in these cases I also like adding a title so mouse users can get information about what the icon is hoping to communicate.

<button data-icon="plus" class="fab" title="Add new action" aria-label="Add new action">
  <svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">...</svg>
</button>

FAB style #

First let's turn the button into a padded round button with a strong shadow, as these are the first defining features of the button:

.fab {
  --_size: 2rem;

  padding: calc(var(--_size) / 2);
  border-radius: var(--radius-round);
  aspect-ratio: 1;
  box-shadow: var(--shadow-4);
}

Next let's add color. We'll use a strategy we've used in GUI Challenges before. Create a clearly named set of custom properties that statically hold the light and dark colors, then an adaptive custom property that will be set to either the light or the dark variables depending on the user's system preference for colors:

.fab {
  …

  /* light button and button hover */
  --_light-bg: var(--pink-6);
  --_light-bg-hover: var(--pink-7);

  /* dark button and button hover */
  --_dark-bg: var(--pink-4);
  --_dark-bg-hover: var(--pink-3);

  /* adaptive variables set to light by default */
  --_bg: var(--_light-bg);

  /* static icon colors set to the adaptive foreground variable */
  --_light-fg: white;
  --_dark-fg: black;
  --_fg: var(--_light-fg);

  /* use the adaptive properties on some styles */
  background: var(--_bg);
  color: var(--_fg);

  &:is(:active, :hover, :focus-visible) {
    --_bg: var(--_light-bg-hover);

    @media (prefers-color-scheme: dark) {
      --_bg: var(--_dark-bg-hover);
    }
  }

  /* if users prefers dark, set adaptive props to dark */
  @media (prefers-color-scheme: dark) {
    --_bg: var(--_dark-bg);
    --_fg: var(--_dark-fg);
  }
}

Next add some styles to help the SVG icons fit the space.

.fab {
  …

  & > svg {
    inline-size: var(--_size);
    block-size: var(--_size);
    stroke-width: 3px;
  }
}

Last, remove the tap highlight from the button since we've added our own visual feedback for interaction:

.fab {
  -webkit-tap-highlight-color: transparent;
}

Mini FAB #

The goal of this section is to create a variant for the FAB button. By making some of the FABs smaller than the default action, we can promote the action the user performs the most often.

Mini FAB markup #

The HTML is the same as a FAB but we add a ".mini" class to give CSS a hook into the variant.

<button data-icon="heart" class="fab mini" title="Like action" aria-label="Like action">
  <svg aria-hidden="true" width="24" height="24" viewBox="0 0 24 24">...</svg>
</button>

Mini FAB style #

Thanks to usage of custom properties, the only change needed is an adjustment to the --_size variable.

.fab.mini {
  --_size: 1.25rem;
}

Accessibility #

The most important part to remember for accessibility with FABs is placement within the keyboard flow of the page. This demo only has the FABs, there's nothing to compete with in terms of keyboard order and flow, which means it doesn't have an opportunity to demonstrate a meaningful keyboard flow. In a scenario where there's competing elements for focus, I suggest thinking deeply about where in that flow should a user find themselves entering into the FAB button flow.

Keyboard interaction demonstration

Once the user has focused into the FAB container, we've already added role="group" and aria-label="floating action buttons" which inform screen reader users about the contents of what they have focused. Strategically I've placed the default FAB first, so that users find the primary action first. I then use flex-direction: column-reverse; to visually order the primary button on the bottom, close to the users fingers for easy access. This is a nice win because the default button is visually prominent and also first for keyboard users, giving them very similar experiences.

Lastly, don't forget to hide your icons from screen reader users and ensure you provide them with a label for the button so it's not a mystery. This has been done in the HTML already with aria-hidden="true" on the <svg> and aria-label="Some action" on the <button>s.

Animation #

Various types of animation can be added to enhance the user experience. Like in other GUI Challenges, we'll set up a couple of custom properties to hold the intent of a reduced motion experience and a full motion experience. By default the styles will assume the user wants reduced motion, then using the prefers-reduced-motion media query swap the transition value to full motion.

A reduced motion strategy with custom properties #

Three custom properties are created in the following CSS: --_motion-reduced, --_motion-ok, and --_transition. The first two hold appropriate transitions given the user's preference, and the last variable --_transition will be set to either --_motion-reduced or --_motion-ok respectively.

.fab {
  /* box-shadow and background-color can safely be transitioned for reduced motion users */
  --_motion-reduced:
    box-shadow .2s var(--ease-3),
    background-color .3s var(--ease-3);

  /* add transform and outline-offset for users ok with motion */
  --_motion-ok:
    var(--_motion-reduced),
    transform .2s var(--ease-3),
    outline-offset 145ms var(--ease-2);

  /* default the transition styles to reduced motion */
  --_transition: var(--_motion-reduced);

  /* set the transition to our adaptive transition custom property*/
  transition: var(--_transition);

  /* if motion is ok, update the adaptive prop to the respective transition prop */
  @media (prefers-reduced-motion: no-preference) {
    --_transition: var(--_motion-ok);
  }
}

With the above in place, changes to box-shadow, background-color, transform and outline-offset can be transitioned, giving the user nice UI feedback that their interaction has been received.

Next, add a little bit more flair to the :active state by adjusting translateYa little bit, this gives the button a nice pressed effect:

.fab {
  …

  &:active {
    @media (prefers-reduced-motion: no-preference) {
      transform: translateY(2%);
    }
  }
}

Then lastly, transition any changes to the SVG icons in the buttons:

.fab {
  …

  &[data-icon="plus"]:hover > svg {
    transform: rotateZ(.25turn);
  }

  & > svg {
    @media (prefers-reduced-motion: no-preference) {
      will-change: transform;
      transition: transform .5s var(--ease-squish-3);
    }
  }
}

Conclusion #

Now that you know how I did it, how would you‽ 🙂

Let's diversify our approaches and learn all the ways to build on the web.

Create a demo, tweet me links, and I'll add it to the community remixes section below!

Community remixes #

Nothing to see here yet.

Resources #

Source code on Github

web.dev

All of Learn Accessibility! is available

Our top Core Web Vitals recommendations for 2023

Largest Contentful Paint (LCP) #

Ensure the LCP resource is discoverable from the HTML source #

Ensure the LCP resource is prioritized #

Use a CDN to optimize document and resource TTFB #

Cumulative Layout Shift (CLS) #

Set explicit sizes on any content loaded from the page #

Ensure pages are eligible for bfcache #

Avoid animations/transitions that use layout-inducing CSS properties #

First Input Delay (FID) #

Avoid or break up long tasks #

Avoid unnecessary JavaScript #

Avoid large rendering updates #

Conclusion #

New to the web platform in December

Stable browser releases #

Support for height and width attributes of <source> #

Trigonometric CSS functions #

Support for last baseline in all three engines #

CSS font-variant-alternates #

Beta browser releases #

Other news #

Interop 2022: end of year update

Cascade layers #

The dialog element #

Subgrid #

Viewport units #

Color 4 #

Interop 2023 #

Community highlight: Elisa Bandy

Prioritize your accessibility use cases #

Culture of accessibility #

Build your own set of expertise #

Experience accessibility tools first-hand #

Simulators, while useful, are not equivalent to a disability #

Do one thing: stop building infinite scroll #

Optimize Interaction to Next Paint

Figure out what's causing poor INP #

Find slow interactions in the field #

Reproduce slow interactions in the lab #

What if you don't have field data? #

Diagnose and deal with long input delay #

How to identify input delay #

How to fix long input delays #

Optimize event callbacks #

Minimize presentation delay #

When interactions overlap #

Improving INP requires persistence #

New to the web platform in November

Stable browser releases #

A change to Layout Viewport behavior in Chrome on Android #

New viewport units #

Support for the CSS fragmentation avoid keyword #

Federated Credential Management API #

Beta browser releases #

The large, small, and dynamic viewport units

The viewport and its units #

The need for new viewport units #

Caveats #

Additional resources #

Accessibility Week

Watch us answer your questions #

More resources #

On the web #

Community highlight: Albert Kim

Build for "invisible" disabilities #

Participate in COGA and other W3C initiatives #

Stop creating bad user experiences #

Include content warnings #

Do one more thing: communicate clearly #

GDE community highlight: Lars Knudsen

Community highlight: Olutimilehin Olushuyi

Create accessible layouts #

Build an accessible community #

Spec versus implementation #

Accessibility as a career #

Do one thing: add keyboard focus #

Speedy CSS Tip! Animated Gradient Text

Support for `height` and `width` attributes of `<source>` #

CSS `font-variant-alternates` #

Support for the CSS fragmentation `avoid` keyword #

Additions to `getDisplayMedia()` #

Interpolating `grid-template-columns` and `grid-template-rows` #