
If you wanted to integrate a popover on a website before, you had to reach out
to a **third-party package** in the past because they made it easy to customize
things like positioning and enhancing functionality. This may soon be a tale of
the past!

[The popover API](https://hidde.blog/popover-semantics/) with the popover
attribute was introduced recently and is available in Chromium 114. By using
this new popover API, it will be **easier to integrate popovers into websites**.
It brings all the needed functionality and satisfies all the **accessibility
concerns**. And all of that without using any JavaScript.

To make use of the new popover API, three basic things are required:

- the popover attribute on the element containing the popover
- an id on the element containing the popover
- the element which opens the popover needs to have a popovertarget attribute
  with the value of the popover’s id

```html
<button popovertarget="popover">Open popover</button>

<div
  popover
  id="popover"
>
  <p>Popover content</p>
</div>
```

Implementing such a popover is **accessible by default** because the popover and
its trigger are **connected semantically**. Furthermore, closing the popover
with the ESC key is built-in, making it easy for keyboard users to dismiss it.

In addition to that, the new popover has a **light-dismiss functionality**. If
you click anywhere outside the popover, it will close and return focus. If you
open the popover, the next keyboard tab will stop inside the popover, so **focus
management is handled by default**.

Another great advantage of it is that the popover will always appear on a
separate level above the rest of the page, so there is **no need for manual
z-index handling**.

That’s such a great addition, I can’t wait until it’s stable in all modern
browsers and we can use it! It’s a big step into easier and faster ways to build
websites and improve accessibility by default.

It’s important to note that the new popover attribute **will only add behavior,
not semantics**. Popovers have no default role, and you’re supposed to add your
own semantics to it! Hidde de Vries wrote an
[excellent post about different semantics](https://hidde.blog/popover-semantics/)
that could make sense for popover-behaved elements. He takes a closer look at
menus, dialogs, and listboxes.

### Sources

- [Introducing the popover API by Una Kravets](https://developer.chrome.com/blog/introducing-popover-api/)
- [Popover semantics by Hidde de Vries](https://hidde.blog/popover-semantics/)


The popover API is a new HTML attribute that makes it easy to integrate popovers into websites without the need for JavaScript.

The popover API


If you browse the web, you'll notice quickly that **sticky menus are used
often**. Sometimes I'm happy they're on a website, so I can quickly reach
call-to-action buttons or other important information. But most of the time, it
feels to me that they **take up a lot of space** away, and I intend to
**remove** them.

Seeing them so much in the wild was a validation to me. If implemented this
often, they must be helpful and improve the user experience. But if you think
about it: every website uses cookie banners, e-mail sign-up modals, and other
kinds of overlays, and we all hate them and know it's terrible UX.

So I was curious when I stumbled over this post by Adam Silver:
["The problem with sticky menus and what to do instead."](https://adamsilver.io/blog/the-problem-with-sticky-menus-and-what-to-do-instead/)
He states several well explain arguments on **why to avoid sticky menus and
shares better alternatives**.

His key takeaways, why we should replace them are:

1. **They constantly take up space**
2. **They obscure content**
3. **They break when you zoom in**
4. **They're difficult to access**
5. **Internal page anchors feel broken when clicked twice**
6. **They appear closer than they are**
7. **They obscure links and other focusable elements**

While most are obvious and reasonable arguments, numbers six and seven stood
out. I wasn't aware that sticky menus not only **decrease user experience** in
general but they're also reducing **accessibility** by a lot.

Sticky menus make us think that they are always very close to reach. That might
be true if you're using a mouse. You just move to it and can click. But, ever
tried to navigate to a sticky menu with a keyboard? Oh boy! They are often way
out of the normal document flow and very **hard to reach using the tab key**.

More accessibility problems arise if you're trying to move up the page with your
keyboard. Chances are you reach content that's right below the sticky menus. So
links and other focusable elements are not visible to you because they get
obscured by sticky menus.

Adams's advice on what to do instead is:

- **Keep pages short. This removes the need for a sticky menu**
- **Just let users scroll.**
- **Scrolling is never a problem, is fast, and everyone does it anyway**
- **Instead of putting important CTAs into a sticky menu, put them in a context
  like a CTA at the end of a pricing section**

If you think about implementing a sticky menu, I hope this post helps you to
think again by summarizing Adams's points here and sharing his alternatives.
Because sticky menus can have serious issues!


Sticky menus are used widely on the web but come with some serious issues. In this post I learned about the problems they cause and what to do instead.

The problem with sticky menus


Today I learned about the tool [Image Carbon](https://imagecarbon.com/). It's a
tool that helps you to calculate the carbon footprint of your websites images.

After entering a URL it will show you the amount of CO2 you could reduce by
optimizing your images. It can achieve that by uisng the
[Sustainable Web Design](https://sustainablewebdesign.org/calculating-digital-emissions/)
model.

It checks every image on your page for the format and the size and tells you how
you could improve on that.

Here are the results for my website:
[https://www.imagecarbon.com/sites/marcoheine.com](https://www.imagecarbon.com/sites/marcoheine.com)

Reducing your image sizes by compressing them and using better formats is not
only better for your websites performance but also for reducing the carbon
footprint.


Image Carbon is a tool that helps you to calculate the carbon footprint of your websites images

Image Carbon


As we all know, **the web is not accessible**, and that's a big bummer. A lot of
developers know way too less about accessibility, as we see if we look at the
HTML structure of websites, which often just consist of a ton of `divs.`

On the other hand, a lot of companies don't pay for or don't have the budget for
accessibility audits and improvements and the increased workload that comes with
building accessible websites.

It's our job as developers to **make accessibility a mandatory part of our
work** and create awareness for it. Sooner or later, new websites will have to
be accessible by law.

I'm not an expert in accessibility, but I'm trying to improve my knowledge of it
every day and with every new website or component I build.

Recently I built a modal dialog for a website, and here's everything I learned
and applied to make it accessible.

## Building accessible modal dialogs

There are a few key things to remember when building accessible modal dialogs.
First of all, we need to ensure that the modal dialog can be **accessed and
navigated with a keyboard only**.

Next, the **keyboard focus** should be managed properly. When opening the modal,
the focus should be on the first focusable element inside the dialog. This
enables keyboard users to navigate the modal dialog with the tab key right away.

Additionally, the elements behind the modal should be **hidden** from screen
readers and not be focusable so users who use assistive technologies don't get
lost in a sea of content.

To support this, the modal dialog should also be **full-screen on mobile**.

An obvious thing but often not implemented correctly is that the modal dialog
should be **closable with a certain close button** and also be able to be
**closed with the escape key**.

When you implement all of these things, you'll have a pretty accessible modal
dialog and help many of people who use assistive technologies to access your
content without any problems.

The important properties to enforce these things are the following:

### role="dialog"

First and foremost, if you're not using the
[html5 `<dialog>` element](#html5-dialog-element), you need to give your modal
dialog the `role="dialog"` attribute. This tells screen readers that the element
is a dialog and not just a regular div. The proper HTML element for your dialog
can be a `div` or a `section.`

### aria-modal="true"

You also need to give your modal dialog the `aria-modal="true"` attribute. This
tells screen readers that the dialog is modal and that the user needs to
interact with it before they can continue.

It also helps with getting lost in content, which I talked about earlier by
limiting the navigation to the modal dialog content and hiding elements in the
background.

### aria-labelledby and aria-describedby

Next, you need to give your modal dialog an `aria-labelledby` attribute with the
id of the title of the dialog. This tells screen readers which title belongs to
the dialog.

If you don't have a descriptive title element inside your modal dialog, you can
use the `aria-label` attribute instead.

If you have a description for your modal dialog, you can use the
`aria-describedby` attribute to tell screen readers which element contains the
description.

### aria-label="close modal"

Often, close buttons do not consist of descriptive text like "close". Instead,
icons, svgs, or images are used. In this case, you need to give the close button
the `aria-label="close modal"` attribute to tell screen readers what the button
does.

## What about the html5 dialog element? <a name="html5-dialog-element"></a>

There exists a new HTML5 element called `<dialog>.` It was introduced in
Chromium 37 back in 2014. Unfortunately,
[it's not yet widely supported by all browsers](https://caniuse.com/?search=dialog),
but we may be able to use it without any polyfills very soon. So if you're just
looking to support modern browsers, you can use it right now.

It then can be used instead of `role="dialog"` because it's the semantic html5
equivalent.

## Sources and further reading:

- [Technique: Accessible modal dialogs ](https://accessibility.huit.harvard.edu/technique-accessible-modal-dialogs)
- [Modal Dialog Example ](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/examples/dialog/)
- [The a11y Monthly: Making modals accessible](https://yoast.com/developer-blog/the-a11y-monthly-making-modals-accessible/)


Today I learned how to make modal dialogs accessible so that they can be used by people who use assistive technologies to navigate the web.

Building accessible modal dialogs


Filling forms can be an **annoying and painful user experience**, especially if
you're on mobile. If you've ever tried to fill a long form on your phone and the
inputs weren't set up correctly, you know what I'm talking about.

The wrong keyboard opens, and you have to switch to special characters or
numbers all the time.

But this can be made so much easier and user-friendly with some simple steps.
Using the right input type value for the input is the first and, in most cases,
the only step you need to take.

For example, `<input type="email" />` will open up the right virtual keyboard on
mobile. The same goes for `type="url"`, `type="tel"` or `type="number"`.

But there are more attributes you can offer to make the user experience even
better.

Big thanks to Jeremy for teaching me about these attributes in this great
article
[Three attributes for better web forms](https://adactio.com/journal/19842?skin=default).

### inputmode

Inputmode is an attribute that can tell the browser to show a **specific virtual
keyboard**. This is redundant if you've already set the type to
`email, tel, url` or `search`.

But if you have an Input with the type text and you want to tell your users to
enter numbers there, `inputmode="numeric"` is super helpful. You can even
enclose the input by using `pattern="[0-9]*"`.

The other possible values for `inputmode` are
`text, numeric, decimal, search, email, tel` and `url`.

To learn more about it, check out the
[MDN documentation for inputmode](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode).

### enterkeyhint

As explained above, the inputmode provides help to show the correct virtual
keyboard, whereas the `enterkeyhint` attribute provides help to specify what is
shown on the enter key on a virtual keyboard.

The possible values are `enter, done, go, next, previous, search, send`. This is
helpful in tailoring the user experience to the specific input. For Contact
forms, it's usually `send`, and for search forms, it's `search`.

Checkout the full documentation for
[enterkeyhint on MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/enterkeyhint).

### autocomplete

The autocomplete attribute is my favorite one. It doesn't specify the virtual
keyboard, like the previous attributes. Instead, it tells the browser that there
are values that could be used to pre-fill the Inputs.

This is such a great feature because it makes filling Forms a way more pleasant
experience.

There are several categories with different values you can use. For the `name`
category you can use
`given-name, additional-name, family-name, nickname, honorific-prefix, honorific-suffix`
and `username`. If you don't need to break it down into different parts, you can
use `name` itself.

The same goes for `tel` and `address`. Check out the available attributes on the
[MDN documentation of `autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete).

That's it; these are three awesome attributes you can use to make your forms
more user-friendly. I made a CodePen to showcase all the attributes explained in
this post. Check it out:

<CodePen
  id="wvEGPWK"
  title="Input Attributes for better Forms"
/>


Filling Forms on website can be an unnecessary pain. Recently I've learned about some simple steps to make Forms more user friendly.

Input Attributes for better Forms


Today I learned about the a11y project. As you might know a11y stands for accesibility. It has 11 characters that's where the short-hand name comes from.

The a11y project is a community-driven effort to make digital accesiblity easer. They provide a ton of information on their website: <a href="https://www.a11yproject.com/" target="_blank">the a11y project &#8599; </a>.

One of the greatest things they curate is a <a href="https://www.a11yproject.com/checklist/" target="_blank">checklist &#8599;</a>, where you can check your WCAG compliance. I'm gonna use this checklist for every new web project from now on. And it's a shame that I haven't used it before. 

Other than that they provide a big list of <a href="https://www.a11yproject.com/resources/" target="_blank">resources &#8599;</a>, be it books, newsletters, podcasts, talks, different tools or communities where you can participate to digital accessiblity.

So if you want to make the web more accessible, the a11y project seems to be a fantastic starting point to learn more about the fundamentals and principles of accessiblity.

a11y stands for accessibility - the a11y project is a community-driven effort to make digital accesibility easier

The a11y project


Writing good alt text is hard. I get it. But not having any alt text is the
worst you can do. It's still one of the most common accessibility issues on the
web.

In this [blog post](https://jakearchibald.com/2021/great-alt-text/) Jake
Archibald explains how to write great alt text.

The key take aways for great alt text are:

- the context matters
- describing the emotion is important
- not to be afraid of trying

Check out the blog post of Jake, to get better at writing alt texts. I
especially liked one sentence of him at the end:

> "[...] if you're trying to do the right thing, you're almost certainly
> improving the experience for real people."

I think that sums it up perfectly. Now go, write your alt texts!


In this post, I'll show how to write great alt text, according to Jake Archibald.

How to write great alt text


The web is **not accessible**. That’s not new, that’s not what I learned today.
But the amount of accessibility errors did surprise me.

The [WebAIM report](https://webaim.org/projects/million/) states over **50
million errors** in the top one million websites.

Today I learned that all of these errors are **the most basic accessibility
issue**, you can fix so easy:

- low text contrast,
- missing alternative text,
- empty links and buttons,
- missing form labels and missing languages.

Hidde wrote a fantastic blog post about it:
https://hidde.blog/common-a11y-issues/


Most common accessibility issues


To make sure you added an alt tag to all your images, you can set a specific CSS
rule, which highlights the images missing an alt tag.

```css
img:not([alt]) {
  filter: blur(5px);
}
```

Addy Osmani explains it on the Twitter Link below. Alt tags are necessary for
visual impaired users, who can not see an image but the screenreader can read
the alt tag to them. So if you leave it out, they have no chance to get any
information from it.

Learn more: https://twitter.com/addyosmani/status/1223873759213314050


Today I learned