The author provides an history about the base, reset ,normalize and classless stylesheets.

The page itself is a demo of base.css, a classless stylesheet, and document itself.

Each topic is covered by a description, the rules and the relying css implementation. Each rule is well meant for accessibility such as "You should read a caption without having to scrol". It starts with the CSS Properties.

Use CSS properties for customization. There is the root style rules:

1. Set customization options on the the root element for all elements
2. Use native properties for font family and font size options.a
3. For font size, CSS has font relative units to create variations from the root or parent value.
4. For font family, it's useless to use custom property. Its value, a string value, can't create variations. Variation of font family would be by, if possible, using font variant alternates. a
5. Use custom property for line height. This maintains unitless value while creating automatic variations for blocks. b
6. Use custom property for pseudo content. This enables fallback trick for its native counterpart. c
7. Use custom property for the others due to lack of native properties. d
8. Prevent adjustments of font size orientation changes in iOS
9. Remove padding and margin, use box model of border box, and inherit color and font on all elements.

The library defines carefully the font-family, font-size, line-height, line-length, color, styles, blocks, mixes and phrases.

A font family declaration is a set of typefaces to create safer designs. Using multiple typefaces requires a sound knowledge of type pairings: space, type (sans, serif, cursive), wight, width, style normal and italic, cases: smalls, caps and smapp caps, roles: caption, body and display.

Font-sizes are defined with the em unit and relative calculations based on a --font-scale value.

The line height is computed based on the element around it. For example the paragraph following a hgroup with a heading. It creates a cohesive design.
All line height are derived from a --line-height value.

To respect the support of dark and light mode, developers must use the light-dark() function. Prefer human-based color mdoels such as LCH or OKLCH. The primary color component is Hue. Lightness and Chroma creates variations. Variations for one hue is a monochromatic pallete; for 2 hues is diadic; for 3 hues is triadic; and so on. CSS can programmatically create a live pallete from one hue using calc(). A 90deg deviation creates a complementary scheme; a type of diadic.

The web is filled with unsemantic styles: the absence of styles, the misuse of styles, the lack of unique styles. This can be seen through the lens of base stylesheets, as of writing.
All components — blocks, mixes, and phrases of media and forms — should have unique styles.

Blocks define region in the HTML document. Subsections uses one _ for each nesting level.

Mixes use all-round borders to define the boundary of their content

Phrases is all about content and forms. They are inline content, so their block content is maintained within a line height. Each phrase is clearly identified

The same content can create clarity for one person and confusion, stress, or exclusion for another, without changing a single word.

Accessibility is a must. Here are some examples

1. When color disappears completely

• Buttons that look clickable even without color
• Links that are underlined or styled consistently
• Hierarchy created through spacing, borders, size, and structure

2. When nice colors choices stop working

• Contrast that survives more than one type of vision
• Less reliance on subtle color differences
• Clear affordances that don’t depend on perfect perception

3. The most color blindness is ignored

• Meaning that survives without red or green
• Icons, labels, or position reinforcing importance
• Safer decisions and faster understanding

4. When text becomes slightly blurry

• Text that stays readable when slightly blurred
• Comfortable line height and spacing
• Zoom that doesn’t punish the layout

5. When you can only see a small part of the screen

• Clear headings that anchor the page#
• Logical reading order
• Visible focus states that guide navigation

7. When letters won't stay still (dyslexia)

• predictable layouts
• plain, calm language
• no uneccessary visual tricks

8. When language stops making sense

• plain language
• clear labels
• information that unfolds gradually, not all at once

a thing you absolutely cannot do is nest one interactive control inside another

it has few examples.

On the contrary:

• disabilities can be invisible
• disabilities can be temporary
• accessibility features benefit everyone
• people with disabilities are normal
• people with disabilities are underestimated (for profits, as workforce)

While meant as a compliment, this kind of praise treats disability as something extraordinary that must be constantly overcome.

1. Keyboard accessibility
2. Accessible design tokens
3. Named control
4. Zoom and user preferences
5. Screen reader compatibitlity

Acessibility wurde hier betrachtet:

• alle Bilder mit Alt-Text
• korrekte Gliederung
• Formularfelder alle mit Label und Name
• <noscript> Hinweis wo er nötig war
• keine Cookies
• Kontraste geprüft
• Alternativtext für eine Grafik, die anstelle dieser eingeblendet wird

Some people care about it!

A list of tools: audit bookmarklets, HTML De-crapulator, Role Reverser, Diagnostic CSS files

Documents will be available in HTML!

Baseline acts as a flag that tells this feature is supported across browsers.

But there is a few critics:

• Baseline doesn’t take all the browsers they need to support into account
• The safest Baseline stage — Baseline Widely Available — doesn’t cover old enough browser versions, which they still support
• Baseline says nothing about whether a web feature comes with accessibility challenges or no
• Baseline doesn’t tell web developers if it is OK to use a feature that’s not Baseline yet, perhaps as a progressive enhancement, or by using a polyfill.

Here are the definition of a traffic light-style:

• Not Baseline, if a feature is not yet supported on Chrome (desktop and Android), Safari (macOS and iOS), Edge, Firefox (desktop and Android)
• Baseline Newly Available, if it’s supported on the above browsers
• Baseline Widely Available, if it’s been supported on the above browsers for more than 2.5 years

Perfecting baseline: accessibility, flag progressive enhancement, polyfills and best practices; extend browsers and browsers versions to allow configure which (other) browsers should be taken into account.

Not read yet.

If JS fails to load, a keyframe remove the effect provided by JS in 2 seconds.

Misconceptions:

1. only blind people use screen readers
2. people use screen readers in the same way
3. all screen readers work in the same way
4. building a screen reader specific version of a website or app is a good idea
5. screen reader users don't care about images
6. screen reader users need instructions on all content
7. all content must be focusable to work with screen readers

The overlays for accessibility are often wrong.

One way sighted people can determine what to put in alt text: Imagine you sent the post or article to a friend, and the image didn't load. What would someone need to know to get the equivalent experience and context? This will help you identify the important details.

Under accessibility, but this tag should be the norm

<output> is currently underused in so many SPAs and apps, because it announces