A website can look polished and still prevent someone from sending an enquiry, selecting a product or finding an error in a form. Accessibility work becomes useful when it follows those tasks all the way through, rather than stopping at a scanner’s score.
This guide focuses on the practical WordPress work: choose the pages, reproduce the barriers, fix the source and retest. For the legal background and appropriate technical targets, read the Australian web accessibility requirements guide. This is an implementation workflow, not a claim that a checklist guarantees legal compliance.
Start with a small set of complete journeys
Include the homepage, navigation, contact form, key service page and any checkout or account flow. Add a representative article and a page with downloads or embedded media. The point is to cover different templates and actions, not scan a hundred near-identical URLs while missing the important form.
Write down what success looks like: a user can find the contact route, understand the field labels, correct an error and confirm that submission worked. Keep the same tasks for the retest so the result is comparable.
Use WCAG as a technical framework
W3C’s WCAG overview explains the guidelines and their conformance levels. WCAG 2.2 Level AA is a useful current target for practical work; the legal discussion belongs with the specific Australian context rather than a universal claim that every private site must meet a particular version.
The WAI tutorials provide implementation guidance on images, page structure, forms and other components. Use that guidance alongside testing with the actual technologies and user tasks involved.
Try the site with a keyboard
Navigate without a mouse. Check whether focus is visible, the order makes sense and menus, dialogs and buttons can be operated. Look for traps that prevent leaving a component and for focus that disappears behind a sticky header or overlay.
Test the whole form, including invalid input and submission. A field can be reachable while its label or error remains unclear. Do not remove focus outlines for visual tidiness without providing an effective replacement.
Check structure, text and content
Use headings to describe the page hierarchy, not merely to produce a larger font. Give links meaningful text and avoid a page full of indistinguishable read-more controls. Images need alternatives appropriate to their purpose; decorative images can have empty alternatives rather than unnecessary descriptions.
Test zoom and narrow layouts. Text should remain readable, and essential controls should not disappear off-screen. Check contrast and avoid conveying meaning only through colour. These are content and template decisions, not something a hosting upgrade will automatically repair.
Automated scanning is useful but incomplete
Accessibility Checker by Equalize Digital is one WordPress option for identifying issues in content. I use it on this site. This is an editorial resource link, not a claimed affiliate relationship.
A scanner can help find patterns and organise repairs. It cannot establish that a real person can complete your particular workflow or judge every alternative description’s meaning. Treat the results as a queue for investigation, then manually test the important journeys.
Do not confuse an accessibility widget with repaired source content. Test the underlying navigation, forms and templates rather than assuming a purchased overlay makes the site conformant. If you evaluate a plugin that changes presentation, check its effect with the assistive technologies people actually use.
Repair the shared template before every individual page
A broken menu or form component may affect many pages. Fixing the shared source is usually more sustainable than adding a different workaround on each URL. Record the cause and the relevant acceptance test so a later theme update does not reintroduce the same barrier.
Some fixes belong in content, some in the theme, and some in a third-party widget. Identify ownership before promising a repair. An embedded booking service may need its own vendor escalation. Keep an accessible alternative route available while the issue is being addressed.
Include video, documents and remote participation
A website’s embedded meeting recording or PDF can exclude someone even when the surrounding page is good. Provide appropriate captions, usable text information and accessible documents rather than relying on the player or download link alone.
The accessible video-meetings guide covers the recording and participation decisions. The assistive-technology guide explains why testing needs the person’s actual applications and input methods.
Keep performance improvements accessible
A faster site is useful, but an optimisation that breaks keyboard navigation or delays essential controls is not a complete improvement. Test accessibility and the main customer task after changing scripts, forms or page-builder settings.
Use Core Web Vitals to assess loading and interaction separately. A green performance score does not certify accessibility, just as a clean scanner report does not prove that checkout works.
Unsubscribe is a real customer task
Marketing opt-out pages should not require a difficult login or hide the stop option behind confusing controls. The Australian spam-law guide explains the specific unsubscribe requirements. Include that journey when the website handles campaign preferences.
A sustainable repair record
- URL, template and affected task.
- Reproduction steps and observed barrier.
- Relevant technical guidance.
- Owner and planned repair.
- Manual and automated retest evidence.
- Remaining limitation and alternative access route.
Keep that record with the site’s maintenance process, not in a forgotten launch report. Contact Matt if you need help separating content fixes, template changes and vendor issues into a practical sequence.
Featured image is illustrative; source credit is recorded with the existing media attachment.
