In a form, the user gets the screen reader navigation capabilities. The tab key becomes the norm again, and all that helps without aria is then the <label for=""> each input.

aria-label, aria-labelledby, and aria-describedby can all be used to bring extra clarity to a given element when it's exposed to assistive technology.

• aria-label overrides an element's name with contents you specify.
• aria-labelledby replaces an element's name with contents from another node on the page. You'd use this when you'd already have a visible label anyways.
• aria-describedby sets your element's description to the contents of another node on the page. This is great for noncritical, supplemental information.
• aria-description… is coming.

As always, avoid ARIA whenever possible.

Using a description list dl with description terms dt and their description detail dd: so basically a list of key - value pairs.

Advangtages for screen readers instead of divs:

1. The screenreader could tell the user how many name–value groups are in the list.
2. The screenreader could tell the user how far into the list they are.
3. he screenreader could treat the list as one block that the user could skip over if they're uninterested in it.

In the meantime:

.visually-hidden:not(:focus):not(:active) {
  border: 0;
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

It is when you start to not be fully able that

Through all of it, I’ve found myself noticing “accessibility” helpers more than ever before: that railing on the stairs, that ramp off to the side of the building, that elevator tucked away in the back.

1 in 5 people currently have a disability. 100% of people will have some form of disability in their lifetime.

To annotate accessibility features on mockups. Discovered from https://adhoc.team/2023/06/28/become-an-accessibility-champion-by-using-simple-mockup-annotations/

An argument in favor of emoji instead of raw ASCII ones:

There are a lot of blind people on here, who use screen reader software to tell them what is on the screen. To help screen reader users, it's a good idea to use emoji rather than old-style smileys.

For example 😄 will be read out loud as "smile" because that's its alt text. However, :D will be read out loud as "colon D".

It's a growing directory of tools, articles, books, podcasts, and other learning resources to guide us in creating more ethical and more inclusive products.

To favorise:

• checkbox
• file
• hidden
• radio
• password
• text

To avoid:

• button
• date
• datetime-local
• email
• month
• number
• reset
• search
• submit
• time
• week

The rest is not sure or evident...

If a state is important enough to indicate visually, it's probably important enough to expose to assistive technologies.

With an example such as <a href="/about" aria-current="page" class="current-page">, we now have two meanings that convey the same information: the aria attribute and the class. This can leads to bugs while refactoring.

Another example is provided with dropdowns or toggle buttons, and sorted table columns.
Mentions to :disabled or aria-disabled, :invalid or aria-invalid, aria-selected, role="tab", and the list can go on!

You need to be using the appropriate elements (s are your friend!), and managing the appropriate attributes and their values to make truly accessible user experiences.

The idea: uses CSS to detect accessibility issues.

The author uses different code snippets for it. One ensures the outline of the focus is never clipped. Another makes sure that not expanded content (aria-exanded="false") is not displayed. Another one targets aria-invalid elements. A busy container is not displayed in CSS, etc...

Every time you come up with a style that reflects a state or property of something (open, closed, expanded, collapsed, on, off, checked, disabled, busy, locked, selected, sobbing uncontrollably), do not use a class.

And an argument against utility-classes such as Tailwind: If you use these tools, you still need to know CSS. On top of that, you may need to know the tools’ syntax in order to incorporate any CSS that goes beyond what they offer. If you build these tools, please consider how you can use CSS that promotes and reinforces good and accessible underlying HTML syntax.

It provide a good example: this semantic HTML

<button
  id="navbar-toggle"
  type="button"
  aria-label="Toggle menu"
  aria-controls="navbar-menu"
  aria-expanded="true"
></button>
<ul id="navbar-menu" aria-labelledby="navbar-toggle"></ul>

should be styled as follow in CSS

/* State: closed. Click to open. */
#navbar-toggle[aria-expanded="false"] {}

/* State: open. Click to close. */
#navbar-toggle[aria-expanded="true"] {}

Just as before, it turns out that the class name was completely redundant. In fact, because we reached for a class name prematurely, we forgot to communicate the right semantics at the markup level.

It generated 2 colors that have an accessible contrast with each other

As it turns out, links are not focusable in Safari if they have 0 dimensions. Adding 1px padding, border, or width and height fixes the issue.

Une bonne introduction à l'accessibilité web