Alexander Lehner – Oida, is des org!

Enhance Dialogs with the closedby Attribute

Sat, 28 Mar 2026 00:00:00 GMT

The native <dialog> HTML element is a thing of beauty. It enables you to easily create accessible, modal dialogs that work well for all users. And it has been supported by all modern browsers since 2022.

But it gets even better: The new closedby attribute allows you to define which user actions will close the dialog. You can add light dismiss behavior, or go the other way: e.g., prevent the ESC key from closing the dialog.

Photo: © Miguel Á. Padriñán / pexels.com

We’ll take a look at the technical specification and some use cases for the new attribute.

How it works

The HTML specification defines closedby as an enumerated attribute with the following keywords:

any – Close requests or clicks outside close the dialog.
closerequest – Close requests close the dialog.
none – No user actions automatically close the dialog.

If you don’t set the closedby attribute on a modal dialog, then it behaves as if the value was closerequest . This means, pressing the ESC key on desktop platforms, or a “back” or “dismiss” gesture on mobile platforms, will close the dialog.

Use Cases

Light Dismiss for Informational Dialogs

Some dialogs only present information. The user isn’t expected to make a decision or fill in a form. In my opinion, this is a perfect use case for adding light dismiss behavior: The dialog should close when the user clicks or taps outside it.

Before we had the closedby attribute, you needed additional JavaScript code to implement light dismiss. See my article “Why you should use the Native Dialog Element” for an example. Lucky for us, now we only need the following HTML code:

<dialog closedby="any">
    <!-- content -->
</dialog>

Awesome! 🥳

Prevent Accidental Closing

Dialogs are a great way to encapsulate workflows like, e.g., the data entry via a form. You can also handle the onboarding process for your web application with a dialog.

In all these cases, you’ll want to prevent the user from accidentally closing the dialog, e.g., via the ESC key. They would lose the data they had already filled in the form, or not be able to access the onboarding dialog again.

Therefore, you should set closedby=“none” on the dialog. Now the user can only close the dialog via a developer-specified mechanism, like a close button. Here’s an example:

<dialog id="mydialog" closedby="none">
    <!-- content -->
    <button commandfor="mydialog" command="close">
        Continue
    </button>
</dialog>

Maybe you’re wondering about the command and commandfor attributes on the close button. They’re part of a new web feature called Invoker Commands API. You don’t have to use them in your dialogs. But I like their simplicity and elegance, so I wanted to include them in my code example. 😉

Browser Support

The closedby attribute is already supported by Firefox, Chrome and Edge. Thanks to Interop 2026, Safari/WebKit should catch up until the end of the year.

Useful Resources

The closedby attribute (MDN)
“Accessibility Engineering — Let the Web Platform do the Work” (section: “The dialog element: Always on top”)
“Native Dialogs and the Popover API — What you need to know”

Best Practices for CSS Scope in Angular Applications

Tue, 24 Feb 2026 00:00:00 GMT

The new @scope CSS at-rule has been supported by all major browsers since December 2025. This awesome new feature makes it super easy to scope styles to specific DOM subtrees, like the content of a component.

At work, I mostly implement web applications with the Angular framework. The last few months, I started to ditch Angular’s default view encapsulation and use the native CSS feature instead. Now I’d like to share my learnings and some best practices with you.

Photo: © Aditya Aiyar / pexels.com

If you’re unfamiliar with CSS scope, then read my article “Will the CSS Scope Feature replace Angular’s View Encapsulation?” first. It explains the basics of the @scope CSS at-rule and how to use it in Angular.

Demo Project: CSS Scope Sandbox

I’ve created a project with two Angular applications that display the same content. The only difference is: The app-without-css-scope uses the standard view encapsulation provided by the Angular framework. On the other hand, the app-with-css-scope disables this feature and uses the @scope CSS at-rule instead.

Here’s the deployed application with CSS scope. Go ahead and inspect it using your browser’s developer tools:

I love how clean and tidy the DOM looks. It’s way easier to understand the page structure and inspect the styles of an element.

The CSS selectors you see in the browser’s dev tools match those you defined in your source code. No more weird additions of custom attributes like _ngcontent-xxx .

So, what are the best practices for CSS scope that I’d recommend?

Best Practice 1: Use efficient Donut Scopes

First of all, we need to disable view encapsulation for each of our components. Here’s an example from my demo:

@Component({
    selector: 'app-beer-item-list',
    encapsulation: ViewEncapsulation.None,
    ...
})
export class BeerItemList { ... }

Now the CSS selectors won’t be extended with custom attributes and the component styles are applied globally. Next, we need to use the @scope at-rule instead to encapsulate the styles.

@scope (app-beer-item-list) {
    :scope {
        display: grid;
        ...
    }
}

This defines the component’s container element app-beer-item-list as the scoping root which determines the upper boundary of the subtree we want to target.

But what about the content rendered by the child components in the template? The BeerItemList component includes the child component <app-beer-item-details> in its template. We don’t want the parent component’s styles to affect the content of its children.

The @scope at-rule allows us to define a scoping limit which determines the lower boundary. This type of scoping – with an upper and lower boundary – is called a donut scope:

@scope (app-beer-item-list) to (app-beer-item-details > *) {
    :scope {
        display: grid;
        ...
    }

    app-beer-item-details {
        background: var(--canvas-bg-color);
        ...
    }
}

This scope includes the <app-beer-item-details> container element but excludes the content of the child component.

What happens when you’re styling a component that includes several child components in its template? For example, the app component in my demo includes the child components AppFooter , AppHeader and BeerItemList . You would have to define each child component as a scoping limit, which would get annoying really fast.

To make using CSS scope easier, I’ve created the custom directive CustomNgHostDirective . The directive adds the custom attribute data-ng-host to a component’s container HTML element. Simply apply the directive to a component with the hostDirectives property:

@Component({
    selector: 'app-beer-item-details',
    encapsulation: ViewEncapsulation.None,
    hostDirectives: [CustomNgHostDirective],
    ...
})
export class BeerItemDetails { ... }

Now we can use the data-ng-host attribute for an efficient definition of the lower boundary of an @scope at-rule. For example:

@scope (app-beer-item-list) to ([data-ng-host] > *) {
    :scope {
        display: grid;
        ...
    }

    app-beer-item-details {
        background: var(--canvas-bg-color);
        ...
    }
}

Best Practice 2: Go deep without `::ng-deep`

When using Angular’s view encapsulation, component styles normally apply only to the HTML in the component’s own template. You can use the ::ng-deep pseudo-class to disable view encapsulation for a specific rule. But this pseudo-class has been deprecated for a while and you’re not supposed to use it anymore.

With CSS scope, you’re in control again! You can define the scope in a way that lets you safely override, e.g., the inner styles of a 3rd party library.

For example: Let’s say you’re using an Angular Material table to display tabular data. You’re mostly happy with the design but would like to tweak the background colors a bit. Here’s what your component’s styles could look like:

@scope (app-fancy-table) {
    table[mat-table] {
        thead tr {
            background-color: lightblue;
        }
    }
}

Best Practice 3: Define shared styles as Global CSS Classes

Not all your styles have to be defined as scoped styles in the CSS file of a component. You’ll want to put shared styles in global files, e.g. in your src/styles folder, and provide them for the whole application.

I personally prefer to create SCSS files with general styles for each type of content or element. For example: _details.scss , _forms.scss and _table.scss . They contain styles for specific HTML selectors like, e.g., details , as well as global CSS classes like, e.g., .default-expansion-panel .

To make it easy for components to override these general styles, if necessary, I put them in a dedicated cascade layer:

@use "sass:meta";

@layer reset, general, components;

@layer general {
    @include meta.load-css("base/details");
    @include meta.load-css("base/forms");
    @include meta.load-css("base/table");
}

Learn more about cascade layers in my article “Using CSS Cascade Layers in Angular”.

As an alternative, you might prefer to use SCSS features like placeholders or mixins to create reusable styles. I can confirm that including a mixin with @include also works within the context of the native @scope at-rule.

Unfortunately, using an SCSS placeholder with @extend didn’t work for me in the context of CSS scope. The SCSS preprocessor apparently doesn’t account for the @scope at-rule yet, resulting in unscoped styles. At least that was the case for me with Angular 21. Maybe it will be fixed in the future.

Conclusion

As I’ve shown you, it’s pretty easy to switch off Angular’s view encapsulation and define component styles inside a @scope at-rule. The generated HTML and CSS code has better readability and is far easier to debug.

Or in other words: Angular’s view encapsulation is dead! Long live CSS scope! 🤩

Using the Temporal API in Angular without including a Polyfill

Sat, 31 Jan 2026 00:00:00 GMT

The Temporal API is gaining momentum! Chrome and Edge 144 recently shipped with Temporal support. They finally caught up to Firefox, the first browser to enable the Temporal API by default in May 2025. The implementation in WebKit/Safari is also making progress.

Well, I can’t wait to finally ditch the horrible Date object and embrace modern date and time management with Temporal , including built-in time zone and calendar representation. Don’t know what I’m talking about? Then read my article “Date and Time Management with the Temporal API” first!

Photo: © Łukasz Martenka / pexels.com

In my current project at work, I’m developing a new web application with Angular 21 that doesn’t have to support Safari. The perfect opportunity to go all in with the Temporal API.

The only problem is: The Temporal proposal is still at stage 3 in the TC39 proposal process. Therefore, the current TypeScript version doesn’t include types for Temporal objects yet. When I try to use Temporal in my Angular application, the TypeScript compiler will refuse and say: “Cannot find name ‘Temporal’.” 😢

After some tinkering, I found a solution for the problem: I’ll show you how to add type definitions for Temporal without blowing up the bundle size of your app. 🤩

Step 1: Install the Temporal Polyfill

Install the @js-temporal/polyfill package as a dev dependency for your Angular project:

npm install --save-dev @js-temporal/polyfill

The documentation recommends to import the polyfill in the following way:

import { Temporal } from '@js-temporal/polyfill';

Don’t do this! The polyfill actually includes the JavaScript code for all objects and methods of the Temporal API. This import would increase the bundle size of your application by around 150 kB.

Here’s what you do instead.

Step 2: Declare a global `Temporal` object

Create a new file src/types/temporal.d.ts in your repository and include the following code:

import type { Temporal as TemporalType } from "@js-temporal/polyfill";

declare global {
    const Temporal: typeof TemporalType;
}

We only import the type definitions for the Temporal namespace from the polyfill package. Then we declare a global constant named Temporal and assign it the imported type. This way we teach TypeScript that the Temporal namespace exists and that it includes several objects like Instant , Now and ZonedDateTime .

Now, you can use all features of the Temporal API in any .ts file without an additional import. For example:

const zdt = Temporal.ZonedDateTime.from("2026-01-30T12:34:56-04:00[America/New_York]");

During runtime of the web application, the actual global Temporal object of the browser will be used.

Step 3: Using types from the `Temporal` namespace

The last piece of the puzzle: If you want to use Temporal types for variables or class properties, you need to import and use the type definitions the following way:

import type { Temporal as TemporalType } from "@js-temporal/polyfill";

interface MyInterface {
    property: TemporalType.ZonedDateTime;
}

Demo application

I’ve created a simple demo app with Angular 21 following the steps above. It includes a time zone picker and a simple date calculator. Both were super easy to implement, thanks to the elegant and powerful Temporal API.

If you just started working on a new Angular application, then give it a go! Temporal is simply awesome and you’ll love using it. 😉

My First Steps as an Astronaut

Mon, 12 Jan 2026 00:00:00 GMT

I’m officially an astronaut! Well, not an actual astronaut who journeys into space. Rather, a happy user of the web framework Astro.

Many in the Astro community affectionately refer to themselves as “Astronauts” – playing on the framework’s name. And now I’m one of them! After four years of managing my web blog with Gatsby, it was time to move on and switch to a different framework.

Photo: © cottonbro / pexels.com

I’ll explain why I left Gatsby behind and what I like about Astro.

Why I dropped Gatsby

I must admit I’ve been lazy! Back in January 2022 I set up my web blog with Gatsby 4. After I was happy with the configuration and everything worked well enough, I never really touched the setup again. I also never updated the project’s dependencies.

The setup simply worked. So, I preferred to spend my time experimenting with new web features and writing blog posts.

Now, four years later, I had to admit to myself that my setup had become completely outdated! The Gatsby CLI felt clunky and slow, and building my web blog for production took up to 15 minutes. Unacceptable!

My first thought was to update to the latest Gatsby version and optimize my setup. But then I came across GitHub issues like “Is GatsbyJS Officially Dead?” and “Is Gatsby discontinued?”. Apparently, the framework is no longer actively developed and has become hopelessly outdated.

“Well, time to move on!”, was my conclusion. After some research on various frameworks for static site generation, I settled on Astro as an ideal fit for me.

What I like about Astro

I’ve now finished setting up my web blog with Astro, maintaining the same basic features:

A bilingual website in English and German.
A homepage with a short introduction and a list of recent blog posts.
An about page with more information about me and the website.
A blog archive with links to all my published posts.
Blog posts created from Markdown files.
Automatic creation of RSS files.

Switching to Astro went pretty smoothly, thanks to its familiar component structure and built-in support for Markdown. Here’s what I especially like about Astro:

The framework offers very detailed documentation, including an interactive tutorial for building a blog. Perfect for my use case! They even have several migration guides, e.g., Migrating from Gatsby, that explain key differences.
Astro components (.astro files) make it easy to implement basic building blocks for different pages. If you’re familiar with JSX, you’ll feel right at home! 🤩
Per default, Astro renders your web pages to fast, static HTML. If you need interactive JavaScript logic, you define a client island: an interactive UI component that is hydrated separately from the rest of the page. I used this concept to add a filter component to my blog archive page. Worked like a charm!
There’s a vibrant community and a ton of plugins.

The Future Looks Bright

I’m very happy with my choice of framework. Astro is simply delightful to work with. And I have a feeling that I’ve only scratched the surface of what’s possible.

Hopefully, Astro stays open source and alive for a long time. I don’t want to switch framework again in a few years. 😝

Flexible Menu Animation with Anchored Container Queries

Sun, 23 Nov 2025 00:00:00 GMT

Chrome has just released a new version 143 with support for CSS anchored fallback container queries. These queries enable us to style an anchored element’s descendants based on its current position relative to the anchor. That’s pretty cool! 🤩

A few months ago, I published an article on building an accessible custom menu with the Popover API and CSS Anchor Positioning. In the article, I complained that I had to resort to JavaScript to make the scaling animation work for different positions of the menu panel relative to the menu button.

Well, not anymore! I’ll show you how to define the menu panel’s animation with CSS only.

Photo: © Snapwire / pexels.com

The Basics of Anchored Container Queries

The CSS Anchor Positioning Module Level 2 document introduces the new anchored value for the container-type property. It states:

Establishes a query container for container queries, allowing for descendants of an anchor positioned element to be styled based on certain features of the anchoring. (Currently, limited to which of the position-try-fallbacks are applied, if any.)

In our use case, we have a custom menu panel that is anchored to its menu button. When we apply container-type: anchored to the menu panel, we turn it into a query container that’s aware of its anchor positioning state.

This allows us to adapt the menu panel’s scaling effect to its current position, using the new at-rule @container anchored(fallback: …) . For example: When the panel is placed at the top and left of the button, we let it grow out of the bottom right corner.

Before we take an in-depth look at the HTML and CSS code, check out the final demo of the custom menu.

I’ve created a new CodePen demo that includes the same menu element four times, placed roughly at the four corners of the screen. This way, you can easily test how the animation of the menu panel takes into account the position relative to the menu button:

See the Pen Menu Anchor Positioning (with Container Query) by Alexander Lehner (@alexlehner86) on CodePen.

If your browser doesn’t support anchored container queries, the menu panel will simply fade in. I’ll show you the details of implementing the scaling effect as a progressive enhancement.

How to use Anchored Container Queries for Flexible Animations

I’m not going to repeat all the details of the accessible custom menu I built. Make sure to read my article “Let’s build an Accessible Menu with Modern Web Features” first before you continue.

Step 1: The basic HTML structure

To make the anchored container query work, we need to slightly adapt the HTML structure of our custom menu. I tried to apply the change to the div[role=“menu”] element itself, but it had no effect. Why is that?

The official specification states that the container query only allows for descendants of an anchor positioned element to be styled. This means, we need an additional inner container:

<button id="menu-btn-1" class="menu-btn" aria-label="More options" popovertarget="menu-content-1" type="button">
    <span>/* icon */</span>
</button>
<div id="menu-content-1" role="menu" aria-labelledby="menu-btn-1" popover>
    <div class="menu-inner-box">
        <button role="menuitem" type="button">...</button>
        <button role="menuitem" type="button">...</button>
        <button role="menuitem" type="button">...</button>
    </div>
</div>

The .menu-inner-box element is a descendant of our menu panel. Therefore, we can change its transform-origin depending on the menu panel’s anchor positioning state.

The panel should fade in and grow in size when it is opened. As the transition applies to a popover that changes from display: none to display: flex , we also need to transition the overlay and display properties. Here’s the basic setup for the panel:

div[role="menu"] {
    /* General animation and end of fade-out */
    opacity: 0;
    transition-property: opacity, overlay, display;
    transition-behavior: allow-discrete;
    transition-duration: 100ms;
    transition-timing-function: linear;
}

The scaling animation is defined separately for the inner container. As the menu panel’s default position is to the bottom and right of the menu button, we set transform-origin: top left for the scaling effect:

div[role="menu"] > .menu-inner-box {
    transform: scale(1);
    transform-origin: top left;
    transition-property: transform;
    transition-duration: inherit;
    transition-timing-function: inherit;
}

We want the fade-in to last 120 milliseconds and use a smooth cubic-bezier timing function. At the end of the transition, the popover is fully visible and scaled to 100 percent:

div[role="menu"]:popover-open {
    /* End of fade-in and start of fade-out */
    transition-duration: 120ms;
    transition-timing-function: cubic-bezier(0, 0, 0.2, 1);
    opacity: 1;
}

div[role="menu"]:popover-open > .menu-inner-box {
    transform: scale(1);
}

As the menu panel switches from a hidden to a visible state, there are no computed values that the transition can use as a starting point. Therefore, we use @starting-style to set the starting opacity to 0 and the initial scale to 80 percent:

/* Start of fade-in */
@starting-style {
    div[role="menu"]:popover-open {
        opacity: 0;
    }
    div[role="menu"]:popover-open > .menu-inner-box {
        transform: scale(0.8);
    }
}

With this setup, the scaling animation works for the default placement of the menu panel. Next, we’ll use anchored container queries to adapt the animation to different positions.

Step 3: Position Fallbacks

Our menu button is implicitly defined as the anchor element of the menu panel. Therefore, we simply define the default placement of the menu panel and several fallbacks:

div[role="menu"] {
    position: fixed;
    position-area: end span-end;
    position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;
}

When the anchored element (the menu panel) overflows its containing block, the browser will automatically try the list of alternative positions defined by the position-try-fallbacks property. It will use the first alternative that doesn’t overflow the containing block or viewport.

How can we detect which fallback position was picked by the browser? First, we turn the menu panel into a query container for its anchor position:

div[role="menu"] {
    container-type: anchored;
}

Now we can define anchored queries to check the fallback and adapt the animation accordingly. Here’s an example:

@container anchored(fallback: flip-block) {
    div[role="menu"] > .menu-inner-box {
        transform-origin: bottom left;
    }
}

When the menu panel’s position is flipped in the block axis (moved to the top), then this at-rule will take effect and make the panel appear to grow outwards from the menu button. Awesome! 😍

You can find the rest of the necessary container queries in the CSS code of my CodePen demo.

Step 4: Progressive Enhancement

Last but not least, we don’t want the animation of the menu panel to break on browsers that don’t support anchored container queries yet. Using the @supports at-rule, we only define the scaling effect for the inner container as well as the container queries if the browser supports it:

@supports (container-type: anchored) {
    div[role="menu"] {
        container-type: anchored;
    }

    /* Styles related to the scaling effect animation */
}

Progressive enhancement has never been this easy!

Useful Resources

Let's Play Accordion with the HTML details element

Sat, 27 Sep 2025 00:00:00 GMT

Managing content on a website can be challenging. You don’t want to overwhelm your users with too much information at once. One helpful strategy is to place content in sections with show/hide functionality. A typical example would be an FAQ page with a list of expandable questions and answers.

We can use the native <details> HTML element to create such a disclosure widget. The element has been around for many years, but it used to be tricky to style and animate. Thanks to Interop 2025, browsers have greatly improved their implementations of the element and added new features.

Photo: © Jefferson Lucena / pexels.com

I’ll quickly go over the basics of the native HTML element. Then we’ll take a look at the new shiny features. 🤩

The `<details>` HTML element

The native details element creates a disclosure widget, also called an expansion panel. The information placed inside the element is visible only when the widget is toggled into an open state. We use the <summary> HTML element to provide a label for the widget. Here’s an example:

<details>
    <summary>An interesting question?</summary>
    <p>A fascinating answer!</p>
</details>

With just a few lines of code we get a fully accessible disclosure widget. It communicates its name, role and current status to assistive technologies and is fully operable with a keyboard.

New Features

Exclusive Accordions with the `name` attribute

An accordion component is a common UI pattern found on many websites. It consists of several disclosure widgets that individually can be expanded and collapsed.

A variation of the accordion pattern is the exclusive accordion , in which only one section can be open at the same time. Use the name attribute to turn a list of <details> elements into an exclusive accordion. Take a look at this code snippet from my CodePen demo:

<details name="faq">
    <summary>What is the Doctor's real name?</summary>
    <p>I'll never tell!</p>
</details>
<details name="faq">
    <summary>Who are the Daleks?</summary>
    <p>The Daleks are...</p>
</details>

Now the individual disclosure widgets are linked. When you open one of the sections in the accordion, the browser will automatically close all other sections. Try it yourself:

See the Pen FAQ Accordion with Details Element by Alexander Lehner (@alexlehner86) on CodePen.

Content Styling with `::details-content`

You can easily style the expandable content of the <details> element using the new ::details-content CSS pseudo-element. Here’s an example:

details::details-content {
    color: rgb(54, 69, 79);
    line-height: 1.3;
    padding-inline: 0.5rem;
}

Furthermore, we can use the pseudo-element to animate the opening and closing of our disclosure widget. Our goal is to smoothly transition the content from zero height to its full height. To pull this off, we depend on the still experimental interpolate-size CSS property, which is only supported in Chromium browsers at the moment.

But don’t worry! We can implement the animation as a progressive enhancement. Using the @supports at-rule, we only apply the animation when the browser supports it:

@supports (interpolate-size: allow-keywords) {
    details {
        interpolate-size: allow-keywords;

        &::details-content {
            height: 0;
            overflow-y: clip;
            transition:
                height 0.35s ease,
                content-visibility 0.35s ease allow-discrete;
        }
    }

    details[open]::details-content {
        height: auto;
    }
}

I know, there’s a lot going on in the CSS code above. I’ll explain it step-by-step:

By default, browsers don’t support animations and transitions involving an intrinsic size value like auto . We enable this behavior by setting interpolate-size: allow-keywords .
We set the initial height of the content to zero (height: 0 ) and clip any overflowing content.
Using the transition shorthand, we define the animation of the height property. We also need to include the content-visibility property, which is automatically set by the browser when the details element is expanded or collapsed. See transition-behavior for more information.
At last, we set height: auto for the content when the details element is in the open state.

Open my CodePen demo in Chrome or Edge to see the smooth animations for yourself. 😎

Custom Indicator for open/closed state

Browsers typically present the <details> element with a small triangle that rotates to indicate open/closed state. This indicator will appear differently across platforms and browsers.

To replace the default triangle with a custom indicator, we need to override the display: list-item value of the <summary> element. I use flexbox as this supports my desired layout. But you could also set display: block , for example.

In addition, we also need to hide the pseudo-elements for the default triangle. This includes ::-webkit-details-marker , which is used in the Safari browser:

details summary {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: 1rem;

    &::marker,
    &::-webkit-details-marker {
        display: none;
    }
}

Next, we define our custom indicator. I want to display an arrow icon that points downwards when the disclosure widget is closed. Thanks to modern CSS, we don’t need any images or icon fonts. We can simply draw the shape using the ::after pseudo-element and the clip-path CSS property.

details summary::after {
    --shape-chevron-width: 1rem;
    --s: calc(var(--shape-chevron-width) / 4);

    content: "";
    aspect-ratio: 7/5;
    background: currentColor;
    clip-path: polygon(0 0, 0 var(--s), 50% 100%, 100% var(--s), 100% 0, 50% calc(100% - var(--s)));
    flex-shrink: 0;
    width: var(--shape-chevron-width);
}

I adapted a code example from the website CSS Shape. It offers tons of code snippets for pure CSS shapes made with a single-element and modern CSS. You should definitely check it out! 🥰

Finally, we want the arrow icon to point upwards when the disclosure widget is open. Of course, the transition should be animated. Here’s the code:

details {
    summary::after {
        rotate: 0deg;
        transition: rotate 0.35s ease;
    }

    &[open] summary::after {
        rotate: -180deg;
    }
}

Et voilà! We’ve replaced the default triangle with a custom arrow icon that looks the same on all platforms and browsers. Here’s the final result:

See the Pen Accordion with Custom Arrows by Alexander Lehner (@alexlehner86) on CodePen.

Flexbox and Grid Layouts

Historically it wasn’t possible to change the display type of the <details> element. This restriction has now been relaxed in all major browsers (e.g., Firefox 143).

That means, it’s finally possible to use grid or flex layouts on the <details> element. Check out the article “More options for styling <details>” on the Chrome Developer blog.

Conclusion

The <details> and <summary> elements are awesome! Thanks to the new features we can easily create disclosure widgets and even exclusive accordions with custom styling and animations.

This means: One more type of content we can build with native web features. No need for UI library components and their annoying tendency for breaking changes. I love the (native) web! ❤️

How to Create an Accessible Table with Clickable Rows

Mon, 25 Aug 2025 00:00:00 GMT

Tables on websites usually display static information in rows and columns. But what if you want to make the rows clickable, e.g., to show more information about the thing that the row is about? Your first thought might be to put click event handlers on the table rows (<tr> ) to make them clickable. But you really shouldn’t!

A table row with a click event handler doesn’t magically turn into an accessible control. You won’t be able to focus the row using a keyboard, let alone trigger the click event using the ENTER key. The purpose of the click event handler would be unclear to a screen reader user. So what should we do?

Photo: © Kampus Production / pexels.com

To create an accessible table with clickable rows, we simply take a <button> element and extend its reach to cover the whole row. My solution is inspired by Adrian Roselli’s article “Don’t Turn a Table into an ARIA Grid Just for a Clickable Row”.

Demo: Table with Clickable Rows

I’ve created a CodePen demo that lists several Studio Ghibli movies in a tabular format. Each row can be clicked to open a dialog with more information about the movie:

See the Pen Table with Clickable Row by Alexander Lehner (@alexlehner86) on CodePen.

Building the Accessible Table

The Ideal Solution

We add a <button> element in the last table cell of each row. The button’s accessible name (“More Information” ) together with the row heading (the <th> element in the row) inform screen reader users about the purpose of the control:

<tr>
    <th>Spirited Away</th>
    <td>2001</td>
    <td>2h 4m</td>
    <td>
        <button id="info-btn-1" aria-label="More Information" type="button">
            <span>/* icon */</span>
        </button>
    </td>
</tr>

The button is keyboard operable by default. All we need to do is to visually convey that the whole table row is focused. We can use the :focus-within CSS pseudo-class:

table tbody tr {
    &:focus-within, &:hover {
        outline: 0.188rem solid black;
        outline-offset: -0.313rem;
    }

    button:focus {
        outline: none;
    }
}

This way, the table row is highlighted on hover or when the button within the row receives focus.

Finally, we want to trigger the button when the user clicks on the table row. To achieve this, we use the ::after pseudo-element together with the inset CSS property:

table tbody tr {
    position: relative;

    button::after {
        content: "";
        position: absolute;
        inset: 0;
    }
}

The pseudo-element is absolutely positioned relative to its parent <tr> element and covers the whole table row thanks to inset: 0 . Now, a click on the table row will count as a click on the button within. Awesome! 🤩

There’s only one problem: It doesn’t work in Safari (at the moment). The position: relative definition for the <tr> element is simply ignored. 🤬

The Safari Supported Version

As long as the WebKit bug isn’t fixed, we need a workaround. I’ve created an alternative CodePen demo that also works in Safari:

See the Pen Table with Clickable Row (Safari Support) by Alexander Lehner (@alexlehner86) on CodePen.

The solution is a bit hacky, but it works. Instead of using the table row as the relative anchor, we position the pseudo-element relative to its parent <td> element. Take a look:

table {
    overflow: clip;
}

table tbody tr {
    td:has(button) {
        position: relative;
    }

    button::after {
        content: "";
        position: absolute;
        inset: 0;
        left: auto;
        width: 100vw;
    }
}

We revert the pseudo-element’s left property to auto and set its width to 100% of the viewport width. In addition, we set overflow: clip on the table to limit the reach of each button to the actual width of the table row.

Conclusion

As you can see, creating an accessible table with clickable rows isn’t that hard. Always keep in mind that not all of your users use a mouse or a touch device. Always test with keyboard and screen readers as well. 😉

Let's build an Accessible Menu with Modern Web Features

Mon, 14 Jul 2025 00:00:00 GMT

We’re all familiar with menu elements on websites. A menu is a widget that offers a list of choices to the user, such as a set of actions. Such menus behave like native operating system menus and should not be confused with navigation menus that are commonly placed in the page header.

Unfortunately, the existing <menu> element doesn’t behave as expected. There are plans to adapt the native element, but in the meantime we have to create our own custom menu. We could use a menu component from a UI library. Which represents another dependency for your project, and possibly breaking changes in the future. I’d rather not.

But there’s good news! Thanks to new web features like the Popover API and CSS Anchor Positioning, creating your own custom menu element has become a lot easier. Let’s build an accessible menu together!

Photo: © Zachary DeBottis / pexels.com

What we want to achieve

Our custom menu should meet the following requirements:

The menu is fully accessible, meaning:
- It conveys its role and status to assistive technologies like screen readers.
- It supports keyboard operation and has a visible focus indicator.
- The text and graphical elements have sufficient color contrast.
Inside the menu panel, the user can activate one of several menu items. For the sake of simplicity, we don’t support nested menus (maybe I’ll look into this in the future).
The menu panel opens next to the trigger button and stays attached on scrolling.
The opening and closing of the menu panel is smoothly animated.

I’ll show you how to achieve this step by step. But first, take a look at the result.

I’ve created a CodePen demo that includes the same menu element four times, placed roughly at the four corners of the screen. This way, you can easily test how the placement of the menu panel takes into account the available space:

See the Pen Menu Anchor Positioning Testcase by Alexander Lehner (@alexlehner86) on CodePen.

Step 1: The basic HTML structure

We define an icon button with an aria-label to communicate its purpose to screen reader users. Next to it, we place a div container with several buttons inside it, creating the menu panel. The attributes role=“menu” on the container and role=“menuitem” on each button convey the appropriate roles to assistive technologies:

<button id="menu-btn-1" class="menu-btn" aria-label="More options" type="button">
    <span>/* icon */</span>
</button>
<div role="menu" aria-labelledby="menu-btn-1">
    <button role="menuitem" type="button">More information</button>
    <button role="menuitem" type="button">Share</button>
    <button role="menuitem" type="button">Download the file</button>
</div>

With CSS, we style our menu button to have a good target size and proper color contrast. We turn the menu panel into a flex container that arranges its menu items in a column. Here’s an excerpt:

button.menu-btn {
    color: white;
    background-color: #00514c;
    /* other styling */
}
div[role="menu"] {
    display: flex;
    flex-direction: column;
    margin: 0.25rem 0;
    /* other styling */
}

So, what have we got? An icon button with an always visible list of buttons next to it. Now we build upon this foundation to create our accessible menu.

Next, we add the popover attribute to our menu panel. This causes the menu panel to be hidden on page load. When the popover is shown, it is put into the top layer so it will sit on top of all other page content.

Now, we want our menu button to control when the menu panel is shown or hidden. To create this connection, we assign an id to the popover element and set the popovertarget attribute with the ID value on the menu button. Here’s the end result:

<button popovertarget="menu-content-1" id="menu-btn-1" class="menu-btn" aria-label="More options" type="button">
    <span>/* icon */</span>
</button>
<div popover id="menu-content-1" role="menu" aria-labelledby="menu-btn-1">
    /* menu items */
</div>

These simple steps already provide us with a lot of features: The menu button opens and closes the panel, it communicates its state to assistive technologies (like aria-expanded would), we get light-dismiss and some keyboard operability. Find out more in the MDN article Using the Popover API.

One important piece of advice on styling popover content: If you want to use a flexbox or grid layout, you should only change the value of the popover’s display property when the popover is open. Otherwise, you would override its display: none value when it is closed, making it always visible. Here’s a code example:

div[role="menu"] {
    flex-direction: column;
    margin: 0.25rem 0;
    /* other styling */

    &:popover-open {
        display: flex;
    }
}

Step 3: Panel placement with CSS Anchor Positioning

To establish a visual link between the menu button and its panel, we need to place them next to each other. And we want to ensure that the panel stays tethered to the menu button, e.g., on scrolling. Historically, this would necessitate the use of a JavaScript overlay library. How annoying!

Lucky for us, the new CSS Anchor Positioning feature does the job for us. It is currently part of Interop 2025 and should be supported in all browsers by the end of the year.

In general, you need to define an anchor element using the anchor-name property. Then you would tether another element to this anchor with the position-anchor property. In case of popover elements, you don’t need to do any of this. As the specification states:

Some specifications can define that, in certain circumstances, a particular element is an implicit anchor element for another element. Implicit anchor elements can be referenced with the auto keyword in position-anchor.

This applies to a button that serves as a popover control, like our menu button. Which means: We’re good to go! Our menu button is implicitly defined as the anchor element of the menu panel.

So where should we place the panel? How about below and to the right of the button? We could achieve this using the anchor() function for inset properties. But I prefer the more elegant and straight-forward position-area property. Take a look:

div[role="menu"] {
    position: absolute;
    position-area: end span-end;
}

You should think of the anchor element and the space around it as a 3x3 grid. The first value we define refers to the block axis, the second one to the inline axis. So, position-area: end span-end means, that we want to place our menu panel at the end of the block axis (below the button) and to let it span from the center to the end of the inline axis (center to right).

But what happens when the menu button is placed on the right edge of the screen? Or if the page’s scroll position places the button at the lower edge of the screen? In both cases, there’s not enough space to display the menu panel with all its options below and to the right of the menu button.

We can easily solve this issue with the help of the position-try-fallbacks property. It allows us to specify a list of one or more alternative positions. When the element would otherwise overflow its containing block, the browser will try placing the positioned element in these different fallback positions.

position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;

We basically tell the browser: If there’s not enough space below the menu button, then move the menu panel above the button. Not enough space to the right? Ok, then flip the inline axis and let the menu panel span the space from the left to the center. And if neither of these work alone, then do both (flip-block flip-inline ).

Step 4: Keyboard Interaction with JavaScript

Our custom menu should be fully operable for keyboard users. The ARIA APG Menu Pattern defines the following requirements:

When a menu opens, keyboard focus is placed on the first item.
Tab and Shift + Tab do not move focus among the items in the menu.
When focus is in a menu, Down Arrow moves focus to the next item, optionally wrapping from the last to the first.
When focus is in a menu, Up Arrow moves focus to the previous item, optionally wrapping from the first to the last.
When focus is on a menuitem in a menu, then Tab and Shift + Tab move focus out of the menu, and close all menus and submenus.
The Enter key activates the item and closes the menu.
Escape closes the menu that contains focus and returns focus to the menu button.

The last requirement is already taken care of thanks to the Popover API. For the rest, we need to implement some JavaScript code and adjust our HTML structure. First, we set tabindex=“-1” on all menu items, to take them out of the focus order:

<div popover id="menu-content-1" role="menu" aria-labelledby="menu-btn-1">
    <button role="menuitem" tabindex="-1" type="button">More information</button>
    <button role="menuitem" tabindex="-1" type="button">Share</button>
    <button role="menuitem" tabindex="-1" type="button">Download the file</button>
</div>

I’ve written a JavaScript class named MenuNavigationHandler that encapsulates the required interactivity of the custom menu element. You simply create a new instance of the class, passing a specific menu element as the parameter. Here’s an excerpt from the code:

class MenuNavigationHandler {
    constructor(menuEl) {
        this.menuEl = menuEl;
        this.menuBtn = document.getElementById(this.menuEl.getAttribute("aria-labelledby")
    );
        this.menuItems = Array.from(menuEl.children);
        this.selectedItem = null;
        this.selectedItemIndex = 0;
        // Handle interaction with menu
        this.menuEl.addEventListener("toggle", (event) => this.onMenuOpen(event));
        this.menuEl.addEventListener("keydown", (event) => this.onMenuKeydown(event));
        this.menuEl.addEventListener("click", (event) => this.onMenuClick(event));
    }

    // Private methods
}

const menus = document.querySelectorAll('div[role="menu"]');
menus.forEach(item => new MenuNavigationHandler(item));

The constructor stores references to the menu button and menu panel. It adds event listeners for the popover toggle event as well as keydown and click events on the menu panel. You can dig into all the code in my CodePen demo.

Step 5: Adding Smooth Animations

Last but not least, we want the custom menu to look and feel good. We use CSS transitions to animate the opening and closing of the menu panel.

div[role="menu"] {
    transition: opacity, transform, overlay, display;
    transition-behavior: allow-discrete;
}

We want the fade-in to last 120 milliseconds and use a smooth cubic-bezier timing function. At the end of the transition, the popover is fully visible and scaled to 100 percent:

div[role="menu"]:popover-open {
    /* End of fade-in and start of fade-out */
    transition-duration: 120ms;
    transition-timing-function: cubic-bezier(0, 0, 0.2, 1);
    opacity: 1;
    transform: scale(1);
}

@starting-style {
    /* Start of fade-in */
    div[role="menu"]:popover-open {
        opacity: 0;
        transform: scale(0.8);
    }
}

Now, to define the end values for the fade-out state, we simply leave out the :popover-open pseudo-class and define the styles for the menu element in general. We want a snappier, linear animation that only lasts 100 milliseconds:

div[role="menu"] {
    /* End of fade-out */
    transition-duration: 100ms;
    transition-timing-function: linear;
    opacity: 0;
    transform: scale(1);
}

Alright, the animation looks pretty cool already. We could leave it at that. But I want to achieve one more thing: The menu panel should appear to be growing out of the menu button. As we’re using the transform property for the scaling effect, we simply need to define its origin like this:

transform-origin: top left;

But there’s a problem! The origin should adapt to the placement of the menu panel next to the menu button. For example, when the panel opens to the top and left of the button, then we would need to define bottom right as the origin.

Unfortunately, the position-try-fallbacks we defined don’t affect the transform-origin property. I also tried to define custom position options with the @position-try rule. But then I realized that the specification (and browser implementation) only allows a very limited set of properties. It just didn’t work.

There’s a note in the specification that gives me hope for the future:

It is expected that a future extension to container queries will allow querying an element based on the position fallback it’s using, enabling the sort of conditional styling not allowed by this restricted list.

In the meantime, we must resort to good old JavaScript. When the menu panel is opened, we call the following method of the MenuNavigationHandler class to set the appropriate transform-origin :

setTransformOriginOnMenuPanel() {
    const menuPanelPos = this.menuEl.getBoundingClientRect();
    const menuTriggerBtnPos = this.menuBtn.getBoundingClientRect();
    let originY = menuTriggerBtnPos.y > menuPanelPos.y ? "bottom" : "top";
    let originX = menuTriggerBtnPos.x > menuPanelPos.x ? "right" : "left";
    this.menuEl.setAttribute("style", `transform-origin: ${originY} ${originX};`);
}

I know it’s a bit dirty. But it works! At least in Chrome and Edge. I’ll have to thoroughly test the whole custom menu in Firefox and Safari when they finally support CSS anchor positioning.

If you don’t know or care about the JavaScript framework Angular, please skip this section.

You’re still here? Alright, then check out my Accessible Popover Menu project. It includes the custom directives CustomMenuTrigger , CustomMenu and CustomMenuItem . These directives encapsulate all the functionality I’ve described in this article so far. You can use them to efficiently create accessible menu components in your Angular project.

Conclusions

Using Popover API and CSS Anchor Positioning is a blast! They make it so much easier to create complex widgets like a custom menu, as I’ve shown you. I’ll do a thorough test run of the functionality in Firefox and Safari as soon as they also support anchor positioning. But I’m very optimistic! 🤩

I hope this article inspires you to experiment with these new web features yourself. I’m curious to see what kind of widgets and components you build with them!

Update on 11/23/2025

Anchored container queries are supported in Chrome 143 now. So forget the use of JavaScript for animations in this article. Go read my new article “Flexible Menu Animation with Anchored Container Queries” instead.

Make Screen Readers talk with the ARIA Notify API

Thu, 22 May 2025 00:00:00 GMT

A user presses the search button and the page content is updated to include the results of the search. Or you click the “Add to Shopping Cart” button and the shopping cart icon in the header receives a visual badge to indicate the added item. Typical workflows in modern websites.

A sighted person can simply perceive the visual change of the page content. But what about blind and visually impaired users? How can they perceive important changes that are not given focus? At the moment, web developers have to use ARIA live regions to create status messages that are announced by screen readers.

Photo: © Edmond Dantès / pexels.com

Unfortunately, ARIA live regions are tightly coupled with DOM elements that need to be updated. But in some cases it would be more straightforward to simply let the screen reader announce a specific text. This is the idea behind the new ARIA Notify API.

Microsoft Edge has recently implemented the new API as a developer and origin trial. So, I went ahead and created a demo project to test the new functionality. Here’s what I think.

How does ARIA Notify work?

ARIA Notify is an imperative notification API designed to replace the usage of ARIA live regions in situations where a visual live region isn’t necessary. The API provides an ergonomic way to tell assistive technologies, such as screen readers, exactly what to announce to users and when.

Developers can call the ariaNotify() method with the text to be announced to the user. Here’s an example:

document.ariaNotify("This is an audible notification");

Optionally, you can set the priority option to indicate how the screen reader should rank the notification with respect to other, pending, notifications:

document.ariaNotify("Critical error", { priority: "high" });

Want to give it a try?

Demo: Online Shop with Shopping Cart

I’ve created a CodePen demo of an online shop named “The Shop” . You can add products to the shopping cart like “Fancy Stuff” or “Useless Junk” . The shopping cart will visually indicate that products were added. Screen reader users will hear a message like, e.g., “Item Fancy Stuff was added to shopping cart.”

See the Pen Shop Demo with ARIA Notify API by Alexander Lehner (@alexlehner86) on CodePen.

At the moment of writing this blog post, the ARIA Notify API is only supported as an origin trial in Microsoft Edge. You need to install Edge Canary and start the browser with the following command:

"C:\Users\[username]\AppData\Local\Microsoft\Edge SxS\Application\msedge.exe" --enable-blink-features=AriaNotify

The -enable-blink-features=AriaNotify flag enables the ARIA Notify API. Now you should hear your screen reader announce a message when you add a product to the shopping cart. I successfully tested this with current versions of NVDA and JAWS.

First Impressions

I like how straightforward and easy to use the new API is. You simply call ariaNotify() and the screen reader announces the message. Awesome! 🤩
The W3C will have to update their list of sufficient techniques in WCAG 4.1.3 Status Messages. 😅
The priority option didn’t really make a difference in my test cases. I’ve created another demo with a toggle for using high or normal priority. But the screen reader announcements came at the same time. Maybe I misunderstood something. 😩
Web developers will have to be very careful with the new API. When it’s that easy to make a screen reader announce text, then there’s a danger of flooding users with too many messages. I’m thinking about autoplay carousels that constantly announce status messages! 😨

Anyway. We’re still in a very early, experimental phase. I’ll wait for other browsers to also implement the new API and let it mature a bit. Then I’ll test it on more devices, especially on mobile.

In general, I’m excited and optimistic about the ARIA Notify API.

Date and Time Management with the Temporal API

Thu, 17 Apr 2025 00:00:00 GMT

Are you fed up with the Date object in JavaScript? Me too! Lucky for us, the Temporal API is just around the corner. This new namespace comprises several classes for date and time management, including built-in time zone and calendar representation.

Photo: © KoolShooters / pexels.com

The new API is already available in Firefox Nightly. We’ll quickly cover the main features of Temporal and then look at some code snippets I’ve compiled.

High-Level Overview

The Temporal API exposes over 200 utility methods via several classes. That’s a lot! So I won’t cover all of them but just name the most important features.

There are several objects for working with plain dates and times, without a time zone:

Temporal.PlainDate represents a calendar date without a time or time zone. Example: 2025-04-14
Temporal.PlainTime represents a time without a date or time zone. Example: 21:10:30.025
Temporal.PlainDateTime represents a date and time without a time zone. Example: 2025-04-14T21:10:30.025

To represent a unique point in time we use the Temporal.Instant object. It is semantically the same as Date , but more precise (nanosecond precision).

At last we arrive at the Temporal.ZonedDateTime object, which combines an instant, a time zone, and a calendar system. Example: 2025-04-16T21:22:26.384+02:00[Europe/Vienna] .

Furthermore, we can get the current time in various formats using the Temporal.Now object. And the Temporal.Duration represents a difference between two time points, which can also be used in date/time calculations.

Code Snippets

I’ve compiled a list of code snippets for working with the new Temporal API in JavaScript. Here’s a few examples:

Create a new plain date object and access parts of it

let calendarDate = Temporal.PlainDate.from("2025-04-09");
calendarDate.day; // 9
calendarDate.dayOfWeek; // 3
calendarDate.month; // 4
calendarDate.year; // 2025

Add a duration to an immutable plain time object

let t1 = new Temporal.PlainTime(14, 55, 10, 250); // "14:55:10.25"
let t2 = t1.add({ seconds: 5000 });
t2.toString(); // "16:18:30.25"

Language-sensitive formatting of a zoned datetime

let datetime = Temporal.ZonedDateTime.from("2020-10-15T08:30Z[America/New_York]");
datetime.toLocaleString("en-US"); // "10/15/2020, 4:30:00 AM EDT"

Compare two instants

let inst1 = Temporal.Instant.from("2022-07-10T12:00Z");
let inst2 = Temporal.Instant.from("2023-01-01T15+01:00");
inst1.equals(inst2);  // false
Temporal.Instant.compare(inst1, inst2); // -1 (is before)

Round a duration to a specified unit

let duration = Temporal.PlainTime.from("12:30").until("17:45"); // "PT5H15M"
duration = duration.round("hours"); // "PT5H"

Browser Support

Are you hyped already? I sure am! And it gets even better: Firefox will soon be the first browser to ship Temporal in stable release. Firefox 139 is due on May 27.

The implementation in other browsers is still a work in progress (Chromium, WebKit/Safari). But I’m sure they’ll get there soon. In the meantime: Get familiar with Temporal in Firefox Nightly. 😉

My Favorite Tools for Web Accessibility Testing

Sun, 30 Mar 2025 00:00:00 GMT

Web accessibility has many facets: Operation with the keyboard and other input devices, alternative texts for images, descriptive headings and error texts, etc. The range of tools for testing the accessibility of websites is just as diverse.

First things first: there is no single power tool that automatically detects all barriers and ideally also removes them straight away. This also applies to AI-based accessibility tools. Yes, artificial intelligence has great potential, but current tools cannot replace a comprehensive accessibility test. Even if certain people claim otherwise in the frenzy of AI hype.

Photo: © Thirdman / pexels.com

We need the right tools for the delicate little plant of accessibility to flourish. Here is my personal selection of free bookmarklets, browser extensions and accessibility testing tools.

Structure and Semantics

WAVE (Web Accessibility Evaluation Tools): An accessibility analysis tool from WebAIM. Available as a browser extension for Firefox, Chrome and Edge. I find the structure view particularly useful, where you can see at a glance whether meaningful landmarks (header , main , etc.) and heading levels have been defined.
Firefox Accessibility Inspector is a built-in component of the Firefox developer tools. Do you want to know what information an interactive element communicates to assistive technologies? Simply right-click on it and select “Inspect Accessibility Properties” . Firefox opens the “Accessibility” tab in the developer tools and jumps to the corresponding node in the accessibility tree. Debugging has never been so easy! 😍
Test with screen readers: No accessibility audit is complete without screen reader testing. In view of limited budgets in projects, it is not possible to test with all screen readers on all platforms. Based on current statistics, I have therefore defined the following test scenarios:
- NVDA in Windows
- VoiceOver in iOS
- TalkBack in Android
If you have never tested with the screen reader, then read my article “5 Tips for getting started with Accessibility Audits using a screen reader”.

Ideal for testing the WCAG criteria 1.3.1 Info and Relationships and 4.1.2 Name, Role, Value.

Keyboard Operability

Test with keyboard: Use the tab key to access the interactive elements on the page (buttons, links, etc.). Does the focus order make sense? Can keyboard users reach and activate all interactive elements? Is the focused element visibly highlighted? On a smartphone or tablet, you can simply connect a Bluetooth keyboard for testing.
taba11y: This useful browser extension calculates the tab order of all elements and displays it visually, either by drawing a path or by highlighting the elements.

Ideal for testing the WCAG criteria 2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, and 2.4.7 Focus Visible.

Responsive Content

Browser settings: Change the default font size of your browser to check whether the website automatically adjusts the text size. Most browsers, such as Edge, only allow you to choose from predefined options such as “Small”, “Medium” and “Large”. In Firefox, on the other hand, users can define a specific pixel value as the default font size.
Alternatively, you can use the browser’s zoom function (CTRL and + key) to enlarge the entire page content in proportion to the font size.
Use the text spacing bookmarklet or a browser extension (e.g. Editor for Textlayout) to set the values for line height, spacing following paragraphs, letter spacing and word spacing to the maximum required values. No content should be cut off or overlap.

Ideal for testing the WCAG criteria 1.4.4 Resize Text, 1.4.10 Reflow, and 1.4.12 Text Spacing.

Target Size of Interactive Elements

Target Size Bookmarklet: It identifies interactive elements, calculates their center and draws a semi-transparent circle of 24 by 24 pixels around the center of the element: A green circle with a thick border means that the target size is sufficient. Elements with a blue circle should be examined manually.
This way, you can find buttons and links much more quickly where users with motor impairments may have problems clicking or tapping.

Ideal for testing the WCAG criterion 2.5.8 Target Size (Minimum).

Minimum Contrast

Chrome Lighthouse is part of the developer tools in Chrome. The Lighthouse accessibility check reliably finds the majority of elements with too low a contrast ratio.
PowerToys Color Picker: The Microsoft PowerToys are a collection of utilities for power users. With the key combination WIN +Shift +C you can activate the color picker at any time and extract the color value of a pixel on the screen.
WebAIM Contrast Checker: Simple tool to check the contrast ratio of a font color to the background color. A particularly useful feature is that you can share the selected color values and their evaluation as a permalink.

Ideal for testing the WCAG criteria 1.4.3 Contrast (Minimum) und 1.4.11 Non-text Contrast.

Additional Links

Accessibility Engineering — Let the Web Platform do the Work

Mon, 03 Feb 2025 00:00:00 GMT

Being a web developer is hard. You’re handed some written requirements and, if you’re lucky, a visual design. You start work on the new feature: You add HTML elements, style them with CSS, and implement business logic with JavaScript. You need to think about usability, web security, page speed, data management, and so on.

You take a deep breath and tell yourself: “I can do this!”

Your project manager comes in and asks: “The website will also be accessible, right?” You panic and start to research web accessibility. You’re flooded with information. Some of it contradicting. You ask ChatGPT for help. It shows you overcomplex code ridden with ARIA attributes. You sigh, thinking: “That’s a lot of work!”

I have good news for you: Accessibility doesn’t have to be this exhausting. It can actually be quite simple and, I dare say, beautiful. All you need to do is embrace the web platform and let it do the work!

Photo: © ThisIsEngineering / pexels.com

We’ll take a quick look at the basic tools of the web and how to use them efficiently. Then I’ll give you several specific examples of web features with accessibility baked in.

The Basic Tools of Accessibility Engineering

The web platform is a collection of technologies developed as open standards by the World Wide Web Consortium and other standardization bodies. These technologies include HTML, CSS, JavaScript and WAI-ARIA. These building blocks of the web enable us to design websites that are accessible to all people.

Then why are so many web developers struggling with accessibility? I think there are two main reasons:

Over-reliance on external libraries.
Insufficient experience with native web features.

Most junior developers nowadays learn web development based on frameworks like Angular, React or Vue.js. They learn everything about components and data management, but hardly familiarize themselves with native HTML elements and advanced CSS features.

I don’t blame any of them! Modern JavaScript frameworks and UI libraries offer powerful features that help us implement complex web applications. But they are another level of abstraction. They take us away from the essential building blocks of the web. So what should you do?

HTML First and The Rule of Least Power

The rule of least power is a design principle that suggests choosing the least powerful language suitable for a given purpose. What does this mean for web developers? If you can do something with HTML, use HTML. Need to adapt the styling? Use CSS. If you can’t do it with HTML and CSS alone, use JavaScript and WAI-ARIA.

Native HTML elements are built to work on multiple browsers and with different types of assistive technology, like screen readers. They’re usually more robust and reliable than custom solutions. Next time you start to implement a new feature, look for a solution in the following order:

HTML
CSS
JavaScript
WAI-ARIA
External Libraries

As a first step, I always search for a native solution on MDN Web Docs. If I can’t do something with HTML and CSS alone, I start to research the proper use of ARIA attributes and JavaScript to create an accessible solution. The ARIA Authoring Practices Guide (APG) provides all the information you need.

Why are external libraries last on the list? Because they create an additional dependency for your project. Once you’ve commited to using a UI component library, you’re usually stuck with it. That’s why you should make sure to pick an accessible UI library. Go read my “Checklist for Accessible UI Component Libraries”.

The Current State of the Web

The web platform is constantly evolving. New HTML elements, CSS properties and Web APIs are specified and implemented by browsers every day. Initiatives like Interop 2024 help to improve the interoperability of the web.

For web developers, it’s way easier and straightforward to create accessible websites today than it was 10 years ago. I admit, not everything can be done with HTML and CSS alone. Right now, you still need ARIA and JavaScript to implement a tab list or custom tooltips.

But I want to focus on the bright side! Let’s take a look at some native HTML features that make it very easy and convenient to create robust, accessible websites.

Examples of Native HTML Features

The `button` element: A Powerful Allrounder

Chances are, the button element is older than you! It was first introduced in the HTML 4.0 specification in December 1997. This means, buttons have been around for quite a while. But still, many web developers underestimate this powerful and versatile HTML element. Some even think it’s a good idea to use a div element instead. The horror! 😱

Maybe you’re thinking: “Alright, Romeo! Why are you so in love with the button element?” Let me answer with the short description by MDN:

The <button> HTML element is an interactive element activated by a user with a mouse, keyboard, finger, voice command, or other assistive technology. Once activated, it then performs an action, such as submitting a form or opening a dialog.

The button element was designed to work well for all users. You can click on it with a mouse. You can focus a button with the TAB key and activate it with the Enter or Space key. When you navigate to the button using a screen reader, it will be able to tell you that this is a button that can be activated.

Browsers also apply a default styling to HTML buttons. Some web developers might find this annoying, because they have to override these styles with CSS. They might pick the div element instead and slap a click event handler on it, thinking that’s enough. Well, it’s not!

There’s a big difference between button and div elements! A button will trigger the click event handler for all types of user interaction: mouse, keyboard, screen reader, and so on. The div element, on the other hand, will only trigger on mouse or touch interaction. To turn a div into an accessible button, you need to:

Add a tabindex to make it keyboard focusable.
Show a visible focus indicator when the button receives focus.
Add key event handlers for the Enter and Space key.
Add a role attribute to tell screen reader users it’s a button.

Wow, that’s a lot of work and code bloat! An implementation using a native button instead will always be easier to read and maintain. If you’re still not convinced, go read my article “3 Ways how Web Developers also benefit from Accessibility”.

That’s already a lot of text about buttons. But there’s one more argument I’d like to make: Native buttons are still gaining more superpowers!

The latest upgrade is thanks to the new Popover API. You can use the popovertarget attribute to turn the button element into a popover control button. Check out this menu button demo (currently only works in Chromium browsers):

See the Pen Accessible Menu with Popover API by Alexander Lehner (@alexlehner86) on CodePen.

There are so many use cases for buttons with attached popovers: Menus, tooltips, date pickers, etc. If you’re new to the topic, you can take a look at the following articles I’ve written:

But we’re not done yet! The next button upgrade will arrive with the (currently experimental) Invoker Commands API. This API provides a way to declaratively assign behaviors to buttons, like opening or closing a modal dialog. Awesome! 🥰

Oh, what a coincidence! Dialogs are the next native HTML feature I want to talk about.

The `dialog` element: Always on top

Dialogs are an integral part of modern web user interfaces: From simple prompts for confirming an action to content-heavy windows. The native dialog element makes it super easy to open an accessible modal dialog on top of the other page content.

The dialog element is accessible by default. When you use the showModal() method to open a modal dialog, the following happens:

The browser automatically moves focus to the first interactive element inside of the dialog.
A screen reader will announce that the new content is part of a dialog.
While the modal dialog is active, the content obscured by the dialog is inaccessible to all users. This means that keyboard users can’t leave the dialog with the TAB key, and a screen reader’s virtual cursor is not allowed to leave the modal dialog as long as it remains open.
Users can close the modal dialog with the ESC key.
On close, keyboard focus returns to the control that initially activated the dialog. This allows keyboard and screen reader users to continue browsing from where they left off.

Of course, you don’t have to use the native dialog element. You could also implement a custom, accessible dialog using ARIA and JavaScript. But why would you? Come on! Be a smart web developer and let the web platform do the work. 😉

If you’re unfamiliar with the native dialog element and want to know more, go read my article “Why you should use the Native Dialog Element”.

Form Controls: The Good and the Bad

Far too often, web developers use custom form controls to meet design needs – neglecting accessibility in the process. You can do better! Modern browsers enable us to apply custom styling to most native form controls. This way, we can create accessible web forms with a consistent look across all platforms.

Native form controls like input or select are accessible by default. They receive keyboard focus and can be activated with Enter or Space , e.g., to mark a checkbox as checked. They communicate their role and current state to screen readers.

The following demo shows an accessible web form with custom styles for the native select list and radio buttons:

See the Pen Styling Native Form Controls by Alexander Lehner (@alexlehner86) on CodePen.

Unfortunately, not all native form controls can be easily adapted with custom styles. Mozilla has a great article on Styling web forms, which I highly recommend. They categorize native form controls into three groups: “The good”, “The bad”, and “The ugly”.

In my opinion, the native elements for text inputs, radio buttons, checkboxes and simple select lists are very easy to style. There is no reason to use custom elements instead. Unless you have a masochistic disposition. Read my article “Create Accessible Web Forms with Custom Styling” for more information.

Now, what about the rest? Several native form controls have internals that can’t be styled in CSS alone. These include the color picker, date picker, file picker, and the drop-down list of the select element. In these cases, I understand the need for custom components. Just make sure they’re accessible.

Lucky for us, the select element will soon get an important upgrade. A customizable version of the element is officially in Stage 2 in the WHATWG, with strong cross-browser interest and a prototype available in Chrome Canary. Read this Chrome blog post for more information. 🤩

Disclosure and accordion widgets with native HTML

The native details HTML element creates a disclosure widget in which information is visible only when the widget is toggled open. The content of the nested summary element provides the label for the disclosure widget. The perfect HTML elements for a FAQ page or an expandable info section in an article.

<details>
    <summary>What is HTML?</summary>
    HTML is the standard markup language for web pages, defined by the W3C and WHATWG.
</details>

Historically it wasn’t possible to change the display type of the details element. This restriction has already been relaxed in Chromium browsers, allowing you to use grid or flex layouts. The article “More options for styling <details>” includes a really cool demo for an exclusive accordion.

Conclusion

Alright. This article turned out longer than I had intended. 😂

I hope it helps you on your journey to becoming an accessibility engineer. Native HTML is powerful and (mostly) accessible by default. If you keep this in mind, you’ll be alright.

Placeholder Text needs Good Color Contrast

Fri, 20 Dec 2024 00:00:00 GMT

Does placeholder text in forms need to meet color contrast requirements? The short answer is: “Yes, it does!”

The long answer: Not all users have perfect vision with high contrast sensitivity. Especially when you get older, it gets harder to recognize text as being separate from the background behind it when color contrast is low. Therefore, you should always provide sufficient contrast between text and its background.

This also applies to placeholder text in web forms or documents. The placeholder usually provides a useful hint that describes the expected value of an input field. It isn’t purely decorative. So, all users should be able to perceive the placeholder text.

Photo: © Egor Komarov / pexels.com

Requirements for minimum color contrast

The Success Criterion 1.4.3 Contrast (Minimum) of WCAG 2.2 defines requirements for minimum color contrast. Text must have a minimum contrast ratio of 4.5 to 1 with the background, or 3 to 1 contrast ratio if its large text. The understanding document explicitly states:

This Success Criterion applies to text in the page, including placeholder text and text that is shown when a pointer is hovering over an object or when an object has keyboard focus.

There’s lots of tools you can use to check the contrast ratio of two color values. I mostly use the WebAIM Contrast Checker.

How to style placeholder text in web forms

In most browsers, the default appearance of placeholder text is a light gray color by default. UI libraries also sometimes use very light colors for placeholder text. This results in placeholder text with poor color contrast.

Use the ::placeholder CSS pseudo-element to define a text color with sufficient color contrast:

input::placeholder {
    color: #5b5b5b;
}

You can also change the font style and weight of your placeholder text. Take a look at my demo where you can compare your browser’s default styling with the applied custom styles:

See the Pen Style placeholder text by Alexander Lehner (@alexlehner86) on CodePen.

A small change that highly improves the accessibility of your website. Sometimes it’s that easy! 😊

Useful Resources

How to build Accessible Navigation Menus with the Popover API

Thu, 17 Oct 2024 00:00:00 GMT

Navigation menus are an essential part of every website. They’re usually placed in the header and provide an overview of a website’s page hierarchy. They enable users to gain an overview of the content and to quickly navigate to main sections of the website.

Many websites use fly-out (or drop-down) menus, where certain menu items open submenus on hover or click. Often, these menus offer very poor accessibility for screen reader and keyboard users. But we can do better!

I’ll show you how to leverage the power of modern web features like the Popover API to easily create an accessible fly-out menu.

Photo: © Valentin Antonucci / pexels.com

What we want to achieve

Our navigation menu should be easy to use for different user groups:

The submenus should appear on top of the site content and should not disappear immediately after the mouse has left the clickable area.
Screen reader users require meaningful markup to understand and operate the navigation menu.
Keyboard users should be able to operate the menu using the keyboard alone.

I’ve created a CodePen demo of an accessible navigation menu using the Popover API. Be sure to open the demo on a desktop screen or tablet in landscape mode to see the fly-out menu. On smaller devices, the demo will display a mobile menu instead.

Photo: © Alexander Lehner

The navigation menu is easy to use for mouse, keyboard, and screen reader users. Let’s examine the key elements.

Meaningful Markup

We use the nav element to convey the role of the navigation menu. The menu items are placed inside an unordered list (ul element). This allows assistive technologies to announce the number of items in the menu and provide corresponding navigation functionality.

<nav class="main-nav">
    <ul>
        <li>
            <button popovertarget="nav-panel-solutions" type="button">Solutions</button>
            <div id="nav-panel-solutions" popover>...</div>
        </li>
        <li><a href="#">Products</a></li>
        <li>...</li>
        <li>...</li>
    </ul>
</nav>

The list items either contain a direct link to a subpage, or they contain a button element that opens a submenu which uses the popover attribute. The button is connected to the popover content via the popovertarget attribute.

One of the great advantages of the Popover API: It automatically conveys to assistive technologies whether the submenu navigation is presently collapsed or expanded. You should read the article “On popover accessibility: what the browser does and doesn’t do” for more information.

Avoid the `menu` role

As you can see in my demo, I’m not using the menu and menuitem roles in my navigation menu. This is on purpose! These ARIA roles are only inteded for menu widgets that behave like native operating system menus.

Go read the article “Don’t Use ARIA Menu Roles for Site Nav” by Adrian Roselli for a detailed explanation.

Visual Placement

When a submenu is opened, it will automatically appear on the top layer, a separate layer that sits on top of all other layers displayed in the web document. You only need to take care of the placement and size of the submenu:

header nav.main-nav [popover] {
    top: var(--header-height);
    margin: 0;
    width: 100%;
}

The default placement of popover content is in the center of the screen. To place our submenus right beneath the header, we set top to the height of the header and remove any margin . Next, we set width to 100% to make the submenu cover the whole width of the page.

Keyboard Operability

You can use the TAB key to focus the links and buttons in the navigation menu. After opening a submenu, its content will be next in the focus order. Pressing the ESC key will close the submenu and automatically return focus to the trigger button. All thanks to the mighty Popover API! 🤩

Light-dismiss of Submenus

Another baked in feature of the Popover API is light-dismiss: Clicking outside of the submenu area will close the submenu and return focus to the trigger element. No need to mess around with focusout events in JavaScript.

Useful Resources

Easy Offline Storage with idb and the IndexedDB API

Mon, 09 Sep 2024 00:00:00 GMT

I really like the JavaScript library idb, a minimal wrapper for the IndexedDB API. I’ve used it in several web applications to provide offline capabilities.

The idb library makes it easy to store data on your device and retrieve it later via a Promise. It also includes great TypeScript types and interfaces that support creating generic logic for interacting with your offline storage.

Photo: © RDNE Stock project / pexels.com

Let’s take a look at the basics of setting up a database with idb . Then I’ll provide some code examples of reusable generic methods for storing and retrieving data.

Setting up the database

First of all, you’ll need to define the schema for the data you want to store. Here’s a basic example:

import { DBSchema } from "idb";

export interface MyAwesomeDB extends DBSchema {
    images: {
        value: MyImageData;
        key: string;
    };
    videos: {
        value: MyVideoData;
        key: string;
    };
}

I recommend you bundle the DB operations in their own class. This class only serves the specific purpose of interacting with the database, making your code easier to read and understand. In an Angular application, I would create an injectable service class like this:

import { IDBPDatabase, openDB } from "idb";

@Injectable()
export class OfflineStorageService {
    private _databaseVersion = 1;
    // The promise returned when opening the IndexedDB with openDB() method.
    private _myDatabase$: Promise<IDBPDatabase<MyAwesomeDB>> | null = null;

    public init(): void {
        this._myDatabase$ = openDB<MyAwesomeDB>(
            "my-awesome-database",
            this._databaseVersion,
            {
                // Initialize objects in database if opened for the first time.
                upgrade: (database, oldVersion) => { ... },
            },
        );

        // Handle success and error case.
        this._myDatabase$.then(
            () => console.log("IndexedDB was successfully opened.""),
            () => this.onOpeningDatabaseFailed(),
        );
    }
}

Storing data

Let’s assume you want to store several items in a specific object store of your database. Usually, you’ll open a transaction with readwrite access and then store the items. For this operation, you can define a generic method with the parameters storeName and items :

import { StoreNames, StoreValue } from "idb";

// Stores all items in the object store named "storeName".
private storeAllItemsInObjectStore<Name extends StoreNames<MyAwesomeDB>>(storeName: Name, items: StoreValue<MyAwesomeDB, Name>[]): void {
    this._myDatabase$?.then((database) => {
        const transaction = database.transaction(storeName, "readwrite");
        items.forEach((item) => transaction.store.add(item));
    });
}

The method uses the types StoreNames and StoreValue from the idb library . They make sure that the storeName parameter passed to the method is actually part of the database and that the items have the expected data structure. Here’s an example of using this generic method:

public storeImages(items: MyImageData[]): void {
    this.storeAllItemsInObjectStore("images", items);
}

Retrieving data

When retrieving data from the local database, I prefer turning the native Promise into an Observable . This makes it easier to integrate the offline storage into an observable based application state logic (e.g., NgRx store). Here’s a generic method that returns a specific item from an object store wrapped in an observable:

import { StoreKey, StoreNames, StoreValue } from "idb";
import { Observable, catchError, from, of, switchMap } from "rxjs";

// Retrieves the item identified via "itemKey" from the object store named "storeName". Resolves with undefined if no match is found, the database is unavailable, or there's an error.
private getItemFromObjectStore<Name extends StoreNames<MyAwesomeDB>>(
    storeName: Name,
    itemKey: StoreKey<MyAwesomeDB, Name>,
): Observable<StoreValue<MyAwesomeDB, Name> | undefined> {
    if (this._myDatabase$ === null) {
        return of(undefined);
    }

    return from(this._myDatabase$).pipe(
        switchMap((database) => from(database.get(storeName, itemKey))),
        catchError((error) => {
            console.error(error);
            return of(undefined);
        }),
    );
}

You can use the generic method like this:

public getImage(imageId: string): Observable<MyImageData | undefined> {
    return this.getItemFromObjectStore("images", imageId);
}

Have fun using IndexedDB and the idb library!

Native Dialogs and the Popover API — What you need to know

Sat, 15 Jun 2024 00:00:00 GMT

The modern web is awesome! We can easily create accessible, robust modal dialogs with the native <dialog> element. Want to open a menu or tooltip on top of the other page content? No problem! The HTML attribute popover turns any element into popover content.

The last few months, I’ve been building more and more dialogs with the native HTML element. And in April, when the Popover API reached cross-browser support, I started experimenting with popover in various projects. I quickly realized: These web features make our lives as web developers a lot easier, but there are some pitfalls. Especially when you combine both features!

Photo: © Rama Khandkar / pexels.com

I’ll quickly go over the basics of how dialogs and popovers work together. Then I’ll share some of my hard-earned learnings with you. If you’re not familiar with the features in general, I recommend you read my blog posts “Why you should use the Native Dialog Element” and “Make your content pop with the Popover API and CSS Anchor Positioning”.

When you open a modal dialog with the showModal() method, the dialog is added to the top layer and rendered on top of other page content. The same happens when you show popover content using the showPopover() method.

Now, what happens if an element is already open in the top layer and you add another element to it? The elements are stacked in the order they are added to the top layer. The last one in always appears on top. You can’t use the z-index property to change this stacking order. The only thing that matters is, when an element was added to the top layer.

To give you an example: A button opens a menu panel as a popover. This menu contains an option that opens a modal dialog that is rendered on top of the menu panel. This dialog contains a button that opens a tooltip popover on top of the dialog. We could go on and on. 😉

What you need to know about dialogs and popovers

Animation as progressive enhancement

Everything looks better with smooth entry and exit animations. There’s only one problem: Dialogs and popovers are set to display: none when hidden and display: block when shown. And we all know that you can’t transition content from or to display: none . Right? Wrong!

The new @starting-style rule together with the transition-behavior CSS property enable us to animate dialogs and popovers. I described both features in detail in my blog post “Accessible Alerts made easy by the Popover API”.

Check out my demo for a modal dialog with smooth fade in and out animation. At the moment of writing, this only works in Chrome and Edge:

See the Pen Dialog Animation Demo by Alexander Lehner (@alexlehner86) on CodePen.

You can define transitions for the dialog (or popover) itself as well as its backdrop. Here’s the CSS code for animating the dialog:

dialog {
    --duration: 150ms;
    --start-opacity: 0.5;
    --start-scale: scale(0.8);

    /* End values for fade out. */
    opacity: var(--start-opacity);
    transform: var(--start-scale);
    transition:
        opacity var(--duration) ease-out,
        transform var(--duration) cubic-bezier(0, 0, 0.2, 1),
        overlay var(--duration) allow-discrete,
        display var(--duration) allow-discrete;
}

dialog[open] {
    /* End values for fade in; start values for fade out. */
    opacity: 1;
    transform: scale(1);

    @starting-style {
        /* Start values vor fade in. */
        opacity: var(--start-opacity);
        transform: var(--start-scale);
    }
}

And this is how you animate the dialog’s backdrop:

/* Styling for backdrop behind the dialog */
dialog::backdrop {
    background: rgb(0 0 0 / 0.32);
    /* End value for fade out. */
    opacity: 0;
    transition: opacity var(--duration),
        overlay var(--duration) allow-discrete,
        display var(--duration) allow-discrete;
}

dialog[open]::backdrop {
    /* End value for fade in; start value for fade out. */
    opacity: 1;
}

/* This starting-style rule cannot be nested inside the above selector because the nesting selector cannot represent pseudo-elements. */
@starting-style {
    dialog[open]::backdrop {
        /* Start value vor fade in. */
        opacity: 0;
    }
}

But what about browser support? Don’t worry! The @starting-style rule and the transition-behavior property are perfect examples of progressive enhancement. If a browser doesn’t support these new features, then it will still render the dialog or popover element, but without the animation.

Automatically close the dialog on backdrop click

The native <dialog> element has several great features built in:

When a modal dialog is opened, the browser moves focus to the first interactive element inside of the dialog.
Closing the modal dialog returns focus to the element that opened the dialog.
Users can close the modal dialog with the ESC key.

But one important feature is not supported by default: Automatically closing the dialog when the user clicks on the backdrop. In my first blog post about dialogs, I demonstrated the following custom implementation of light dismiss: Getting the coordinates of the click and comparing them to the dialog’s rectangle.

Some time ago, I came across a more elegant solution: You add a click event listener to your dialog and then check the tag name of the event target. Here’s the JavaScript code for the function:

function onDialogClick(event) {
    event.stopPropagation();
    if (event.target.tagName === "DIALOG") {
        dialogElementRef.close();
    }
}

A click on the dialog’s backdrop is registered as a click on the dialog element. For this to work, the dialog’s content needs to be wrapped in an extra element. Otherwise, clicking inside certain areas in the dialog would also close it.

Check out the CodePen demo above where I also implemented this custom behavior.

Some time ago, I was working on a web project for a client that includes a list of items. The user can click on one of the items to open a modal dialog with more details. This dialog contains a button that allows the user to add the item to their list of favorites. Afterwards, a snackbar appears on the bottom of the screen that also includes an undo button.

Being the hip, state-of-the-art web developer that I am, I wanted to use the <dialog> element combined with a popover element for the snackbar. After implementing everything, I started to test the undo feature and was baffled: Although the snackbar with the undo button was visible and appeared on top of the modal dialog, I wasn’t able to interact with it. Me: “What the hell is happening?!”

After some research, I found the cause of the problem. But before I tell you, check out this demo with a minimal version of the web project I described above. The dialog includes two buttons: The first opens a snackbar that you can’t interact with. The second button opens a snackbar with a working undo button. Can you tell the difference?

See the Pen Dialog with Popover Demo by Alexander Lehner (@alexlehner86) on CodePen.

Let me explain what’s going on: In general, the position of a popover element in the DOM doesn’t affect its visibility. When you show the popover, the browser adds it to the top layer and it appears on top of all other content. But only because you can see something doesn’t mean you can interact with it. The answer can be found in the description of the showModal() method:

The showModal() method of the HTMLDialogElement interface displays the dialog as a modal […]. Interaction outside the dialog is blocked and the content outside it is rendered inert.

This means, if you place the popover element for the snackbar outside of the dialog, then it’s rendered inert. All user input events for the element and its descendants are ignored. So what can you do? Simply place the popover element inside of the dialog element. Now the browser considers it part of the dialog’s content and won’t render it inert.

Always close manual popovers nested inside dialogs

One last observation about manual popovers nested inside a modal dialog. If you close the dialog, make sure to also close the popover with the hidePopover() method. Otherwise, the popover might not be visible, but would still be open and remain in the top layer.

Now, when you open the dialog again, it will be placed above the popover inside the top layer. So even if you try to open the popover again with the showPopover() method, nothing will happen! The popover is already open and placed beneath the modal dialog in the top layer. What a mess!

Conclusion

The native <dialog> element and the popover attribute are very powerful and convenient features. But there are some pitfalls. I hope my learnings can help you to make great use of these awesome features in your own projects. Happy coding! 😊

Update on 03/28/2026

Use the new closedby attribute instead of JavaScript to add light dismiss behavior to the dialog. This feature should have cross-browser support until the end of the year. Learn more in my new article “Enhance Dialogs with the closedby Attribute”.

Will the CSS Scope Feature replace Angular's View Encapsulation?

Thu, 02 May 2024 00:00:00 GMT

We developers love convenience. We welcome any tool or feature that makes our lives easier. This is especially true in regards to styling web content with CSS.

One major challenge is to define CSS rules that target specific elements without writing overly-specific selectors that are hard to override. Also, you don’t want to couple your selectors too tightly to the DOM structure as it is prone to change.

Various JavaScript frameworks have come up with different solutions for the problem: React uses CSS Modules, which allow the scoping of CSS by automatically creating a unique class name for a component’s styles. In Angular, a component’s styles are encapsulated using custom HTML attributes so that they don’t affect the rest of the application.

Photo: © cottonbro studio / pexels.com

But why can’t we scope styles with CSS alone? Actually, we can! The new @scope CSS at-rule allows you to scope styles to specific DOM subtrees. You can even define lower bounds for the scope, creating a so-called donut scope .

I’ll explain the basics of this new CSS feature and test its capabilities with an Angular demo application.

Demo: CSS Scope vs View Encapsulation

My demo application was generated with Angular 17. It includes a header and main section with some paragraphs, links, and several recipe cards.

The app-recipe-card component (yellow background) uses the new CSS scope feature to only target the HTML elements in its own subtree. Important: At the moment of writing this article, scoped styles only work in Chrome, Edge, and Safari!

For comparison, I’ve also defined the app-recipe-card-old component (blue background), which uses Angular’s default view encapsulation. Go ahead and inspect the elements with your browser’s developer tools.

As the demo shows, CSS scope enables us to write simple selectors with low specificity and without the need of extra class names. Let’s take an in-depth look at how it all works.

The Basics of CSS Scope

The new CSS scope feature is defined in the CSS Cascading and Inheritance Level 6 module, which is still a working draft at the time of writing this post. It states:

A scope is a subtree or fragment of a document, which can be used by selectors for more targeted matching. A scope is formed by determining: The scoping root node, which acts as the upper bound of the scope, and optionally the scoping limit elements, which act as the lower bounds.

In short, you need to define the root node of the DOM subtree you want to target. Optionally, you can also list one or more inner elements that represent the lower boundary of your scope.

The @scope CSS at-rule

The app-recipe-card component in my demo includes headings, paragraphs, and an unordered list. We style them with the following CSS code:

@scope (app-recipe-card) {
    h3 {
        color: var(--highlight-color);
        font-size: 1.3rem;
    }

    p {
        margin-block: 0 1em;
    }

    ul {
        list-style: square;
        margin: 0;
        padding-inline-start: 1.25rem;
    }

    li::marker{
        color: var(--highlight-color);
    }
}

The @scope block above defines app-recipe-card as the scoping root , which determines the upper boundary of the subtree we want to target. Now all contained style rules, like h3 { … } , can only select from that limited subtree of the DOM.

Creating a Donut Scope

In some cases, only setting a scoping root won’t be enough. In Angular or React, you usually nest components within other components to create complex user interfaces. How can you make sure that the parent component’s styles don’t affect its child components?

The @scope at-rule also accepts a scoping limit which determines the lower boundary. In my demo, the recipe cards are nested within the app-recipes-list component. Here’s part of its CSS code:

@scope (app-recipes-list) to (app-recipe-card, app-recipe-card-old) {
    p {
        font-style: italic;
    }
}

This way, we only italicize the paragraphs defined by the app-recipes-list parent component. The paragraphs inside the child components app-recipe-card and app-recipe-card-old are not affected.

This type of scoping – with an upper and lower boundary – is called a donut scope . I recommend you also read the article “Limit the reach of your selectors with the CSS @scope at-rule” by Bramus Van Damme. It includes great visualizations of different scope scenarios.

The :scope selector

Another useful feature is the :scope selector. It allows you to target the scoping root element itself inside of the @scope block. Here’s an example from my demo:

@scope (app-recipe-card) {
    :scope {
        --highlight-color: rgb(194 34 2);
        display: block;
        background: lightgoldenrodyellow;
        color: black;
        padding: 1rem;
    }
}

Browser Support

What’s that? You think that CSS scope is awesome and want to use it right away in all your projects? Unfortunately, you’ll have to be patient.

At the moment, the @scope at-rule is only supported by Chrome 118+, Edge 118+, and Safari 17.4+. Firefox doesn’t support it yet, but Mozilla is actively working on the feature. Let’s hope for cross-browser support sometime in 2024!

How to use @scope in an Angular application

In Angular, a component’s styles are encapsulated by default. The framework creates custom HTML attributes like _ngcontent-pmm-6 , adds them to the generated HTML elements and modifies the component’s CSS selectors so that they are only applied to the component’s view.

If you want to use the @scope at-rule instead, you need to manually switch off view encapsulation for each component.

Switching Off View Encapsulation

To disable view encapsulation, you need to set encapsulation to ViewEncapsulation.None in the component’s decorator. Here’s an example from my demo:

@Component({
    selector: 'app-recipe-card',
    standalone: true,
    templateUrl: './recipe-card.component.html',
    styleUrl: './recipe-card.component.css',
    encapsulation: ViewEncapsulation.None,
})
export class RecipeCardComponent {
    @Input({ required: true }) recipe!: Recipe;
}

Now your CSS selectors won’t be extended with custom attributes and the component styles are applied globally. You’ll need to use the @scope at-rule instead to encapsulate the styles.

Comparing the HTML and CSS output

As we’ve seen, using CSS scope requires a little bit of effort when creating a component. Simply using Angular’s default view encapsulation instead would be more convenient.

But I would argue that the advantages of CSS scope far exceed this minor inconvenience. Let’s take a look at the HTML and CSS generated for the app-recipe-card component in my demo:

<app-recipe-card>
    <h3>Pizza Margherita</h3>
    <p>The best pizza in town!</p>
    <h4>Ingredients</h4>
    <ul>
        <li>Cutting edge CSS features!</li>
        /* More list items */
    </ul>
</app-recipe-card>

/* Generated CSS code (excerpt) */
@scope (app-recipe-card) {
    h3 {
        color: var(--highlight-color);
        font-size: 1.3rem;
    }
}

Let’s compare this to the HTML and CSS generated for the app-recipe-card-old component:

<app-recipe-card-old _nghost-ng-c2291633987>
    <h3 _ngcontent-ng-c2291633987>Pizza Margherita (Old)</h3>
    <p _ngcontent-ng-c2291633987>The (second) best pizza in town!</p>
    <h4 _ngcontent-ng-c2291633987>Ingredients</h4>
    <ul _ngcontent-ng-c2291633987>
        <li _ngcontent-ng-c2291633987>DOM cluttering view encapsulation</li>
        /* More list items */
    </ul>
</app-recipe-card-old>

/* Generated CSS code (excerpt) */
h3[_ngcontent-ng-c2291633987] {
    color: var(--highlight-color);
    font-size: 1.3rem;
}

Now imagine you need to debug your application. The recipe card isn’t rendered the way you intended. You open your browser’s developer tools and inspect the DOM and the applied styles. Which code would be easier to read and understand?

I think that the myriad of _ngcontent-ng-c2291633987 attributes would be very distracting. I think that my mind would find it easier to process the @scope (app-recipe-card) { h3 } selector than the h3[_ngcontent-ng-c2291633987] selector. 😉

Conclusion

Getting back to my initial question: Will the CSS scope feature replace Angular’s view encapsulation? Maybe. I really don’t know. Ideally, the Angular team will adapt their default view encapsulation mechanism to use the @scope at-rule.

Regardless of what the Angular team does: It’s already pretty easy to switch off view encapsulation for a component and define the styles inside a @scope block. The generated HTML and CSS code has better readability and is far easier to debug. It also contributes to a reduced bundle size of your web application.

For me, one thing is certain: As soon as CSS scope has cross-browser support, I’ll be using it in my projects. 🤩

Update on 02/24/2026

Native CSS scope has cross-browser support now. Learn more about this awesome feature in my new article “Best Practices for CSS Scope in Angular Applications”.

Support different color themes with a two-color focus indicator

Thu, 21 Mar 2024 00:00:00 GMT

Do you use the keyboard to surf the web? If so, then you’ll appreciate having a clearly visible focus indicator. This accessibility feature is especially important for people with motor impairments who rely on a keyboard, instead of a mouse, to navigate a web page.

In general, I recommend using the :focus-visible pseudo-class to define custom focus indicators. Check out my article “Provide highly visible Keyboard Focus with :focus-visible” for more information. But how do you account for different color themes and dark mode?

Photo: © cottonbro / pexels.com

The elegant solution is: Define a two-color focus indicator that has sufficient contrast against any solid background color. The W3C’s Technique C40 recommends this solution as a possible way to conform with the WCAG criteria 2.4.7: Focus Visible and 2.4.13: Focus Appearance.

Demo: Two-Color Focus Indicator

Here’s my demo of an accessible two-color focus indicator. You can toggle between light and dark mode using the checkbox labelled “Dark Mode”. Focus on the button and the link with the tab key and observe the focus indicator:

See the Pen Two-color focus indicator by Alexander Lehner (@alexlehner86) on CodePen.

How does this work?

The (not so) secret CSS ingredients

To create the two-color focus indicator, you simply combine the CSS properties outline and box-shadow to draw a light and dark line around the focused element.

:is(a[href], button):focus-visible {
    /* inner indicator */
    outline: 3px #fff solid;
    outline-offset: 0;
    /* outer indicator */
    box-shadow: 0 0 0 5px #000;
}

This way, one of the lines always provides sufficient contrast with the current background color. In my demo, I used a simple combination of pure white and black. But you can also use other colors, as the W3C technique explains:

As long as the two indicator colors have a contrast ratio of at least 9:1 with each other, at least one of the two colors is guaranteed to meet 3:1 contrast with any solid background color.

The two-color focus indicator even works in forced colors mode. If you’re not familiar with this feature, then read my article “CSS tweaks for better visibility in Forced Colors Mode”.

Enhance your Designs with Accessibility Annotations

Mon, 26 Feb 2024 00:00:00 GMT

Accessibility is a joint project. To ensure that a website is easy to use for all users, accessibility should be considered throughout the entire development process. How can designers best contribute?

As a web developer and requirements engineer, I work closely with UI/UX designers. Based on the requirements, they develop designs and prototypes for the user interface, which developers later implement. This work is often very visually dominated: Which colors are used? How do we best take the customer’s corporate identity into account?

Photo: © Amina Filkins / pexels.com

When designers tackle accessibility, they often think of the use of color and sufficient contrast ratios. But designs can do even more: accessibility annotations convey important information about the structure and semantics of the website.

There are various programs for creating prototypes. My colleagues like to work with Figma, a collaborative platform for UI/UX design.

To document accessibility considerations there, designers can define suitable elements themselves or work with ready-made libraries such as the A11y Annotation Kit. This offers a wide range of tools to mark up semantic information in the design. Let’s take a closer look at a few of them.

Mark up Headings

Sighted users usually scan a website for headings to find what they are looking for. Headings are also of central importance for blind and visually impaired users: According to the latest survey by WebAIM, 9 out of 10 screen reader users say that meaningful heading levels are very or somewhat useful for them.

Headings must be marked up semantically so that screen readers can recognize them as headings. On websites, this is done with the HTML tags h1 to h6 . Users can then use keyboard shortcuts to jump from heading to heading, for example, and thus get a quick overview.

Designers should consider as early as possible how the content of a page can be meaningfully structured with headings. In the final design, all headings and their level (1 to 6) should be annotated. Here’s an example:

Screenshot: © Alexander Lehner

Two questions will constantly accompany you: What makes a headline a headline? Which headline hierarchy makes sense? To make your life a little easier, here are a few learnings and tips:

Headings structure the content of the page: A heading introduces a new section of content and should describe it. Large font, bold print or a separate line do not automatically turn a text into a heading!
Never skip a heading level! The most important heading should be marked as h1 , followed by h2 , h3 , etc. Headings with the same or higher rank start a new section. Headings with a lower rank start new subsections.
Separate styling and semantics: The visual appearance of a heading should never determine which heading level is used! My advice: Define your own heading classes such as heading-sm , heading-md , heading-lg , etc. This allows you to style headings regardless of their position in the hierarchy.
In some cases, a visually hidden heading can also make sense in order to improve the page structure.
Be creative! A perfect heading structure is hard work. Make a draft. Get feedback from outside. Refine your designs step by step. No one is born a master 😉

Alternative Text for Images

Missing or poor alternative text is one of the most common barriers on websites. According to the WebAIM Million 2023 study, over one third of the images on popular websites have missing, questionable, or repetitive alternative text.

Design prototypes should therefore define alternative texts for image content so that visually conveyed information is also accessible for screen reader users. You should consider the following points:

Functional images: If a button or link only contains an image or icon, the alternative text must describe the purpose of the element.
Informative images: These are images that convey relevant information. Here, the design should specify a concrete alternative text or at least communicate that a meaningful alternative text must be defined.
Decorative images: If images are only intended to embellish the page, then they must be hidden from assistive technologies. The accessibility annotation can represent this with alt="" .

Screenshot: © Alexander Lehner

You can find more information and some negative examples in my article “A Picture Says More Than a 1000 Words – Unless You’re Blind!”.

Button or Link?

Links are underlined. Buttons are clickable boxes. Aren’t they? 🤔

Visually, links and buttons are often not clearly distinguishable from each other. In some designs, links look like classic buttons, and vice versa. This is usually not a problem for sighted users: they only need to understand that these elements are interactive.

However, the semantic role of the elements is particularly important for assistive technologies. Depending on whether the screen reader announces an element as a link or a button, users expect different behavior:

Links navigate to a new resource, e.g. another website or another section on the same page. You leave the current context.
Buttons, on the other hand, trigger an action in the same context, e.g. a pop-up menu or playing a video.

This means that the appearance is secondary. The function of the element is crucial. I recommend you read the article “Links vs. Buttons in Modern Web Applications”, which delves deeper into the topic.

Dear designers: Mark links and buttons according to their function. And please add a legend to your design that tells developers to use native elements for this. So a for links and button for buttons. Your users will love you for it! 🤩

Accessible Alerts made easy by the Popover API

Sat, 06 Jan 2024 00:00:00 GMT

Alerts are a common pattern on the web. They show an important message in a way that attracts the user’s attention without interrupting the current workflow. For example: “Item was added to your cart” , or “Login has failed: Check username/password” .

Creating accessible and nicely animated alerts will become a lot easier in the near future, thanks to the new Popover API and new capabilities of CSS transitions. I’ve prepared a demo that you can try out.

Photo: © Thirdman / pexels.com

If you’re not familiar with the Popover API, go read my article “Make your content pop with the Popover API and CSS Anchor Positioning” first. I won’t repeat the basics of the API and instead focus on the relevant parts of this specific use case.

Accessible Alerts Demo

Here’s my demo of accessible alerts using the Popover API. You can adapt the message as well as the duration and position of the alert. Give it a try:

The alert appears above all other elements of the page and is automatically announced by screen readers. I’ve tested this behavior with JAWS, NVDA, TalkBack and VoiceOver. The alert doesn’t interrupt the user’s current task and disappears after some time.

Implementation Details

Now let’s examine the different building blocks that I used to create the accessible, animated alerts.

Generating dynamic HTML

I’ve implemented an Angular service that dynamically generates the popover element using JavaScript methods like createElement() and appendChild() . Check out the demo code for more details. You don’t need to be familiar with the Angular framework to understand the important parts.

The following HTML code is appended to a container at the end of the body element:

<div popover="manual" role="alert" class="alert top-right">
    This is a very important message
</div>

The popover attribute turns the div element into a popover that is initially hidden by the browser. We show the popover alert by calling the element’s showPopover() method.

Setting popover=“manual” on the element defines a manual popover state. This prevents light-dismiss, meaning, interacting with other elements on the page won’t close the popover. We close the popover programmatically using the hidePopover() method.

Semantic Markup

Set role=“alert” on the popover element to define it as an alert. The document Accessible Rich Internet Applications (WAI-ARIA) 1.2 describes the alert role as follows:

A type of live region with important, and usually time-sensitive, information. […] Alerts are assertive live regions, which means they cause immediate notification for assistive technology users.

In general, we use ARIA live regions to communicate dynamic content changes. Setting role=“alert” is actually equivalent to setting aria-live=“assertive” and aria-atomic=“true” . This means, as soon as our popover alert is displayed, screen readers immediately announce the alert’s message.

Animation

Now let’s put the icing on the cake. Let’s add some animation to the popover element. There’s only one problem: Popovers are initially hidden via display: none . What a nightmare! This creates two obstacles:

An element with the display property value of none is not rendered. Therefore, it has no computed values for the different CSS properties like, e.g., opacity . If there is no computed value, you have no starting point for the transition.
The same problem exists the other way around: When the display property is set to none , it immediately takes the element out of the flow of the rendered HTML document without triggering the transition effect.

Lucky for us, the CSS Transitions Level 2 specification adds new capabilities to CSS transitions. It defines the new @starting-style rule:

The @starting-style rule is a grouping rule. The style rules inside it are used to establish styles to transition from, if the previous style change event did not establish a before-change style for the element whose styles are being computed.

This allows us to define a starting state for our transition when the display type changes from none to another type.

The second piece of the puzzle is the new transition-behavior property and its allow-discrete value:

The transition-behavior property specifies whether transitions will be started or not for discrete properties.

Discrete properties have values that can’t be interpolated. This is the case, e.g., for the display and overlay properties. To allow transitions for them, we need to set the allow-discrete value. You can also include the transition-behavior value as part of a shorthand transition declaration.

How does it all fit together? My demo includes the “top-right” position, where the alert fades in and slides in from the right. Here’s the CSS code for the transition:

.alert[popover].top-right {
    /* Final state of the exit animation */
    opacity: 0;
    transform: translateX(100%);

    transition: opacity 0.5s,
        transform 0.5s,
        overlay 0.5s allow-discrete,
        display 0.5s allow-discrete;
}

.alert[popover].top-right:popover-open {
    /* Final state of the show animation */
    opacity: 1;
    transform: translateX(0);
}

/* Needs to be after the previous [popover]:popover-open rule to take effect, as the specificity is the same */
@starting-style {
    .alert[popover].top-right:popover-open {
        opacity: 0;
        transform: translateX(100%);
    }
}

In the example above, the opacity and transform properties are transitioned for a duration of half a second. We want the browser to show the transitioned content and keep the popover in the top layer for the entire animation duration. To achieve this, we also include overlay 0.5s allow-discrete and display 0.5s allow-discrete in the transition.

Warning: These features are experimental and might change in the future!

Browser Support

The popover attribute is already supported in all major browsers. At the time of writing this article, Firefox had only enabled the feature in its experimental Nightly builds. But I expect Firefox to release the feature soon.

The new transition capabilities are only supported by Chrome and Edge at the moment. I’m hopeful that they’ll be part of Interop 2024 and reach cross-browser compatibility until the end of the year.

Useful Resources

The PDF Accessibility Checker: Strengths and Weaknesses

Wed, 06 Dec 2023 00:00:00 GMT

From invoices for online shopping to official notices: PDF documents are ubiquitous today. Numerous companies and organizations use the file format to display and exchange information. But are PDFs also accessible? The short answer: It depends!

Photo: © ANTONI SHKRABA production / pexels.com

The PDF/UA standard was published in 2012. It defines how a PDF document can meet accessibility requirements. Unfortunately, even today many documents do not comply with this standard.

To prevent this from happening to you, you should check your PDFs for accessibility. The audit is best started with the PDF Accessibility Checker, or PAC for short. This free standard tool has recently been released in version 2024: https://pac.pdf-accessibility.org/en

I have been using the tool for several years now and appreciate its strengths. However, the automated tool does not replace a manual check, for example with a screen reader and keyboard. I will therefore give you a brief overview of the strengths and weaknesses of the PDF Accessibility Checker.

The tool’s strengths

The PAC is a tool for automatically checking PDF documents for accessibility in accordance with the PDF/UA standard (DIN/ISO 14289-1). In addition, relevant points of the Web Content Accessibility Guidelines (WCAG) and additional quality features are checked.

The PAC can automatically detect the following barriers, among others:

No title is set for the PDF document.
The language of the document is not defined.
The contents of the PDF document are not tagged.
An image does not have an alternative text.

Furthermore, the tool also transparently shows which guidelines it checks and which it does not in the WCAG tab. Guidelines such as “2.1 Keyboard Accessible” and “3.2 Predictable” can only be checked manually.

The tool’s weaknesses

The PDF Accessibility Checker can check the code of a PDF document according to certain rules. However, it cannot understand and interpret the content of the document. Automated checking tools generally cannot do this.

To show the tool’s weaknesses, I conducted an experiment: How many barriers can I include in a PDF document without the PAC sounding the alarm? My test document consists of several headings, body text and an image. You can download the document and audit it yourself.

Let’s now take a closer look at the individual barriers.

No descriptive title

My test document has the title “A Fabulous Title” . PAC is satisfied with this. However, when screen reader users hear this title, they won’t be very happy about it.

The title of a website or document is the first piece of information that users come across. The title should describe the content and provide orientation for users. The relevant WCAG success criterion 2.4.2 states:

Web pages have titles that describe topic or purpose.

Therefore, during a manual check, a human must assess whether the set title of the PDF document is meaningful enough.

Incorrectly tagged headings

As PAC correctly states, the entire content of my test document is tagged. This means that for each element in the PDF, the type of content it represents is defined. This information is essential for screen reader users, among others, in order to correctly understand the content and quickly navigate through the document.

However, I have fooled PAC: All headings, such as “A fabulous heading”, are marked as body text with the <P> tag. While sighted people can visually recognize the headings as such, this information is not captured semantically. The WCAG success criterion 1.3.1 requires:

Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Automated tools such as the PAC cannot assess what should be tagged as a heading and what should not. Therefore, a person should have the PDF document read aloud by a screen reader. In addition, PAC itself also offers the useful screen reader preview function, which visualizes the tagging structure.

No meaningful sequence

Take another close look at the screenshot above. Do you notice anything? Exactly, the image is visually in a different position than in the screen reader preview.

The reading order is saved separately in a tagged PDF. This allows a logical reading order to be defined, especially for documents with complex layouts. For example, when blind users navigate through the document with a screen reader, the virtual cursor of the screen reader follows this sequence.

Therefore, WCAG success criterion 1.3.2 defines the following accessibility requirement:

When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.

During a manual check, a person with an activated screen reader should therefore navigate sequentially through the document and consider whether the sequence of content makes sense. The visual presentation serves as a guideline here. However, a different reading order may also be meaningful.

Alternative text does not describe the image

The PDF Accessibility Checker only checks images to see whether they are tagged correctly and whether an alternative text is defined. However, the WCAG success criterion 1.1.1 requires more:

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. […]

The picture in my test document shows the blue, open sea off the coast of Mallorca. The alternative text of the image, however, reads “A dust-dry desert” . An automated tool cannot recognize that this is nonsense.

Conclusion

The PDF Accessibility Checker is a great tool for auditing a PDF document for major violations. However, it does not replace manual testing. A comprehensive accessibility audit should include both automated and manual steps.

PS: Also test the corrected version of my test document with a screen reader to experience the improved user experience for yourself.

How To Meet WCAG 2.2 — Some Practical Examples

Tue, 17 Oct 2023 00:00:00 GMT

The new version 2.2 of the Web Content Accessibility Guidelines was released recently. It adds 9 new success criteria and removes the old 4.1.1 Parsing criterion.

I won’t bore you with another “WCAG 2.2 is finally here!” article. Other accessibility experts with more experience than me have already explained the changes compared to WCAG 2.1 (see the link section at the end). Instead, I’d like to focus on some of the new criteria and give you practical examples of how to meet them.

Photo: © George Milton / pexels.com

The New Criteria of WCAG 2.2

Several new criteria aim to improve the operability of websites and apps: Focus indicators should be clearly perceivable and the focused control should not be obscured by other content on the page.

Controls should be large enough so they can be easily activated without accidentally activating an adjacent target. If a site has functionality that uses a dragging movement for operation, then it must offer an alternative way for mouse and keyboard users.

Here’s a list of all new success criteria that relate to operability:

The following success criteria aim to improve accessibility for people with cognitive and learning disabilities:

Now let’s look at some practical examples for the new success criteria.

Practical Examples

Many websites include a header that sticks to the top of the page, even when the page is scrolled. If done right, this sticky header improves the usability of the website. Imagine a user reading a long article: When they arrive at the bottom of the page, they don’t have to scroll back up to access the main navigation in the header.

Unfortunately, a sticky header can hurt the experience of sighted people who can’t use a mouse. When they navigate a website using the keyboard, they always need to see what has keyboard focus. A sticky header or footer can lead to focused elements disappearing behind these elements.

Lucky for us, there’s a simple and elegant solution for this problem: The CSS property scroll-padding enables us to define offsets for the optimal viewing region of the scrollport — the region used as the target region for placing things in view of the user. All you need is one line of CSS:

html {
    scroll-padding: 4rem 0;
}

Here’s a demo of a website with a sticky header and footer. Try navigating with the tab key and pay attention to the browser keeping the focused link in view:

This way, the website conforms to 2.4.11 Focus Not Obscured (Minimum) (AA) and 2.4.12 Focus Not Obscured (Enhanced) (AAA).

Another related CSS property is scroll-margin . You can use it to, e.g., un-obscure content underneath a fixed-position banner, as the WCAG technique C43 demonstrates: “Using CSS margin and scroll-margin to un-obscure content”.

Use Case: Interactive Map with Drag to Move

An interactive map usually allows the user to drag the view of the map with the mouse or on touch. But some people cannot perform dragging movements in a precise manner. Or they use a specialized input device, such as a trackball, or head pointer, which may make dragging cumbersome and error-prone.

An accessible map should also include up/down/left/right buttons to move the view, and conform to the success criterion 2.5.7 Dragging Movements (AA). Users with motor impairments can easily tab to the controls and use them to pan the map. Check out my demo of a map with zoom and pan buttons:

Photo: © Alexander Lehner

As the screenshot above shows, the focused button is clearly highlighted with a thick outline and color change. Continue to the next section to learn more about accessible focus indicators.

Use Case: Clearly Visible Focus Indicators

Providing visible focus indicators is a basic feature of accessible websites and apps. The success criterion 2.4.7 Focus Visible (AA) states:

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

This criterion has been around for almost 15 years, ever since WCAG 2.0 was released. Unfortunately, there’s still lots of websites with no or barely visible focus indicators. One of the reasons might be that WCAG never normatively defined what “visible” meant in practice.

The new sucess criterion 2.4.13 Focus Appearance (AAA) finally defines the minimum dimensions and appearance for focus indicators. They should cover enough space and provide a contrast of at least 3:1 between an element’s focused and unfocused state.

Often, a client or designer might oppose strong focus indicators for aesthetic reasons. In this case, I recommend the use of the :focus-visible CSS pseudo-class. It lets you show focus styles only when they are needed (e.g., on keyboard navigation). Check out my demo that compares :focus to :focus-visible .

If you want to go into more details, read my post “Provide highly visible Keyboard Focus with :focus-visible”.

Useful Resources

Why I think that accessibility certifications are useful

Thu, 14 Sep 2023 00:00:00 GMT

Accessibility is becoming increasingly important. The European Accessibility Act will prescribe binding requirements for products and services from 2025. This also increases the need for experts who support companies in the accessible design of their websites and apps.

But what distinguishes an accessibility expert? How do I know that someone actually has a clue or is just throwing around buzzwords?

From my point of view, recognized certifications play an important role here. In this article I would like to discuss the advantages and disadvantages of accessibility certifications and venture a definition of what skills can be expected from professionals.

Photo: © Marcus Aurelius / pexels.com

Note: I earned the “Certified Web Accessibility Expert” certificate from UBIT Academy incite in 2019. In the beginning of 2023 I became an “IAAP Certified Professional in Accessibility Core Competencies (CPACC)” (credential at Credly).

The Essential Skills of an Accessibility Expert

Accessibility experts should have empathy for people with disabilities. They should have a sincere interest in the everyday life of these people and try to put themselves in their respective situation:

How do blind people surf the Internet with the help of a screen reader?
Under what conditions can people with motor impairments operate a website using the keyboard alone?
When is video and audio content accessible for deaf people?
etc.

An expert needs to know the different user groups and assistive technologies. These include screen magnifiers, high contrast mode, screen readers, speech input software, keyboards, and many more.

Knowledge of the relevant standards and laws is another minimum requirement. This includes both the success criteria of the Web Content Accessibility Guidelines (WCAG), the European standard EN 301 549, and relevant national laws such as the Austrian Barrierefreiheitsgesetz (BaFG).

In addition, accessibility experts should also have experience in testing for accessibility. They must be able to assess whether a website or app complies with specific criteria and point out solutions for any barriers found.

Accessibility Certifications

Various institutions offer certifications on the topic of accessibility. There are national certification bodies such as the UBIT Academy incite in Austria. They offer certification as a Certified WebAccessibility Expert .

The International Association of Accessibility Professionals (IAAP) offers several certifications, including the Certified Professional in Accessibility Core Competencies (CPACC) and the Web Accessibility Specialist (WAS) . Their aim is to support accessibility experts in building up their expertise.

What are the advantages and disadvantages of such certifications?

Advantages

Increased credibility: Certification is proof that one has certain skills and experience. This underlines the credibility of experts.
Uniform standard: In order to obtain certification, interested parties must demonstrate their knowledge of specific content in examinations or individual interviews. Reputable institutions define a publicly accessible body of knowledge for this purpose, which makes this content transparent.
Community of practice and knowledge exchange: IAAP supports the networking of accessibility experts with online forums, webinars and various events.

Disadvantages

Cost: Certification is not free. CPACC, for example, costs just under $500 (slightly less for members). Not everyone can afford it. However, compared to many other certifications in the IT field, I find the price very moderate.
Cognitive barrier: Often a certification consists of a multiple-choice test with countless questions. For example, on the CPACC, you have to answer a full 100 questions in two hours. That’s exhausting. For people with cognitive impairment, that can also be an insurmountable barrier.

Conclusion

From my point of view, accessibility certifications are a good thing. They provide uniform, transparent proof of concrete skills. They help companies to distinguish real experts from frauds.

Do all accessibility experts have to be certified? Of course not. There are other ways to prove your expertise. For example, if you have been designing accessible websites or apps for many years and can show them as references.

In any case, I am happy about my certifications. They represent key milestones in my career as an accessibility expert. And the badge I earned just looks cool! 😉

Useful Resources

Manage concurrent and interdependent requests with RxJS

Sun, 20 Aug 2023 00:00:00 GMT

Have you ever had to retrieve information from multiple data sources or different API endpoints? Did you optimize your request sequence for concurrency and interdependent data?

If you answered yes to at least one of these questions, you should read on now. I’ll show you my solution using the Angular framework and RxJS. Let your requests flow like a series of interconnected waterfalls.

Photo: © Quang Nguyen Vinh / pexels.com

Before we take an in-depth look at some code examples, here’s a brief explanation of RxJS.

What is RxJS and what are Observables?

The name RxJS is an abbreviation for Reactive Extensions Library for JavaScript . In the official RxJS Introduction it says:

RxJS is a library for composing asynchronous and event-based programs by using observable sequences.

The term “observable sequence” is key here. It represents the idea of an invokable collection of future values. The related functionality is encapsulated in the Observable class.

For example, you can create an observable that emits the value of a text input on every value change. Or, you can wrap the Promise of a fetch request in an observable that emits the response when the promise completes.

Another key concept to keep in mind is the use of a pipe . Using an observable’s pipe function, we can execute a series of actions on the observable and its datastream. If you’re new to RxJS, you should learn the basics with the official docs. I can also recommend the website Learn RxJS.

The Challenge

In a current client project, I was faced with the following challenge: The web application should enable users to make specific data sets available offline. As a first step, I turned the app into a Progressive web app and created an injectable service that handles the data storage with IndexedDB.

Then I was lost for a moment!

To be honest: I’ve never had to retrieve information from different API endpoints where the result of some initial requests would determine hundreds of follow-up requests. I had to optimize the request sequence for concurrency as well as interdependency.

After a lot of online research and some trial and error, I arrived at a satisfying solution. The following source code is an adapted version of my client project, which I’m happy to share with you.

The Solution

Do you like going to the movies? Imagine a web application that shows the movie program for different cinemas. You can see when which movie is playing, access information about the actors, watch film clips and browse through screenshots. You can also read general information about the cinemas (e.g. name, location) and their movie halls (e.g., number of seats).

Photo: © Pixabay / pexels.com

To retrieve and store all this data offline, we need to access different endpoints. Some of the requests (e.g., for each movie) depend on information retrieved in other requests (e.g., for the movie program). This means, we first need to define a logical order for our download sequence.

Step 1: The Main Download Pipe

In my project, the CinemaDownloadService class contains the entire download logic. The service can be injected by, e.g., an Angular component. It provides the public method downloadCinemaInfo that downloads all necessary information to make a cinema and its movie program available offline:

public downloadCinemaInfo(cinemaId: number): Observable<CinemaOfflineData> {
    return this.downloadDataForCinemaId(cinemaId).pipe(
        switchMap(this.downloadMovies),
        switchMap(this.downloadActorBiographies),
        switchMap(this.downloadFilmClips),
        switchMap(this.downloadScreenshots),
    );
}

The method returns an observable that emits the data collection CinemaOfflineData once all individual downloads have finished.

export interface CinemaOfflineData {
    generalInfo: CinemaGeneralInfo;
    movieHalls: MovieHall[];
    movieProgram: MovieProgram;
    movies: Movie[];
    actorBios: Actor[];
    filmClips: FilmClip[];
    screenshots: MovieScreenshot[];
}

To collect the data, the method first downloads all information that directly depends on cinemaId . We’ll take a closer look at this in a moment. Afterwards, it uses a pipe and the switchMap operator to download the remaining data.

The switchMap operator takes the value emitted by the observable to create a new observable, which replaces the old one. To put it in simpler terms: Once we’re finished with a specific download operation, we start a new one that incorporates the result of the previous operation.

Step 2: Download Basic Information

As a first step, we want to download the general information about the cinema, its movie halls and the current movie program:

private downloadDataForCinemaId(cinemaId: number): Observable<CinemaOfflineData> {
    return forkJoin([
        this._request.getCinemaGeneralInfo(cinemaId).pipe(
            retryStrategy()
        ),
        this._request.getMovieHalls(cinemaId).pipe(
            retryStrategy()
        ),
        this._request.getMovieProgram(cinemaId).pipe(
            retryStrategy()
        ),
    ]).pipe(
        map(([generalInfo, movieHalls, movieProgram]: [CinemaGeneralInfo, MovieHall[], MovieProgram]) => {
            const data: CinemaOfflineData = {
                generalInfo, movieHalls, movieProgram,
                movies: [], actorBios: [],
                filmClips: [], screenshots: [],
            };
            return data;
        })
    );
}

The individual backend requests are made through an independent RequestService , which we access through this._request . The details of the implementation are irrelevant for this post. All you need to know is: Each request method returns an observable that emits the response and then completes.

We use the forkJoin operator to wait for all requests to finish and then create the first instance of our CinemaOfflineData object. The remaining properties, like movies , are initialized as empty arrays. We’ll download the corresponding data in the next steps of our download pipe.

Step 3: Limit Concurrent Requests with `mergeMap`

After we’ve successfully downloaded the movie program, we want to retrieve all movies that are listed in the program. Depending on the size of the cinema and the covered time period, this could mean hundreds of individual requests.

The modern HTTP/2 protocol supports full request multiplexing. But depending on your backend server and the maximum requests per second, it might be a good idea to limit the number of concurrent requests.

To achieve this, we use a combination of the following RxJS functions: from , mergeMap , and reduce . Here’s the complete movies download method:

private downloadMovies = (data: CinemaOfflineData): Observable<CinemaOfflineData> => {
    const movies: Movie[] = [];
    const movieIds = this.getMovieIds(data.movieProgram);
    return from(movieIds).pipe(
        mergeMap(
            id => this._request.getMovieInfo(id).pipe(
               retryStrategy()
            ),
            MAX_CONCURRENT_BACKEND_REQUESTS
        ),
        reduce(
            (accumulator, item) => {
                accumulator.push(item);
                return accumulator;
            },
            movies
        ),
        map(movies => ({ ...data, movies }))
    );
};

I know, that’s a lot to take in. Let’s look at the implementation step by step:

We extract the unique movieIds from the movie program we’ve already downloaded. Then we use from to turn the array of movie IDs into an observable.
Next, we use mergeMap to create a request for each movie. We pass the constant MAX_CONCURRENT_BACKEND_REQUESTS as the second parameter to limit the max number of concurrent requests.
Each individual request observable applies the retryStrategy operator to repeat the request in case it should throw an error. This is my own custom operator, which uses the retry function.
The next element in our observable pipe is reduce. We use this function to accumulate the results of all backend requests into a single movies array.
Last, we integrate the movies data into a new instance of our CinemaOfflineData object, using the map operator.

Now the main download pipe can move on the the next step: Downloading the biographies for all actors. We extract the unique actorIds from the movies array and apply the same download logic as before:

private downloadActorBiographies = (data: CinemaOfflineData): Observable<CinemaOfflineData> => {
    const actorBios: Actor[] = [];
    const actorIds = this.getActorIds(data.movies);
    return from(actorIds).pipe(
        mergeMap(
            id => this._request.getActorBiography(id).pipe(
                retryStrategy()
            ),
            MAX_CONCURRENT_BACKEND_REQUESTS
        ),
        reduce(
            (accumulator, item) => {
                accumulator.push(item);
                return accumulator;
            },
            actorBios
        ),
        map(actorBios => ({ ...data, actorBios }))
    );
};

We repeat the same steps for the film clips and the screenshots.

To execute the whole download logic, you need to call the public method downloadCinemaInfo and subscribe to the observable it returns:

this._cinemaDownloadService.downloadCinemaInfo(cinemaId)
    .subscribe((cinemaData: CinemaOfflineData) => {
        /* Store data offline, e.g., with IndexedDB */
    });

That’s it! You’ve successfully created an elegant download logic that is optimized for concurrency and interdependent data.

Of course, you’ll also want to cover error handling using catchError. You might also want to visualize the download process using a Subject to communicate the current status.

Conclusion

As we’ve seen, RxJS offers a set of powerful tools like mergeMap and reduce . They help us to create efficient and robust solutions.

You can define a main download pipe that provides a quick overview of the individual steps. Then you place the specific download logic into isolated private functions. This helps to keep your code clean and maintainable.

Useful Resources

Make your content pop with the Popover API and CSS Anchor Positioning

Sun, 09 Jul 2023 00:00:00 GMT

Menus, tooltips, date pickers, or dialogs – popover content is everywhere on the web. Despite how common these components are, there are no native HTML elements for most of them (except for dialogs). And their implementation requires quite a lot of JavaScript.

All of this will change with the new Popover API combined with CSS Anchor Positioning. They provide developers with a powerful mechanism for displaying popover content on top of other page content.

Photo: © Zachary DeBottis / pexels.com

I’ve prepared two demos with examples of popover content. We’ll take an in-depth look at the technical aspects as well as the accessibility of the new features.

What can we do with it?

I love the saying: Show, don’t tell! That’s why I’ve created two demos to illustrate the capabilities of the new API.

At the moment, the examples only work in Chrome Canary, the nightly build for developers. Open the browser and access the chrome://flags page to enable the experimental web platform features.

Warning: The anchor positioning feature is still highly experimental. Therefore, the demos might break if the specification changes.

Standard tooltips created with the title attribute are pretty bland. So, I’ve tried my hand at a fancy custom tooltip. Click on the info icon button next to the heading:

See the Pen Accessible Tooltip with Popover API by Alexander Lehner (@alexlehner86) on CodePen.

I did my best to make the tooltip accessible, following the Tooltip Pattern defined in the ARIA Authoring Practices Guide. Unfortunately, the desing pattern is still work in progress and there’s no consensus yet. Also, the Popover API doesn’t account for hover and focus yet.

I also created a demo for an accessible menu. Each item in the list of checked out books contains a menu button that toggles a menu panel with a set of actions for each book:

See the Pen Accessible Menu with Popover API by Alexander Lehner (@alexlehner86) on CodePen.

My implementation follows the Menu and Menubar Pattern defined in the ARIA Authoring Practices Guide. I’ve used the appropriate ARIA roles and properties and also implemented (most of) the recommended keyboard interaction.

Now let’s examine the different building blocks that I used to create these components.

The magical `popover` attribute

This HTML attribute turns any element into popover content. The HTML specification states:

All HTML elements may have the popover content attribute set. When specified, the element won’t be rendered until it becomes shown, at which point it will be rendered on top of other page content.

This popover content is always non-modal, meaning that the rest of the page can be interacted with while the popover is open. If you need to display a modal popover (e.g., a confirmation dialog), you should use the <dialog> element.

To create a popover, you add the popover attribute to an element and also define an id . Next, you use the popovertarget attribute with the value of the popover’s id on the element that opens the popover. Here’s an example:

<button popovertarget="popover-1">
    Info
</button>
<div id="popover-1" popover>
    Hi, I'm a popover!
</div>

That’s it! You just created a popover with a few lines of HTML and zero JavaScript. Awesome!

When using the popover attribute, you’ll get all of the following for free:

Placement in the top layer: Popover content will automatically appear on the top layer, a separate layer that sits on top of all other layers displayed in a web document. No more worrying about the DOM order or z-index.
Light-dismiss: Clicking outside of the popover area will close the popover and return focus to the trigger element.
Accessible keyboard interaction: When the popover is open, you can hit the ESC key to close the popover and return focus to the trigger element.
Semantic relationship: Connecting a popover element to a toggle button will also create a semantic relationship for assistive technologies. Think aria-controls and aria-expanded per default.

More options and styling

By default, when you create a popover with a popovertarget , the trigger button will toggle it open and closed. Alternatively, you can also set an explicit value for the popovertargetaction attribute:

“hide”: The button will hide a shown popover. This can be useful if you need a close button inside of the popover.
“show”: The button will show a hidden popover.
“toggle”: The button will toggle a popover between showing and hidden. This is the default behavior.

Furthermore, the popover attribute is actually a shortcut for popover=“auto” . This standard type of popover will force close other auto popovers. It can be dismissed via light-dismiss or a close button.

With popover=“manual” you can create a manual popover. These popovers don’t close via light-dismiss and they do not force close any other popovers. They must be closed via an explicit close action. A possible use case for manual popovers are alert snackbars that should be confirmed by the user.

Popovers also include useful CSS features: The ::backdrop pseudo-element allows effects to be added to the page content behind the popover. You can use the :popover-open pseudo-class to style popover elements when they are showing.

CSS Anchor Positioning

If you’ve made it this far, you might be wondering: What about the position of the popover on the page? To position our popover content relative to other elements, we actually need another new, experimental feature: Anchor Positioning.

This feature is defined in the CSS Module CSS Anchor Positioning. Right now, the document is still a “Working Draft” , but Chrome already offers the feature behind the experimental web platform features flag. The document states:

This specification defines ‘anchor positioning’, where a positioned element can size and position itself relative to one or more “anchor elements” elsewhere on the page.

In my examples above, I’ve used anchor positioning to place the tooltip and the menu panels next to their trigger buttons. Let’s find out how to set up anchors and use them in our CSS styles.

How to define an anchor element

There are two different ways to set up anchors. You can turn an HTML element into an anchor by giving it an id , and then use the anchor attribute to tether another element to your anchor. Here’s an example in combination with a popover:

<button id="toggle-btn-1" popovertarget="popover-1" class="toggle-btn">
    Info
</button>
<div id="popover-1" popover anchor="toggle-btn-1">
    Hi, I'm a popover!
</div>

As an alternative, you can use the CSS property anchor-name to set up an anchor. It accepts a dashed-ident value like —toggle-btn . Next, you use the position-anchor property to tether another element to your anchor.

button.toggle-btn {
    anchor-name: --toggle-btn;
}
div[popover] {
    position-anchor: --toggle-btn;
}

Position content with the `anchor()` function

Alright, so far you’ve set up an HTML element as an anchor and tethered your popover to it. Now you can use the anchor() function to position the popover. The function has three arguments:

Anchor element: This value specifies how to find the anchor element. You can specify an explicit anchor name with a dashed-ident value. Or, you can omit the value to use the implicit anchor that was defined through the anchor attribute or the position-anchor CSS property.
Anchor side: This value refers to the position of the corresponding side of the target anchor element. For example: bottom or left .
Fallback (optional): A length or percentage value that serves as a fallback in case of an invalid anchor function.

Here’s an example that shows how to place a tooltip below its toggle button and center the content horizontally:

[role="tooltip"][popover] {
    position: absolute;
    position-anchor: --toggle-btn;
    top: anchor(bottom);
    left: anchor(center);
    translate: -50% 0;
}

The specification includes even more features like the anchor-scroll property and the anchor-size() function. But this blog post is already long enough, so I’ll skip them for now.

Accessibility of Popovers

How accessible are popovers? As my examples above show, you can build user-friendly, accessible components with the new Popover API. But that doesn’t happen by itself.

Define the appropriate semantic role

Using the popover attribute can definitely help your website’s accessibility. For example, with the ability to close the popover via the ESC key. Or, through the semantic relationship between the toggle button and the popover created by the popovertarget attribute.

On the other hand, the popover attribute doesn’t define any implicit role for the HTML element it is used on. This means, you’ll have to think about your specific use case and choose the correct native HTML element or assign the appropriate ARIA role (like tooltip or menu ) yourself.

How do screen reader users experience the interaction with web content built with the Popover API? Due to the limited browser support for the new feature, I only tested my demos with the following scenarios:

NVDA 2023.1, Windows 11, Google Chrome Chanary 117.0.5876.0
TalkBack, Samsung Galaxy S20, Android 13, Google Chrome Chanary 117.0.5876.0

Both demos worked great: I was able to navigate the tooltip and menus with the keyboard while NVDA announced the semantic roles and current status of the controls.

The interaction on my smartphone was also smooth: With TalkBack activated, I navigated the pages using swipe gestures while the screen reader informed me about the content, semantic roles and current status of the controls.

This makes me really optimistic about the future of the web! I plan on doing more tests with other browsers and screen readers as soon as the Popover API has better support.

Browser Support

When can we start using the Popover API and CSS Anchor Positioning in production? Unfortunately, it’s going to take some time until we have cross-browser support for them.

According to caniuse.com, the popover attribute is already supported by Chrome and Edge. The Safari 17 Technology Preview promises support for the attribute and Firefox lists it as an experimental feature (behind the flag dom.element.popover.enabled ).

Cross-browser support for CSS Anchor Positioning will take even longer. As far as I know, only Chrome has implemented the experimental feature so far. Because of the status as a “First Public Working Draft” , the current specification is subject to change in the future. We’ll just have to wait and see, I guess.

Conclusion

The new Popover API combined with CSS Anchor Positioning will make our lives as web developers easier and help to make the web more accessible by default.

Despite the still experimental status of the new APIs, you should play around with them and familiarize yourselves with the new attributes and properties. This way, when cross-browser support arrives, you’ll be ready to rumble! 😎

Useful Resources

Update on 04/05/2024

Revised code examples and explanations to account for changed CSS Anchor Positioning specification (W3C Working Draft, 26 March 2024) and the implementation in Chrome Canary.

Update on 04/18/2025

CSS Anchor Positioning is part of Interop 2025. That’s why I’m fairly certain that we’ll have cross-browser support until the end of the year.

Unleash the Power of Inline SVG Images

Thu, 22 Jun 2023 00:00:00 GMT

SVG images are an integral part of modern web design. SVG, short for Scalable Vector Graphics , are highly scalable and have a small file size. You can also customize them with CSS, as I’ll show you.

In general, you can embed an SVG image in a website using the <img> tag or the CSS property background-image . In this case, you won’t be able to make major style changes to the image. I prefer to use inline SVG images instead. They can be customized and even animated with CSS.

Photo: © Andrea Piacquadio / pexels.com

How can you embed inline SVG images? What are best practices to customize them with CSS properties and variables? Read on to find out more.

How to embed an inline SVG

SVG images can be embedded directly in the HTML document using the <svg> tag. Simply open the image file in the code editor of your choice, copy the code, and paste it into your HTML template. Here’s an example:

<svg height="48" width="48" viewBox="0 -960 960 960" xmlns="http://www.w3.org/2000/svg">
    <path d="m393-165 279-335H492l36-286-253 366h154l-36 255Zm-73 85 40-280H160l360-520h80l-40 320h240L400-80h-80Zm153-395Z"></path>
</svg>

Nowadays, websites are often built with component-based JavaScript frameworks like Angular or React. These allow you to wrap an inline SVG in its own component that you can easily reuse in different sections of your website. One example for this pattern is the Material UI icon library.

The UI library Angular Material even goes a step further: You can add SVG files as assets to your website. The application later fetches the images from the server, allowing the SVG code to be embedded in the HTML document via the <mat-icon> component.

Demo: Flexible styling of SVG Icon Buttons

I’ve created a demo with use cases for inline SVGs. You can customize the color of the icons through a color picker element:

I accomplished this by linking the SVG image’s fill to the CSS property color .

Customizing the SVG with CSS

First, you set the SVG image’s fill property to the value currentColor . This special keyword represents the value of an element’s color CSS property. This way, the SVG image’s vectors will be filled with the element’s font color. You can set the property in the SVG code:

<svg fill="currentColor" height="48" width="48" viewBox="0 -960 960 960" xmlns="http://www.w3.org/2000/svg">
    <path d="..."></path>
</svg>

Or, you can set the property in your CSS code:

.icon svg {
    fill: currentColor;
}

Now, you can control the appearance of the SVG image through the color CSS property. This makes it easier to manage color themes and different states of controls.

Imagine you have a button with an icon and text, like in my demo above: You can color all elements inside the button with a single CSS rule. You can easily style different states like :hover , :focus , or :disabled . And you can even animate the color change:

.primary-btn {
    color: #f118a6;
    transition: color 0.5s ease;
}
.primary-btn:hover, .primary-btn:focus {
    color: #920c64;
    outline: 2px solid currentColor;
}

Use CSS Variables for Multi-Colored Images

You can even use CSS variables inside SVG code. This can be useful when you’re dealing with an SVG image that uses multiple colors. In this case, you can still link the main color to the color CSS property. Then, define CSS variables for the other colors:

<svg fill="currentColor" viewBox="0 0 20 20" xmlns="http://www.w3.org/2000/svg">
    <path d="..." />
    <path d="..." />
    <path fill="var(--secondary-fill)" d="..." />
</svg>

In the example above, the first and second path elements are colored by the defined font color. The fill of the third path can be controlled through the CSS variable —secondary-fill :

.icon {
    color: darkred;
    --secondary-fill: white;
}

Check out the article “Multi-Colored SVG Symbol Icons with CSS Variables” for an in-depth look at the concept.

Make Your Images Accessible

Last, but not least: Don’t forget about accessibility! If the SVG image is purely decorative, then use aria-hidden=“true” to hide the element from assistive technologies.

If the image conveys important information, then assign role=“img” and provide alternative text through the aria-label attribute. Read “Accessible SVGs” for more information and use cases.

Use the inert attribute to prevent unintended user interaction

Thu, 04 May 2023 00:00:00 GMT

Web design is all about making efficient use of the available space. You don’t want to clutter the screen with too much content. This is the reason for common patterns like slide-in submenus, expansion panels, popups or dialogs.

Often, these elements are implemented as custom widgets with an insufficient hidden state. They use CSS code like opacity: 0 or position: absolute; left: -10000px to hide the content only visually. But users can still access the content with the keyboard or assistive technologies. What can we do about it?

Photo: © Roxanne Minnish / pexels.com

You can use the HTML attribute inert to prevent any interaction with hidden content. A kind of digital sloth, so to say. Let’s take a closer look at the attribute that is now supported by all major browsers.

How the `inert` attribute works

The inert property is a global HTML attribute that tells the browser to prevent any user interaction with a specific section of content. The HTML specification states:

The inert attribute is a boolean attribute that indicates, by its presence, that the element and all its flat tree descendants […] are to be made inert by the user agent.

This means that all user input events for the element and its descendants are ignored, including focus events and events from assistive technologies.

For example: Let’s say you place a registration form off-screen and let it slide into view when the user presses a certain button. Adding inert to the <form> element ensures that a keyboard user cannot accidentally interact with the form elements while they’re off-screen. The content will also be hidden from screen reader users.

The native <dialog> element also makes use of this. When you open a modal dialog with .showModal() , the browser will automatically render all other content inert. Find out more in my blog post “Why you should use the Native Dialog Element”.

I’ve created a demo for an animated navigation menu that uses the inert attribute for its hidden submenus. It works well for keyboard and screen reader users:

The navigation menu is structured as an unordered list inside a nav element. The HTML code for a menu option and its hidden submenu looks as follows:

<button type="button" aria-expanded="false" aria-controls="sub_menu_research">
    Research
</button>
<div id="sub_menu_research" class="subMenu" inert>
    <ul>
        <li><a href="/black-holes">Black Holes</a></li>
        <li><a href="/climate-change">Climate Change</a></li>
        <li><a href="/modern-way-of-work">Modern Way of Work</a></li>
    </ul>
</div>

In my CSS code, I reference the inert attribute to also visually hide the submenu:

.subMenu {
    overflow: hidden;
}

.subMenu[inert] > ul {
    transform: translateY(-100%);
}

When the menu option is activated, the inert attribute is removed and the submenu slides into view:

.subMenu:not([inert]) > ul {
    transform: translateY(0);
}

The creation of the slide animation is pretty easy and straightforward using the transition CSS property:

.subMenu > ul {
    transition: transform 0.4s ease-in-out;
}

You can view the complete source code here.

Wouldn’t `display: none` do the job?

Some of you might be thinking: “Why should I use the inert attribute? I can simply hide stuff with display: none, duh!” You’re right. When you apply the CSS property display: none to an element, it won’t be rendered by the browser and is hidden from assistive technologies. The downside: You won’t be able to animate the element any more.

Using the inert attribute gives you more flexibility. You can let your content fade in and out, slide into view or create any sophisticated animation you can think of. Also, you’ll want to use the attribute for content that is visible but should not be interacted with. For example, the partially visible previous and next slide in a carousel widget.

Browser Support

Firefox finally added support for inert in version 112. This means that all major browsers support the attribute now.

Yay! Let’s go and build cool stuff with it.

How the Description List Element improves Accessibility and the Developer Experience

Sun, 02 Apr 2023 00:00:00 GMT

Lists are among the basic building blocks of the web. Every web developer knows the HTML elements <ul> and <ol> for unordered and ordered lists. Yet few are familiar with their close relative <dl> , the description list.

A typical use case for the element is to implement a glossary with terms and definitions. In fact, you can do a lot more with it. I would argue that any list of key-value pairs should be marked up as a description list. It improves the developer experience by making the code more readable. And it makes your content more accessible.

Photo: © Ketut Subiyanto / pexels.com

We’ll take a look at the history of the element, see how it works and how it affects accessibility.

A Quick History of the Description List Element

The <dl> element has existed since HTML+ in the year 1993. The document defined the element as a “definition list”:

A definition list is a list of terms and corresponding definitions. Definition lists are typically formatted with the term flush-left and the definition, formatted paragraph style, indented after the term.

This narrow definition is still present in many minds today. But it no longer applies. The element’s definition was changed in HTML5, making it more versatile:

The dl element represents an association list consisting of zero or more name-value groups (a description list). […] Name-value groups may be terms and definitions, metadata topics and values, questions and answers, or any other groups of name-value data.

This means that the element can be used to markup any list of key-value pairs. For example, a list of metadata about a client: name, address, telephone number, etc.

How to use the `<dl>` element

The description list contains a list of terms and descriptions that are defined with the HTML elements <dt> (description term) and <dd> (description details). Here’s an example for a list of metadata:

<dl>
    <dt>Account Owner</dt>
    <dd>Martina Musterfrau</dd>
    <dt>Banking Institute</dt>
    <dd>Musterbank</dd>
    <dt>IBAN</dt>
    <dd>AT12 3456 7891 2345 6789</dd>
    <dt>Telephone</dt>
    <dd>+43 1234 56 78</dd>
</dl>

The semantic HTML tags convey important information to assistive technologies. Screen readers can navigate the individual list items and convey the relationship between term and description. But web developers also benefit from the semantic markup. Imagine the example above as a sequence of <div> elements:

<div class="metadata">
    <div class="term">Account Owner</div>
    <div class="description">Martina Musterfrau</div>
    <div class="term">Banking Institute</div>
    <div class="description">Musterbank</div>
    <div class="term">IBAN</div>
    <div class="description">AT12 3456 7891 2345 6789</div>
    <div class="term">Telephone</div>
    <div class="description">+43 1234 56 78</div>
</div>

I hope you agree with me that the semantic HTML is easier to understand and work with. You can also leverage the semantic tag names for expressive and easy to understand CSS selectors. Check out my article “3 Ways how Web Developers also benefit from Accessibility”.

Styling the Description List

The standard styling of description lists is rather bland. But don’t worry! You can freely customize the element with CSS. The HTML specification allows wrapping each key-value pair in a <div> element.

<dl>
    <div>
        <dt>Account Owner</dt>
        <dd>Martina Musterfrau</dd>
    </div>
    <div>
        <dt>Banking Institute</dt>
        <dd>Musterbank</dd>
    </div>
    <div>
        <dt>IBAN</dt>
        <dd>AT12 3456 7891 2345 6789</dd>
    </div>
</dl>

This content structure enables us to create a responsive, horizontal layout using CSS flexbox:

dl {
    display: flex;
    flex-wrap: wrap;
    gap: 1rem;
}

dl > div {
    flex-grow: 1;
}

dt {
    color: #6e2755;
    font-size: 0.9rem;
    font-weight: bold;
}

dd {
    font-size: 1rem;
    margin-inline-start: 0;
}

Here’s the end result:

See the Pen Flexbox styled Description List by Alexander Lehner (@alexlehner86) on CodePen.

The description list element makes your content more accessible, especially for screen reader users. There are minor differences between browsers and screen readers, but overall the support is generally good. Adrian Roselli has done extensive screen reader testing for his article “Updated Brief Note on Description List Support”. Go check it out!

I’d like to add one important aspect to his analysis: Screen readers are software applications. And software can have bugs or miss an important feature (like the correct handling of the <dl> element). But this should not stop us from using this feature. Especially if we can expect the screen reader vendor to fix their mistakes in the near future.

Update on 04/18/2025

Added link to the updated blog article by Adrian Roselli.

Checklist for Accessible UI Component Libraries

Wed, 22 Mar 2023 00:00:00 GMT

Accessibility is a choice. Designers can use color combinations with sufficient contrast, or pick colors for purely aesthetic reasons. Web developers can implement a button with the native button tag, or they use the generic div tag instead.

In an ideal development process, accessibility is considered right from the start. The requirements clearly state the needs of people with disabilities. Designers create mockups and prototypes which meet these requirements. Developers implement the features with semantic markup. Testers verify that the web content meets the accessibility requirements.

In reality, accessibility is often treated as an afterthought. This can be especially problematic when it comes to UI component libraries. I will talk about why it’s important to check the accessibility of the library before you write your first line of code. And what you should keep in mind when working with UI components.

Photo: © Alena Darmel / pexels.com

The Advantages of UI Component Libraries

HTML elements are the basic building blocks of any website. But they don’t cover all types of content and possible use cases. Complex UI patterns like accordions, carousels, or tabs require custom implementations anyway.

To speed up development and ensure a consistent look and feel, a modern web application usually makes use of a UI component library. They’re a collection of design elements that are ready to use in your application. Usually, you can apply a color theme and customize the functionality of the components.

Hundreds of different component libraries are available for major web frameworks like Angular, React, or Vue.js. For example, if you like the Material design system, you can use Angular Material, Material UI, or Material Components Vue.

Checking the Library’s Accessibility

Here’s a checklist for picking an accessible UI component library:

Is accessibility mentioned on the library’s website or documentation? For example, the Angular Material homepage states that they offer: “Internationalized and accessible components for everyone.”
Does the documentation explain if and how the components are made accessible? The Angular Material documentation has dedicated accessibility sections for every component.
The documentation usually includes demo pages and examples for the different components. Inspect their markup and accessibility properties using your browser’s dev tools. Test with assistive technologies like your keyboard and different desktop and mobile screen readers.

No Guarantee of Complete Accessibility

Picking an accessible UI component library is an important first step towards making you web application accessible. But it doesn’t guarantee it. Every time you use a component on a page, you should answer the following questions:

Where and how is the component included? Think about the context and order of content.
Is the type of use consistent with the actual purpose of the component? Or are you only trying to achieve a specific visual appearance?

The visual presentation of content should not determine which component you use. It’s easy to apply a specific design with CSS. But it’s nearly impossible or at least very tedious to override a component’s semantic markup and implemented keyboard interaction.

To give you an example: Angular Material’s <mat-chip-listbox> component provides a multi-select listbox, following the listbox pattern. The semantic markup communicates to assistive technologies that the element offers several options of which one or more can be selected. The whole listbox receives keyboard focus via the TAB key. The arrow keys move focus to the next or previous option.

Now imagine your client saying: “I love the design of the chips component. I want this list of links styled in the same way!” Do you think you should really use the component for this use case?

It’s our responsibility as web developers to pick the right component for the job. And to resist the seemingly easy path that would lead to disaster! 😉

Responsive Component Design with CSS Container Queries

Fri, 17 Feb 2023 00:00:00 GMT

Everything is in flux. Modern web design has to account for a seemingly endless array of different screen sizes. With @media queries, you can style elements based on features of the browser viewport, e.g, the screen’s width.

But what if you want to create reusable components that are responsive to the container they’re placed in? For example, a news card that can span the whole width of the website or fit into a narrow column on the side. We can do that now!

With CSS Container Queries we can design responsive, reusable components that adapt to the available space. With the recent release of Firefox 110, the feature is now supported by all major browsers. This is a total game changer! Let’s see how it works.

Photo: © Pixabay / pexels.com

Query the Size of Containers

Container queries allow us to apply styles to elements based on the size of their container rather than the viewport. The feature is defined in the CSS Module CSS Containment Module Level 3. The document states:

While media queries provide a method to query aspects of the user agent or device environment that a document is being displayed in (such as viewport dimensions or user preferences), container queries allow testing aspects of elements within the document (such as box dimensions or computed styles).

We can query different size container features like width , height or inline-size . The specification also includes container style queries, but those aren’t supported by browsers yet.

To style a component based on its parent size, we need to set containment on the parent element with the container-type CSS property. It’s recommended to also name the container using container-name . Here’s an example:

.news-card {
    container-type: inline-size;
    container-name: news-card;
}

You can also set the type and name simultaneously with the container shorthand property:

.news-card {
    container: news-card / inline-size;
}

Now we can query the container with the @container CSS at-rule and apply some conditional styling. For example, if the container’s width is below a certain threshold:

@container news-card (max-width: 25rem) {
    .card-image {
        flex-basis: 100%;
    }
}

Demo: Responsive News Card

I’ve created a simple demo on CodePen that shows a news card component. If enough space is available, the card lays out its content horizontally. If the container’s width falls below a certain threshold, the text is moved below the image.

See the Pen CSS Container Queries Demo by Alexander Lehner (@alexlehner86) on CodePen.

Conclusion

I’m super excited about CSS container queries! Yet, I’ve barely scratched the surface of all the possible use cases. My goal is to use the feature in more and more projects and contiuously improve my understanding of it.

In my opinion, one thing is certain: Container queries will change the way we write CSS for good. What ideas and use cases have you already implemented with the feature?

Design Perfectly Aligned Layouts with CSS Subgrid

Sun, 29 Jan 2023 00:00:00 GMT

CSS Grid Layout is a two-dimensional grid-based layout system for websites. It makes it easy to arrange content in rows and columns and create responsive layouts.

If you’re familiar with grid layouts, you’ve probably encountered the following issue: A grid container can be placed inside another grid to create a nested grid layout. Unfortunately, the content of the child grid doesn’t automatically align with the parent grid. But don’t worry! We can solve this issue with the subgrid feature!

Photo: © RODNAE Productions / pexels.com

The subgrid feature makes grid layout even more powerful and enables us to create perfectly aligned layouts. I’ve prepared a demo of a typical use case. Let’s see how it all works.

The Basics of Grid Layout

The grid layout system is defined in the CSS Grid Layout Module specification:

A two-dimensional grid-based layout system, optimized for user interface design. In the grid layout model, the children of a grid container can be positioned into arbitrary slots in a predefined flexible or fixed-size layout grid.

You can turn an HTML element into a grid container with the CSS property display: grid . Next, you can define the rows and columns with the properties grid-template-rows and grid-template-columns .

There are many ways to define a grid and populate it with content. Listing all possible settings and scenarios would go beyond the scope of this article. If you want to learn more, I can recommend the tutorials “A Complete Guide to CSS Grid” and “Learn CSS Grid”.

What is Subgrid and What’s it Good for?

The subgrid feature was added in CSS Grid Layout Module Level 2. The specification states:

A nested grid can defer the definition of its rows and/or columns to its parent grid container, making it a subgrid. In this case, the grid items of the subgrid participate in sizing the parent grid, allowing the contents of both grids to align.

To define a subgrid, you simply set the value subgrid for the property grid-template-rows or grid-template-columns . That’s it! The nested grid will now use the columns and/or rows defined by the parent grid and align its content accordingly.

Demo: Punk API Beer List

I’ve created a React demo that displays a list of beers in a grid with three equally sized columns. Each grid cell contains information about a specific beer. Check out the live version here (best viewed on a desktop screen).

The Parent Grid Container

The demo uses an unordered list as the parent grid container. Here’s the JSX code:

<ul className={styles.beerGrid}>
    {items.map(item => (
        <li key={item.id}>
            <BeerItemDetails item={item} />
        </li>
    ))}
</ul>

In my CSS code, I use the repeat and minmax functions to create a grid with three columns and a variable number of rows. Each column is equally sized with a minimum width of 15rem .

ul.beerGrid {
    display: grid;
    gap: 2.5rem;
    grid-template-columns: repeat(3, minmax(15rem, 1fr));
    grid-template-rows: auto;
    list-style: none;
}

Turning the Beer Content Cards into Subgrids

Each list item is rendered using the BeerItemDetails React component. This component consists of a header section (hgroup element) and a details section (div element):

<hgroup className={styles.heading}>
    <h2>{item.name}</h2>
    <p>{item.tagline}</p>
</hgroup>
<div className={styles.flexRow}>
    <!-- details -->
</div>

In my CSS code, I define the list items as grid containers with two rows (grid-row: span 2 ). The grid-template-rows: subgrid declaration tells the browser to align the header and details section of each beer card that is placed on the same row.

ul.beerGrid li {
    display: grid;
    grid-template-rows: subgrid;
    grid-row: span 2;
    gap: 0;
}

Easier Development with CSS Grid Inspector

I made heavy use of the CSS Grid Inspector that is part of Firefox DevTools. This awesome tool highlights your grid’s rows and columns and makes it easier to understand how the parent grid and its subgrids fit together.

The Chrome DevTools offer a similar tool. But as a passionate Firefox user, I just had to mention the Firefox tool first. 😉

Browser Support and Progressive Enhancement

At the time of publication of this post, only Safari and Firefox support the subgrid feature. But don’t worry! You don’t have to wait for Chrome and Edge to catch up.

Apply the principle of progressive enhancement to provide a basic layout and also take advantage of the subgrid feature in supporting browsers. To achieve this, we use @supports to check browser support before we set the subgrid value:

@supports (grid-template-rows: subgrid) {
    ul.beerGrid li {
        display: grid;
        grid-template-rows: subgrid;
    }
}

Useful Resources

Create an Accessible News Carousel as an Angular Standalone Component

Sun, 15 Jan 2023 00:00:00 GMT

I love carousels! The colorful theme park rides with animals and chariots are often beautifully crafted. Kids can spend hours on them, going round and round. Pure joy!

Can I say the same about carousel UI components? Not so much. I actually dislike most forms of web carousels, especially when they change slides by themselves. Also, most of them are inaccessible nightmares. So, I said to myself: Let’s do better!

Photo: © Alexander Nadrilyanski / pexels.com

I’ve created a news carousel as an Angular standalone component. It’s accessible, responsive and has smooth animations. Let’s take a look at how it’s built and how it works.

Demo: Accessible News Carousel

My demo application displays a list of news items, each with a heading, text snippet and a background image. Users can move from slide to slide using swipe gestures or the navigation buttons.

Design and Accessibility Requirements

There is no native HTML element for web carousels. That’s why there are so many different custom implementations. At least, the W3C has defined basic requirements in their “ARIA Authoring Practices Guide”. Their definition of the carousel pattern states:

A carousel presents a set of items, referred to as slides, by sequentially displaying a subset of one or more slides. Typically, one slide is displayed at a time, and users can activate a next or previous slide control that hides the current slide and “rotates” the next or previous slide into view.

This abstract definition applies to basic image rotators as well as slide shows with complex content. In general, carousels should fulfill the following requirements:

It should convey its structure to assistive technologies.
It should indicate the currently active slide, both visually and to assistive technologies.
Users should not be forced to use swipe gestures to operate the carousel. It should offer simple controls that the user can click on or operate with the keyboard.
Dynamic content changes of the carousel (e.g. moving to the next slide) should be communicated to screen reader users via status messages.
If the carousel can automatically rotate, it also has a button for stopping and restarting rotation.

I hate moving content that starts automatically. That’s why my news carousel doesn’t rotate on its own and, therefore, has no pause button.

Content Structure and Semantic Markup

The Carousel Container

The ARIA specification doesn’t include a carousel role. Therefore, you need to set the generic role=“region” and provide a custom description with aria-roledescription=“carousel” . An accessible label is provided by the aria-label attribute.

In my NewsCarouselComponent , I use the HostBinding decorator to apply these properties to the carousel component’s container:

/**
* The aria label for the carousel container.
* It should convey to screenreader users what the carousel is about.
*/
@HostBinding('attr.aria-label') @Input() public carouselLabel!: string;
@HostBinding('attr.role') role = 'region';
@HostBinding('attr.aria-roledescription') get carouselDescription() { return this.config.carouselDescription; }

The carousel includes two icon buttons to navigate to the previous or next slide. Accessible labels are provided by the aria-label attribute set on the button tags.

The Slide Container

Each slide container has role=“group” and the property aria-roledescription set to “slide”. The slide container’s aria-label attribute conveys the slide’s number and the total set size (e.g., “2 of 5”).

<div
    *ngFor="let item of newsItems; let i = index"
    class="news-item"
    role="group"
    [attr.aria-roledescription]="config.slideDescription"
    [attr.aria-label]="(i + 1) + ' ' + config.slideLabel + ' ' + newsItems.length"
>
    <!-- slide content -->
</div>

The disadvantage of custom role descriptions is that they’re not automatically translated by screen readers. If you’re building a multi-lingual website, you’ll need to keep that in mind. My NewsCarouselComponent has a config input property with default values in English that can be overriden.

@Input() public config: NewsCarouselConfig = {
    carouselDescription: 'carousel',
    slideDescription: 'slide',
    slideLabel: 'of',
    nextButtonLabel: 'Next slide',
    previousButtonLabel: 'Previous slide',
}

Avoid List Markup

A common mistake is to use list markup for the slides. Screen readers announce the number of items in a list, but ignore list items that are hidden. In my component, only the visible slide is also presented to assistive technologies. The other slides are visually and programmatically hidden using the CSS property visibility: hidden .

If I’d implement all slides as <li> elements inside an unordered list (<ul> ), then the screen reader would announce the presence of a list with only one item. This would not match the true number of slides and be confusing for the user.

ARIA Live Region

The carousel should communicate dynamic content changes to screen reader users via status messages. At first, I tried to turn the container element for all slides into an ARIA live region. The results were not satisfying. Due to the implementation of the slide transition using the visibility CSS property, the screen reader would announce the new slide several times or announce the wrong slide.

I tried different approaches using properties like aria-busy and aria-relevant . They only ever worked for some browser and screen reader combinations. So, in the end I chose the simple approach of putting a visually hidden ARIA live region at the end of the carousel container. It’s a bit redundant, but it works!

<div
    class="active-slide-live-region"
    aria-live="polite"
>
    {{config.slideDescription + ' ' + (activeSlideIndex + 1) + ' ' + config.slideLabel + ' ' + newsItems.length + ':'}}
    {{newsItems[activeSlideIndex].heading}}
</div>

Keyboard Operability and Swipe Gestures

I love swiping! When I come across a carousel on a website, I instinctively try to swipe its content. Swiping itself is not evil. But a web carousel that is only operable through swipe gestures is!

Swipe gestures are inaccessible to many people with motor disabilities. They prefer single-pointer alternatives like a clickable button. Also, keyboard users require controls they can tab to and activate with the space or enter key.

This is why I try to make everyone happy! My Angular component implements swipe gestures using the Hammer.js library and also includes buttons to navigate to the previous or next slide.

<div class="news-carousel-controls">
    <button
        type="button"
        [attr.aria-label]="config.previousButtonLabel"
        (click)="this.showPreviousSlide()"
    >
        <!-- arrow icon -->
    </button>
    <button
        type="button"
        [attr.aria-label]="config.nextButtonLabel"
        (click)="this.showNextSlide()"
    >
        <!-- arrow icon -->
    </button>
</div>

Slide Transitions with CSS Animations

I wanted to create beautiful transitions between slides with smooth slide in and out animations. Angular provides its own animations module. But I wanted to find a solution that would reduce the build size and be efficient at the same time. Which is why I decided to use CSS animations.

Creating animations with CSS is super simple and elegant. First, you define keyframes for your named animations. Each keyframe describes how the animated element should render at a given time during the animation sequence.

// Keyframes for slide animation from left to right
@keyframes slide-in-from-left {
    0% {
        transform: translateX(-100%);
    }
    100% {
        transform: translateX(0%);
    }
}

@keyframes slide-out-to-right {
    0% {
        transform: translateX(0%);
        visibility: visible;
    }
    100% {
        transform: translateX(100%);
        visibility: hidden;
    }
}

Then, you apply these animations to specific slides using the animation CSS property. This shorthand allows you to define a wide range of animation related properties (e.g., name, duration, direction) in a single CSS rule.

app-news-carousel .news-carousel-items.animate-from-left .news-item {
    &.active {
        animation: slide-in-from-left 0.5s forwards;
    }

    &.moved-out {
        animation: slide-out-to-right 0.5s forwards;
        border-left: 0.125rem solid white;
    }
}

In the example above, two HTML elements are animated: The element with the class active slides in from the left while the other element with the class moved-out slides out to the right.

Responsive Design and Custom Styling

Flexible Layout with `max-width` and Container Queries

An application that uses the carousel component can set the CSS variable —news-carousel-max-width to define a basic width for the carousel container. If no variable is set, then the fallback value of the var() function is used.

app-news-carousel {
    height: var(--news-carousel-height, 25rem);
    width: var(--news-carousel-max-width, 50rem);
    max-width: 100%;
}

By setting max-width: 100% we ensure that the containers width is limited by the space available to its parent element. This way, the carousel never uses up more space than the viewport width of the device.

Furthermore, I use CSS Container Queries to adapt the carousel’s styling if the container’s width is below a certain threshold. This new, powerful feature will soon be supported by all major browsers. I’ll take a closer look at it in a separate blog post.

@container news-carousel (max-width: 28rem) {
    app-news-carousel .news-item .slide-text {
        bottom: 0.5rem;
        border-radius: 0.5rem;
        width: calc(100% - 1rem);

        p {
            display: none;
        }
    }
}

Custom Styling with CSS Variables

CSS variables are great for component libraries. You can define a default styling and allow the user to override specific styles by defining the responding variable. An application using my NewsCarouselComponent can customize the following style properties via CSS variables:

—news-carousel-height : Set the height of the carousel.
—news-carousel-max-width : Set the max width of the carousel. The carousel’s actual width is responsive to its container.
—news-carousel-button-background : The background (color) of the previous and next buttons.
—news-carousel-button-color : The color of the arrow icon in the previous and next buttons.
—carousel-text-background : The background (color) of the slides’ text container.
—carousel-text-color : The text color of the slides’ text container.
—news-carousel-slide-focus-color : The color of the slides’ focus indicator.

What Else to Say

I want to make one thing clear: My carousel component is only one of several ways to implement an accessible, responsive carousel. Yes, I’m pretty confident that my implementation is awesome. But of course, there’s other valid approaches as well.

Web standards, browsers and assistive technologies are always evolving and changing. So, in a few years, or maybe even in a few months, there might be a better solution. I can’t wait to see it! 😊

Useful Resources

Looking Back at 2022 — My First Year of Blogging

Thu, 29 Dec 2022 00:00:00 GMT

One year ago, I took the course “Full Stack for Front-End Engineers” at Frontend Masters. I set up my own web server, bought a domain and started a web development blog using the Gatsby framework. 12 months and 18 blog posts later, I would like to reflect on the past year and set some goals for 2023.

Photo: © cottonbro studio / pexels.com

In general, I truly enjoy writing articles on a regular basis. I actually moved to Vienna in 2006 to study journalism. I’ve also worked for some media organizations. But it wasn’t the right fit and I returned to coding. So, it really feels good to kind of combine my two passions.

What I’ve Learned this Year

First of all, how to set up my own web server, manage a domain, create an SSL certificate, and so on. It felt good to leave my comfort zone and try something new!
How to automate my build and deploy workflow with GitHub Actions.
That I love to experiment with new features like the native <dialog> HTML element or the :focus-visible CSS pseudo-class. It’s a great challenge to explain the concept and functionality in a succinct way and provide useful demo code.
I became familiar with RSS and learned how to provide my own RSS feed. You can subscribe here.

My Favorite Blog Posts

It’s hard to pick my favorites among the 18 blog posts I’ve written this year. Therefore, I simply picked three posts about topics that I deem especially relevant and exciting:

“Common ARIA mistakes and how to avoid them”: It’s great that more and more companies realize the importance of accessibility. Unfortunately, a lot of them go overboard with ARIA, sometimes making their website even less accessible. I hope my blog post helps developers to better understand ARIA and avoid bad practices.
“Using CSS Cascade Layers in Angular”: 2022 was a pretty great year for CSS. Among the exciting new features adopted by modern browsers were CSS cascade layers. They’re a powerful tool to structure your styles and avoid pesky conflicts due to specificity or order of appearance.
“Lights Off! Experience how Blind Users navigate the Web”: A few weeks ago, I gave a workshop on accessibility for a new client. Using my demo page, I turned everything black and used a screen reader to navigate the website. The participants were truly amazed. One of them said: “I didn’t know that blind people can even use the internet!” This taught me once more: People need to experience the effects of disabilities to truly appreciate accessibility.

Goals and Expectations for 2023

As a web developer, I’m pretty excited for the new year. There’s a lot of new features on the horizon that should make our lives easier. As a human being, I just hope for the terrible war in Ukraine to end. And for humanity to tackle climate change head-on!

Anyway, here’s a list of goals for 2023 as well as topics I’d like to write about in the coming year:

I want to turn my social media interactions into Webmentions and display them on my blog.
Flexbox or Grid? I want to deepen my knowledge about CSS layouts and experiment with new features like CSS Subgrid.
I’d like to improve my skills as a Requirements Engineer and Software Architect and write about what I’ve learned.
Attending more developer conferences and maybe giving a talk some day. Hosting local events could be awesome too.
Last but not least: Continue writing about accessibility.

A Conversation with ChatGPT about Web Accessibility and Widespread Myths

Sat, 10 Dec 2022 00:00:00 GMT

Artificial intelligence is gaining momentum. Be it self-driving cars, image generation, or chatbots – AI is more and more a part of our everyday life. The conversational agent ChatGPT shows just how advanced and human-like AI can be.

A lot of people have already shared their conversations with the AI. It impresses with thoughtful and well composed answers. But how would the chatbot react to rather pointed questions and biased opinions? To answer this question, I just had a casual conversation with ChatGPT about some widespread accessibility myths.

I split the conversation into several sections, starting with common questions, followed by four widespread myths about accessibility. At the end of the article, I’ll share my thoughts about ChatGPT with you.

My conversation with ChatGPT

Me: Hi ChatGPT! Everyone’s talking about web accessibility. Can you explain the concept in simple terms?

ChatGPT: Sure! Web accessibility refers to the practice of making websites and web applications usable by people with disabilities. This includes people with visual, auditory, motor, and cognitive impairments, among others. The goal of web accessibility is to allow all users to access and use the content and features on a website, regardless of any disabilities they may have. This can be achieved by following a set of web accessibility guidelines and standards, such as the Web Content Accessibility Guidelines (WCAG) developed by the World Wide Web Consortium (W3C). These guidelines provide a set of specific criteria that websites and web applications should meet in order to be considered accessible. By following these guidelines, website developers and designers can ensure that their sites are usable by a wide range of users.

Me: I’m afraid that it will make web development more expensive and overly complicated. What is your opinion?

ChatGPT: Incorporating web accessibility into the design and development of a website or web application does not have to be expensive or overly complicated. In fact, following web accessibility guidelines can often improve the overall user experience for all users, not just those with disabilities. For example, using clear and descriptive headings and labels on forms can make it easier for everyone to navigate and use the site, not just people with visual impairments. Additionally, using proper formatting and structure can make it easier for screen-reading software to interpret and read the content of a page, benefiting users who are blind or have low vision.

Myth #1: Accessibility benefits only a small group of people

Me: Ok, sound’s great. What are the major benefits of an accessible website design?

ChatGPT: There are several benefits to having an accessible website design. For users with disabilities, the most obvious benefit is the ability to access and use the content and features of the site. This can improve their overall experience of using the internet and allow them to participate in online activities that they may have previously been unable to do.

In addition to benefiting users with disabilities, accessible website design can also provide benefits for businesses and organizations. For example, an accessible website can improve the search engine optimization (SEO) of the site, making it more visible to search engines and potentially increasing traffic to the site. An accessible website can also increase the potential audience for the site, since it can be used by a wider range of users. This can be especially beneficial for businesses and organizations that serve a diverse population or that are required by law to provide accessible services.

Finally, incorporating web accessibility into the design of a website can also improve the overall user experience for all users, regardless of any disabilities they may have. This can lead to increased customer satisfaction and loyalty, as well as potential cost savings by reducing the need for customer support.

Me: I’m not sure. Doesn’t accessibility only benefit a small group of people?

ChatGPT: While it is true that web accessibility primarily benefits users with disabilities, the potential audience for accessible websites is actually quite large. According to the World Health Organization, about 15% of the global population lives with some form of disability. This means that, in terms of sheer numbers, the potential audience for accessible websites is significant. Additionally, web accessibility can benefit a wide range of users with different types of disabilities, including visual, auditory, motor, and cognitive impairments, as well as users who may not have a permanent disability but who may have temporary impairments (such as a broken arm) or situational limitations (such as using a website on a mobile device while on the go). Overall, the potential audience for accessible websites is much larger than many people realize.

Me: You said that the potential audience for accessible websites was significant. But do people with disabilities really use the internet that much?

ChatGPT: Yes, people with disabilities use the internet at similar rates to those without disabilities. A study by the Pew Research Center found that, in the United States, about 88% of adults with disabilities use the internet, compared to 91% of adults without disabilities. This indicates that people with disabilities are just as likely to use the internet as those without disabilities, and highlights the importance of ensuring that websites are accessible to all users.

Additionally, the use of the internet by people with disabilities is likely to increase in the coming years, as advances in assistive technologies and the proliferation of mobile devices make it easier for people with disabilities to access the internet. This means that the potential audience for accessible websites will continue to grow, making web accessibility an increasingly important consideration for businesses and organizations.

Myth #2: Accessibility is easy and should be the last step

Me: Alright, let’s say I intend to create accessible websites. How hard can it be? I think accessibility can wait until the end of the development process after all of the other work is done.

ChatGPT: While it is certainly possible to make a website accessible after it has been developed, it is generally much easier and more effective to incorporate web accessibility into the design and development process from the beginning. This is because accessibility is not just a matter of adding a few accessibility features at the end of the development process, but rather it involves considering accessibility at every stage of the design and development process.

For example, when designing the layout and content of a website, it is important to consider how the site will be used by people with disabilities and to ensure that the design is usable by a wide range of users. This may involve using clear and descriptive headings and labels, providing alternative text for images, and using proper formatting and structure to make the content easily readable by screen-reading software.

During the development process, it is also important to test the website to ensure that it meets web accessibility standards and guidelines. This can be done using a combination of automated testing tools and manual testing by individuals with disabilities or other specialized expertise. By incorporating accessibility into the design and development process from the beginning, it is much more likely that the final website will be accessible to all users.

Overall, while it is possible to make a website accessible after it has been developed, it is much easier and more effective to consider web accessibility from the beginning. This can help to ensure that the website is usable by a wide range of users and meets the relevant accessibility standards and guidelines.

Me: But accessibility is so restrictive. Wouldn’t this hamper the creativity of web designers and developers?

ChatGPT: Web accessibility does not have to restrict the creativity of web designers and developers. In fact, incorporating accessibility into the design and development process can often lead to more creative and effective solutions. This is because accessibility is not just about adding a few accessibility features to a website, but rather it involves considering the needs of all users, including those with disabilities, and finding ways to make the website usable and enjoyable for everyone.

For example, when designing the layout and content of a website, web designers and developers can consider how the site will be used by people with disabilities and look for creative ways to make the site accessible and usable. This may involve using innovative design techniques, such as responsive design, to make the site accessible on a wide range of devices, or incorporating multimedia elements, such as videos or audio recordings, to make the content more accessible to users with visual or auditory impairments.

Additionally, by incorporating accessibility into the design and development process, web designers and developers can often improve the overall user experience of the site for all users. This can lead to more creative and effective solutions that are not only accessible, but also engaging and enjoyable for all users.

Overall, web accessibility does not have to restrict the creativity of web designers and developers. In fact, by considering the needs of all users and incorporating accessibility into the design and development process, web designers and developers can create websites that are not only accessible, but also innovative and effective.

Myth #3: Accessibility is too hard and expensive

Me: Still, there are so many different disabilities and assistive technologies to consider. Training employees and integrating accessibility into the whole development process is just too expensive. What do you think?

ChatGPT: While it is true that training employees and incorporating accessibility into the design and development process can require some initial investment, the long-term benefits of web accessibility can outweigh the costs. For businesses and organizations, having an accessible website can increase the potential audience for the site, improve the search engine optimization (SEO) of the site, and lead to increased customer satisfaction and loyalty. This can result in significant financial benefits, such as increased sales or donations, and can help to offset the initial costs of implementing web accessibility.

Additionally, there are many resources available to help businesses and organizations implement web accessibility, including training materials, guidelines and standards, and automated testing tools. These resources can help to make the process of implementing web accessibility more efficient and cost-effective.

Overall, while implementing web accessibility can require some initial investment, the long-term benefits of an accessible website can outweigh the costs. By considering the needs of all users and incorporating accessibility into the design and development process, businesses and organizations can create websites that are usable by a wide range of users and that can provide significant financial benefits.

Me: Wouldn’t it be much cheaper to simply use an accessibility overlay?

ChatGPT: An accessibility overlay is a tool that can be added to an existing website to make it more accessible to users with disabilities. While an accessibility overlay can provide some benefits, it is generally not as effective or efficient as incorporating accessibility into the design and development process from the beginning.

One major disadvantage of using an accessibility overlay is that it only addresses the accessibility of the user interface (UI) of the website, not the underlying content or structure. This means that, while the UI may be more accessible with an overlay, the content of the site may still be difficult or impossible for users with disabilities to access. For example, an accessibility overlay may add alternative text to images, but if the images are not properly labeled or organized in the first place, they may still be difficult for users with visual impairments to understand.

Additionally, using an accessibility overlay can be less efficient and more expensive than incorporating accessibility into the design and development process. This is because an accessibility overlay must be added to the site after it has been developed, which can require additional time and resources. In contrast, incorporating accessibility into the design and development process from the beginning can be more efficient and cost-effective, since it involves considering accessibility at every stage of the process.

Overall, while an accessibility overlay can provide some benefits, it is generally not as effective or efficient as incorporating accessibility into the design and development process from the beginning. By considering the needs of all users and incorporating accessibility into the design and development process, businesses and organizations can create websites that are truly accessible to all users.

Myth #4: Accessible websites are ugly

Me: Maybe you’re right and we should design for accessibility from the start. It’s just so hard to create accessible websites that look good. Most accessible websites are ugly and have poor visual design.

ChatGPT: While it is true that some accessible websites may not have the same visual appeal as other websites, this does not have to be the case. Accessibility and visual design are not mutually exclusive, and it is possible to create websites that are both accessible and aesthetically pleasing.

One way to achieve this is by following web accessibility guidelines and standards, such as the Web Content Accessibility Guidelines (WCAG) developed by the World Wide Web Consortium (W3C). These guidelines provide specific criteria that websites should meet in order to be considered accessible, while also allowing for flexibility in the design and layout of the site. This means that web designers and developers can use their creativity and expertise to create visually appealing websites that are also accessible to users with disabilities.

Additionally, by considering the needs of all users, including those with disabilities, web designers and developers can create websites that are not only accessible and visually appealing, but also user-friendly and engaging for a wide range of users. This can lead to more effective and successful websites that are appreciated by all users, regardless of any disabilities they may have.

Overall, while some accessible websites may not have the same visual appeal as other websites, it is possible to create websites that are both accessible and aesthetically pleasing. By following web accessibility guidelines and standards and considering the needs of all users, web designers and developers can create websites that are accessible, visually appealing, and user-friendly.

Me: What about underlining links? The WCAG success criterion 1.4.1 basically forces you to underline links, although it hurts the aesthetic appeal of a website.

ChatGPT: The Web Content Accessibility Guidelines (WCAG) success criterion 1.4.1 states that “information and relationships conveyed through presentation can be programmatically determined or are available in text.” This means that any information or relationships that are conveyed visually through the presentation of a website, such as the location of a link, should also be available in text so that they can be understood by users with visual impairments who may not be able to see the visual presentation of the site.

In the case of links, the WCAG success criterion 1.4.1 does not necessarily require that links be underlined, but it does require that the location of the link be clearly indicated in text. This can be achieved in a number of ways, such as by using a different color for links, by using a unique style or font for links, or by underlining links. The specific method used to indicate the location of a link is up to the web designer or developer, as long as it meets the requirements of the WCAG success criterion 1.4.1.

Ultimately, the goal of the WCAG success criterion 1.4.1 is to ensure that the information and relationships conveyed through the presentation of a website are available in text so that they can be understood by users with visual impairments. While underlining links is one way to meet this criterion, there are other options available that can also provide good visual design while ensuring accessibility.

Me: You mixed up the criteria 1.3.1 and 1.4.1. The success criterion 1.4.1 actually states that “color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.”

ChatGPT: I apologize if I mixed up the WCAG success criteria. The success criterion 1.4.1 that I mentioned does indeed state that “color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.” This means that websites should not use color as the only way to convey information or indicate an action, since this can make the content difficult or impossible to understand for users with visual impairments who may be unable to see the…

Conclusion

In the end, ChatGPT suddenly broke off mid-sentence and became unresponsive. Maybe I overheated its artificial synapses, who knows.

Overall, I’m impressed by the detailed and mostly accurate responses of ChatGPT. Talking to the AI, it actually feels like you’re having a conversation with another human being. It’s kind of eerie.

Of course, the AI isn’t perfect. After some time, the answers seem a little repetitive. Also, when I asked a specific question about the WCAG success criterion 1.4.1, ChatGPT responded with erroneous information. I suppose that with more training, those errors will happen less and less often.

Have you already had a conversation with ChatGPT? What was your experience like?

3 Ways how Web Developers also benefit from Accessibility

Sun, 27 Nov 2022 00:00:00 GMT

Web accessibility is an ethical duty and economically viable. You contribute to the inclusion of people with disabilities and increase your potential client base. Still, as a web developer, you might be thinking: “That’s great for my company and society in general. But it means more work for me, argh!”

I get it! Web accessibility can be overwhelming in the beginning. And yes, some stuff like ARIA live regions actually increase your workload slightly. But I want to let you in on a little secret: Accessibility will make your life as a web developer easier and save you time in the long run!

You don’t believe me? Then keep on reading for three examples of the superior experience that accessibility brings.

1. Semantic markup is easier to read and maintain

Semantic markup doesn’t only convey information about the meaning of each element to assistive technologies. It also conveys this information to developers who need to read it, modify it or refactor it.

Imagine you’re joining a new team and getting familiar with the codebase. Would you be happy to find this kind of code?

<div class="fixed-header" role="banner">
    <div id="header-logo" role="img" aria-label="Logo Example Page"></div>
    <div role="navigation" aria-label="Main Navigation">
        <div role="list">
            <div role="listitem"><a href="/">Home</a></div>
            <div role="listitem"><a href="/about">About</a></div>
        </div>
    </div>
</div>
<div role="main">
    <div role="heading" aria-level="1">Best Pizza in Town</div>
    <div role="heading" aria-level="2">Pizza Salami</div>
    <div id="pizza-salami" role="img" aria-label="Pizza with salami slices"></div>
    <div>Some text</div>
    <div role="heading" aria-level="2">Pizza Capricciosa</div>
    <div id="pizza-capri" role="img" aria-label="Pizza with baked ham, mushroom and artichoke"></div>
    <div>Some text</div>
</div>

Damn, that’s a lot of div tags! Kinda hard to read. Well, wouldn’t you rather see this HTML code instead:

<header>
    <img src="/header-logo.svg" alt="Logo Example Page">
    <nav aria-label="Main Navigation">
        <ul>
            <li><a href="/">Home</a></li>
            <li><a href="/about">About</a></li>
        </ul>
    </nav>
</header>
<main>
    <h1>Best Pizza in Town</h1>
    <h2>Pizza Salami</h2>
    <img src="/pizza-salami.jpg" alt="Pizza with salami slices">
    <p>Some text</p>
    <h2>Pizza Capricciosa</h2>
    <img src="/pizza-capri.jpg" alt="Pizza with baked ham, mushroom and artichoke">
    <p>Some text</p>
</main>

Ah, that’s better! Now you can talk about the HTML code with your teammates in a meaningful way. Fun fact: Both code examples would result in the same accessible experience for screen reader users. But only the second one is beneficial for web developers.

If you think that I exaggerated with my example of spaghetti code hell, let me tell you this: I’ve seen variations of this on many websites out there. Which makes me sad.

2. Native HTML controls are keyboard operable by default

HTML elements like a , button , input type=“checkbox” , or input type=“radio” are all accessible by default. For example, users can navigate between buttons using the tab key and activate their selection with the space or enter key.

Imagine, for whatever reason, you want to implement a button using the div element. To make this abomination operable through a keyboard, you would have to do the following:

Apply tabindex=“0” to include the div in the tab order.
Define a clearly visible focus indicator to convey when the div has focus.
Implement a keydown event handler to activate the “button” when the space or enter key is pressed.

Here’s what you need to do using the native button element:

Nothing!

Buttons are keyboard operable by default and trigger the click event when the space or enter key is pressed. And you can easily customize their styling with CSS. This is also true for most form elements. Check out my post about styling web forms.

3. Stateful, semantic CSS selectors are more expressive and robust

You can leverage the semantic tag names and ARIA attributes for expressive and easy to understand CSS selectors like header nav > ul { … } or button[aria-expanded=“true”] { … } .

By interweaving your CSS rules with HTML tags and attributes, you no longer need to manage extra CSS classes dynamically with JavaScript. You can concentrate on your business logic being reflected in the HTML code alone (e.g., by setting aria-expanded to true or false).

For more examples and an in-depth look at the concept, check out the article “Style with Stateful, Semantic Selectors” by Ben Myers.

Useful Resources

Update on 12/16/2022

Revised section on stateful, semantic CSS selectors.

Building Accessible Toggle Buttons in React

Fri, 18 Nov 2022 00:00:00 GMT

Filter options, system preferences or a dark mode control – it’s very likely that you’ve come across a toggle button before. At first sight, toggle buttons are simple: They allow the user to change a setting between two states, usually “on” and “off”.

Unfortunately, there’s no native HTML element for toggle buttons. Which is why there’s a lot of different custom implementations roaming the internet. Some of them, you guessed it, totally inaccessible nightmares.

I created a demo app in React with accessible toggle buttons, which I’d like to show you. I’m not sure that it’s the perfect solution. So I’m eager for some feedback.

Demo: Beer List with Toggle Buttons

In my demo, I display a list of beers. Users can switch between weak and strong beers using toggle buttons. Give it a try:

If you inspect the code, you’ll see that I used a group of buttons and applied the switch role to them. Before we take a closer look at the technical details, I want to explain what I wanted to achieve with the control.

Goals and Requirements

The control should clearly convey its functionality, both visually and to assistive technologies.
It should indicate its current state, both visually and to assistive technologies.
Users should be able to operate the control with the keyboard alone, duh!
Only one option (“weak” or “strong”) can be active at one time. If one option is switched on, the other one is switched off.
Switching between the two options should be a deliberate act by the user and not happen by accident.

Semantic Markup and Keyboard Operability

You could use radio buttons and change their styling with CSS. I decided not to use them because they’re automatically selected on focus (not what I want!) and they’re standard form elements. Web forms should not trigger a change of context until hitting the submit button.

So, I decided to use a button element for each selectable option (“weak” and “strong”) and apply the switch role. The specification for the role states:

A type of checkbox that represents on/off values, as opposed to checked/unchecked values.

My React component contains a toggle button for each option. This way, I can label them individually and clearly convey their state (on or off). Furthermore, the two buttons are grouped inside a section element with the group role. Take a look at the JSX code:

<section className={styles.container} role="group" aria-label={switchLabel}>
    <p>{switchLabel}:</p>
    <div className={styles.switchWrapper}>
        <button
            type="button"
            role="switch"
            aria-checked={selectedState === stateValues[0]}
            onClick={toggleSwitch}
        >
            {stateLabels[0]}
        </button>
        <button
            type="button"
            role="switch"
            aria-checked={selectedState === stateValues[1]}
            onClick={toggleSwitch}
        >
            {stateLabels[1]}
        </button>
    </div>
</section>

Users can focus the buttons with the tab key and toggle the state with the space or enter key.

Custom Styling with CSS

The toggle buttons’ styling visually conveys their functionality and current state. When an option is selected, I invert its colors and add a vertical line using the ::after pseudo-element. Here’s an excerpt from my component’s SCSS file:

/* Invert background and text colors */
button[aria-checked="true"] {
    background: var(--light-black);
    color: white;
}
/* Add vertical line to highlight selected option */
button[aria-checked="true"]:after {
    content: "";
    position: absolute;
    bottom: 0.2em;
    top: 0.2em;
}
button[aria-checked="true"]:first-of-type:after {
    right: 0.2em;
    border-right: 0.3em solid var(--primary-color);
}
button[aria-checked="true"]:last-of-type:after {
    left: 0.2em;
    border-left: 0.3em solid var(--primary-color);
}

Feedback

So, that’s it. My proposed solution for accessible toggle buttons. Do you love it, do you hate it? Hit me up on Twitter, Mastodon or GitHub!

Useful Resources

Common ARIA mistakes and how to avoid them

Mon, 17 Oct 2022 00:00:00 GMT

So you want to make your website more accessible? Great! And you’ve heard about ARIA, which stands for Accessible Rich Internet Applications. Just slap some ARIA attributes on all HTML elements and your page is accessible? Wrong!

If you don’t know what you’re doing, you’ll end up making your website even less accessible! There’s a reason why the first rule of ARIA is: No ARIA is better than Bad ARIA! Use native HTML elements and attributes with the semantics and behaviour you require.

Let’s take a look at use cases for ARIA and common mistakes you should avoid.

ARIA, what is it good for?

ARIA is a set of roles and attributes that can help you to make web content more accessible to people with disabilities. The latest version WAI-ARIA 1.2 was released by the W3C in December 2021.

Persons with certain types of disabilities use assistive technologies to interact with web content. For example, blind users navigate websites with the help of screen readers. People with motor disabilities may rely on speech recognition software to interact with a website.

Web developers can use ARIA roles and attributes to convey semantics of the content to users of assistive technologies. You can set aria-expanded on an element to indicate if a control is expanded or collapsed. The aria-selected attribute indicates if, e.g., a tab is currently selected or not.

<h3>
    <button type="button" aria-expanded="false" aria-controls="section1" id="header1">
        Personal Information
    </button>
</h3>
<div id="section1" role="region" aria-labelledby="header1">
    <!-- Panel content that is shown/hidden via button -->
</div>

In general, only use ARIA for custom widgets like, e.g., an expansion panel. Check out the ARIA Authoring Practices Guide, which describes how to apply accessibility semantics to common design patterns and widgets.

Bad ARIA practices

I’ve audited hundreds of websites for accessibility. One thing I’ve noticed is: Many web developers apparently have no idea what they’re doing! They clutter the DOM with ARIA roles and attributes as if there was no tomorrow. I’ll show you some of the most common mistakes I’ve encountered.

Using `aria-hidden=“true”` on a focusable element

ARIA gives you full control over the accessibility tree, which is a modified version of the DOM that is presented to assistive technolgies. The aria-hidden attribute allows you to remove an element from the accessibility tree and thereby hide it from screen reader users.

<a href="https://www.stuff.com" aria-hidden="true">Interesting Stuff</a>

The problem is: Removing a focusable element like a link from the accessibility tree does not remove it from tab order. A screen reader user tabbing through the website will arrive at the link and hear “empty” or something similar. Please, don’t do this!

Setting an `aria-label` different from the visible label

Imagine you’re a university student in Vienna and want to register for a lecture online. Because of your hand-tremor, you use voice recognition software to operate the website. You encounter the following web form in German:

<form action="">
    <div class="form-field">
        <label for="firstname">Vorname</label>
        <input type="text" aria-label="First Name" name="firstname" id="firstname">
    </div>
    <div class="form-field">
        <label for="lastname">Nachname</label>
        <input type="text" aria-label="Last Name" name="lastname" id="lastname">
    </div>
    <!-- Other fields -->
</form>

To fill out the form, you want to focus on the first input field with the visible label “Vorname”. Therefore, you speak the voice command “Vorname klicken” (in German), but nothing happens. What is going on?

As the code above shows, the label element is programmatically associated with the input field using the for attribute. Unfortunately, the aria-label attribute overwrites the input element’s accessible name with “First Name”. This means, that the control’s name does not include the visible label.

So the form is not easy to operate for voice recognition users and it also represents a clear WCAG violation. Fun fact: This is an actual example from the German website of a large university in Vienna.

The `aria-labelledby` attribute references an ID that doesn’t exist

You can use the aria-labelledby attribute to label an element by referencing another element. Its value should be a list of one or more ID values referencing the elements that label the current element. Here’s an example:

<nav aria-labelledby="sidenav-title">
    <h2 id="sidenav-title">Related Content</h2>
    <ul>
        <!-- List of links -->
    </ul>
</nav>

If there were no element with the id “sidenav-title”, then the nav element would have no label. This would result in a less than optimal experience for screen reader users. Therefore, always check that the elements referenced by aria-labelledby are present in the DOM.

Navigation Menu with `role=“menubar”` or `role=“menu”`

Many websites include site navigation that is styled to look like a menubar with expandable sections. Because of the visual appearance, a lot of web developers think that they should apply the following semantic roles:

<ul role="menubar">
    <li role="none">
        <a role="menuitem" href="/">Home</a>
    </li>
    <li role="none">
        <a role="menuitem" aria-haspopup="true" aria-expanded="false" href="#">About</a>
        <ul role="menu" aria-label="About">
            <li role="none">
                <a role="menuitem" href="/overview">Overview</a>
            </li>
            <li role="none">
                <a role="menuitem" href="/administration">Administration</a>
            </li>
        </ul>
    </li>
</ul>

The problem with this markup is the expectations it creates. The roles menubar and menu should be used for menu widgets that offer a list of choices to the user, such as a set of actions. These menus should behave like native operating system menus, which means: They should implement a specific set of keyboard interactions, including navigation with arrow keys.

If you create a site navigation with, e.g., role=“menubar” , then screen reader users will expect to navigate the menu with the arrow keys. When this doesn’t work, they’ll be confused. A better alternative is to implement the disclosure pattern for site navigation with expandable groups.

Basic rules for using ARIA

As we’ve seen, a lot can go wrong with ARIA. Here’s a list of basic rules that will make your life easier:

Go for native HTML elements first.
Do not change native semantics, unless you really have to.
Use ARIA for custom widgets and strictly follow the Authoring Practices Guide.
All interactive ARIA controls must be usable with the keyboard.
Test your code with assistive technologies like screen readers and voice recognition software.

Useful Resources

CSS tweaks for better visibility in Forced Colors Mode

Tue, 27 Sep 2022 00:00:00 GMT

High contrast between text and its background benefits everyone. Be it people with low vision or anyone looking at the screen in the glaring sun. That’s why WCAG has minimum requirements for contrast of text and UI components.

For some visually impaired users, this is not enough. They need specific color themes with high contrast to increase text legibility and improve readability. Assistive technology like High Contrast Mode on Windows can actively change a website’s colors to accomodate users with limited vision.

I’ll show you how forced colors mode works for websites and how to improve the user experience with some CSS tweaks.

How does Forced Colors Mode work?

Forced colors mode is a cross-browser standard defined in CSS Color Adjustment Module Level 1. Operating systems should provide built-in color themes and allow users to customize their own themes.

The specification states:

When forced colors mode is active (…), colors on the element are force-adjusted to the user’s preferred color palette.

This means that color values are replaced with system colors to match the defined theme. Among the affected CSS properties are:

color
background-color
border-color
outline-color
fill

Other properties like box-shadow and text-shadow are set to none . To give you an example, this is what my blog looks like in forced colors mode with a dark theme:

How to test forced colors mode

You can use the developer tools in Chrome and Edge to emulate forced colors mode and check the visibility of your content:

Open the Rendering tab.
Under “Emulate CSS media feature forced-colors”, select “forced-colors: active” from the dropdown list.

The `forced-colors` media query

Use the media query forced-colors to apply certain styling only when forced colors mode is active. For example, I’ve included a SVG pattern in the background of my blog using the background-image property:

#___gatsby {
    background-image: url("data:image/svg+xml...");
    background-attachment: fixed;
    background-size: cover;
}

Using the media query, I remove the background image when forced colors mode is active:

@media (forced-colors: active) {
    #___gatsby {
        background-image: none;
    }
}

Another useful CSS property is forced-color-adjust . It allows you to opt certain elements out of forced colors mode and optimize its styling yourself.

Transparent borders and outlines

Web layouts often communicate the boundary of an element with a different background-color or via box-shadow . In forced colors mode, all elements have the same background color and shadows are removed. This lack of clear boundaries between elements can be confusing for users.

But don’t despair! There’s a clever solution for this problem: Set a border with the color transparent . When forced colors mode replaces the color value, the border becomes visible and communicates the boundaries of the element:

section.info-card {
    border: 1px solid transparent;
}

You can use the same logic to ensure visible focus indicators in forced colors mode. Usually, browsers add an outline to a link or button when it receives focus. It’s totally fine to remove the outline with outline: none if you provide a different focus indicator, e.g., a different background color. As this won’t work in forced colors mode, the better solution is to make the outline transparent:

a:focus {
    background: var(--primary);
    color: var(--white);
    /* Provide visible focus indicator in forced colors mode */
    outline: 2px solid transparent;
}

There’s even more great CSS techniques to fix common accessibility issues in forced colors mode. Please watch the video “Practical Styling in Forced Colors Mode” by Mike Herchel.

Useful Resources

Using CSS Cascade Layers in Angular

Mon, 05 Sep 2022 00:00:00 GMT

We’ve all been there: You define a new CSS rule, rebuild your web application, and check the browser to see that your styling isn’t being applied. Come on!

Many times, there’s a conflict with another CSS rule that has higher specificity. Maybe you’ve included a third-party library that defines style rules that conflict with your own.

Luckily for us web developers, a new CSS feature comes to the rescue: CSS Cascade Layers . They allow us to strictly layer our styles and avoid conflicts. I’ll show you how to use them in an Angular web application with SCSS.

What are Cascade Layers?

CSS Cascade Layers give authors more control over the cascade, which is to say: The way the browser chooses which styling rules to apply for a specific HTML element.

The new feature is defined in the CSS Module Cascading and Inheritance Level 5. Although the document has only “Editor’s Draft” status, cascade layers are already supported by all modern browsers. The document states:

Cascade layers provide a structured way to organize and balance concerns within a single origin. Rules within a single cascade layer cascade together, without interleaving with style rules outside the layer.

This means that we can establish various layers – starting with low-priority styles like resets and third-party libraries, up to high-priority styles like components and utilities. Conflicts between layers are always resolved by using the higher-priority layer styles.

If we look at the steps of the cascade, we see that layers are evaluated before specificity and order of appearance are taken into account:

Origin and importance (!important )
Context
Element Attached styles
Layers
Specificity
Order of Appearance

Please watch the video “The CSS Cascade, a deep dive” by Bramus Van Damme if you want to explore the CSS cascade in more detail.

The `@layer` rule

In general, we create a named cascade layer and define rules within this layer using the @layer rule:

@layer my-layer {
    // CSS rules
}

You can also create a named cascade layer without assigning any styles. This is used to determine the hierarchy of your layers. A best practice is to first define the hierarchy of your layers in a single @layer statement, followed by the style rules separated into these layers.

@layer my-layer-1, my-layer-2;

@layer my-layer-1 {
    // CSS rules
}

@layer my-layer-2 {
    // CSS rules
}

Any styles not in a layer are gathered together and placed into a single anonymous layer that comes after all the declared layers. This means that any styles declared outside of a layer will always override styles declared in a layer.

I won’t get into all the details about cascade layers. Please read the great article “A Complete Guide to CSS Cascade Layers”.

Demo Application with Angular and SCSS

I’ve created an application with Angular 14 and Leaflet to display an interactive map. I use SCSS for styling, as it offers great features like placeholders and mixins. Check out my demo code here.

My goal for the application is simple: I want to make sure that my styling for individual components is always applied. They should take precedence over, e.g., CSS resets and library styles. For this purpose, I’ve created several cascade layers in the main styles.scss file of my application:

@use "sass:meta";

@layer reset, thirdparty, overrides;

@layer reset {
    @include meta.load-css("layers/reset/normalize");
}

@layer thirdparty {
    @include meta.load-css("node_modules/leaflet/dist/leaflet.css");
}

@layer overrides {
    @include meta.load-css("layers/overrides/leaflet");
}

I use the SASS function load-css to load the CSS from another SCSS file and include it as part of a cascade layer. I put all user agent style resets in the lowest-priority layer, followed by the layer for the basic styling of the interactive leaflet map and a layer for global overrides.

I don’t define cascade layers for the styles of specific components declared in their own SCSS file. All these styles are automatically put into an anonymous layer that receives the highest priority. Let’s look at a specific example.

My demo app lists my 5 favorite places in Vienna. They are marked on an interactive leaflet map. When you click on a marker, a popup opens. The HTML template fav-place-popup.component.html of the popup component looks like this:

<h2>{{data.name}}</h2>
<p *ngFor="let desc of data.description">{{desc}}</p>

I’ve applied the following styles in fav-place-popup.component.scss :

p {
    font-size: 0.8rem;
    margin: 0.5em 0;
}

At the same time, the leaflet library defines the following styles for paragraphs inside of map popups:

.leaflet-popup-content p {
    margin: 18px 0;
}

Thanks to my established order of cascade layers, I don’t have to worry about leaflet’s styles for .leaflet-popup-content p interfering with my component styles for p . At the same time, Angular’s view encapsulation ensures that my component’s styles are not applied to all paragraphs in my application. Sweet!

Conclusion

I love cascade layers! They’re a powerful tool to structure your styles and avoid pesky conflicts due to specificity or order of appearance.

There’s one problem remaining: Some Angular libraries (e.g. Angular Material) automatically add styles to the HTML document’s head tag. So far, I haven’t found a way to put these styles in a cascade layer of my choice. I hope this issue will be addressed in the future.

Why you should use the Native Dialog Element

Tue, 19 Jul 2022 00:00:00 GMT

We’re all familiar with dialogs. From simple prompts for confirming an action to content-heavy windows — dialogs are an integral part of modern web user interfaces.

Unfortunately, we didn’t have a native dialog element for a long time, leading to different custom implementations with many accessibility issues. This changed when HTML 5.2 introduced the <dialog> element. With Safari finally adding support in version 15.4, all modern browsers now support the element.

I’ll show you how easy it is to create an accessible, modal dialog using the native element. Some minor accessibility issues remain with some browsers and screen readers, which I’ll cover at the end of the post.

What does the `<dialog>` element do?

The dialog element creates a popup box on your website that draws the user’s attention. The HTML specification states:

The dialog element represents a part of an application that a user interacts with to perform a task, for example a dialog box, inspector, or window.

A typical use case would be a modal dialog that obscures the rest of the page and asks the user for some input. I’ve created a demo using the React framework (source code):

Basic Setup and Interaction with the Dialog

The basic JSX code of my modal dialog demo looks like this:

<dialog
    aria-labelledby='dialog-personal-info-heading'
    ref={formDialogRef}
    onClick={onFormDialogContainerClick}
>
    <h3 id="dialog-personal-info-heading">
        Personal Information
    </h3>
    <p>...</p>
    <form
        method="dialog"
        onClick={event => event.stopPropagation()}
    >
        // form elements
    </form>
</dialog>

By default, the browser won’t display the dialog until you pass in an open property to make it visible. It is recommended to use the .show() or .showModal() methods to render dialogs, rather than the open attribute.

In my case, I want to show a modal dialog that obscures the rest of the page. In my functional React component, I retrieve a reference to the HTML element with the useRef hook and open the dialog on a button click:

const formDialogRef = useRef<HTMLDialogElement>(null);

const onOpenFormDialogClick = () => {
    formDialogRef.current?.showModal();
}

To close the dialog, use the .close() method. As my demo shows, a <form> element can also close the dialog using the attribute method=“dialog” . When the form is submitted, the dialog closes with its returnValue property set to the value of the button that was used to submit the form:

<form method="dialog">
    <div className={styles.formField}>
        <label htmlFor="favMovie">Favorite movie:</label>
        <input id="favMovie" type="text" />
    </div>
    <button
        type="submit"
        value={DIALOG_CONFIRM_VALUE}
    >
        Confirm
    </button>
</form>

You can add an event listener for the dialog’s close event and trigger an action depending on the value of the returnValue property.

Styling the Dialog and its Backdrop

The modal dialog is rendered in the center of the page on top of the other content. Browsers apply a default style to the dialog element, usually a thick black border. You can easily customize the dialog’s appearance with CSS. For example, add a drop shadow and rounded corners like this:

dialog {
    border: 0.125rem solid var(--border-color);
    border-radius: 4px;
    box-shadow:
        0 11px 15px -7px #0003,
        0 24px 38px 3px #00000024,
        0 9px 46px 8px #0000001f;
    font-size: 1rem;
    max-width: min(18rem, 90vw);
}

A really awesome feature of the dialog element is the ::backdrop CSS pseudo-element. It allows you to style behind a modal dialog to, e.g., dim and blur the unreachable content of the page:

dialog::backdrop {
    background: rgba(36, 32, 20, 0.5);
    backdrop-filter: blur(0.25rem);
}

Keyboard and Mouse Control

When the modal dialog is opened, the browser moves focus to the first interactive element inside of the dialog. This works well for many use cases, like my form dialog. But sometimes you would prefer to set the focus on the whole dialog or a text element at the top. Learn more about the issue in this proposal for initial focus placement.

While the modal dialog is active, the content obscured by the dialog is inaccessible to all users. This means that keyboard users can’t leave the dialog with the TAB key, and a screen reader’s virtual cursor (arrow keys or swiping) is not allowed to leave the modal dialog as long as it remains open.

Users can close the modal dialog with the ESC key. On close, focus returns to the control that initially activated the dialog. This allows keyboard and screen reader users to continue browsing from where they left off.

Unfortunately, the dialog element doesn’t close automatically when the user clicks outside of it. If we want to implement this light dismiss behavior, we can get the coordinates of the click and compare them to the dialog’s rectangle (thanks for the idea, Amit Merchant):

const isClickOutsideOfDialog = (dialogEl: HTMLDialogElement, event: React.MouseEvent): boolean => {
    const rect = dialogEl.getBoundingClientRect();
    return (event.clientY < rect.top
            || event.clientY > rect.bottom
            || event.clientX < rect.left
            || event.clientX > rect.right);
}

const onFormDialogContainerClick = (event: React.MouseEvent) => {
    const formDialogEl = formDialogRef.current;
    if (formDialogEl &&
        isClickOutsideOfDialog(formDialogEl, event)
    ){
        formDialogEl.close(DIALOG_CANCEL_VALUE);
    }
}

This works fine, except for some use cases. For example, opening a native select inside the dialog would count as a click outside of the dialog and close it. Therefore, I apply a click event listener to the form element and use the .stopPropagation() method.

Accessibility Issues with some Screen Readers

The native dialog element works well with most screen readers and browsers. But still, some issues remain as the accessibility audits of my demo on different platforms have shown:

Windows 10, Google Chrome 103.0.5060.114, NVDA 2022.1: When the dialog is opened and receives focus, the screen reader announces the dialog role, the heading (thanks to aria-labelledby ), the first paragraph and the focused select element. Focus order and the screen reader’s virtual cursor are limited to the dialog’s content.
Windows 10, Firefox 102.0.1, NVDA 2022.1: Identical to Google Chrome, except that the button that opened the dialog is part of the focus order. Probably a Firefox bug that will be fixed in the future.
Samsung Galaxy S20, Android 12, Google Chrome 103.0.5060.71, TalkBack: The screen reader only announces the focused select element. The virtual cursor (e.g. swipe right) is limited to the dialog’s content.
Samsung Galaxy S20, Android 12, Firefox 102.2.1, TalkBack: The screen reader only announces the focused select element. The virtual cursor is not limited to the dialog’s content. This is probably due to Firefox still not supporting the aria-modal property.
iPhone 8, iOS 15.5, Safari, VoiceOver: The screen reader only announces the focused select element. The virtual cursor can be moved outside the dialog to the elements in the header, but not to the elements in the main content section.

Conclusion

The <dialog> element is easy to use and accessible by default, apart from some minor issues. Right now, a robust custom dialog like a11y-dialog might still be the better option for some use cases. But I’m very optimistic about the native element’s future.

Useful Resources

Update on 03/07/2023

The HTML specification has received an important update regarding initial focus management. It will be possible to make the dialog element itself get focus if it has the autofocus attribute set.

Sure, it’ll take some time until browser vendors implement these changes. But there’s no reason to wait any longer! I agree with Scott O’Hara: “Instead of waiting for perfect, I personally think it’s time to move away from using custom dialogs, and to use the dialog element instead.”

Update on 03/28/2026

A Picture Says More Than a 1000 Words – Unless You're Blind!

Sun, 03 Jul 2022 00:00:00 GMT

Visual content is awesome! Images can convey emotions, capture our imagination, or simply make a website aesthetically more appealing. However, many people can’t visually perceive our content. Blind and visually impaired users depend on web developers and content editors to provide alternative text.

Unfortunately, a lot of websites have images with misleading alternative text or no alternative text at all. Imagine you visit a website and instead of all the images you only see blank spaces or fuzzy images. Not great, huh?

In this article, I’ll share some examples of bad alternative text that I regularly encounter in accessibility audits. But first, let’s go over the basics.

The Basics of Accessible Images

Typically, we use the img element to display an image on our website. With the alt attribute we can define alternative text for the image. The HTML specification states:

alt — Replacement text for use when images are not available

This means, that the alt text is displayed on the page if the image can’t be loaded, e.g because of network errors. Of course, it’s even more important for accessibility, as screen readers read the text out to their users so they know what the image means.

Other ways to include images on a website are inline svg elements or the CSS pseudo elements :before and :after . They pose different challenges in regard to accessibility (see the section “Useful Resources” below).

Write Effective Alternative Text

What all image elements have in common is the question: What kind of alternative text is appropriate for the image? This depends on the type of image:

Informative images: Images that convey relevant information. The text alternative should convey the meaning or content that is displayed visually.
- Opinions differ on whether the alt text should consist of a single, short sentence or it should describe the image in more detail with several sentences.
- In case of complex images (e.g. charts and diagrams), the alternative text should be kept short and refer to a long description that follows the image.
Decorative images: Images that don’t add relevant information to the content of a page. This is the case for images that are added to make the website more visually attractive. Or images that provide information which is already conveyed using adjacent text. These images should be hidden from assistive technologies, e.g. by setting an empty alternative text (alt="" ).
Functional images: Images used in buttons, links, and other interactive elements. In this case, the alternative text should convey the purpose of the interactive element and not describe the image itself.

My Personal Top 5 of Bad Alternative Text

When evaluating the accessibility of websites, I regularly encounter the same alt text mistakes over and over. So here’s my personal list of shitty alt text examples:

Title on repeat: Article previews (e.g. in a news carousel) usually include a thumbnail image to illustrate the article. A lot of times, the image’s alt text simply repeats the article’s title instead of describing the image. This means redundant information and a waste of time for screen reader users. Please, take the time to describe what the image actually shows!
Did the photographer take a selfie? I often encounter photos with alt text that includes the copyright information. Did the photographer take a selfie and can be seen in the picture? No? Then leave their name out of the alt text! You can put the copyright in the visible caption of the photo.
What does it do? Another common mistake is descriptive alt text for functional images. Imagine an icon button that visually displays a downward arrow. The button allows you to download a document. But the alt text says “arrow down”. Not the best way to convey the button’s purpose.
I’m not even here: Take a div element and slap an image on it using the background-image CSS property. Et voilà! You can see the image. But there is no information for assistive technologies. Screen reader users won’t even notice that the image is there. Or even worse, they’ll arrive at an image link or icon button with no information about their purpose. Thanks for nothing!
That’s just lazy: Sad, but true. I still encounter img tags with no defined alt attribute. Just no description at all. As a fallback, screen readers announce the image’s file name instead. Not very helpful, when the image is described as “wdkmm12xpY5.png”.

Conclusion

When you include visual content on a page, take a second to answer the following questions: What is the purpose of the image? Is it purely decorative? If not, define meaningful alternative text that describes the image or the purpose of the link or button.

Useful Resources

Creating a fancy, accessible File Input in 3 Steps

Tue, 24 May 2022 00:00:00 GMT

Native HTML elements are accessible by default and you can style most of them with CSS however you like – as I’ve shown in my blog post about web forms. Then again, there’s elements like the file input, which is very hard to style.

The <input type=“file”> element is rendered as a button that allows the user to open the operating system’s file picker. This button is completely unstylable – it can’t be sized or colored, and it won’t even accept a different font. But don’t despair! I’ll show you how to make it work.

Step 1: Use Native HTML Elements

When I include a file picker in a web form, I want all users to be able to select and upload files. This includes keyboard and screen reader users as well. Which is why I’ll use the native, accessible <input type=“file”> element. I’ve created a demo using the React framework. Here’s what my JSX code looks like:

<label htmlFor="filepicker" className={styles.filePicker}>
    <span>Upload PDF</span>
    <input
        id="filepicker"
        type="file"
        accept=".pdf"
        aria-describedby="selected-file"
        onChange={event => onFilePickerChange(event)}
    />
</label>
<p id="selected-file">{selectedFile}</p>

I use a label element that contains the visible label of my file picker (“Upload PDF”) as well as a visually hidden input element. This way, the label element serves as the visible UI component and you can apply any custom styling (more on that in step 2).

The p element displays the hint “No file selected” or, if a file was selected, the file’s name (see step 3). Thanks to the aria-describedby attribute, the text is also read by screen readers when the user arrives at the file input.

I also tried setting aria-hidden=“true” to hide the paragraph itself from assistive technologies. As this led to problems with certain browser and screen reader combinations, I removed the attribute again. Now screen reader users may hear the hint twice. Which is better than not hearing it at all.

Step 2: Apply CSS Magic

Next, I use CSS to visually hide the input element and position it above the label. This enables me to style the label element and thereby the visible file picker however I want:

form label[for].filePicker {
    position: relative;
    background-color: rgb(49, 4, 92);
    color: white;
    font-size: 1rem;
    // ... more custom styling
}

form label[for].filePicker input[type=file] {
    position: absolute;
    top: 0;
    left: 0;
    height: 100%;
    width: 100%;
    opacity: 0;
}

It’s important that you don’t hide the <input type=“file”> from assistive technologies. Using display: none or setting the element’s size to zero would hide it from screen readers.

To give visual feedback to sighted users, I display an outline on hover and when the input element within the label receives focus:

form label[for].filePicker:focus-within,
form label[for].filePicker:hover {
    outline: 2px solid black;
    outline-offset: 2px;
}

Step 3: A Dash of JavaScript

As a last step, I want to display the file name after the user has selected a file. To achieve this, I use the change event, which is fired when an alteration to the input’s value is committed by the user.

const FileUpload: React.FunctionComponent = () => {
    const [selectedFile, setSelectedFile] = useState('No file selected');

    const onFilePickerChange = (event: React.ChangeEvent<HTMLInputElement>) => {
        const files = Array.from(event.target.files ?? []);
        if (files.length > 0) {
            setSelectedFile(files[0].name);
        }
    }

    return (
        // Only the relevant sections of the JSX code
        <input type="file"
            // ...
            onChange={event => onFilePickerChange(event)}
        />
        <p id="selected-file">{selectedFile}</p>
        // ...
    );
};

Of course, you can do all that in plain JavaScript too – or any framework of your choosing. My code is simply an example of an implementation as a React component. You can view the complete source code on GitHub.

The Perfect File Input, right?

Check out the result of my styled file input below. I’ve also included a standard file input for comparison:

Awesome, right? I’m happy with the final result. But still, there’s room for improvement. The styled <input type=“file”> works perfectly for sighted keyboard users. For screen reader users, the results are pretty good, but not perfect.

Firefox fixed an important issue with aria-describedby in version 121. At the moment of my retests, this new version was still in beta. Here’s a detailed account of my accessibility audits on different platforms:

Windows 11, Google Chrome 120.0.6099.71, NVDA 2023.3: On focus, NVDA reads “Upload pdf, button, no file selected”. After selecting the file “testfile.pdf” the browser automatically focuses on the file input and reads “Button, upload pdf, testfile dot pdf”. When I navigate away and then return, the screen reader announces “Upload pdf, testfile dot pdf, button, testfile dot pdf”.
Windows 11, Firefox Beta 121.0b9, NVDA 2023.3: On focus, NVDA reads “Clickable, upload pdf, browse, button, no file selected”. After selecting the file “testfile.pdf” the browser automatically focuses on the file input and reads “Button, upload pdf, browse, upload pdf, browse, testfile dot pdf”. When I navigate away and then return, the screen reader announces “Clickable, upload pdf, browse, button, testfile dot pdf”.
Samsung Galaxy S20, Android 13, Google Chrome 119.0.6045.194, TalkBack: On focus, TalkBack reads “Upload pdf, no file chosen, button, no file selected, double tap to activate”. After selecting the file “testfile.pdf” the screen reader announces the element as “Upload pdf, testfile dot pdf”.
Samsung Galaxy S20, Android 13, Firefox for Android Beta 121.0b9, TalkBack: The screen reader only focuses on the text “Upload PDF”. It provides no information about the button role or the file name. At least, the file input can be triggered via double tap. After selecting the file “testfile.pdf”, this text is displayed next to the button and read by the screen reader on focus.
iPhone 8, iOS 16.7.2, Safari, VoiceOver: On focus, VoiceOver reads “Upload pdf, button, no file selected”. After selecting the file “testfile.pdf” the screen reader announces the element as “Upload pdf, button, testfile pdf”.

Conclusion

As my demo shows, you can create an accessible file picker with custom styling using the <input type=“file”> element and a bit of ingenuity.

Unfortunately, I’ve encountered some accessibility problems with certain browser and screen reader combinations. Maybe this will be fixed in future updates of the browsers and/or screen readers. Or maybe I’ll discover a better solution. We’ll see.

Update on 03/26/2023

I was wrong: There actually is a way to customize the native <input type=“file”> HTML element. You can use the ::file-selector-button CSS pseudo-element to style the rendered button. Unfortunately, you can’t change the text rendered inside the button. Here’s a demo with more info about it.

Update on 12/10/2023

I revised the HTML code in my example and redid the screen reader tests with the current browser versions.

How to develop a keen sense for Digital Accessibility

Sun, 03 Apr 2022 00:00:00 GMT

“I would like to be able to look at a mockup for a website and immediately know: This is not accessible!” – A colleague of mine expressed this wish a few days ago. He has been working for many years as a web developer, but still has little experience with digital accessibility.

His question got me thinking: What can newbies do to develop a keen sense for accessibility?

Responsive Design? What’s that good for?

Younger colleagues may find it hard to imagine: But web content didn’t always fluidly adapt to different screen sizes. Even in the 2000s it was still common to optimize websites for specific screen sizes only. The following article provides a good summary: “A Brief History of Responsive Web Design”.

This changed when smartphones became more and more popular. Today, users expect websites to look good and work on all devices. Responsive design is explicitly defined as a requirement for web projects. UI/UX experts create designs and prototypes for different screen sizes. Developers test implemented features on desktop and mobile devices.

Now what does that have to do with accessibility? For me, the triumph of responsive design clearly shows that the more people use websites in a certain way, the more these needs are taken into account in web development.

Accessible Design? What’s that good for?

Most people use their smartphone or a computer mouse to surf the Internet. They click a button and notice the visual feedback on the page. They’re not dependent on a screen reader being able to read the web content in a meaningful way or on interactive elements being accessible with the keyboard.

Web developers are users too. Their everyday experiences influence their perception of what makes a good, usable website. For example: If you’ve never used a screen reader, it’s hard to imagine why the semantic markup of web content is so important.

This brings me back to the central question: What can newbies do to develop a keen sense for accessibility as quickly as possible? Very simple: Change perspective!

Take on the perspective of people with disabilities

If you want to understand the needs of people with disabilities, the best way is to just ask them how they use digital content. Have a blind or partially sighted person show you how to shop online using a screen reader. Talk with a deaf person about watching the news with closed captions or in sign language.

If you don’t know any people with disabilities, you can organize a workshop in your company, for example. Contact an organization of persons with disabilities in your country. Some organizations also offer specific trainings, e.g., the Sensing Journey (in German).

Practice makes perfect

As a web developer, you are constantly confronted with new requirements that result from rapid technological change. That’s why we live by the principle of “learning by doing”. This approach also helps us when it comes to digital accessibility: Just do it!

For a start, you should read up on the “Web Content Accessibility Guidelines” (WCAG). They’re already a legal requirement for the public sector in all EU member states. The WCAG cover a wide range of needs from different user groups. They provide very detailed online resources, with concrete examples of accessible implementations, as well as common mistakes.

My recommendation: Most web content can be made accessible with semantic HTML and CSS alone. I often come across websites that make excessive use of ARIA attributes, creating more barriers than they remove. It makes sense to use ARIA for complex UI components, as illustrated by the WAI-ARIA Authoring Practices.

Take your time

Digital accessibility is complex and multi-layered. For newbies, this means a steep learning curve and a lot of potential for frustration. You should approach the topic step by step and be open to new perspectives. Then you will develop a keen sense for accessibility over time all by yourself.

Accessible and interactive charts with Angular and Highcharts

Sun, 13 Mar 2022 00:00:00 GMT

Column and line charts don’t have to be boring and static. Modern JavaScript libraries enable us to create animated, interactive, and accessible charts.

I’m a fan of Highcharts, a JavaScript charting library based on SVG rendering. Several wrapper libraries exist that integrate Highcharts into the component-based architectures of React and Angular, for example. In my demo app, I’ll show you how to interweave Highchart’s event handling with Angular components.

Demo App: Selecting a tab when a column is clicked

I built a demo app with Angular 13, Highcharts and highcharts-angular, a minimal Highcharts wrapper for Angular. A column chart depicts the primary desktop screen reader usage. Several tabs provide more information about the screen readers. When a column in the chart is clicked, the corresponding tab is selected. Try it yourself:

So, how did I do this?

Step 1: Define chart options and display the chart

The Highcharts library is super convenient. You simply define your chart options and let Highcharts do the rest. In my demo app, I define a chart with two column series:

export const EXAMPLE_CHART: Highcharts.Options = {
    series: [
        {
            data: [
                [ScreenreaderName.Jaws, 53.7],
                [ScreenreaderName.Nvda, 30.7],
                [ScreenreaderName.VoiceOver, 6.5],
                [ScreenreaderName.ZoomTextFusion, 4.7],
                [ScreenreaderName.Other, 4.4],
            ],
            name: 'Worldwide',
            type: 'column',
        },
        {
            data: [
                [ScreenreaderName.Jaws, 40.2],
                [ScreenreaderName.Nvda, 41.6],
            ],
            name: 'Europe',
            type: 'column',
        }
    ],
    subtitle: {
        text: '',
    },
    title: {
        text: 'Primary desktop/laptop screen reader (2021)',
    },
    xAxis: {
        categories: [
            ScreenreaderName.Jaws,
            ScreenreaderName.Nvda,
            ScreenreaderName.VoiceOver,
            ScreenreaderName.ZoomTextFusion,
            ScreenreaderName.Other,
        ],
    },
    yAxis: {
        title: {
            text: 'Usage in percent',
        }
    }
}

Then, in my AppComponent , I provide the chart options and the Highcharts library:

import * as Highcharts from 'highcharts';

@Component({
    selector: 'app-root',
    templateUrl: './app.component.html',
    styleUrls: ['./app.component.scss']
})
export class AppComponent {
    public chartOptions = EXAMPLE_CHART;
    public highchartsLib = Highcharts;
}

Finally, in the app component’s template, I pass on the library and the chart options to the <highcharts-chart> component:

<highcharts-chart
    [Highcharts]="highchartsLib"
    [options]="chartOptions"
    (chartInstance)="addCustomPropertiesToChart($event)"
></highcharts-chart>

Step 2: Add custom properties to the chart instance

The <highcharts-chart> component provides the output property chartInstance . It emits the chart instance after the chart is created. We use this to add an arrow function as a custom property to the chart instance:

public addCustomPropertiesToChart(chartInstance: Highcharts.Chart): void {
    (chartInstance as MyExampleChart).onSeriesPointClick =
        (name) => this.selectScreenreaderTab(name);
}

Highchart’s Chart interface doesn’t define a method onSeriesPointClick . Therefore, we need to define our own interface that adds this custom property:

export interface MyExampleChart extends Highcharts.Chart {
    onSeriesPointClick: (name: ScreenreaderName) => void;
}

Now our chart instance provides a method that is directly connected to the chart’s parent component. A chart event handler can call this method to communicate, e.g., that a specific series point was clicked.

Step 3: Call the custom method inside an event handler

In the plotOptions property of the chart options, we define a click event handler for all series points:

click: function(this) {
    const chart = this.series.chart as MyExampleChart;
    chart.onSeriesPointClick(this.name as ScreenreaderName);
}

The event handler retrieves the chart instance that we typecast to our custom MyExampleChart interface. Now we can call the custom method onSeriesPointClick and thereby select the corresponding screenreader tab in our application.

Step 4: Make your chart accessible

Highcharts provides great accessibility features. You can set colors in the chart as pattern fills. This helps people with limited color vision who benefit when information conveyed by color is available in other visual ways as well.

color: {
    pattern: {
        backgroundColor: '#96dbe7',
        color: '#080e38',
        height: 10,
        path: 'M 0 0 L 10 10 M 9 - 1 L 11 1 M - 1 9 L 1 11',
        width: 10,
    }
},

The linkedDescription property enables you to link the chart to an HTML element describing the contents of the chart:

accessibility: {
    enabled: true,
    linkedDescription: '#highcharts-description-1',
},

Conclusion

Combine Angular and Highcharts to create accessible and beautiful charts with minimal effort. With the help of custom properties, you can even interweave Highchart’s event handling with Angular’s component-based architecture for even more interactive experiences.

Resources

Create Accessible Web Forms with Custom Styling

Sat, 26 Feb 2022 00:00:00 GMT

HTML is accessible by default. At least, if you use the right native elements. Very often, developers build custom form controls to meet design needs – neglecting accessibility in the process.

As I’ll show in this post, modern browsers enable us to apply custom styling to most native form controls. This way, we can create accessible web forms with a consistent look across all platforms.

When Design Needs wreck Accessibility

Native form controls like input or select are accessible by default. They receive focus when keyboard users press the tab key. The enter and space key can be used to interact with them, e.g., to mark a checkbox as checked. They communicate their role and current state to screen readers.

Sounds great! You would be mad not to use native form controls and, instead, build custom UI components with non-semantic spaghetti code. Right? Well, the sad truth is: Using custom form controls is a common practice. And most of the time they’re not accessible. Let’s look at an example for a custom select:

<div class="custom-select">
    <div class="select-trigger">
        <span>PlayStation 5</span>
        <div class="arrow"></div>
    </div>
    <div class="custom-options">
        <span class="option selected">
            PlayStation 5
        </span>
        <span class="option">Nintendo Switch</span>
        <span class="option">Xbox Series X</span>
    </div>
</div>

By itself, this mess of div and span tags is not accessible to keyboard and screen reader users. Yes, you can fix this with ARIA attributes and keydown event listeners. But many developers are either not aware of this or simply don’t care. What they care about is styling the custom elements to meet the design needs of their clients.

Why Styling Native Form Controls can be challenging

Using CSS to style form controls has historically been difficult. Browsers apply their own default styling and form controls vary greatly in how easy they are to customize with CSS. Fortunately, this is getting easier as old browsers are retired (bye-bye IE11) and modern browsers offer more features to use.

Mozilla has a great article on styling web forms, which I highly recommend. They categorize native form controls into three groups: “The good”, “The bad”, and “The ugly”. I mostly agree with them, except for considering checkboxes and radio buttons difficult to style. This may have been true in the past, but modern CSS allows you to do whatever you want as I’ll show you.

Styling Example 1: Radio Buttons

In order to style your radio buttons with CSS, you need to set the value of the appearance property to none . This removes the default appearance applied by the browser and operating system. Now you can get creative and even apply smooth CSS transitions if you like:

input[type="radio"] {
    -webkit-appearance: none;
    appearance: none;
    box-sizing: border-box;
    position: relative;
    width: 1.4em;
    height: 1.4em;
    border: 0.15rem solid darkred;
    border-radius: 50%;
}

input[type="radio"]::before {
    position: absolute;
    top: 50%;
    left: 50%;
    content: "";
    width: 0.7em;
    height: 0.7em;
    border-radius: 50%;
    background-color: darkred;
    /* scale(0) hides the dot in unchecked state */
    transform: translate(-50%, -50%) scale(0);
    transform-origin: center;
    transition: all 0.3s ease-in;
}

input[type="radio"]:checked::before {
    transform: translate(-50%, -50%) scale(1);
    transition: all 0.3s cubic-bezier(0.25, 0.25, 0.56, 2);
}

In my example, I defined the unchecked state of the radio button to appear as a darkred circle. With the help of the ::before pseudo-element and the :checked pseudo-class, a darkred dot appears inside the circle when the radio button is selected. Check out the demo on CodePen.

Styling Example 2: Select

The select element belongs to the category “The ugly”. The problem with the form controls in this group is that they have very different default looks across browsers. You can style them to some degree with CSS, but some parts of their internals are literally impossible to style.

You can use the appearance property to override the default look of the select element. But this will not affect the list of options that appears when you click on the element. Styling the option element with CSS is highly limited and only supported by some browsers.

In my opinion, the styling options are sufficient to meet basic design needs (e.g. color and font). Take a look at my demo on CodePen where I used the following styling:

select {
    -webkit-appearance: none;
    appearance: none;
    box-sizing: border-box;
    background-color: white;
    background-image:
        url('/assets/custom_arrow_for_select.svg');
    background-position: right;
    background-repeat: no-repeat;
    background-size: contain;
    border: 0.25rem solid darkred;
    padding: 0.25em;
    /* Leave enough space for the arrow on the right */
    padding-right: 2em;
}

Native HTML is always better

What I wanted to show with this post is: Using native HTML is always better than messing around with custom UI components. Because keyboard and screen reader accessibility is already built in. Therefore, I would always pick the native form control if it can be sufficiently styled with CSS.

Spell it out! Determine how Screen Readers should read text

Sun, 13 Feb 2022 00:00:00 GMT

Numbers, abbreviations and equations can pose a challenge for screen reader users. Using the speak-as CSS property, you can determine how text should be read.

To spell, or not to spell, that is the question

Some days ago, I consulted a client in the banking industry. They want to optimize their web application for screen reader users. One of their questions was: How can we make the screen reader read numbers one at a time? For example, a bank account number with 12 digits or more?

In many cases, screen readers will announce the whole number instead of the single digits. For example, 9100 will be read as “nine thousand one hundred” instead of “nine one zero zero”. Similar problems can arise with abbreviations or equations. It all comes down to the screen reader’s inherent heuristics that determine how to read specific letters and punctuation.

Well, wouldn’t it be great if we could just tell the screen reader how to read certain content? The answer is: Yes, we can! But browser support is really bad.

The CSS speak-as property

The CSS Speech Module defines the speak-as property. It determines in what manner text gets rendered aurally, based upon a predefined list of possibilities:

normal: Uses the browser’s language-dependent pronunciation rules (default).
spell-out: Instructs the browser to spell the text one letter at a time (useful for acronyms and abbreviations).
digits: Speak numbers one digit at a time, like 9100 would be read “nine one zero zero”.
literal-punctuation: Spells out punctations (like semicolons, braces, etc.) rather than treating them like pauses.
no-punctuation: Entirely skips punctuation.

Using this property, we could define a class for bank account numbers like this:

.bank-account-number {
    speak-as: digits;
}

This all sounds great in theory. Unfortunately, it won’t work with most browsers and screen readers. I put together a demo on CodePen and tested the following scenarios:

NVDA 2021.3.1, Google Chrome 98.0.4758.82, Windows 10
TalkBack, Firefox 97.1.0, Android 12
VoiceOver, Safari 15, iOS 15.1

Out of the three, only VoiceOver does a great job and reads the content according to the speak-as property’s value. NVDA and TalkBack completely ignore it.

Considering the fact that the CSS Speech Module was written over 10 years ago, I’m very disappointed by the current situation. I hope that more browsers and screen readers will support the feature in the future!

3 Underrated HTML elements that are actually awesome

Sat, 05 Feb 2022 00:00:00 GMT

Did you know that there are over 100 different HTML elements? We’re all familiar with common elements like <h1> , <p> or <img> . But many elements lead a niche existence. Some web developers don’t even know they exist.

That’s why in this article I’d like to bring three underrated HTML elements to the fore: <time> , <picture> and <dl> .

The time element: Machine-readable dates

The <time> HTML element represents a specific point in time, date, or period. Together with the datetime attribute, the date is provided in a machine-readable format. What’s that good for? Here’s an example:

See the Pen time element German by Alexander Lehner (@alexlehner86) on CodePen.

The example above shows three events, each with a date displayed in a tear-off calendar style. Maybe your thinking: Dude, that’s self-explanatory! Together with the heading “Events 2022” it’s clear what the precise dates are.

Sighted people will probably have no problem with this representation of the date. But that’s not true for blind or visually impaired users. When the screen reader announces “mar four” or “jul eight”, it will be confusing. Use the <time> element to provide clarity.

Unfortunately, not all popular screen readers support the element. VoiceOver correctly reads out the date defined in the datetime attribute (tested with iPhone 8, iOS 15, Safari). Sadly, it doesn’t work with NVDA and TalkBack at the moment.

The picture element: Load images based on screen size

The <picture> HTML element is an image container that enables you to offer alternative versions of an image for different display/device scenarios. It contains one <img> element and usually several <source> elements. Consider the following example:

<picture>
    <source srcset="cat_lg.avif" type="image/avif" media="(min-width: 60rem)">
    <source srcset="cat_md.avif" type="image/avif">
    <source srcset="cat_lg.webp" type="image/webp" media="(min-width: 60rem)">
    <source srcset="cat_md.webp" type="image/webp">
    <source srcset="cat_lg.jpg" media="(min-width: 60rem)">
    <img src="cat_md.jpg" alt="An adorable cat" loading="lazy" decoding="async">
</picture>

The type attribute specifies a MIME type for the resource defined in the srcset attribute. In the example above, the first <source> element points to an image in the modern AVIF format. The browser will pick this image if it’s capable of rendering AVIF images. Otherwise, it moves on to the next <source> element.

This allows modern browsers that support AVIF or WebP format to load a highly compressed, high-quality image. Older browsers can access the JPG version of the image instead.

The media attribute specifies a media query that the browser will evaluate. In the example we’re telling the browser that if the viewport width is wider than 60 rem it must use the large image. If the media query evaluates to false, the browser skips it and evaluates the next <source> element.

The srcset attribute offers another option for image optimization. You can also use it together with an <img> element, as shown in the cute cat picture above. Its HTML code looks something like this:

<img
    srcset="cat-480w.jpg 480w, cat-800w.jpg 800w"
    sizes="(max-width: 600px) 480px, 800px"
    src="cat-800w.jpg"
    alt="A sleeping cat with black-grey fur."
>

The srcset attribute defines a set of images we will allow the browser to choose between, and what size each image is. The sizes attribute defines a set of conditions (e.g. screen widths) and indicates what image size would be best to choose, when certain media queries evaluate to true.

If you want to delve deeper into the topic, I can recommend the following articles:

Markup key-value pairs with dl, dt and dd

Lists are one of the basic building blocks of HTML. Every web developer knows the HTML elements <ul> and <ol> for unordered and ordered lists. Yet few are familiar with their close relative <dl> .

The so called description list contains a list of terms and descriptions that are defined with the HTML elements <dt> and <dd> . Common uses are to display a glossary or metadata (a list of key-value pairs).

<dl>
    <dt>Account Owner</dt>
    <dd>Martina Musterfrau</dd>
    <dt>Banking Institute</dt>
    <dd>Musterbank</dd>
    <dt>IBAN</dt>
    <dd>AT12 3456 7891 2345 6789</dd>
</dl>

Why do I think this element is awesome? You guessed it! It conveys the content in a programmatic way that screen readers can understand. But web developers also benefit from it. Think of the example above as a sequence of <div> elements. Which code block is more readable and easier to navigate? Semantic HTML makes code more readable!

Lights Off! Experience how Blind Users navigate the Web

Sat, 29 Jan 2022 00:00:00 GMT

What does it feel like to be blind? How can you navigate a website and read the content? My demo page “Come to the Dark Side” allows you to turn everything black and experience the website as a blind user would.

2.2 billion people have a vision impairment

According to the “World report on vision 2019”, about 2.2 billion people around the world are blind or visually impaired. Many of them use a screen reader to navigate the web.

As a person that can see, it can be hard to truly understand what that means: No visual input, relying only on the auditory feedback a screen reader provides.

Because I’m a curious person, I put together a demo page that allows you to experience what it feels like to be a blind web user. My goal is to help people get a better understanding of how important accessible web content is for blind users.

Come to the Dark Side

I’ve included my demo page below. Simply activate your screen reader and turn everything black via the “Go Dark” button in the header.

I look forward to your feedback! Just hit me up on Mastodon.

Provide highly visible Keyboard Focus with :focus-visible

Sat, 22 Jan 2022 00:00:00 GMT

Fancy design or accessibility? The :focus-visible pseudo-class enables you to support keyboard-only users and, at the same time, satisfy the aesthetic expectations of your clients.

The Importance of Keyboard Focus

Being able to navigate with a keyboard is an important feature of accessible websites. This benefits people with motor impairments who rely on a keyboard, instead of a mouse, to navigate a web page. Providing a visual indicator that clearly highlights the element that currently has keyboard focus is therefore indispensable.

Browsers provide a default focus indicator to ensure that keyboard focus is visible. In CSS, the styling of the focus indicator can be changed via the :focus pseudo-class. For example:

button:focus {
    outline: 2px solid purple;
}

Design versus Accessibility

I think we can all agree that a visual focus indicator is very helpful for keyboard users. On the other hand, the focus indicator also appears when users click an element with a mouse or touch it with their finger. For some users, this can be distracting or even irritating. Especially, without the knowledge that highlighting the element is actually an accessibility feature.

Often, web developers have to deal with clients and designers, who insist that they remove the focus styles altogether for purely aesthetic reasons. Consequently, many websites define CSS rules like this one:

button:focus {
    outline: none;
}

Please, don’t do this! You would actively exclude people who depend on keyboard navigation.

The Solution is :focus-visible

There is a way to reconcile accessibility with design expectations: The :focus-visible pseudo-class. The specification states:

The :focus-visible pseudo-class applies while an element matches the :focus pseudo-class and the user agent determines via heuristics that the focus should be made evident on the element.

This means: It lets you show focus styles only when they are needed, that is to say, when an element receives focus and the browser determines that the focus indicator should be shown (e.g., on keyboard navigation).

/* Hide focus styles if they're not needed. */
button:focus:not(:focus-visible) {
    outline: none;
}

/* Show focus styles on keyboard focus. */
button:focus-visible {
    outline: 2px solid purple;
}

This way, you gain precise control over when the focus indicator of e.g., buttons and links is shown. For some elements like input fields, the focus indicator will still be shown when the users click on it. This is because clicking the input field activates keyboard input. You can test this behavior in my demo.

Browser Support

Most modern browsers already support the feature. Safari also added support for :focus-visible with version 15.4. Still, I’d recommend you define regular focus styles for non-supporting browsers and then overwrite them for browsers that support :focus-visible .

/* Regular focus styles for non-supporting browsers. */
button:focus {
    outline: 2px solid purple;
}

/* For browsers that support :focus-visible */
@supports (:focus-visible) {
    button:focus:not(:focus-visible) {
        outline: none;
    }

    button:focus-visible {
        outline: 2px solid purple;
    }
}

Useful Links

Update on 04/14/2022

Post updated for Safari 15.4.

5 Tips for getting started with Accessibility Audits using a screen reader

Sat, 15 Jan 2022 00:00:00 GMT

The hardest part is getting started: How to efficiently use a screen reader and which keyboard shortcuts and gestures will make your life easier.

My First Time

Three years ago, when I activated a screen reader on my laptop for the first time, I briefly panicked. A robotic voice began talking to me at high speed. Intuitively I tried to match what I heard to what I saw on the screen – and failed miserably. Very stressful!

Using a screen reader can be confusing at first, especially for sighted people. For example, for web developers who want to check a newly implemented feature for accessibility. Or for testers who want to audit an application for the blind and visually impaired. So I want to share a few tips to make it easier to get started.

Tips for Beginners

For desktop devices running Windows, I can recommend the free screen reader NVDA. The screen reader VoiceOver is already pre-installed on Apple devices like the iPhone. The counterpart on Android devices is called TalkBack.

Where’s the stop button? Every screen reader provides a way to pause reading. For example, with VoiceOver, simply tap anywhere on the screen with two fingers.
Not so fast! Experienced users have their screen reader read text at double or even higher speed. Especially at the beginning you should slow down the reading speed and adapt it to your individual needs. With NVDA, for example, you can set the speed with a slider in the settings under “Speech”.
Choose the right voice: In the screen reader settings, select the voice you find most agreeable. Most of the time there are several male and female voices to choose from.
Gestures and Keyboard Shortcuts: Screen readers offer a variety of gestures and keyboard shortcuts that you can use to perform specific actions more quickly. For example, if you swipe left or right with three fingers when TalkBack is activated, you can select a navigation mode (e.g. headings). Then swipe up or down with one finger to jump to the previous or next item of that type. This way you can quickly check whether elements have been implemented with the correct semantic markup.
At your command! Find out the quickest way to turn the screen reader on and off. By default, NVDA can be started with the key combination CTRL + ALT + N and switched off with INS + Q. On the iPhone, you must explicitly set VoiceOver as a shortcut in the settings under “Accessibility”. Then you can toggle the screen reader on and off by triple-pressing the home button.

The most important thing is to give yourself the time you need. Always remember: practice makes perfect.

Useful Links

First Steps towards more Accessibility

Fri, 14 Jan 2022 00:00:00 GMT

I know, accessibility can be daunting. Especially when you take your first look at the abundance of WCAG criteria and resources available. My advice: Take a deep breath, pick a topic you’re interested in (e.g. semantic markup) and improve one thing in your website or app. Accessibility isn’t an “all or nothing” issue! Every single improvement counts.

Where to begin?

Here’s a list of first improvements you can make to your website or app:

Check the color contrast of text, graphical elements and UI components. High color contrast especially helps older people who are less able to make out low contrast patterns. Related WCAG criteria: 1.4.3 Contrast (Minimum) and 1.4.11: Non-text Contrast.
Interact with your website only using a keyboard. Can you navigate to all interactive elements via the tab key? If not, check if the elements are implemented with the correct semantic markup (e.g. button and link tags). On your smartphone, use the screen reader to navigate via swiping and check if interactive elements are correctly identified and can be activated. Related WCAG criteria: 2.1.1: Keyboard and 4.1.2: Name, Role, Value.
Do your videos offer captions? Captions enable people who are deaf or hard of hearing to watch videos. At the same time, everyone benefits who finds themselves in a situation where they can’t listen to the audio (e.g. in a crowded subway with no headphones). Related WCAG criteria: 1.2.2: Captions (Prerecorded)

Alexander Lehner – Oida, is des org!

Enhance Dialogs with the closedby Attribute

How it works

Use Cases

Light Dismiss for Informational Dialogs

Prevent Accidental Closing

Browser Support

Useful Resources

Best Practices for CSS Scope in Angular Applications

Demo Project: CSS Scope Sandbox

Best Practice 1: Use efficient Donut Scopes

Best Practice 2: Go deep without ::ng-deep

Best Practice 3: Define shared styles as Global CSS Classes

Conclusion

Using the Temporal API in Angular without including a Polyfill

Step 1: Install the Temporal Polyfill

Step 2: Declare a global Temporal object

Step 3: Using types from the Temporal namespace

Demo application

My First Steps as an Astronaut

Why I dropped Gatsby

What I like about Astro

The Future Looks Bright

Flexible Menu Animation with Anchored Container Queries

The Basics of Anchored Container Queries

Demo: Accessible Menu with CSS only animation

How to use Anchored Container Queries for Flexible Animations

Step 1: The basic HTML structure

Step 2: Menu Panel Animation

Step 3: Position Fallbacks

Step 4: Progressive Enhancement

Useful Resources

Let's Play Accordion with the HTML details element

The <details> HTML element

New Features

Exclusive Accordions with the name attribute

Content Styling with ::details-content

Custom Indicator for open/closed state

Flexbox and Grid Layouts

Conclusion

How to Create an Accessible Table with Clickable Rows

Demo: Table with Clickable Rows

Building the Accessible Table

The Ideal Solution

The Safari Supported Version

Conclusion

Let's build an Accessible Menu with Modern Web Features

What we want to achieve

Demo: Accessible Menu

Building the Menu Element step by step

Step 1: The basic HTML structure

Step 2: Using Popover API for the menu panel

Step 3: Panel placement with CSS Anchor Positioning

Step 4: Keyboard Interaction with JavaScript

Step 5: Adding Smooth Animations

Bonus: Custom Menu in Angular

Conclusions

» Update on 11/23/2025

Make Screen Readers talk with the ARIA Notify API

How does ARIA Notify work?

Demo: Online Shop with Shopping Cart

First Impressions

Date and Time Management with the Temporal API

High-Level Overview

Code Snippets

Create a new plain date object and access parts of it

Add a duration to an immutable plain time object

Language-sensitive formatting of a zoned datetime

Compare two instants

Round a duration to a specified unit

Browser Support

My Favorite Tools for Web Accessibility Testing

Structure and Semantics

Keyboard Operability

Responsive Content

Target Size of Interactive Elements

Minimum Contrast

Additional Links

Accessibility Engineering — Let the Web Platform do the Work

The Basic Tools of Accessibility Engineering

Best Practice 2: Go deep without `::ng-deep`

Step 2: Declare a global `Temporal` object

Step 3: Using types from the `Temporal` namespace

The `<details>` HTML element

Exclusive Accordions with the `name` attribute

Content Styling with `::details-content`

Update on 11/23/2025

The `button` element: A Powerful Allrounder

The `dialog` element: Always on top

Avoid the `menu` role

Update on 03/28/2026

Update on 02/24/2026