Reviewed: 29 August 2026 · Next review: 28 February 2027
Author: Ozlin Info Editorial Team · Human review: Lin
Web accessibility is the practice of making digital content and functionality usable by people with a wide range of disabilities, technologies and situations. It is not a final audit checkbox. Decisions made in research, content, visual design, component design, development, procurement and maintenance all affect whether people can complete a task.
The current W3C Recommendation is Web Content Accessibility Guidelines (WCAG) 2.2. WCAG is organised around four principles: content must be perceivable, operable, understandable and robust. A Level AA conformance claim requires every applicable Level A and Level AA success criterion to be satisfied for the full pages in scope—not an average score across selected checks (W3C — WCAG 2.2).
WCAG is a technical standard, not a complete description of every person's experience and not, by itself, a legal opinion. An organisation should separately determine which laws, procurement rules, contracts or policies apply to its website.
Define scope and target before changing components
Begin with the service people need to use. Record:
- the pages, templates, states, documents and third-party journeys in scope;
- target users, assistive technologies and supported browsers;
- the intended WCAG version and conformance level;
- critical tasks such as finding information, purchasing, registering or contacting support;
- who owns design, code, content and external widgets; and
- how defects will be prioritised, accepted and retested.
For a new or substantially redesigned business site, WCAG 2.2 Level AA is a sensible engineering target. It includes the earlier WCAG 2.1 criteria and adds requirements such as focus not being obscured, alternatives to dragging, minimum target size, consistent help, avoiding unnecessary repeated entry and accessible authentication. WCAG 2.2 removed the obsolete 4.1.1 Parsing criterion, although a contract or policy that explicitly names an earlier WCAG version may still require separate reporting (W3C — What's New in WCAG 2.2).
Do not publish “WCAG compliant” based only on a home-page scanner. A formal claim has specific scope and documentation requirements, and third-party content can affect the outcome.
Prefer native, semantic HTML
Native elements carry established keyboard and accessibility behaviour. Use a real <button> for an action, an <a href> for navigation, labelled form controls, ordered heading levels and landmarks such as header, nav, main and footer. Add ARIA only where native HTML cannot express the required name, role, state or relationship.
A styled div with a click handler does not automatically gain button semantics, keyboard activation, focus behaviour or disabled state. Recreating these features increases code and test burden. If a custom widget is necessary, follow the appropriate WAI-ARIA Authoring Practices pattern and test the implemented behaviour; adding a role alone does not make it accessible.
Content also needs structure and meaning:
- give each page a descriptive title and one clear primary heading;
- write link text that makes sense in context;
- provide useful alternative text for informative images and empty
alttext for decorative images; - provide captions for prerecorded video and an appropriate transcript for audio information;
- identify the page language and language changes; and
- present instructions and errors in text, not colour or position alone.
Alternative text should communicate the image's purpose in that context. It is not a keyword field and does not need to describe every visible detail.
Design for more than one way to interact
Every interactive task should work without a mouse. Test forward and reverse keyboard navigation, logical focus order, visible focus, modal entry and exit, menus, disclosures, validation and any custom control. Focus must not be trapped or hidden behind sticky headers, cookie banners or other author-created content.
Colour contrast matters, but colour is only one part of perceivability. Check text, controls, focus indicators and meaningful graphical objects against the applicable criterion. Do not use colour alone to communicate an error, status or selection.
Responsive layouts must remain usable when people enlarge text or zoom. Check narrow viewports and 400% zoom for lost content, overlapping controls and two-dimensional scrolling where the criterion does not permit it. Fixed-height cards and clipped navigation often fail before the colour palette does.
Authentication deserves particular attention. WCAG 2.2's Accessible Authentication criterion limits cognitive function tests such as memorising or transcribing information unless an alternative or assistance is available. Support password managers and paste; do not block them in the name of security without a carefully assessed reason.
Make forms understandable and recoverable
Each control needs a programmatically associated, visible label. Group related radio buttons or checkboxes with fieldset and legend when appropriate. Explain required formats before they are needed and identify required fields without relying on colour alone.
When validation fails:
- retain safe values the user already entered;
- provide a clear summary and field-specific message;
- associate the error with its field;
- move or manage focus deliberately so the error is discoverable; and
- tell the user how to correct it.
For an asynchronous submission, expose the result as a programmatically determinable status message. Do not unexpectedly move focus for every small update.
Combine tools with human evaluation
Automated tools are useful for repeatable checks such as missing accessible names, some contrast failures and certain invalid relationships. They cannot reliably judge whether alternative text is meaningful, focus order follows the task, instructions make sense or a screen-reader experience is coherent. W3C explicitly says no tool alone can determine whether a site meets accessibility guidelines (W3C — Introduction to Web Accessibility).
A practical test set includes:
| Method | What it can reveal |
|---|---|
| Automated rules in CI | Repeatable detectable regressions across known templates |
| Keyboard-only walkthrough | Reachability, order, traps, focus visibility and operability |
| Zoom and reflow checks | Clipping, overlap, loss of content and excessive scrolling |
| Screen-reader checks | Names, roles, headings, landmarks, reading order, status and errors |
| High-contrast or forced-colour checks | Information lost when authored colours are overridden |
| Content review | Heading logic, link purpose, instructions, captions and alternatives |
| Disabled-user evaluation | Barriers, workarounds and priorities that technical inspection can miss |
Test representative pages and every distinct component or state, not just URLs selected at random. Include errors, empty results, loading, authentication, session expiry and third-party flows. W3C's Easy Checks are a useful first review but are explicitly not exhaustive (W3C — Easy Checks).
Keep an evidence-based remediation backlog
Record each finding with the affected task, URL or component, WCAG criterion, reproducible steps, observed and expected behaviour, severity, owner, target release and retest evidence. Prioritise barriers that block critical tasks, affect many pages or create safety, privacy or financial consequences.
Reusable components create leverage: correcting a shared navigation, dialog, form field or error summary can remove the same barrier across many pages. Add a regression test where automation is reliable, but retain manual checks in the definition of done.
An accessibility statement should be accurate about scope, known limitations and contact paths. It should not claim perfection or replace a working way for people to report a barrier. Give accessibility reports an owner and response process.
Treat accessibility as ongoing quality
Content edits, plugin updates, third-party scripts and new features can reintroduce barriers. Review accessibility during discovery and design, test components before release, run automated rules in continuous integration and schedule periodic task-based evaluation. Train the people who publish content as well as the developers who build templates.
For help reviewing a website workflow, component library or remediation backlog, see Ozlin Info's web development services or contact Ozlin Info.
Related reading: 10 WordPress performance checks before optimisation.
General-information disclaimer
This article provides general technical information only. It is not legal, regulatory, procurement or accessibility-conformance advice. A conformance claim requires evaluation of the complete defined scope against the relevant standard and may require qualified legal or accessibility advice.
AI-assistance disclosure
AI tools assisted with source discovery, outlining and copyediting. A human reviewer must verify every technical statement, link, service claim and publication decision before release. Automated or AI-assisted checks do not prove accessibility or WCAG conformance.
Primary sources checked
- W3C — Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI — What's New in WCAG 2.2
- W3C WAI — Introduction to Web Accessibility
- W3C WAI — Easy Checks: A First Review
- W3C WAI — Conformance Evaluation and Reports
Source access date: 29 August 2026.
Leave a Reply