Keeping a Site Accessible After Launch
By CodexierPublished 5 min read
Accessibility is usually checked once, just before launch, and then quietly forgotten. Every new page, blog post, uploaded PDF and campaign banner can undo that work: a missing image text here, a heading used for styling there, a PDF that screen readers cannot read. This guide sets out why accessibility decays, the rules editors need, how to handle documents and a recurring check that keeps the site in shape.
Why accessibility decays
The developers who built the site usually followed WCAG. After handover, the people publishing content are marketing staff, managers and whoever has a login. They are not trained in accessibility, and the CMS rarely stops them. Plugins and third-party widgets such as chat, booking and cookie banners add their own problems with every update.
It matters beyond good practice. Public-sector websites are covered by the Swedish law on accessibility to digital public services, and since June 2025 the accessibility act covers many consumer-facing services such as e-commerce, with an exemption for the smallest companies. Our guide to the accessibility law for company websites explains who is covered.
Rules for editors: headings, links and images
- Headings in order: one H1 per page, then H2 and H3 in sequence; never pick a heading for its size
- Link texts that make sense on their own: 'Read the price list', not 'Click here'
- Image descriptions that say what the image shows or does; decorative images marked as decorative
- No text inside images, such as banners with the offer written in the picture
- Sufficient contrast for text on coloured backgrounds; use the site's approved colour pairs
- Videos with captions, and audio content with a transcript
- Tables only for tabular data, with header rows marked
Put these on one page, add screenshots from your own CMS, and include them in onboarding for anyone who gets an editor login. Where possible, configure the CMS to enforce them: required image-description fields, limited heading choices and a restricted colour palette.
PDFs and documents
PDFs are where most sites fail. A PDF exported from a scanned paper or a design tool without structure is an image to a screen reader. Price lists, menus, reports and forms are the usual culprits.
| Document type | Better approach |
|---|---|
| Price list or menu | Publish as a web page, offer PDF as an extra |
| Form to print and fill in | Replace with a web form |
| Annual report or long report | Export with tags and headings from Word or InDesign, and check it |
| Scanned document | Avoid; if necessary, run text recognition and add a summary on the page |
Word and InDesign can both export tagged PDFs if the original uses real headings and styles. Adobe Acrobat's accessibility checker catches the basic errors.
Periodic automated and manual checks
Automated tools find only part of the problems, but they find them cheaply and consistently. Manual checks catch the rest: whether image texts make sense, whether a form can be completed with a keyboard, whether the page is understandable when zoomed.
| How often | What | Who |
|---|---|---|
| Every publication | Editor checklist | The editor |
| Monthly | Automated scan of key pages with a tool such as WAVE or axe | Web owner |
| Quarterly | Keyboard-only test of key flows, zoom to 200 per cent, screen reader spot check | Web owner or supplier |
| After redesigns and new plugins | Full check of affected templates | Developer or supplier |
Key pages are the ones with most traffic and the ones where people complete tasks: contact, booking, checkout, login.
The accessibility statement
Public-sector bodies must publish an accessibility statement that describes how the site meets the requirements, known shortcomings and how users can report problems. Businesses covered by the accessibility act must provide information on how their service meets the requirements. Even where it is not required, a short statement with a contact route is a sign of good faith.
- Which standard you aim for, usually WCAG 2.1 level AA
- Known shortcomings and when they will be fixed
- How to report a problem, and how quickly you respond
- When the statement was last reviewed
The statement is only credible if it is updated after each quarterly check. A statement from three years ago signals the opposite of care.
When you need help, and when you do not
If your site is small, rarely updated and built on a well-maintained platform, the editor rules and a monthly scan may be all you need. Bring in help when the scan shows problems in templates rather than content, after a redesign, or when you are covered by the law and need a documented review. Our website health audit includes an accessibility check of templates and key flows; prices are on our pricing page. You can also book a short call first.
Frequently asked questions
Can an accessibility overlay widget fix the site for us?
No. Overlays that promise one-line fixes do not repair the underlying structure and can interfere with assistive technology. Fix the content and templates instead.
How much of accessibility can automated tools check?
Only part of it. They catch missing image texts, low contrast and missing labels, but not whether texts are meaningful or whether flows work with a keyboard. Combine them with manual checks.
Is our small company covered by the accessibility act?
The act covers certain consumer-facing services such as e-commerce, but micro-enterprises providing services are exempt. Check your size and services against the rules, or ask us on a call.
Who should own accessibility after launch?
Whoever owns the website's content, usually marketing or communications. Developers fix template issues, but most decay comes from content, so ownership must sit there.
Not sure how accessible your site is today?
On a short call we look at a few key pages together and tell you whether you need rules for editors, template fixes or a full review.
Book a free 15-minute call