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

The lack of tone, diversity of cultures, and the fact that many people using social media in English aren't native speakers make it all harder to detect irony and serious-sounding jokes online.

Please be careful and make sure your jokes don't end up feeding the disinformation machine, even if you feel it's obvious to you. In doubt, at least use the popular markers "/s" (sarcastic) or "/j" (joke) or parentheses at the end to make this clearer.

Make implicit explicit, especially in this age of disinformation and AI slop.

JAWS
NVDA
Narrator
Orca
Talkback
VoiceOVer
*accessibility is not only about screen readers