Small steps towards better accessibility
Tags: webdev, a11y
Published: 2020-11-08 14:01:55

Here are easy things to do to improve a11y.

## Disclaimer

It's about getting started and how to enhance accessibility for your website easily. On no account it's a complete guide with expert's recommendations.

I share in the hope it's useful, but if you see anything wrong, do not hesitate to tell me.

## What is accessibility?

It's a fundamental right for everybody. 

You have to make sure that everybody, or at least as many people as possible, can browse your website no matter what.

Note that I'm not only referring to people with disabilities. I wrote "everybody" on purpose because accessibility does improve the web for all of us.

More pragmatically, the list of lawsuits involving websites that are not accessible has been expanding over the past few years.

It means that, legally, as developers or as designers (product owners too), you need to know what it is and use it.

## a11y?

a11y is an abbreviation for accessibility, 11 is the number of letters between "a" and "y".

It's a convention in the IT world when words are too long. They shorten names with the number of letters between the first and the last letters.

For example, i18n stands for Internationalization, and l10n means Localization.

## What does it mean?

Accessibility is a process. Suppose people with visual, hearing, mobility, or mobility impairments can easily browse your website and use your features, for example, through a screen reader or any text-to-speech tool. In that case, your website is globally better.

I think it's essential to introduce accessibility like that, and I don't want to mislead you with this post. You are not making your website, and after that, some polish for people with disabilities.

Besides, there are misbeliefs on this topic, and 100% accessibility is a chimera. 

However, small improvements are better than nothing, and some tips are super helpful, so here are easy things to do.

## Start with automatic tools and test it

It's neither bulletproof nor sufficient, but it's a good start. I began using npm packages such as [a11y](https://www.npmjs.com/package/netlify-plugin-a11y) to check what I do.

As I host my blog on Netlify, I can even install it from Netlify's interface and apply an accessibility check for each deployment!

> 11:11:11 PM: │ 2. onPostBuild command from netlify-plugin-a11y │

You can also run audits with free online tools such as [web.dev](https://web.dev/). Again, they are not the ultimate tools, but good starters.

##  Contrast ratio 

> The visual presentation of text and images of text has a contrast ratio of at least 4.5:1

>  to provide enough contrast between text and its background 

[Source](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html)

There are various tools to check the contrast. You can use, for example, [webaim.org](https://webaim.org/).

I recommend checking the dark mode too! I realized I was missing that point. My light theme was ok, but my dark theme was terrible, so I changed it.

Here are [my former (very bad) dark colors](https://webaim.org/resources/contrastchecker/?fcolor=222&bcolor=ccc)

Here are [my new dark colors](https://webaim.org/resources/contrastchecker/?fcolor=161E2E&bcolor=C3DDFD)

It's not just more compliant. It looks better now, and it's more comfortable for the eyes.

## Use some ARIA

I began using `aria-current="page"` for my menus and `aria-hidden="true"` for things that screen readers should skip.

`aria-current="page"` provides a more accessible way than using classes such as `.active` or `.current` to highlight the current page in the menu, and I still can style it with something like that:

```css
a[aria-current="page"] {}
```

Besides, I was using the following markup:

```html
<span class="separator">•</span>
```

It's not useful for assistive technology. It adds useless noise. Thus adding ARIA like that seems a better idea:

```html
<span class="separator" aria-hidden="true">•</span>
```

Be careful, though. Never use it on focusable elements.

These are not the only ARIA you can use, but it's a good start, IMHO.

[Source](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA)

## Don't use placeholders text as labels

One of the biggest mistakes you can make in your forms! If you don't use labels, screen readers may skip the text, and it becomes a nightmare to identify the purpose of the input.

As a result, don't do:

```html
<input type="text" name="name" placeholder="enter your name..." />
``` 

Do something like that instead:

```html
<label for="myinput">Enter you name</label>
<input id="myinput" type="text" name="name" />
``` 

## Allow keyboard navigation 

You can test your website keyboard navigation by using the tab key. It should give you a good overview.

I like to style the focus state almost the same as the hover state, so the tab navigation is smooth.

However, remove invisible focusable elements, for example, if you have elements like inactive drop-down menus or off-screen navigations.

## Reduce animations and motion

I know it's cool to have fancy animations and stuff. The good news is you don't have to lose it.

Just include the following rule in your stylesheet:

```css
@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}
```
This way, people that choose to reduce motion will have a much better experience.

I like to include it in my reset rules as it's the right candidate for general CSS instructions.

## Misbeliefs and wrong moves

It occurred to me that a lot of so-called accessibility tips are misunderstood or misused.

### Don't be overzealous with the semantic

Using semantics is also one of the best practices. It means that if you have a semantic element in HTML5 for a specific use, it's better than using div all the time. `<header>` for header, `<nav>` for nav, `<aside>` for non essential contents, `<footer>` for the footer etc.

For example, `<main></main>` is much better than `<div id="main"></div>`. It's even better than `<div role="main"></div>`.

BUT, and I've already seen that, don't use `<main role="main"></main>`. It's redundant.

### Be careful with dark modes

I know it's a must-have feature those days, and don't get me wrong, it's a great feature, but it seems we make mistakes with this mode.

I'm still exploring this aspect, but it's easy to forget conventions as far as I know. One line Dark Mode using CSS is tempting, but it's inaccessible.

### Alternative texts for images

It's probably the most misused accessibility element. You know screen readers do not see images. It's the same for search bots. Adding the right `alt` attributes to your image is not only suitable for blind people. Even if it's not a decisive element, it can boost your SEO.

First, you must add an `alt` attribute to all images, even if it's empty. But, better empty than wrong!

To write appropriate, you may use the following checklist:

* describe the image with pertinent keywords
* make sure it is unique as every single image is unique
* limit chars. Be concise.
* pure decorative images for design should have an empty alt
* [read the full description of alt attributes on WAI](https://www.w3.org/WAI/WCAG21/quickref/#non-text-content)

## Make sense of everything

I hope you like this post. If there is one thing you should keep in mind, all those checks and tips allowed me to visually and semantically improve my websites, so it adds value.

Even if online audits told me "100%" in the accessibility part, there were (and there are) still many things to do, so it's a good start, but it's neither the ultimate score nor an a11y certificate.