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

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 guide on how to write a custom HTML parser. There is a lot of stuff at stake.

Rename a .md file into .md.html with a reference to a js script, and this file is displayed properly in a webpage :)

How to make this better with little css.
Inherit font-size, line-height, word-spacing, border and padding.

There are also

• Under-Engineered Select Menus
• Under-Engineered Custom Radio Buttons and Checkboxen

Store content that should be accessible. If the content should be seen or read on a page, don’t only put them in data attributes, but make sure that content is in the HTML content somewhere.

A use case is to style components based on their data attribute values.

Data attributes can be accessed in JS with tag.dataset.attributeName. It can also store JSON.

An HTML and CSS only tree.
The final CSS-snippet is also available at the end.

It uses only <ul>, <li>,

Build HTML elements visually

Source code: https://github.com/components-ai/css.gui

Different loading hints:

• async resource is loaded when the browser can
• defer resource is loaded when the DOM is parsed (less priority than async)
• rel=preload load the resource before the parsing and everything else
• fetchpriority with value high, low and auto. They are hints.
• rel=preconnect indicates that a connexion has to be established ASAP.
• rel=dns-prefetch resolves the domain name without fetching the resource.
• loading attribute determine when an image is loaded depending of its value:
  • eager: the image is loaded immediately
  • lazy: the loading is delayed until the user scroll to it.

This is in large part because HTML is a limited hypertext. In particular:

• Only <a> and <form> can make HTTP requests
• Only click & submit events can trigger them
• Only GET & POST HTTP Methods are widely available
• A request must replace the entire screen, leading to a clunky and sometimes jarring user experience

To the last point: the transition API is on its way :)

Je suis twitter et exige ma carte pour chaque lien partageable.

Autant faire un standard !

It’s crazy to think how much bandwidth is being used by metadata tags.

and how much of these are used by the client...