A great TLDR

On single-purpose pages containing forms.

Such as login, signup, password reset or 2FA pages.

There are some cases to avoid such as a login form with the use of social logins (Google, GitHub, and the like) and you don't know which one they'll use don't add an autofocus.

There are many approaches.
One solution is to set the color-schema CSS property color-scheme: light dark; then use the light-dark function.

But did you know that you can also set the media attribute to conditionally load and apply CSS based on user preferences? Such as media="(prefers-color-scheme: light)"

This media attribute can also be set in JS too, in order to load the proper stylesheet.

Instead of an isOpen class, why not using aria-expanded="true" (except for <details)?

Why and caveats of aria-labelledby a tag in the node content.

There are good reasons to point aria-labelledby within an element. For example, to give an accessible name to a region based off of the heading within it.

A progressive enhancement with view-transition

<meta http-equiv="refresh" content="1"> for simple web pages.

The Nu HTML validator is recommended. There is also the html-validate for partial validation

• Select all non-summary children of a <dialog> with ::details-content
• appearance: base-select for <select> to customize it
• <dialog> can be closed with method="dialog" on a form.
• Popover is here too
• input type="checkbox" can now have a switch attribute. See the smashing magazine. It has very limited support currently.
• A <search> tag is available for 90% of the users

The author describes 3 states for search option buttons:

1. Disregarded in search results
2. must include it
3. must exclude it

There is three input radio buttons to implement the state.

aria-label and aria-labelledby aren’t permitted on these elements. They are intended for interactive elements (buttons, links, form controls) and landmark regions.

The author provides the HTML elements that are not allowed to have an aria-label or aria-labelledby.

VoiceOver generally announce the contents of the aria-label. That aria-label “works” on generic elements in VoiceOver is a nonstandard remediation of noncompliant code, not an endorsement of a technique working as intended.

The author provides multiple HTML patterns to avoid the use of aria-label in the first place! Great!

• Was the Label Addressing a Problem Worth Solving in the First Place?
• Use visible text
• Use Visually-Hidden Text
• Use More Semantically Applicable Elements
• Add an Applicable Role

What is accessible for an accessible button.

In short:

• Anchors (links) are for navigating within the current document (page) or to another one.
• The dedicated "submit" and "reset" buttons are for specific form actions.
• Regular buttons are for (JavaScript) actions.
• Links can be styled to look like buttons and vice versa.

Link for navigation.
Buttons for actions.

"Look and feel" can be adjusted in CSS anyway...

How to create accessible spoilers without JS? Well it's a tradeoff.

When a link is activated for a navigation, a POST request can be sent at the same time.

I didn't know it, and you can find a short explanation on MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#ping

HTML webpages as reactive notebooks

.setCustomValidity()

Why whitespace is confusing?