Website Accessibility Is a Maintenance Job, Not a Launch-Day Checkbox

Accessibility isn't a launch-day checkbox

Most accessibility work happens once: a pre-launch review, a round of fixes, a sign-off. Then the site goes live, and from that point forward every new banner, every new blog post, every new lead form is written, designed and published by whoever's job that is that week — usually without anyone re-running the checklist that got the site through review in the first place. The site that passed its accessibility check at launch is not the same site six months later. Content is the thing that changes constantly, and content is where most accessibility problems actually come from.

This is why accessibility belongs in maintenance, not just in the launch project. A site can be fully compliant on the day it ships and meaningfully broken a month later, without a single line of the original template changing.

How new content quietly reintroduces old problems

Images without alt text. A developer who built the original template almost certainly added alt attributes to the images that shipped with the site. The marketing person who uploads a new product photo or a promotional banner six weeks later, through a CMS media library, usually isn't thinking about alt text at all — and most CMS platforms don't require it, so the field gets left blank by default. Every new image is a small, independent chance for this to happen again.

Poor contrast in a new banner or promo graphic. Design systems get contrast right once, at launch, when a designer checked it. A new seasonal banner, built in a rush by whoever's available, layering white text over a busy background photo, bypasses that system entirely. It looks fine to someone with typical vision on a bright screen and can be close to unreadable for a meaningful share of users under other conditions.

Forms without labels. A contact form built into the original template was likely tested. A new lead-capture form added later — for a campaign, a new product line, a seasonal promotion — is often assembled quickly with a form-builder plugin, and it's easy for a field to end up with placeholder text standing in for a label instead of an actual <label> element. Placeholder text disappears the moment someone starts typing, and it isn't reliably announced by assistive technology the way a real label is.

Headings used for styling, not structure. This one compounds over time. A content editor wants a line of text to look bigger and bolder, so instead of using the correct heading level for that point in the document, they either skip straight to whatever heading tag happens to render at the right size, or they don't use a heading element at all — just bold, larger body text. Screen reader users frequently navigate a page by jumping between headings; a heading structure that's been bent for visual effect over dozens of posts turns that navigation method from a shortcut into a maze.

None of these require a redesign to happen. They require one content update, made in good faith by someone with no reason to know better, repeated across however many updates a site gets in a year.

What a routine check actually looks for

A practical maintenance routine doesn't need to re-run a full audit every time. It needs a short, repeatable pass after anything that adds new content or new interactive elements: check that new images have meaningful alt text (or are marked decorative, if they genuinely carry no information); check contrast on any new banner or graphic against its background; check that new form fields have real labels, not just placeholder text; and check that new headings sit in the correct order relative to what's around them, rather than being chosen for how large they render. Doing this on every new page or post, rather than in a periodic sweep months later, is what keeps the gap from compounding.

What automated tools actually catch — and what they don't

Automated accessibility scanners are useful and worth running, but their honest limitation is stated plainly by the W3C's own Web Accessibility Initiative: "no tool alone can determine if a site meets accessibility standards. Knowledgeable human evaluation is required to determine if a site is accessible" (W3C WAI, Test & Evaluate). Tools are reliable at catching things that are structurally detectable — a missing alt attribute, a contrast ratio that fails a calculable threshold, a form input with no associated label in the markup, invalid ARIA usage. They cannot judge whether an alt text description is actually accurate or useful rather than just present, whether a heading structure makes logical sense to someone navigating by ear, whether link text like "click here" is meaningful out of context, or whether a page is genuinely usable with a keyboard alone. Those require a person actually going through the page — ideally with a keyboard and, at least occasionally, with a screen reader — not just a scan of the underlying code.

What "conformant" is actually measured against

The current version of the Web Content Accessibility Guidelines is WCAG 2.2, a W3C Recommendation published in October 2023, with later editorial updates (W3C, WCAG overview). It defines success criteria at three levels — A, AA and AAA — and the W3C's own guidance is specific about the top tier: "It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content" (W3C, Understanding Conformance). That leaves Level AA as the realistic general target for most organisations, which is why it's the level most commonly referenced elsewhere.

One detail matters directly for a maintenance routine: WCAG conformance is defined per full page, and every variation a page presents — including how it renders at different screen sizes — needs to conform on its own (W3C, Understanding Conformance). A single new banner with poor contrast, or one form missing a label, doesn't just create an isolated cosmetic issue — it affects the conformance status of that whole page.

We can't point to a specific Malaysian law that mandates a given WCAG level for private-sector business websites — if one applies to your organisation, for example through a specific government procurement contract, that would sit outside general guidance like this and is worth confirming directly with whoever is setting that requirement. WCAG is best treated here as the accepted international standard to build routine checks against, independent of whether a specific local statute requires it.

Keeping it maintained

Accessibility maintenance doesn't need a dedicated specialist checking every post before it publishes. It needs the four checks above built into whatever workflow already exists for adding content, plus an occasional manual pass — with a keyboard, and ideally with a screen reader — through the pages that see the most new content. That's a smaller commitment than it sounds, and considerably smaller than the one required to fix a year of accumulated gaps in one sitting.

If accessibility checks like these are one of several things falling through the cracks between updates, JagaWeb Care (RM450/month) covers ongoing monitoring, and Care + Changes (RM1,500/month) adds capacity to actually action fixes as they're found — one option, not the only way to keep on top of it.

This is general information, not legal advice. We could not identify a Malaysian statute mandating a specific WCAG level for private-sector business websites; that is a statement about what we could verify, not a guarantee that no obligation applies to you. Sector rules and government contract terms can differ — take advice on your own situation.