So the question is, when you have done everything "right" in your attempt to do the right thing and it still doesn't work, at what point do you give up and when do you push on and try to make it right?

What to do?

1. Do nothing (and it degrades user experience for years until a fix is made)
2. Suggest an alternative (and it takes years to fix to go through the roadmap)
3. Work around it
4. Engineer a solution

Use accessibility APIs of OSes that contains building blocks. These building blocks have 3 kinds of information about a UI element.

The first is a role: What kind of element is this?
The second is a name: a label or an identifier for this element.
The third is state and other properties: Other functional aspects of an element that would be relevant for a user or an assistive technology to be aware of. Is a checkbox checked or unchecked, etc...

It looks like ARIA, oh wait!

The web browsers now expose this accessibility tree.

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