
Recently, I started Sara Soueidan’s course
[Practical Accessibility](https://practical-accessibility.today/). In one of the
first chapters, she talks about **assistive technology**, the different types of
it, and how they’re used.

She suggests heading to the Tetralogical website to watch their videos about
[how people with disabilities use assistive technology to browse a website](https://tetralogical.com/blog/2021/12/24/browsing-with-assistive-technology-videos/).
Of course, I’ve heard of **screen readers** before and already used one to
browse a website. I’ve also used my **keyboard to navigate on a page**.

But their videos show even more assistive technology in usage, like **screen
magnifiers** and **speech recognition**. I recommend heading over there and
watching their videos.

I’ve learned a ton. It helps so much with **building accessible and inclusive
user experiences**, and I always think about it whenever I build a new feature
on a website.


Today I learned a lot about browsing the web with assistive technology by watching the videos from Tetralogical.

Browsing with assistive technology


The new generic `search` element is now available in
[Chrome 118, Edge 118, Safari 17.0 and Firefox 118](https://caniuse.com/mdn-html_elements_search).
It still lacks support on some mobile browsers, but it's now available in **all
modern browsers**!

Did you hear about the HTML search element? No problem, me neither until today!
Let me quote the
[MDN documentation](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/search):

> The search HTML element is a container representing the parts of the document
> or application with form controls or other content related to performing a
> search or filtering operation. The search element semantically identifies the
> purpose of the element's contents as having search or filtering capabilities.
> The search or filtering functionality can be for the website or application,
> the current web page or document, or the entire Internet or subsection
> thereof.

So, it's a correct semantic wrapper for search forms. When using it, there is no
need to add a `role="search"` to a form anymore.

It's also important to note that the search element should not be used for
presenting search results.

Here's a simple example:

```html
<header>
  <h1>Search for recipes</h1>
  <search>
    <form
      action="/search"
      method="get"
    >
      <label for="recipes">Search for recipes</label>
      <input
        type="search"
        id="recipes"
        name="recipes"
      />
      <button type="submit">Search</button>
    </form>
  </search>
</header>
```

It's so great to see that the web is evolving and that we get new elements like
this is to improve the **semantics** and **accessibility** of our websites and
applications.


The HTML Search Element is a new semantic element that can be used as a container for the parts of the document related to performing a search or filtering operation.

The HTML Search Element


The
[Sustainability Web Design Community Group](https://www.w3.org/community/sustyweb/)
announced the
[Web Sustainability Guidelines](https://www.w3.org/blog/2023/introducing-web-sustainability-guidelines/).
It’s all about _“how to design and implement digital products and services that
put people and the planet first.”_

> This guideline provides best practices and recommendations for reducing the
> environmental impact of web development and design, such as minimizing data
> transfer, optimizing images, using green hosting, and more.

The climate crisis is a real threat, and it’s fantastic that people exist who
care to share their ideas on **how to reduce the impact of our industry**. If
you’ve thought the internet is not a part of the problem, think again.

We are responsible for _“2-5% of global emissions, more than the aviation
industry”._ I want to quote some actions from the
[Web Sustainability Guidelines](https://w3c.github.io/sustyweb/) you can take
immediately to participate in this.

- Minify Your HTML, CSS, And JavaScript
- Avoid Code Duplication
- EnsureYour Solutions Are Accessible
- Use HTML Elements Correctly
- Choose A SustainableHosting Provider
- Optimize Browser Caching
- Be Mindful Of Duplicate Data.

These are just a few suggestions tailored to a **more environmental friendly
web**. The list is long, and I’m sure everybody will find something they can
apply there. The key takeaway I get from this is **anything you already do to
improve the accessibility of your website and the loading performance is also
good for the environment**.

If you’re interested in sustainable web design, check out
[https://sustainablewebdesign.org/](https://sustainablewebdesign.org/), listed
as the **Implementation** of the Web Sustainability Guidelines.


The Sustainability Web Design Community Group announced the Web Sustainability Guidelines. It’s all about “how to design and implement digital products and services that put people and the planet first.”

Web Sustainability Guidelines


This is technically not a "Today I learned" post because I already knew that
knowing semantic HTML is important. This post is more of a reminder to myself
and others that HTML is still the most important language to learn.

So today, I learned that learning and knowing semantic HTML is still important.

Every developer saw these websites where the DOM consists of a bunch of `div`s
and maybe even worked on a website like that themselves. I know I did. And I
wasn't proud of it. But thankfully, we can do better.

This week I stumbled over two blog posts. The first one is
[I'm betting on HTML](https://catskull.net/html.html), which highlights their
favorite HTML elements. The second one is
[A Blog Post With Every HTML Element](https://www.patrickweaver.net/blog/a-blog-post-with-every-html-element/)
by Patrick Weaver in which, as the title says, he uses every HTML element in a
blog post.

I'd like to share my favorite parts of these blog posts here, so let's jump
right in.

The range of input types is amazing. You get so much functionality without any
JavaScript.

### Different input types

<label htmlFor="color">Color:</label>
<input
  id="color"
  type="color"
/>

{' '}

<br />
<label htmlFor="date">Date:</label>
<input
  type="date"
  id="date"
/>
<br />
<label htmlFor="datetime-local">Datetime-local:</label>
<input
  type="datetime-local"
  id="datetime-local"
/>
<br />
<label htmlFor="range">Range:</label>
<input
  type="range"
  id="range"
/>

Built-in datepickers? Come on! Everyone who has ever built a datepicker knows
how much work it is to make it accessible and usable. And here we have it for
free.

### Meter

The `meter` element is also pretty cool.

<meter value="0.5">50%</meter>
<meter value="0.75">75%</meter>
<meter value="1">100%</meter>

Firefox shows them all as green, but Safari shows them as red, yellow, and green
depending on the value.

### Progress

And of course, the `progress` element.

<label htmlFor="progress">Progress:</label>
<progress
  id="progress"
  value="0.85"
>
  85%
</progress>

Make sure you use a label for it. Otherwise, it's not accessible.

### Mark

I've worked with JS libraries just to highlight some text. Did you know that's
possible with HTML? I didn't. What a shame.

<mark>highlighted text</mark>

Quick and reasy way to highlight text without any JS.

### Differences between elements

The difference between `strong` and `b` is also interesting. `strong` is for the
meaning of the text and `b` is for the presentation. So use `strong` if you want
to emphasize the text and `b` if you want to make it bold.

I think the same goes for `em` and `i`. `em` is for single words, and `i` is for
phrases.

### Samp

Have you ever used `samp`? I haven't. I didn't even know it existed until I read
Patrick's blog post. It's used to render the output of a computer program. I
always used `code` for that.

<figure className="flex flex-col">
  <figcaption>A little JavaScript program:</figcaption>
  <code>const name = 'Patrick'</code>
  <code>console.log(`Hello ${name}!`);</code>
  <samp>Hello Patrick!</samp>
</figure>

Looks all the same but the last line is rendered as `samp` instead of `code`.

### Wbr

Another one I have never heard before is `wbr`. It's used to tell the browser
where it can break long words. It's a gread thing to use for long URLs. The
points where it breaks are more clear which makes it more readable compared to
not using `wbr`.

These were the highlights of my weekly HTML digest. I strongly recommend reading
both mentioned blog posts above because they cover a lot more than I did here.

## Sources

- [I'm betting on HTML](https://catskull.net/html.html)
- [A Blog Post With Every HTML Element by Patrick Weaver](https://www.patrickweaver.net/blog/a-blog-post-with-every-html-element/)

- [Color](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/color)
- [Date](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/date)
- [Datetime-local](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/datetime-local)
- [Range](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/range)
- [Meter](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meter)
- [Progress](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/progress)
- [Mark](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/mark)
- [Samp](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/samp)


Learn HTML! It is still the foundation of the web and the most important language to learn.

Learn HTML


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