Accessible by design: why WCAG 2.2 belongs in Discovery, not final testing

A website is almost ready to launch. Someone runs an automated accessibility scan, receives a list of failures and asks the development team to fix them.

That scan may identify missing labels, contrast problems and code errors. It cannot recover decisions that were made months earlier without accessibility in mind: a journey that depends on dragging, an authentication pattern that creates a barrier, video produced without a transcript, a component library with broken focus behaviour or a procurement choice that locked in an inaccessible third-party service.

Late testing is necessary. Late consideration is expensive and incomplete.

Accessibility belongs in Discovery because it affects who the service is for, what they need to accomplish, which barriers carry the greatest consequence and what requirements the project must satisfy. It belongs in information architecture, content, design systems, development and quality assurance because those requirements must become a usable experience. It belongs after launch because websites and content keep changing.

The point is not to move one final check to an earlier meeting. It is to treat accessibility as a delivery responsibility throughout the lifecycle.

What WCAG 2.2 provides

The Web Content Accessibility Guidelines 2.2 are a W3C Recommendation containing testable success criteria for web content. They are organised under four principles: content and interfaces should be perceivable, operable, understandable and robust.

WCAG has three conformance levels: A, AA and AAA. The W3C encourages use of the latest WCAG version. Its overview explains that WCAG 2.2 is backwards compatible with 2.1 and 2.0, so content conforming to 2.2 also conforms to those earlier versions.

WCAG 2.2 added nine success criteria compared with WCAG 2.1. They include matters such as focus appearance and obstruction, dragging movements, target size, consistent help, redundant entry and accessible authentication. These additions reinforce why accessibility is not only a code-linting exercise. It shapes interaction design, content, components and user flows.

The Australian Human Rights Commission’s 2025 guidelines on equal access to digital goods and services recommend WCAG 2.2 at Level AA as a minimum organisational target and consideration of appropriate AAA criteria. The guidelines are valuable current guidance, but this article is not legal advice or a determination that meeting one technical standard resolves every obligation. An organisation should obtain advice appropriate to its sector, service and procurement context.

Conformance is not a badge added at launch

WCAG conformance applies to complete web pages and defined processes under specific conditions. It is not a general certification of an organisation, platform or agency.

W3C’s WCAG Evaluation Methodology provides a structured approach for evaluating how well a website meets a target standard. It involves defining the evaluation scope, understanding the website, selecting a representative sample, auditing that sample and reporting findings.

This matters for two reasons.

First, a quick scan of several URLs cannot establish whole-site conformance. Automated tools cover only part of the standard and cannot reliably judge meaning, usability or every state.

Second, an accessibility requirement is not fulfilled merely because a launch build once passed an evaluation. New content, campaigns, integrations and component updates can introduce barriers. Conformance work needs an agreed scope, evidence, remediation and ongoing governance.

What accessibility changes during Discovery

Discovery should not begin with a generic statement that the website will be accessible. It should convert the organisation’s context into project requirements and ownership.

Understand audiences without treating disability as an edge case

Disability can affect vision, hearing, mobility, speech, cognition and neurological experience. Access needs also interact with age, language, device, environment, connection quality and temporary or situational limitations.

Research should include people with disability where appropriate, ethically and with suitable support. When direct research is not practical, teams can use existing service evidence, accessibility expertise, support requests and representative scenarios while recognising the limitations of assumptions.

Do not create one simplistic “disabled user” persona. Identify priority tasks and potential barriers for different users and technologies.

Define critical journeys and failure consequences

Accessibility effort should cover the whole service, with particular attention to high-consequence tasks such as:

• Finding urgent or essential information
• Locating a service or facility
• Completing an enquiry, application or transaction
• Creating and using an account
• Uploading evidence or identity documents
• Understanding errors and recovering from them
• Contacting a person through an alternative channel

A marketing page and a multi-step application are both important, but the cost of failure can differ. Critical journeys guide research, design attention and testing depth.

Set the target and evaluation scope

Record the agreed standard, level, website scope, included technologies and any sector or procurement requirements. Decide who can approve interpretations, exceptions and remediation priorities.

If formal conformance evidence is required, involve an accessibility specialist early. An ordinary agency review and a formal evaluation programme are not the same service.

Audit content, technology and third parties

Discovery should examine:

• Current templates, components and recurring barriers
• PDFs, video, audio, charts and interactive tools
• Authentication, payment, booking and embedded services
• Content-management capability and author controls
• Required browsers, devices and assistive-technology scenarios
• Third-party products that may constrain remediation
• Internal skills, publishing processes and support ownership

An inaccessible dependency cannot always be corrected from the website layer. Procurement and architecture decisions can determine what is achievable.

Build accessibility into acceptance criteria

Translate the target into requirements that teams can design, implement and test. “Meet WCAG” is too broad for daily delivery. A form story, for example, should include labels, instructions, keyboard operation, error identification, focus movement, status messages and recovery states.

Information architecture and content carry accessibility

Accessibility is often discussed as a front-end engineering issue. Content and structure create many of the conditions people experience.

Headings, labels and link purpose

Clear headings help people scan visually and navigate with assistive technology. Descriptive link text communicates destination without requiring the surrounding paragraph. Consistent labels reduce cognitive load.

These are editorial decisions supported by the CMS. A developer cannot repair an organisation-wide culture of vague links and unstructured documents through a one-off code change.

Plain language and instructions

People need to understand what is required, why information is requested and how to recover from an error. Plain language benefits many users, including people with cognitive disability and people reading in a second language.

Do not rely on placeholder text for instructions. Keep critical help near the field or task. Explain unfamiliar formats and requirements before the user submits.

Images, charts and media

Plan text alternatives according to purpose. A decorative image may need an empty alternative; an informative image needs an equivalent description; a complex chart may need nearby data or a longer explanation. Video may require captions, transcript and audio description depending on its content and the applicable criteria.

These assets must be commissioned and budgeted. A transcript cannot be recovered from an unrecorded event, and meaningful alternative text requires editorial understanding.

Document strategy

PDFs and office documents can carry significant barriers. Decide whether important content should be available as accessible HTML, whether source documents can be remediated and who maintains them. A website can have accessible navigation while sending users into an inaccessible document library.

UX and design systems turn requirements into patterns

A design system can multiply accessibility or multiply barriers.

Interaction must not depend on one mode

Every function should work without requiring a mouse or a precise touch gesture. Keyboard order should follow the logical visual and reading sequence. Visible focus must show where the user is. Dragging interactions need an alternative that does not require dragging when WCAG 2.2 applies.

Design for reflow, zoom and text change

Responsive design is not only about device widths. Users may zoom, enlarge text or change spacing. Components should reflow without hiding content or requiring unnecessary two-dimensional scrolling at the relevant sizes.

Colour is only one signal

Contrast matters, but accessibility is not achieved by passing a palette calculation. Do not use colour alone to communicate status, selection, error or required action. Define hover, focus, active, disabled, error and success states explicitly.

Components need complete behaviour

A modal is not only a rectangle above the page. It needs an accessible name, sensible focus placement, keyboard behaviour, background handling, close control and focus return. A custom select, carousel, accordion or autocomplete carries its own state and announcement requirements.

Design reviews should inspect these states before development. Component documentation should explain both appearance and behaviour.

Authentication deserves particular care

WCAG 2.2 adds accessible-authentication criteria intended to reduce reliance on cognitive-function tests. Identity and security teams should be involved in choosing mechanisms that meet risk requirements without creating avoidable barriers. Password managers, copy and paste and alternative methods may be important parts of the experience.

Development must preserve semantics and resilience

Developers translate the experience into code, but they should not have to infer all accessibility requirements from static screens.

Use native HTML controls where they meet the requirement. Native elements carry semantics and expected keyboard behaviour that custom widgets must recreate. Ensure names, roles, values, instructions, relationships and status changes are available to assistive technology.

Manage focus intentionally during route changes, validation, modals and dynamic updates. Avoid hiding meaningful content visually while leaving it confusingly active for keyboard or screen-reader users. Test loading, empty, error, expired and permission-denied states, not only successful content.

Accessibility also intersects with performance and resilience. Heavy scripts, delayed interfaces or inaccessible error handling can block task completion. Third-party components need the same scrutiny as custom code.

Evaluation needs several methods

W3C’s Easy Checks explicitly describes preliminary checks as a starting point rather than a definitive evaluation. A page may appear to pass them while still containing significant barriers.

Use a layered approach.

Automated checks

Automation is fast and repeatable for detectable issues such as some missing names, invalid relationships and contrast failures. Integrate it into development and regression testing. Do not report an automated score as a conformance result.

Manual expert review

Manual review covers keyboard operation, focus, semantics, reading order, reflow, content meaning, dynamic states and the application of criteria that require judgement.

Assistive-technology scenarios

Test representative priority tasks with agreed combinations of browsers and assistive technologies. No single combination represents every user, but scenario testing exposes barriers that code inspection can miss.

Evaluation with people with disability

User research and usability evaluation can reveal practical barriers and workarounds. It complements technical conformance work rather than replacing it. A person completing one task does not establish that every criterion across the site is satisfied.

Record findings against affected journeys and components, assign owners, fix the cause and retest. Repeated component failures should be corrected in the design system rather than patched independently on every page.

Accessibility continues after launch

A conforming release can deteriorate when editors add poor headings, upload inaccessible documents, omit text alternatives or embed a new third-party tool.

Create an operating plan that covers:

• Accessible content guidance and CMS author support
• Approval for new components and vendors
• Regression tests for releases
• Periodic evaluation of representative journeys
• A clear way for users to report barriers
• Triage, remediation and communication
• Ownership for public accessibility information where used

Measure more than issue counts. Include successful task completion, customer feedback, recurring support barriers and time to remediate critical issues.

A public Emote example without a certification claim

Emote’s Primary Dental case study describes a website programme across more than 60 locations, with multiple integrations, SEO migration, transition and security considerations.

That public example demonstrates why a multi-audience service needs early planning across structure, journeys and systems. It does not state that the website achieved WCAG 2.2 conformance, and this article makes no such claim. If Emote wants to publish an accessibility outcome for any client, it should first confirm the evaluation scope, target, evidence and permission.

Questions to ask an agency or internal team

• Which WCAG version and level are in scope?
• Which pages, processes, documents and third-party services are included?
• How will people with disability inform research or evaluation?
• How do acceptance criteria flow into design and development work?
• What automated, manual and assistive-technology testing is included?
• Is the service a general review or a formal conformance evaluation?
• Who remediates findings and confirms the fixes?
• What evidence and limitations will be reported?
• How will accessibility be maintained after launch?

Clear answers make proposals easier to compare and reduce the risk of assuming that every agency means the same thing by “accessible”.

Frequently asked questions

Is WCAG 2.2 legally required for every Australian website?

This article does not provide legal advice. Australian anti-discrimination obligations and sector or procurement requirements may apply in different ways. The Australian Human Rights Commission provides current guidance and recommends WCAG 2.2 Level AA as a minimum target. Obtain advice appropriate to the organisation and service.

Does an automated accessibility score prove conformance?

No. Automated tools detect only some issues. Conformance evaluation requires a defined scope and a combination of methods, including informed human judgement.

Can a website be WCAG certified?

WCAG defines conformance, not a universal W3C certification programme for commercial websites. Be precise about the version, level, scope, evaluator, date and limitations of any claim.

Is accessibility mainly a developer responsibility?

No. Leadership, researchers, content teams, designers, developers, testers, procurement teams and website owners all influence the result.

Can accessibility be added to an existing website?

Barriers can be audited and remediated, sometimes progressively. Architecture, third-party and component limitations may make some changes substantial. Prioritise critical journeys while developing a controlled whole-site plan.

Does every website project need a formal accessibility programme?

The depth should reflect user needs, obligations, risk and procurement requirements. Every project should consider accessibility from the beginning. A formal conformance programme requires defined scope, specialist evaluation and evidence beyond ordinary quality assurance.

Build accessibility into every decision that shapes the experience

Final testing matters because a claim needs evidence. It is not the stage where accessibility should first appear.

Discovery defines audiences, tasks, risks and requirements. Content and information architecture make meaning clear. UX and design systems establish usable patterns. Development preserves semantics and behaviour. Combined evaluation finds barriers. Governance keeps the service accessible as it changes.

If accessibility is important to your next website or digital-transformation project, book a meeting with Emote. We can include it in the early qualification and planning conversation, then recommend the appropriate Discovery, design, delivery and specialist-evaluation pathway.