Headings are not decoration

Headings are not decoration. They are navigation.

For a screen reader user, a page's headings work like a table of contents. They announce what is on the page, in what order, and let someone jump straight to the section they need instead of listening to everything from the top.

That breaks when headings are chosen for how they look. A large, bold paragraph is not a heading. Skipping from a level-one heading to a level-three heading because the size looks better leaves gaps in the map.

We build the fix into the system: styled heading levels that look right when used in order, and components that keep visual design and semantic structure tied together. Highly opinionated components do not let those two drift apart.

Use headings to outline the content first. Then style the outline. Not the other way around.

A children's book has to hold attention without a back button

A children's book has to hold attention without a back button.

One idea per page. One clear action. Pictures and words telling the same story, so a young reader who misses one still gets the other. If a page tries to do three things, the story stalls and the reader drifts.

That discipline translates directly to interface design.

A screen that teaches, warns, and sells at the same time does none of them well. A flow that changes its pattern every step forces people to relearn what should already feel familiar. Clear sequence is not dumbing things down. It is respecting how people learn.

Building educational books is a reminder to design in order: show one thing, let it land, then move on. Say it plainly. Show it clearly. Repeat the pattern until it becomes confidence.

Good UX and good storytelling make the same promise: the next step will make sense.

Free webinar Oct 28 at 1 PM GMT: Microsoft and AbilityNet on how accessibility and digital

Free webinar Oct 28 at 1 PM GMT: Microsoft and AbilityNet on how accessibility and digital teams are using AI.

The useful question is not whether AI helps. It is where it helps, where it misses what actual users experience, and what governance keeps it honest.

Worth attending for anyone separating real workflow gains from automation claims.

https://abilitynet.org.uk/resources/financial-sector/free-webinar-how-accessibility-and-digital-teams-are-using-ai

A button without a label should fail the build

A button without a label should fail the build.

Not warn. Not pass with a note in a report someone reads later. Fail — the same way broken code fails.

That is the point of highly opinionated components. A button requires a clear label. A form field requires a label tied to it in code. Color pairings come from tokens tested for contrast, not from a hex value typed in on deadline.

When those rules live in the component and in the pipeline, accessibility stops depending on memory, good intentions, or a final audit. The inaccessible version is simply harder to ship than the accessible one.

Designers and developers still make the real decisions — content, hierarchy, flow. The system just refuses to let the basics break underneath them.

Build the guardrails into the shipping process. Then good practice is not extra work. It is the default path.

A deadline extension is not a pause button

A deadline extension is not a pause button.

The federal timeline for accessible state and local government websites and apps moved. The obligation did not. People still need to pay, apply, register, and get information today — not after a compliance date.

Use the extra runway well: fix the highest-use services first, test with actual users, require accessibility at purchase and renewal, and train the people publishing content every week. That work compounds.

What does not compound is waiting, then rushing an audit at the end and hoping remediation holds.

Government UX at scale is not about a perfect launch day. It is about building a system that stays usable as content, vendors, and tools change.

Start with the services people cannot avoid. Make those work for everyone, first.