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?

Browser support is increasing

<figure>
 <blockquote>
  <p>The truth may be puzzling. It may take some work to grapple with.
  It may be counterintuitive. It may contradict deeply held
  prejudices. It may not be consonant with what we desperately want to
  be true. But our preferences do not determine what's true. We have a
  method, and that method helps us to reach not absolute truth, only
  asymptotic approaches to the truth — never there, just closer
  and closer, always finding vast new oceans of undiscovered
  possibilities. Cleverly designed experiments are the key.</p>
 </blockquote>
 <figcaption>Carl Sagan, in "<cite>Wonder and Skepticism</cite>", from
 the <cite>Skeptical Inquirer</cite> Volume 19, Issue 1 (January-February
 1995)</figcaption>
</figure>

For pull quotes, use an <aside> instead.

Paperwork, documents created, screenshots taken, bookmarked web pages, video and audio files.

Each gets a website.

These websites aren’t complicated – they’re just meant to be a slightly nicer way of browsing files than I get in the macOS Finder.

Each collection is a folder on my local disk, and the website is one or more HTML files in the root of that folder. To use the website, I open the HTML files in my web browser.

I’m deliberately going low-scale, low-tech. There’s no web server, no build system, no dependencies, and no JavaScript frameworks. I’m writing everything by hand, which is very manageable for small projects. Each website is a few hundred lines of code at most.

These are created and curated by hand.

I think this could be a powerful idea for digital preservation, as a way to describe born-digital archives.

A minimal table editor :)

1.

In HTML5,

content “must be quoted from another source”

Heydon rightly makes the distinction between block quotes, which (supposedly) quote another source, and pull-quotes, which highlight excerpts from the article you’re reading.

2. No <cite> in <blockquote>

Heydon suggests using a <figure> and <figcaption> to invoke this grouping, which seems the most sensible option.

The <blockquote> cite attribute is generally useless since it’s invisible and most screen readers also ignore it

3. For inline (or “text-level”) quotations, there is <q> instead.

4. HTML is hard

But the developers have no consequences on that.

Build HTML first, then CSS, then JS.

Building your service using progressive enhancement will:

• ensure your service is robust and of a high quality
• make it more likely your service will work regardless of which browser or device is being used
• mean your service’s most basic functionality will work and meet the core needs of the user
• improve accessibility by encouraging best practices like writing semantic markup help users with device or connectivity limitations to use your service

and arguments against SPA.

HTML isn’t only for people working in the tech field. It’s for anybody, the way documents are for anybody. HTML is just another type of document. A very special one—the one the web is built on.

Resources and more about HTML for People: https://htmlforpeople.com/achievement-unlocked-hypertexter/#resources-from-this-book

HTML carry the semantic, so the bdi element indicates how to read its content: left to right or right to left.

Great website design BTW https://heydonworks.com/latest/

Different definition of a UI component, from the minimalistic css one to the SSR full page.