Skip to main content
Golden wattle in full bloom with bottlebrush spikes threaded through, in a three-ink risograph print

Modern web best practices

Give the agent current guidance, verify the running artefact in a browser and add specialised checks only when they answer a specific question

An agent’s web knowledge comes from training data. It is necessarily older than the platform and weighted toward common code, including common mistakes. Treat its first answer as a proposal, especially around interaction, accessibility and browser support.

Guide before generation

Point the agent at current platform documentation and the project’s own constraints before it builds. Prefer native HTML and CSS capabilities when they fit: semantic controls include keyboard and accessibility behaviour that a hand-built imitation has to recreate.

The exemplar the course uses is the Chrome team’s modern-web-guidance skill: searchable guides covering UI patterns, performance, forms, passkeys and accessibility. It packages a search-first workflow: query the guides for the use case at hand, retrieve the matching recipe, then follow it. This supplies current context before the code gets written. It is also a skill in the course’s technical sense: packaged, on-demand context for a specific task.

Baseline is the course’s vocabulary for browser availability. Features marked widely available work everywhere that matters; newly available features come flagged, with fallback guidance attached. The durable habit is to check current support rather than trust a model’s remembered compatibility table.

Where the stale priors bite

Ask an agent for a modal and you’ll usually get 2019’s modal, delivered with complete confidence. The recurring cases:

In each case, an agent may generate the heavier, older solution found throughout its training data. A short guide supplies the current platform feature that has made the workaround obsolete.

Use the running artefact

Drive the page at both marking viewports. Use the keyboard, watch the console and perform the core interaction from a fresh load. The source, DOM and screen are different artefacts. Evaluate layout and interaction on the screen as the visitor experiences them.

Automation can repeat this pass through a browser tool. It does not remove the need to judge whether the interaction is legible, responsive and worth using.

Specialised sensors

Lighthouse produces repeatable lab signals about performance and other page qualities. axe-core checks the machine-detectable fraction of accessibility failures. Both can be useful when the question they answer matters to the artefact.

Read each result as bounded evidence:

Stale priors cause the greatest harm in accessibility. Divs with click handlers are invisible to assistive technology, and adding ARIA afterwards can make the result worse. Ask for <dialog>, real <button>s and native form controls from the outset; accessible markup then passes the corresponding axe checks.

The course does not require every prototype to install every sensor. Start from the question, choose the smallest trustworthy signal, and keep human judgement for what the signal cannot decide.

Keep the details current

Metrics, thresholds, browser features and tool configuration change. Follow the linked primary documentation when you need exact current values. The course demonstrates the stable pattern: current guidance before generation, evidence after generation, and a clear account of what each signal can establish.