AI can build a website in minutes. It must start with better defaults.

These days, AI tools can build a website in minutes.

That's useful, but it also means that bad design patterns reproduce even faster.

Tiny gray text on black backgrounds. Ten pixel helper copy. Display fonts used in centered paragraphs. Links that barely look like links. Divs pretending to be buttons. Form fields that browsers cannot identify properly. Lazily waving gradients underneath text.

Not a single one of these problems is new; AI just gives them a much larger distribution system.

The following is not a proposal for perfect accessibility (there's no such thing). It is a smaller ask:

When there is an easy, robust, readable way to build something, let's make that the default.

I’m calling this approach Humane by Default.

Accessibility discussions often jump straight to screen readers. Screen readers matter, but the underlying idea is much broader.

Lots of people regularly use browser narration, Reader Mode, translation tools, zoom, voice control, autofill, password managers, captions, keyboard navigation, and other assistive features without identifying as disabled or even thinking of those features as accessibility tools.

Well-structured websites give all of those systems, and others that we haven't even imagined yet, a solid foundation to work with.

Good defaults also benefit people in temporary or ordinary situations: using a phone one-handed, reading in glaring sun, working on an old display, dealing with an injured hand, listening instead of reading, or simply being tired.

Accessibility, at its core, is good engineering meeting real human variability.

A visual pattern has taken over respected software products: dark backgrounds, skinny sans serif type, tiny uppercase labels, translucent cards, slowly drifting gradients. People read it as modern, sophisticated, or technical. Then other designers imitate it and AI tools learn from it and generate thousands more interfaces in the same style, which makes the pattern look even more standard and gives future tools still more examples to copy.

The default perpetuates itself.

That's why the highest leverage intervention is upstream. No individual user should need to understand typography, semantics, focus management, color perception, or vestibular accessibility just to prompt an AI builder out of bad defaults. Change the generator's starting point, and one decision can improve thousands or millions of downstream interfaces.

That's the theory behind the rules below.

This is deliberately an 80/20 list. It doesn't cover everything that makes a site accessible, readable, or pleasant. Instead, it focuses on defaults that are common, highly visible, disproportionately harmful or annoying, structurally valuable, or unusually cheap to get right.

Most of these cost almost nothing to implement at the start: choosing <button> instead of a clickable <div> doesn't add a project phase, setting a readable body text token doesn't require an accessibility consultant, and using the right input type, keeping a focus indicator, choosing readable colors, or honoring prefers-reduced-motion are mostly just decisions about defaults.

Some choices actually remove work; native HTML already knows how common controls are supposed to behave. Every default you do not reinvent is one less thing to code, test, maintain, or accidentally break.

Retrofitting an established product can take more effort, especially when bad choices have spread through design tokens or component libraries, but many fixes can still happen centrally instead of page by page.

There are prosocial reasons to do this (more people can use what you build) and selfish ones too (code that's easier to maintain, pages that are easier to crawl, forms that cooperate with autofill, and fewer people wondering why your beautiful interface is such a pain to use).

Here are the 5 rules for websites that are humane by default.

Start with typography that works for sustained reading.

Default body text to at least 16px, weight 400 or heavier, with comfortable line spacing around 1.5 and a reasonable line length, and use typefaces that stay clear at their actual rendered size.

Reserve display typefaces for short, prominent text such like hero titles. Avoid thin and light weights for paragraphs and important functional text. Secondary does not mean microscopic: helper text, form instructions, and other information people are expected to read still need to be readable.

Why it matters: Bad typography taxes the entire visit.

A broken interaction may affect someone once but small, weak text makes them work harder on every paragraph, label, card, and instruction.

“Serif versus sans serif” is not a useful distinction: a text serif designed for paragraphs can be highly readable, while a display font designed to look dramatic at 52px is miserable at 14px.

Size, weight, spacing, line length, and the typeface's own design all shape the result, and none of that is a WCAG requirement or a magic number. These are just intentionally boring starting points that work far better than asking an AI generator to 'make something sleek'.

Text should meet WCAG 2.2 AA contrast requirements.

That's the floor, not proof that the result is comfortable to read.

• For body and functional text, use APCA or another perceptual method as an additional check since it accounts for the relationship between contrast, rendered size, and weight.
• Pay particular attention to dark themes and muted text.
• Text over gradients, photographs, transparency, glass effects, video, or other variable backgrounds needs a stable reading surface. It should stay comfortably legible everywhere the background can change, including throughout an animation. If that can't be guaranteed, give the text an opaque backing surface.

Why it matters: This is one of the clearest gaps between compliance and experience.

Small or skinny gray text on a black background can comfortably pass WCAG AA and sometimes AAA while still being painful to read.

That creates a useful little compliance fig leaf that says PASS even as you find yourself squinting to read.

The problem compounds when the background itself changes since a text color may work over one part of a gradient and disappear over another. If the gradient moves, its readability can change from second to second.

WCAG remains the compliance baseline. The real question is: Can people comfortably read it?

• Use native HTML when the language already has an element for the job: <header>, <nav>, <main>, <section>, <article>, <footer>, <button>, <a>, <form>, <label>, and the rest of the browser’s existing vocabulary.
• Every page should declare the correct language with lang.
• Each complete page should have one clear page level <h1>, with the rest of the headings representing the actual hierarchy of the content rather than whatever font size looks good.
• Meaningful images need useful alternatives; decorative images should stay out of the way; icon-only controls need names that communicate what they do.
• Avoid generic <div> and <span> elements when a native element already expresses the same meaning, and avoid wrapper soup that serves no purpose.

Why it matters: Structure gives other systems something dependable to work with.

Sighted readers scan headings. Screen reader users navigate through them. Browsers understand native controls. Narration, translation, search, extraction, AI agents, and future tools all make better sense of a page when the markup describes what things are instead of merely where they appear.

It also cuts down on reinvention: a native button already knows how to be a button but a generic rectangle styled to look like one requires somebody to recreate semantics and interaction behavior that the browser provides for free.

Semantic HTML is an accessibility practice, but it's just as much a reliability, interoperability, and maintainability practice.

• Use links for navigation and buttons for actions.
• Inline links in body copy should look like links without requiring someone to hover first. Underlining is a good default; another persistent, equally clear non-color cue can work too.
• Give ordinary form fields visible labels and accessible names. Use the right native field types and appropriate autocomplete metadata.
• An email address should be an email field. A telephone number should be identified as a telephone field. Browsers should not have to reverse engineer what the interface means.
• Interactive controls should work by keyboard, have a clearly visible focus state, and provide sufficiently large or well-spaced pointer targets.

Why it matters: Predictability reduces cognitive and technical work.

People shouldn't have to investigate whether a word is clickable or discover that something that looks like a button actually behaves like a link. Keyboard users should not lose track of where they are.

Correct forms work better for everyone: proper field semantics help autofill, password managers, voice input, mobile keyboards, and other software understand what information belongs where. They can reduce typing, improve validation, summon more useful mobile keyboards, and avoid absurdities like automatically capitalizing the first character of an email address.

The more accurately the page expresses its intent, the less every other tool has to guess.

If something behaves like a modal popup, build it as a real dialog using native <dialog> or a correctly implemented accessible dialog pattern.

It should manage focus, prevent unintended interaction with the page behind it, close predictably, and identify itself correctly to assistive software.

Why the special callout: A modal can look completely correct while being functionally broken.

A centered rectangle, dimmed background, and a tasteful little X do not prove that keyboard focus moved into it, that the background stopped being interactive, that Escape works, or that software can identify what just appeared.

AI is extremely good at generating the rectangle; it needs to generate the behavior too.

Honor user and operating system preferences when the platform exposes them.

The clearest example is reduced motion: when someone has requested reduced motion, you must disable or substantially reduce non-essential animation, parallax, animated gradients, ambient glows, moving backgrounds, and other decorative movement.

Do not make motion necessary to understand or operate the interface.

Why it matters: For some people, motion is distracting. For others it can cause dizziness, nausea, headaches, or other vestibular symptoms.

But there is also a broader design principle here: the person has already expressed a preference.

They shouldn't have to disclose a disability, hunt for a setting, install an extension, or personally ask every website to respect it.

The user has already told you what they need. Listen.

That's about as literal as Hospitable by Design gets.

This is not a list of the five most important WCAG requirements. These are judgment calls, not research scores.

Some of these problems are severe when encountered, others create low-grade friction every second someone uses the page, and some are invisible but improve everything downstream.

An 80/20 standard should care about all three.

The explanation above is for humans. AI tools can use a shorter, less negotiable version.

[HUMANE BY DEFAULT]

Apply these requirements to all generated or modified user-facing web interfaces.

1. READABLE TYPOGRAPHY

Default body text MUST be at least 16px and font-weight 400 or heavier.
Body text SHOULD use line-height around 1.5 and a readable line length.
Text users are expected to read MUST NOT be rendered as tiny, thin, or excessively tracked text.
Display typefaces MUST be limited primarily to short, prominent text.
Body copy, forms, navigation, labels, helper text, metadata, buttons, and other functional text MUST use typefaces readable at their rendered size.
“Secondary” content MUST remain comfortably readable.

2. LEGIBILITY AND CONTRAST

All text MUST meet WCAG 2.2 AA contrast requirements.
Body and functional text MUST ALSO be evaluated with APCA or an equivalent perceptual method that accounts for rendered size and weight.
WCAG compliance MUST NOT be treated as proof of comfortable readability.
Important text MUST NOT use weak or muted contrast merely because it technically passes WCAG.
Dark themes MUST receive the same legibility scrutiny as light themes.

Text and functional controls placed over gradients, images, video, transparency, backdrop effects, or other variable backgrounds MUST remain legible across the entire rendered background.
For animated or changing backgrounds, legibility MUST be maintained across ALL states rather than a single sampled frame.
Body and functional text SHOULD use a stable, sufficiently opaque backing surface when variable backgrounds would otherwise reduce legibility.

3. STRUCTURE AND MEANING

MUST use native semantic HTML when an appropriate native element exists.
MUST NOT recreate native controls with generic elements.
Every complete page MUST declare the correct document language using lang on <html>.
Every complete page MUST have one clear page-level <h1>.
Headings MUST represent content hierarchy rather than visual styling.
Heading levels SHOULD remain logically nested.
Meaningful images MUST have useful alternative text.
Decorative images MUST be marked as decorative.
Icon-only controls MUST have accessible names.
Generic wrapper elements MUST NOT be added without an actual layout, styling, positioning, or component-behavior requirement.
SHOULD keep DOM structure as shallow as practical.

4. PREDICTABLE INTERACTION

MUST use <a> for navigation and <button> for actions.
Inline body-copy links MUST be persistently distinguishable from surrounding text without relying on color alone.
Underlining SHOULD be the default for inline body-copy links.
Hover-only styling MUST NOT be the sole indication that text is interactive.

Form controls MUST have accessible names.
Ordinary form fields SHOULD use visible <label> elements.
MUST use appropriate native input types and autocomplete metadata when applicable.

Interactive elements MUST be keyboard operable.
Interactive elements MUST have a clearly visible focus state.
MUST NOT suppress the browser’s default focus indicator without an equally visible replacement.
Pointer targets MUST meet WCAG 2.2 minimum target-size requirements.

4a. DIALOGS AND POPUPS

Modal interfaces MUST use native <dialog> or a correctly implemented accessible dialog pattern.
Modal implementations MUST correctly manage focus, background interaction, closing behavior, and accessible naming.
MUST NOT implement a modal as a visual overlay alone.

5. USER PREFERENCES

MUST respect prefers-reduced-motion.
Non-essential animation, transitions, parallax, animated gradients, moving backgrounds, ambient glows, and other decorative motion MUST be disabled or substantially reduced when reduced motion is requested.
Essential information or interaction MUST NOT depend solely on motion.

The same rules can work in reverse.

An AI builder can generate against them while another can inspect an existing website against them.

Audit this website against the Humane by Default rules.

For each numbered principle:

- mark it PASS, WARNING, FAIL, or NOT APPLICABLE;
- identify the exact page, component, selector, style, or code responsible;
- explain the practical user impact briefly;
- recommend the smallest effective fix.

For principles containing multiple requirements, report meaningful failures individually rather than giving the entire principle a generic FAIL.

Prioritize repeated design-system, typography, color-token, and component-level problems over isolated exceptions.

Evaluate rendered appearance as well as source/component code where available. For variable or animated backgrounds, inspect multiple states rather than relying on one screenshot.

Do not expand this into a general WCAG audit. Evaluate Humane by Default only, unless you discover a severe accessibility issue that would be irresponsible not to mention.

[PASTE RULES HERE]

This is not a way for AI builders to guarantee accessible websites.

It is not a request to make every generated interface look the same or to remove typography, personality, gradients, animation, or design.

It is a request to stop spending complexity on making ordinary things worse.

For an interactive demo of how comfortable text is to read, check out my project Can You Read Me Now?

For a readable introduction to WCAG without starting in standards document language, Aardvark Accessibility’s WCAG in Plain English is a great starting point.