
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


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


Last year I subscribed to the <a href="https://www.smashingmagazine.com/the-smashing-newsletter/" target="_blank">Smashing Magazine Newsletter &#8599; </a>, and it was a great decision. The authors share **useful front-end & UX bits** once a week, and I could always learn something from them or find something interesting. 

In a recent<a href="https://mailchi.mp/smashingmagazine.com/your-interface-design-patterns-ux-training-final-details-1134401?e=c15e5575ff" target="_blank"> edition &#8599;</a> they shared what **frustrates** users the most, but also what **delights** them the most. 

The key takeaways by the authors concerning the frustrations were that **users generally don't trust websites**. They are most frustrated by pop-ups, modals, push notifications, access to camera/microphone/photos, or install app prompts. 

The authors derive from that that many users see websites as **unfriendly** and **hostile** and therefore see a need to block everything that a website wants from them. 

That is understandable. However, a lot of website opening experiences today could be better. Often before you can even start to consume the content, you get asked to allow cookies, subscribe to the newsletter, and allow push notifications; please disable your ad blocker and better install their native app.

It's our job as people who make websites to do better and try to make them friendly and trustworthy again.

But not everything is terrible. Users are delighted by a calm, fast and accessible experience. They like it when the text and the input elements are large and when they get helpful error messages. In general, users are delighted **when they are in control** and when a website is easy to use and does what they expect it to do.

This State of Usability shows a lot of great insights. It shows what not to do if you don't want to frustrate your users and what to do to make your users happy about the experience of visiting your website.

Today I learned about the State of Usability in 2023