Similar to microdata.

Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards. Instead of throwing away what works today, microformats intend to solve simpler problems first by adapting to current behaviors and usage patterns. - https://microformats.org/wiki/about

What is the difference between microformats and microdata? It seems that microdata is an extension of microformats. Also microdata is meant for HTML5, whereas microformats is meant for everything.

How to make an accessible skeleton with ARIA ?

Note that the skeleton pattern hides a bad design where the UI is slower than expected. So avoid it as much as possible.

Microdata is used to nest metadata within existing content on web pages: for example, a list of persons.

To create an item, such as a person, the itemscope attribute is used.
To add a property to an item, the itemprop attribute is used on one of the item's descendants.

1. Check if the image really needs a description. Maybe it is decorative. The W3C alt decision tree(opens in a new tab) is an excellent resource to help you categorize your photos.
2. Avoid writing "Image of", "Icon of", or "Picture of". Screen readers announce the presence of an image. Adding these words inside your alt is unnecessary.
3. Keep it as short as possible. Be specific but not overly descriptive.
4. Try to put the most essential information at the beginning of your description.

A first approach of ARIA with a toggle button

Because it is possible, someone mare a page with every HTML tags in it.

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.

A disabled link is not a link, its just text. You need to really need to rethink your design if it calls for disabling a link.

The href attribute on a and area elements is not required; when those elements do not have href attributes they do not create hyperlinks. - W3C, Hyperlink spec

and how to build a disabled link... the hard way

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.

RSS reader does not load styles and relies on HTML semantic!

A button style-reset in CSS:

button {
  display: inline-block;
  border: none;
  margin: 0;
  padding: 0;
  font-family: sans-serif;
  font-size: 1rem;
  line-height: 1;
  background: transparent;
  -webkit-appearance: none;
}

and again: link for content and button for actions!

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;
}

Basic validation can be done with HTML/CSS and the CSS selector :user-valid or :user-invalid pseudo-selectors

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...

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.

Everything that does not have to be JS anymore, and there is a lot !

I didn't know about the accesskey attribute :)

An ode to know HTML

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