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

More keyboard shortcuts for Voiceover

Getting started with VoiceOver in 5 commands

L'accessibilité universelle est un principe montrant que rendre un service accessible aux personnes porteuses de handicap est bénéfique pour tous les utilisateurs. Par exemple, utiliser une taille de police de 16 pixels minimum est nécessaire pour les personnes qui ont de la difficulté à voir, mais rendra aussi le contenu plus facilement lisible pour tout le monde.

Comme la situation de handicap peut aussi être temporaire, cela profite aux personnes qui sont temporairement handicapées, comme après un accident par exemple.

Simplifier le langage permettra à plus de personnes de profiter du contenu.

Se baser sur les statistiques d'utilisation de l'application peut être trompeur. En effet, seules les personnes qui auront pu surmonter les différentes épreuves pour arriver jusqu'au contenu apparaîtront dans ces statistiques.

Ce n'est pas à la personne qui utilise votre service qu'appartient la responsabilité de formater des données que vous souhaitez enregistrer en base de données. Par exemple, les messages du type "Entrez votre numéro de téléphone sans tirets" devraient être remplacés par un retrait automatique de ces caractères dans le champ.

Utiliser du HTML sémantique.

Il s'ensuit ensuite d'une liste de recommandations que je connais déjà bien personnellement.

"Understanding and making sense of data is stressful anyway, but in a pandemic, it’s worse." from accessiblenumbers.com/explain-

It's the best online resource I've found so far about accessibility of numbers. I also find practical that nearly every sentence has a link to check the resource in-depth. It can lack good examples though. What should be written instead of the currently hard to read raw number?

A checklist about accessibility. It ensures that the website follows some standards. The demo (https://www.magentaa11y.com/demos/) definitely help in order to follow these.

Most of the time, your job with JavaScript to enhance components’ keyboard accessibility will be done with just a handful of tools, including the use of event listeners and certain JavaScript methods of a couple of Web APIs that can help us in this task.

• keydown event: Instead, the utility of the keydown event comes when you need to add functionality to other keys [than enter or space].
• blur event: most of the time, you’ll use it to reverse the possible changes you have made with the keydown event listener.
• focus event (rare), but instead the focus method!
• button.inert works and avoid a setAttribute.

#idea #project #vue: create a directive to handle keydown and blur event into one action that is reversible.

So now we can have a look at component patterns:

• toggletips
• tabs
• modals

A guide to primary navigation on the related HTML tags. About HTML, inert and tabindex are explained.

For CSS, an optimal focus indicator is explained. There are also :focus-within and :focus-visible.

Finally some patterns such as Accordion, Tooltips and skip links are explained.

A perfect extension to audit web pages about RGAA/WCAG 2.0

Why permanent accessibility plugins are problematic?

Here are some reasons.