Good Content is Accessible Content

Here's something worth noticing about accessibility guidance: almost none of it is unique to accessibility. 

Write clear headings. Say what a link goes to. Describe your images. Keep sentences short. Explain what went wrong when a form fails. Don't bury information in a graphic.

That's not a compliance checklist. That's a style guide. It's what a good editor would tell you regardless of who was reading.

The same advice, from two directions
Accessibility asks: can someone use this if they can't see it, can't hear it, or can't use a mouse?

Good writing asks: can someone follow this quickly, on a phone, while distracted, without prior context?

The two questions arrive at nearly the same answers, because both are really asking whether your content works for someone who isn't you — someone without your context, your screen, your assumptions, or your patience.

• Descriptive headings help screen reader users navigate. They also help the far larger group of people who scan instead of reading.
• "View our pricing" instead of "click here" helps someone tabbing through links out of context. It also tells everyone else what they're about to click.
• Plain language helps people with cognitive disabilities and people reading in a second language. It also helps your busiest customer, who is skimming on a phone between meetings.
• Real text instead of text baked into an image helps screen readers and translation tools. It also means people can copy your address, search for your event, and read it at whatever size suits them.
• Clear error messages help everyone recover — and "Invalid entry" has never helped anyone.
• Every one of those is an accessibility requirement and an editorial improvement at the same time. Not by coincidence. They're the same instruction reached from different starting points.

 Which is why the framing matters
Accessibility gets treated as a separate workstream — something bolted on afterward, owned by someone technical, done grudgingly because a rule says so.

But most of it isn't technical at all. It's content work: writing headings that mean something, describing images, naming links, choosing words people actually use. That work belongs to the people already writing your content, and it makes the content better on its own terms.

When accessibility is a separate project, it gets deferred, done minimally, and quietly undone by the next six months of publishing.

When it's just how you write, it stays done.

 The test
One question covers most of it: would this still make sense to someone who can't see the page?

If your event details are only in the flyer, no. If your headings are font sizes rather than structure, no. If your links all say "read more," no. If your explainer is a twelve-minute video with no transcript, no.

Fix those and you haven't only made the page accessible. You've made it clearer, more findable, easier to skim, and easier to act on — for everyone who was already reading it.

 We can help with this
If your team is writing content already, they're most of the way there. What's usually missing is knowing which habits matter and having someone to ask when a real question comes up.

That's a lot of what we do: training for the people who write and publish your content, practical guidance and checklists they'll actually use, audits when you need to know where you stand, and remediation when you'd rather we did the work.

Get in touch with us — or start with our free Resources and see how much of it you're already doing!