Blog October 24, 2026 · 13 min read

Accessible Content Writing: A Practical Guide for Site Owners

Editor revising accessible website content

Accessible content writing means producing text that people can find, read, understand and act on, whether they use a screen reader, magnification, a keyboard, or simply read English as a second language. In practice it comes down to five habits: plain language, real headings, descriptive links, purposeful alt text, and text that survives the reader’s own display settings. This guide walks through each one with examples you can apply to your next page today.

AccessWiser

Keep Accessibility Issues in View

AccessWiser scans websites against WCAG 2.2 AA criteria, links findings to affected elements, and schedules re-checks to catch regressions.

Explore AccessWiser

TL;DR

Write in plain language: common words, short sentences, active voice, and every acronym spelled out on first use.
Build structure with true HTML headings (H1 to H6), not bold or bigger text, so assistive technology can announce the outline.
Make links and alt text say something specific. “Read our menu” beats “click here,” and alt text should convey purpose, not just appearance.
No ADA rule dictates a writing style, but WCAG is the technical benchmark most often cited, and a clean scan does not prove your content is accessible.
Pair automated checks with a human read of every page you publish.

Why the words on the page are an accessibility issue
Write in plain language
Use real headings, not big bold text
Write links and buttons that make sense out of context
Write alt text that does a job
Fonts, size and contrast: what the guidance actually says
Text spacing and reading aids
What the law says about accessible writing
Our perspective: build accessibility into the writing process
A workflow that keeps new content accessible
Catching regressions with AccessWiser
FAQ
Sources

Why the words on the page are an accessibility issue

Most conversations about web accessibility start with code: contrast ratios, keyboard traps, ARIA attributes. But a page can be technically sound and still fail the reader. A confusing instruction, a heading that says nothing, or a link labeled “here” creates a barrier just as surely as missing form labels.

The ADA.gov web guidance lists common website barriers, including poor color contrast and others that content authors influence directly. The people affected include those with low vision, color blindness, dyslexia, cognitive disabilities and language impairments, plus anyone skimming on a phone in bright sunlight.

There is a practical upside too. Experts at Section508.gov describe accessible writing as being about clarity and efficiency, not only compliance. Content that helps people find information quickly serves every visitor, which is good for customers and good for your business.

Write in plain language

Plain language is the center of accessible writing. The W3C’s writing tips for web accessibility point authors toward common words, simple sentence structures, and avoiding jargon and complex idioms. That lowers the mental effort needed to read, which helps people with cognitive disabilities, language impairments, and readers working in a second language.

Habits that make the biggest difference

Use short, direct sentences. One idea per sentence. If you need a semicolon, you can probably write two sentences.
Choose active voice. “We will email your receipt” is clearer than “A receipt will be emailed.”
Expand acronyms on first use. Write “Americans with Disabilities Act (ADA)” once, then use “ADA.”
Avoid nested clauses and double negatives. “You can skip this step if you already have an account” beats “Users who have not yet failed to create an account need not proceed.”
Be literal. Idioms and figures of speech confuse people who read implied meaning less easily, and they translate poorly.
Make instructions direct. Tell people exactly what to do, in order.

Swap the jargon

Section508.gov gives two clean examples: replace “utilize” with “use,” and “assistive modalities” with “screen readers.” The same logic works for small businesses. Here is how it looks in practice:

Instead of	Write
Utilize our reservation portal	Use our reservation page
Patients must remit payment prior to the appointment	Please pay before your appointment
Our team will endeavor to respond expeditiously	We will reply within one business day (only if that is true)
Click the icon on the right	Select the “Book now” button
Not unlike our competitors	Like other studios

Notice the last two lines of the table above. Directional words such as “right” or “below” fail for people who cannot see the layout, and the layout changes on a phone anyway. Name the thing instead.

Use real headings, not big bold text

This is the most common pitfall for non-technical site owners. If you make a line bold and larger to make it look like a title, sighted visitors see a heading but a screen reader does not. The W3C tips call for true HTML heading tags so assistive technology can announce the structure and let users jump between sections instead of listening to the whole page.

Think of headings as a programmatic outline. The W3C stresses that they are navigation tools, not just “bigger and bolder” text. Here is a simple model:

H1: the page title. One per page.
H2: main sections.
H3: subsections inside an H2.
Do not skip levels to get a smaller font. Change the size with your theme’s styles instead.

What the heading says matters as much as its tag. WCAG’s Success Criterion 2.4.6 asks for descriptive headings and labels so people can orient themselves, especially people with cognitive or visual disabilities. “Our Services” is fine. “Things we do” is vague. “Teeth whitening and cleaning prices” tells a reader whether to stay.

Section508.gov’s core principles for content authors note that most accessibility failures in content management systems come from a small set of recurring issues, and heading structure is among them. In WordPress, Wix, Squarespace, Webflow and Shopify, look for the paragraph or text style dropdown in the editor and pick “Heading 2” rather than stretching the font.

Write links and buttons that make sense out of context

Screen reader users often pull up a list of all the links on a page. A list reading “click here, click here, read more, learn more” is useless. Good link text tells people where the link goes or what it does:

Weak: “For our hours, click here.”
Better: “See our holiday opening hours.”
Weak: “Read more”
Better: “Read the full cancellation policy”

The same applies to buttons and form labels. “Submit” is acceptable at the end of a short form, but “Send my reservation request” gives more confidence. Keep the visible words and the accessible name aligned so a voice-control user who says what they see gets the right result.

Write alt text that does a job

Accessibility specialists say the most common alt text mistake is describing a picture rather than conveying what it contributes. The W3C’s text alternatives guidance is the foundation here. A few rules of thumb:

Informative images: say what the reader needs to know. For a menu photo, “Grilled salmon with lemon and roasted asparagus, $24” helps more than “fish on plate.”
Functional images: describe the action. An image used as a search button should be “Search,” not “magnifying glass.”
Decorative images: mark them as decorative so screen readers skip them, rather than filling the field with filler text.
Images of text: repeat the text in the alt attribute, or better, use real text.

We go deeper with examples in our alt text guidelines for creators and developers.

Fonts, size and contrast: what the guidance actually says

People search for the “most accessible fonts,” but the honest answer is less tidy. According to Section508.gov’s typography guidance, neither WCAG nor Section 508 specifies typefaces or even a minimum font size. What they do expect is clear, consistent headings and highly legible text.

Within that, the research leans one way. The same guidance points to sans-serif fonts as generally easier to read on screens, and a study of font type and screen readability for people with dyslexia found that the presentation of text has a significant effect on its accessibility. Practical choices:

Prefer a clean sans-serif for body text.
Choose typefaces with generous x-heights and clearly distinct characters, so letters like “I”, “l” and “1” are not confusable.
Avoid long stretches of italics or all caps.
Keep body text comfortably large. The guidance cited in our research suggests roughly 13 to 14 points as a floor for designers, though no rule sets one.
Aim for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, which is what WCAG generally requires. Light gray text on a white background is one of the barriers named on ADA.gov.

Our post on color blindness failures and WCAG fixes covers contrast and color use in more depth.

Text spacing and reading aids

Some readers change how your text looks. People with low vision or dyslexia often increase line height, paragraph spacing, letter spacing or word spacing, using browser extensions, custom style sheets or built-in settings. WCAG includes a text spacing success criterion (1.4.12) for exactly this: your content should keep working when a reader loosens the spacing.

The writing side of this is more practical than it sounds:

Do not rely on fixed-size boxes. If a button label sits in a container with a set height, longer spacing can push words out of view or overlap them. Write labels that can wrap.
Keep paragraphs short. Dense blocks get harder to read when spacing grows.
Use real lists and tables. Faux lists made with line breaks and dashes collapse into a jumble.
Put key information in text, not images. Text can be resized and respaced. A flyer image of your hours cannot.

Reading aids such as adjustable contrast, larger text, dyslexia-friendly display options, reduced motion and text-to-speech help visitors tailor a page to their needs. They are a useful complement, but they sit on top of good writing and good markup. They do not replace them.

What the law says about accessible writing

No ADA regulation dictates a universal writing style. What exists is a technical benchmark. Under the Department of Justice’s Title II web rule, state and local government web content must conform to WCAG 2.1 Level AA, with compliance dates staggered by population: April 24, 2026 for entities with 50,000 or more residents and April 24, 2027 for smaller ones.

Private businesses fall under Title III, where the DOJ requires that websites be accessible to people with disabilities and often points to WCAG as the yardstick. The DOJ’s web accessibility guidance is the place to start reading. If you are weighing legal exposure, our post on ADA versus WCAG explains how the two relate. For legal questions about your specific situation, talk to an attorney who handles ADA matters.

To see how WCAG levels relate to each other, read why to target WCAG 2.2 AA first.

Our perspective: build accessibility into the writing process

We scan websites against WCAG 2.2 AA, with Section 508 and EN 301 549 mappings, and we see the same pattern again and again. Teams fix the code, then publish new content that reintroduces old problems: a skipped heading level, a vague link, a missing image description. The scan flags it weeks later.

How new content can reintroduce accessibility issues

Our view is that content habits are the cheapest accessibility investment a business can make, and that they need to be part of how pages are written, not a cleanup job. Automated checks detect a substantial subset of barriers, such as missing alt attributes, heading order and contrast. They cannot judge whether your alt text describes the right thing or whether a link makes sense to a human. That takes a person reading the page, ideally with a screen reader or at least a keyboard.

That is why we focus on permanent fixes in the site’s own code, with plain-language guidance for each finding, rather than runtime patches that paper over problems. It is also why we keep dated records of scans and fixes: they show a documented, ongoing effort, which supports a broader compliance program without claiming that software alone can certify accessibility.

— The AccessWiser Team

A workflow that keeps new content accessible

You do not need a big team. A short routine before every publish covers most of what trips up site owners:

Draft in plain language. Read it aloud. If you stumble, your reader will.
Outline with headings first. Write the H2 and H3 titles, check they make sense on their own, then fill in the text.
Rewrite every link. Remove “click here” and “read more.”
Add alt text with a purpose. Mark decorative images as decorative.
Check contrast and font size in your theme settings.
Preview with zoom and a keyboard. Zoom to 200 percent and tab through the page.
Run a scan, then do a human read. The ADA.gov guidance on web accessibility makes the same point: no tool can replace human judgment on context-dependent issues.
Record what you changed. Dated notes show good faith if a customer or a lawyer ever asks.

For teams that want a structured plan, our WCAG 2.2 checklist for web teams lays out an audit and a 90-day remediation path. Accessibility also tends to help search visibility.

If you run a restaurant, clinic, salon, hotel or online store, apply the workflow to the pages customers use most: your menu or services, booking, contact and checkout. Start there, then work outward.

Catching regressions with AccessWiser

Writing well is the start. Keeping it that way across dozens of pages and several editors is harder. AccessWiser scans your site against WCAG 2.2 AA, ties each issue to the element and criterion it affects, and explains in plain language how to fix it in your own code. Scheduled re-checks catch regressions when new content goes live, and dated records of scans and fixes, along with an accessibility statement, document your efforts.

Plans start at $24 per month for Starter, with Basic at $49 per month and Pro at $119 per month. Business is available with custom pricing details on request. Extra specific page scans are $12 one-off and extra full site scans are $19 one-off. Every subscription begins with a 7-day free trial. See AccessWiser plans and pricing to pick the one that fits your site, or browse our accessibility solutions for every website.

FAQ

Is WCAG legally required?

It depends on who you are. State and local government entities must meet WCAG 2.1 Level AA under the DOJ’s Title II rule. Private businesses fall under Title III, where the DOJ expects accessible websites and WCAG is commonly used as the technical benchmark. An ADA attorney can advise on your situation.

What is the ADA writing style?

There isn’t one. No ADA regulation sets a writing style. The practical equivalent is plain language, structured headings, descriptive links and text alternatives, which are the practices recommended by the W3C and Section508.gov and which support WCAG conformance.

What are the most accessible fonts?

Neither WCAG nor Section 508 names specific typefaces. Government guidance and research point to clean sans-serif fonts with clear character shapes as easier to read on screens, especially for people with dyslexia. Pair them with sufficient contrast, at least 4.5:1 for normal text.

Can a scanner tell me if my content is accessible?

Only partly. Scanners reliably catch structural issues like missing alt attributes, skipped headings and low contrast. They cannot judge whether alt text is meaningful or a link makes sense in context, so pair automated scans with a human review of your content.