Australian businesses should make their digital goods and services usable by people with disability. The Disability Discrimination Act (DDA) prohibits disability discrimination in relevant areas of public life. Australian Human Rights Commission (AHRC) guidance recommends WCAG 2.2 Level AA as the minimum technical target. No scan or plugin proves the whole task works or guarantees compliance.
Disability covers a wide range of sensory, physical, cognitive and neurological experiences. In the ABS 2022 disability survey, 21.4% of Australians had disability, about 5.5 million people.
That's population prevalence, not the share of your visitors who get blocked or a revenue forecast. Don't try to infer anyone's disability or assistive technology from analytics either.
Start with one practical task. Find key information, complete a real enquiry or booking, and check the confirmation can be perceived. Use a test environment and safe test data where you can. Don't send live test enquiries without the business's approval.
Not every failure is an accessibility problem. Our guide to diagnosing failed customer journeys covers the wider picture. For the build side, see our small business website guide.
What does Australian law require?
The DDA makes disability discrimination unlawful in covered areas of public life. Goods, services and facilities are one of those areas.
Section 24 of the Act covers anyone providing goods or services, paid or not. It makes discrimination unlawful in refusing service, in the terms offered and in the manner of providing it. For a legal review, these sections are the starting point:
sections 5 and 6, on direct and indirect discrimination
section 24, on goods, services and facilities
sections 11 and 29A, on unjustifiable hardship
Not every WCAG failure automatically proves unlawful discrimination. Coverage depends on the actual conduct, service and circumstances. Section 24 doesn't set a business size threshold.
Whether unjustifiable hardship applies depends on the facts. The AHRC's workplace guidance says it turns on what's fair and reasonable in the circumstances. It also says the party relying on it has to show it.
Guidance isn't the law
The AHRC's digital access guidelines say they aren't legally binding. Relying on them may not protect an organisation from a finding of unlawful discrimination. The AHRC's standards page recommends WCAG 2.2 at a minimum of Level AA.
So treat AA as the practical target, with a defined review scope. Keep the legal conclusion separate. State and territory laws, sector rules and contracts can add their own requirements. Our wider website compliance checklist covers the other rules.
Web access isn't a new issue. In 2000, the Commission decided Maguire v SOCOG, the Sydney Organising Committee for the Olympic Games. It concerned the Olympics website. It upheld the relevance of WCAG under the DDA. Treat it as history, not a guide to penalties today.
Requirements usually come from four places at once:
These can apply together. They aren't four alternatives to choose between.
Rule or requirement | Status | What it means for you |
|---|---|---|
DDA discrimination provisions | Law, unlawful where the statutory test is met | Get advice on the actual conduct and service |
AHRC WCAG 2.2 AA recommendation | Regulator guidance | Use it as the technical target |
Government service or tender terms | Policy or contract | Check the agency, procurement and service scope |
Elev8d test and release process | Our practice | A proposed process, not legislation |
WCAG 3 material | Draft technical work | Watch it, but keep WCAG 2.2 as the target |
Government services
Government services have their own standard. The Digital Inclusion Standard applies to specified Australian Government digital services. New and replacement services came into scope on 1 January 2025. Existing public facing services followed on 1 January 2026.
Watch the dates. The AHRC's standards page still shows an earlier date for existing services. The Digital Transformation Agency's dates take precedence, because it administers the standard.
It isn't a blanket rule for private businesses. A supplier can still face accessibility deliverables through a contract. Check the actual procurement terms and any exemptions.
NDIS providers and other sectors
The NDIS Practice Standards set provider responsibilities. They include giving information in the language, mode and terms a participant is most likely to understand. That's a communication duty, not a separate WCAG certificate for every NDIS related website. Apply it to service information, consent and enquiry journeys.
Other sectors add their own rules. Our guide to professional services website requirements covers one example.
Does EU accessibility law affect you?
The European Accessibility Act (EAA) applies through EU member state law to covered products and services, including ecommerce.
The Council of the EU explains that the act is a directive. Each member state decides how to implement it. Your Europe lists online shops, ticketing and banking among covered services.
An Australian business serving EU consumers should check whether its offer and target market bring it into scope. A website that can be viewed from Europe isn't automatically covered.
Service micro enterprises, with fewer than 10 employees and under €2 million turnover, are exempt. Products, transition arrangements and other exceptions need separate assessment.
A WCAG 2.2 AA test isn't complete EAA compliance. Check the national rules with an adviser in the relevant market.
What WCAG 2.2 AA means
WCAG, the Web Content Accessibility Guidelines, is the W3C's technical standard for accessible web content. WCAG 2.2 groups its requirements under four principles:
Perceivable: people can perceive the information, for example through text alternatives
Operable: people can use the controls, for example with a keyboard
Understandable: content and behaviour make sense, like clear error messages
Robust: it works with assistive technology
Understandable starts with the words. Our guide to plain website copy helps there.
Levels are cumulative. AA means meeting every applicable A and AA criterion, not scoring 80% or passing on average. AAA adds further criteria. W3C doesn't recommend requiring it as a general policy for entire sites.
W3C's conformance requirements also cover full pages and complete processes. Excluding part of a page breaks conformance. Every page in a process has to conform too.
WCAG 3 is still a draft. W3C says WCAG 3 won't supersede WCAG 2. WCAG 2 won't be deprecated for several years after WCAG 3 is finished. Keep WCAG 2.2 as the target.
The 24 checks below are a practical orientation. They don't restate every AA criterion. WCAG won't cover every individual need either. User research still matters.
Checks 1 to 6: content and visual presentation
The 24 practical checks come in four groups. They keep the same order as before, so existing notes still line up. Each names the relevant WCAG criterion where that helps.
Check 1: useful image alternatives
Describe the information or function an image provides in context. W3C's images tutorial gives decorative images an empty alternative. A linked image should describe its action or destination. Complex charts need a full text equivalent, because a short alt phrase can't carry the data. Test it with a screen reader and listen to what each image announces.
image123.jpg
View the restaurant menu
In this example, the image opens a restaurant menu. The same image would need different text if it were decorative or informational. A common mistake is leaving the file name as the alternative.
Check 2: text contrast
WCAG's contrast minimum asks for at least 4.5:1 for normal text and 3:1 for large text. Large means about 24 CSS px regular or 18.5 CSS px bold. Logos and incidental text are exceptions. Non text contrast is separate, covering controls, states and meaningful graphics.
Check real states, like hover and focus, and text over images. Here's a worked example with opaque colours. Black text on gold #F4A000 has a contrast ratio of about 9.87:1. White text on the same gold is about 2.13:1. That fails both the 4.5:1 and 3:1 thresholds.
That's a calculation for one colour pair. It isn't an audit of any Elev8d component or its current styles.
Check 3: meaning beyond colour
Don't rely on colour alone. Add words, shapes or patterns. That applies to errors, selected states, chart series and stock status. A green and red pair shouldn't be the only signal. Viewing the page in greyscale is a quick way to test it.
Check 4: readable typography
Keep body text a readable size, with comfortable line spacing. There's no WCAG rule requiring 16px body text. Text spacing means users can increase spacing without losing content. The test values aren't required defaults. Override the spacing to those values and look for clipped or overlapping text.
Check 5: resize and reflow
These are two different checks. Text must resize to 200% without loss. Reflow asks content to work at a width equal to 320 CSS pixels without scrolling in two directions.
Reflow is commonly tested at 400% zoom on a 1,280 pixel wide window. Data tables and maps are exceptions, as genuinely two dimensional content. The content around it still needs to reflow. A common mistake is testing 200% zoom and calling reflow done.
Check 6: structure and headings
Use real headings and logical sections. Don't pick heading levels for their font size. Check the page title and language setting too, plus landmarks, the page regions like header, main and footer. An automated heading order check can't tell whether the structure makes sense. A screen reader's headings list shows the outline quickly.
Checks 7 to 12: navigation and interaction
These checks cover how people move through the site and operate its controls.
Check 7: descriptive links
Link text should say where it goes or what it does. Link purpose in context is a Level A criterion, so AA conformance includes it. Clear standalone link text is good practice on top. A screen reader's links list quickly exposes vague links like "click here".
Check 8: keyboard operation
Without a mouse, test:
navigation and menus
dialogs and forms
booking and checkout
Native controls use different keys. Don't insist every control responds to both Enter and Space. Where a task needs dragging, offer a single pointer alternative unless dragging is essential.
Check 9: visible focus
Every interactive control needs an obvious focus indicator, including inside overlays. Tab through the whole journey. A screenshot of the first focused link isn't enough.
Check 10: focus and sticky layers
At AA, author created content mustn't entirely hide a focused component. Full visibility is better still. Check sticky headers, cookie banners and chat buttons, especially on mobile. Tab through the page with each one showing.
Keeping focus inside an open modal can be correct. W3C's modal dialog pattern moves focus into the dialog, keeps Tab inside it and returns focus on close. The problem is a dialog you can't operate or dismiss, or focus that gets lost after it closes. Copying the pattern's attributes doesn't make a dialog accessible. Test it with assistive technology.
Check 11: names and target size
Icon buttons need a meaningful accessible name, the name a screen reader announces. Target size minimum asks for 24 by 24 CSS pixels at AA, with spacing and other exceptions. Bigger targets are kinder. Size alone doesn't prove a control passes. Check icon names with a screen reader or the browser's accessibility inspector.
Check 12: persistent form labels
Give every field a visible, meaningful label that's linked in the code. A common mistake is using placeholder text as the only label. Keep the visible label in the accessible name, so voice users can say what they see. Custom controls need correct semantics and behaviour.
Click each label to test it. Focus should move to its field.
Checks 13 to 18: forms, help and media
Forms and media are where many tasks succeed or fail.
Check 13: useful error and success feedback
Identify the field and explain how to fix it. Keep safe entered data. Cover server failures, duplicate submissions and success messages too. Submit the form empty, then with mistakes, and listen for each message.
Status messages should reach assistive technology without moving focus unnecessarily. Don't announce success before the system has actually accepted the request.
Error
We couldn't send your enquiry. Your entries are still here. Please try again or use the contact options below.
Use wording like this only if the entries really are kept and the other contact options work. Our guide to clear forms and error recovery goes further.
Check 14: clear required fields
Say in visible text which fields are required, and mark them in the code where appropriate. Explain any asterisk. Only ask for what the task actually needs.
Check 15: reuse input and accessible authentication
Redundant entry means details already given in the same process are filled in or selectable, with exceptions. Accessible authentication means no memory or puzzle test without an alternative or help. Test these:
password managers and pasting
multi factor steps
account recovery
Don't remove security controls as an accessibility fix. Pasting a code is a simple help that keeps the security in place.
Check 16: consistent navigation and help
Keep repeated navigation and controls predictable. If help like a phone number appears on several pages, keep it in the same relative order. WCAG doesn't require a help mechanism at all. There's no rule to add live chat. Compare where help sits on three or four pages.
Check 17: bypass repeated blocks
Provide a way to skip repeated navigation. Check the skip link appears on focus. Then check where it lands and where focus goes next.
Check 18: media alternatives
Prerecorded video needs accurate captions, including speakers and meaningful sounds. A common mistake is publishing automatic captions without reviewing them. Fix wrong names, prices or instructions. Watch with the sound off, then listen without the picture.
A transcript isn't audio description. At AA, prerecorded video needs audio description when important visual information isn't in the soundtrack. If the soundtrack already covers it, no extra description is needed.
Checks 19 to 24: motion, documents and third parties
The last group covers movement, files and the tools other companies supply.
Check 19: user control of audio
Prefer playback the user starts. If audio plays automatically for more than three seconds, it needs a pause, stop or separate volume control. Check it doesn't drown out screen reader speech.
Check 20: motion and user preferences
Respect the reduced motion setting, especially for motion triggered by interaction. That's an AAA criterion, so treat it as strong practice. Turn on your device's reduce motion setting and reload the page to test it.
Separately, automatic moving or scrolling content lasting over five seconds needs a pause, stop or hide control. That one is Level A, unless the movement is essential.
Check 21: flash safety
Nothing should flash more than three times a second. The exception is flashing below the general and red flash thresholds. Frequency alone isn't the whole test. Avoid risky flashing effects, and get a qualified assessment if you're unsure.
A reduced motion setting doesn't replace pause controls or a flash assessment.
Check 22: tables and charts
Use real tables with headers linked to their cells. Complex graphics need their relationships and values in an accessible form. Keep meaning available without colour or hover. Horizontal scrolling can suit a genuinely two dimensional table. Use a screen reader's table commands to check each cell announces its headers.
Check 23: documents
Check each document for:
reading order and structure
text alternatives and language
tables and form fields
W3C's technique for optical character recognition (OCR) shows text recognition is only the first step. Tags and reading order still need fixing. Use accessible HTML for key service information, with an accessible download if needed. HTML isn't automatically accessible either. Menus are a common case, covered in accessible online menus and booking information.
Check 24: third party interfaces
Test each embedded tool where it actually appears:
cookie choices
booking and payment
maps and chat
Include loading, error and confirmation states. Check focus moves into the widget and its labels are announced. A vendor report is useful evidence, not a replacement for testing the integration. For stores, see checking the complete ecommerce journey.
Don't make an inaccessible parallel page the default fix. Make the main journey usable wherever you can.
Four journey checks to add
The 24 checks miss some important journeys. Add these four, without renumbering the list above. Even together, they aren't a complete WCAG conformance test.
Time limits
Check whether an enquiry, booking or account session can expire before someone finishes. Timing adjustable asks you to let people turn off, adjust or extend a limit the content sets. It has exceptions, like a real time event such as an auction, or an essential limit.
That isn't an instruction to remove security timeouts. Plan a recovery that keeps appropriate input without exposing sensitive information.
Important submissions
Error prevention for legal, financial and data submissions covers commitments, payments and changes to stored data. Those submissions must be reversible, checked for errors or confirmed before they're final.
Date: [booking date and time, with a change link]
Quantity: [number of guests or items, with a change link]
Total: [amount including GST]
Confirm: [pay button that submits only after this review]
This example review screen is the confirm option. A simple contact form doesn't need an elaborate confirmation step.
Interactive charts and calculators
Test a calculator from its labelled inputs, through any errors, to an announced result. Test charts with:
a keyboard
a screen reader
magnification
reduced motion settings
Keep categories and values available as real text or an accessible table. The alternative should give the relationships and the takeaway, not just the word "Chart". Avoid duplicate announcements when a decorative graphic repeats the same information.
Staff publishing
A public page can work while an editor with disability can't update it. So include a short staff task. Ask an editor, using their usual technology, to:
change a heading
add a meaningful image alternative
check the preview
publish or submit for approval
The Authoring Tool Accessibility Guidelines (ATAG) cover both sides. Part A is about an accessible editing interface. Part B is about helping authors produce accessible content. For the wider workflow, see CMS editing and approval workflows.
Which accessibility fixes come first?
Prioritise by observed harm and task impact, not by the category of the issue.
The same logic works as a table:
Priority question | Action |
|---|---|
Could the issue cause harm or block an essential task? | Contain the harm, provide a usable route and arrange urgent repair |
Does it make information or operation substantially harder? | Assign an owner and a deadline based on impact and exposure |
Is it untested, or is applicability unclear? | Investigate, keep the uncertainty visible and don't mark it Pass |
Has a repair been made? | Retest the task and shared components before closing it |
A category label alone isn't enough. A missing transcript may remove the only usable information. Motion can cause serious difficulty. Don't rank those below a minor heading issue by default.
An alternative contact route doesn't erase the original barrier. Fixes also have typical owners:
Role | Typical fixes |
|---|---|
Content | Image alternatives, link text, headings, captions and documents |
Design | Contrast, focus styles, layouts and target sizes |
Development | Keyboard support, accessible names, status messages and components |
Treat these as typical owners until your team agrees the real split. Content work takes time too. Some fixes cross roles.
A shared component can repeat one defect across hundreds of pages. Log the root cause and the affected tasks. If repairs start to look like a rebuild, use the redesign project checklist to scope it.
Can an overlay make a website compliant?
An overlay is a toolbar or script added on top of a site. It can add settings or change some output. Its presence doesn't prove the whole site conforms.
Installing this widget makes the whole website compliant
Check the actual improvements, unresolved barriers, compatibility and complete task results before making a claim
Evaluate the specific product, the barriers it leaves and independent test results. Fix source content and components where you can.
One US example shows the risk of overstated claims. On 22 April 2025, the US Federal Trade Commission (FTC) approved a final order against accessiBe. It requires a US$1 million payment. The FTC alleged its tool didn't make all websites WCAG compliant. It also alleged reviews were presented as independent when they weren't.
That's a US consent order. It isn't an Australian ruling, a finding about every overlay or an audit of your installation.
How to test real website tasks
Good testing starts with scope, not a homepage scan. Record these before you start:
site version, WCAG version and level, and languages
representative templates and complete business processes
devices, browsers and assistive technology combinations
states like errors, loading and empty results
dialogs, consent banners and signed in pages
Then test complete tasks, from entry through confirmation and recovery. A common mistake is testing the homepage and stopping there.
These methods overlap and repeat. None of them certifies the others. For a wider site review alongside, see a broader website audit.
Automated checks
Record the tool, version, settings, page state and findings. Review possible false positives and gaps. Several scans using overlapping rule engines aren't independent proof.
Human review
A person needs to check what tools can't judge:
whether content and error messages make sense
keyboard operation
resizing and reflow
captions and other media
Use real assistive technology, with someone competent in it. A first screen reader try is useful learning, not a professional evaluation.
Testing with people with disability
W3C recommends combining user involvement with conformance evaluation. Plan participation carefully:
recruit through accessible channels, for a range of relevant needs
let people use their familiar equipment where practical
give accessible instructions and agreed support
get informed consent and pay people for their time
Don't ask for diagnoses the research doesn't need. Never profile visitors covertly to find disability. W3C also warns against assuming one person's input applies to all people with disabilities. A small study gives specific observations, not a population pass rate.
Reporting
State exactly what was evaluated, what failed, what's unknown and the limits. Then record the retest result.
W3C's evaluation method uses a defined scope and a representative sample. Even so, three passing pages don't show that every page or process conforms. A conformance claim needs:
a date
the scope, meaning the pages or processes covered
the WCAG version and level
the technologies relied on
Without those, don't publish a conformance claim at all.
Our free audit checks the most common accessibility barriers, then tells you which to fix first.
Tools and what their results mean
Each tool answers a narrower question than it first seems to.
Tool or method | Use | Limit |
|---|---|---|
Elev8d quick check | Guided manual self review of stated checks | Weighted answers, not a scan or a conformance percentage |
Lighthouse | Automated accessibility checks in Chrome | Manual checks don't count in its score |
WAVE | Finding potential issues on a page | A person still interprets the results |
W3C tools list | Finding other free and paid checkers | W3C doesn't endorse specific products |
Keyboard and assistive technology | Completing the real task and recovery | One setup doesn't cover every person |
W3C Easy Checks | A structured first look | Not a full standards evaluation |
Lighthouse's accessibility score is a weighted average of automated audits. Manual audits don't affect it. So a score of 100 can't show full WCAG conformance.
WAVE flags many issues and supports human evaluation. Its browser extensions suit password protected or local pages. W3C's list of web accessibility evaluation tools covers other free and paid checkers. W3C Easy Checks are quick and not definitive.
Don't paste private customer pages, credentials or personal information into a public checker. Use an authorised local or signed in testing setup instead.
Our quick check is a manual review, not an automated scan. Its score weights your answers and keeps unknowns visible.
Lighthouse's performance numbers are a separate topic. For the difference, see performance field data and lab tests.
An accessibility audit worksheet
A worksheet turns testing into findings someone can fix and retest. These are the fields to keep:
Field group | Fields |
|---|---|
Scope | Finding ID, page or route, template, task, state, date, site version |
Method | WCAG criterion, tool and version, browser, device, assistive technology |
Observation | Steps, expected outcome, observed barrier, evidence reference, affected scope |
Decision | Pass, Fail, Not tested, or Not applicable with a reason, plus severity and why |
Action | Owner, proposed fix, priority, target date, temporary usable route |
Closure | Retest method, tester, date, result, remaining limitations |
Each finding follows the same record:
Task: [what the person was trying to complete]
Scope: [page, template, state, date and version]
Method: [criterion, device, browser, tool and assistive technology]
Steps: [how to reproduce the issue safely]
Expected: [usable outcome]
Observed: [barrier and evidence reference]
Status: [pass, fail, not tested or not applicable with reason]
Action: [owner, severity rationale, fix and date]
Retest: [tester, method, result and remaining limitations]
Here's an example finding. Opening a booking dialog by keyboard puts focus behind a fixed banner. The user can't tell which control is active. Record the exact state and the steps to reproduce it.
A pass applies to the recorded check and setup, not the whole site. A fixed ticket stays open until someone retests the task. Keep sensitive research records out of a shared worksheet, and use dummy examples.
An editable file version isn't published yet. Until it is, copy the fields above into a spreadsheet with Instructions, Findings and Retests tabs.
What does accessibility work cost?
There's no reliable Australian average to quote. Cost depends on scope. A quote should separate these lines:
Cost line | What it covers |
|---|---|
Discovery and evaluation | Scoping, testing and the findings report |
Specialist or participant testing | Assistive technology users and their time |
Remediation | Fixing code, design and content defects |
Retesting | Independent checks after fixes, where appropriate |
Content and document repair | Captions, alternatives and accessible files |
Regression checks | Ongoing checks after later changes |
A cheap scanner subscription and a professional conformance evaluation are different scopes. Ask suppliers to state:
the WCAG target and level
unique templates and complete processes in scope
devices and assistive technology combinations
deliverables, exclusions and who repairs defects
included retest rounds and any ongoing work
Raw page count matters less than complexity. Effort rises with:
logins and signed in areas that need test accounts
custom widgets that need manual testing
multiple languages, each needing its own review
large document sets
third party tools you can't change directly
Here's the full working:
Example work | Calculation | AUD excluding GST |
|---|---|---|
Evaluation and report | 12 hours at $150 | $1,800 |
Remediation | 16 hours at $150 | $2,400 |
Retest | 4 hours at $150 | $600 |
Participant sessions and access arrangements | Project allowance | $900 |
Total initial work | All four items | $5,700 |
Every figure is an example budgeting assumption. It isn't a quote, a typical Australian price or a promise that 32 hours achieves conformance. The $900 is one total allowance, not a rate per participant. If every item attracts 10% GST, the tax is $570 and the total is $6,270.
The example leaves out these costs:
a full redesign or rebuild
remediation of a large document library
extensive translation work
replacing an inaccessible third party platform
legal advice and continuing monitoring
The next year isn't automatically free. Planning accessibility early can reduce avoidable rework. Comparing options still needs scoped quotes.
For the wider budget, see website build and running costs. Before a build, start with setting the accessibility scope before a build.
Suppliers and an accessibility statement
For any supplier, ask for current evidence for the exact version and setup you're buying. That might be an accessibility conformance report (ACR) or other test results. Ask about:
known failures and who repairs them
escalation and retesting
update notices
export and replacement options
An ACR is evidence to assess. It isn't automatically an independent certification.
Then test the embedded or redirected journey with your own site and content. Include consent, payment authentication, confirmation and the vendor's support channel. A vendor's assurance, or a phone number, doesn't settle the duty on its own. If a service is blocked, arrange a usable temporary route. Then name an owner for the permanent fix.
If you're choosing a new platform, check accessibility while assessing platform requirements.
The accessibility statement
A statement should cover:
the site or service it applies to
the target standard
a dated assessment scope and known limitations
feedback routes and how requests are handled
Only promise a response time the business can meet. Offer contact that isn't phone only, because phone only excludes some people. Test that the feedback route works and is accessible itself. Someone also has to watch it and reply, because it's a service, not a sentence.
Target: We're working toward [standard and level] for [service scope].
Review: Our latest review covered [pages, processes and date].
Limits: [accurate known limitations and planned actions]
Contact: If something stops you using the service, contact [email or accessible form] or [phone option].
Details: Tell us the task and page involved, and how you'd like a reply.
Response: We aim to respond within [time the business can actually meet].
A statement doesn't remove the duty to fix barriers. Avoid 100% claims. Don't describe a target as achieved conformance.
If the route collects personal information, link your privacy information for feedback and research. Never ask people to explain a diagnosis to report a broken form.
Keep accessibility working as the site changes
Accessibility slips when nobody checks changes. Build it into normal work:
design system acceptance
CMS guidance for authors
release checks
supplier reviews
Recheck after any material change, like a new theme, form or payment step. A fixed review cycle isn't a legal timetable. It can't replace checks after material changes.
Train authors to keep headings, links and alternatives in good shape. Review generated alt text and captions for real meaning. New content and AI features can bring old problems back.
For the release side, use our website launch checks and ongoing maintenance responsibilities. Slow pages can block tasks too. It's worth investigating slow pages as well.
Semantic structure, useful links and text alternatives can help people and search systems alike. Screen readers and search engines still do different jobs. Don't expect an accessibility score to lift rankings on its own. For the search side, see SEO for small business.
What we recommend at Elev8d
Treat accessibility as part of how the site works, not a badge on top. Test the tasks that matter, fix the source and keep the evidence. If you'd like a site built that way, see our website design and development scope.
Frequently asked questions
Does every Australian business need a WCAG certificate?
No certificate is required. The DDA prohibits discrimination. The AHRC recommends WCAG 2.2 AA as the technical target.
Is a 100 Lighthouse score enough?
No. Lighthouse leaves manual checks out of its score, so test real tasks too.
What should an audit quote include?
The scope, the deliverables and the retest rounds. The cost section lists the details to ask for.
Can a vendor's report cover my integration?
Not on its own. It's useful evidence, but test the vendor's tool inside your actual journey.
What if we can't fix everything immediately?
Fix harmful and blocking barriers first. Offer a usable temporary route, and record the remaining work with owners and dates.
Does WCAG 3 replace WCAG 2.2?
No. W3C says WCAG 3 won't supersede WCAG 2. It's also still a draft.
Next steps
Pick the step that fits.
Starting out
Run one real enquiry using only a keyboard this week.
Already testing
Turn your findings into worksheet records with owners and retest dates.
Buying a tool or service
Ask for evidence for your exact setup, then test the journey yourself.
