Scope and standard
Define the parts of the product under review, the target standard and the user journeys that must work.
Find and prioritise barriers
Accessibility auditing
Find accessibility barriers, understand their impact and get clear priorities for fixing them.
Evidence before remediation
Know where the barriers are—and which ones matter most.
An accessibility audit gives a team a defensible view of current barriers. It connects a technical finding to the experience it obstructs, then gives design and engineering a clear order for action. Qern audits websites and web applications to identify accessibility barriers and explain what should be addressed first. Based in Canberra and working nationally, we define the standard, product journeys and testing approach with you before the review begins.
This may be the right fit when
- You need an independent view of accessibility before a release or procurement decision.
- Automated scan results exist, but the team does not know what is significant or how to prioritise it.
- People report keyboard, screen-reader, zoom or interaction problems.
- A product team needs one actionable findings list instead of scattered observations.
What the audit covers
The testing approach follows the product risk.
We agree the journeys, pages, standard and evidence required before testing. Depending on the scope, the review can combine automated checks with focused manual inspection of behaviour that tools cannot judge on their own.
Automated checks
Use repeatable tooling to identify programmatically detectable failures and create a consistent technical baseline.
Interaction review
Where included in scope, inspect keyboard access, focus, structure, reflow and important component behaviour that requires human judgement.
Impact and priority
Connect findings to affected tasks and severity so the team knows which barriers to address first.
Actionable findings
Provide clear evidence, WCAG references and remediation direction that design and engineering can use.
A clear baseline for the work ahead.
The audit is designed around the product rather than a generic page count, then translated into findings the team can act on.
Scope
Agree what must be evaluated.
Confirm the product areas, key journeys, standard, environments and evidence required.
Test
Review the agreed experience.
Run the defined automated and scoped human checks consistently across the selected areas.
Prioritise
Explain impact and urgency.
Group related issues and identify what most seriously blocks people or creates repeated risk.
Report
Give the team an actionable record.
Document the finding, evidence, criterion and practical direction for remediation.
Findings are written for the people who must fix them.
Qern combines accessibility, product design and engineering thinking. The audit does not stop at a technical rule; it explains the affected experience and gives the team enough context to make a useful fix.
An audit is a snapshot of the agreed scope. It identifies and prioritises barriers, but it does not by itself remediate them, certify legal compliance or prevent future releases from introducing new issues.
Frequently Asked Questions
What is accessibility testing?
Accessibility testing checks whether people with different access needs can perceive, understand and operate a digital product. It can combine automated detection with human review of keyboard, structure, reflow, interaction and other behaviour agreed in the audit scope.
Does an accessibility audit make a website WCAG compliant?
No. An audit identifies the state of the reviewed scope at a point in time. Findings still need to be remediated and verified, and later product changes can introduce new barriers.
What is the difference between an audit and WCAG compliance support?
An audit finds, documents and prioritises barriers. WCAG compliance support helps a team interpret findings, change the design or code, review work in progress and verify that fixes resolved the problem.
What standard does Qern audit against?
Qern aligns the audit scope to the standard and conformance target agreed for the product. For new work, WCAG 2.2 Level AA is the expected baseline unless another documented requirement applies.
Start a conversation
Start a accessibility auditing conversation.
You do not need a finished brief. Tell us what you need from accessibility auditing and where you are stuck.
Thanks. Your enquiry is on its way.
We will reply as soon as we can. If it is urgent, email craig@qern.com.au.