How to audit your website's accessibility using simple tools
An accessibility review should answer a plain-language question: can people perceive, understand and operate the website with the access needs and tools they use? A practical accessibility audit combines automated checks with short manual test passes. Scanners are good at spotting repeated markup problems; they cannot tell whether labels make sense, instructions are clear or an error message helps someone recover.
Start with the journeys that matter most rather than trying to inspect every URL at once. Choose pages for search, product or service details, forms, checkout or booking, account access, contact, help and consent controls. Include content published through different systems, because inaccessible components often appear when a new page builder, campaign template or embedded widget is introduced.
Australian organisations face clear expectations. The Disability Discrimination Act 1992 and DDA Rules 2016 are relevant to many businesses and public bodies, and legal duties depend on the service context. Commonwealth agencies and many state or local government services use WCAG as their digital-access benchmark. Canberra-based agencies behind the NDIS and Services Australia show why accessibility belongs in service design rather than a final compliance pass. Delivering a fair go online means removing barriers, not merely publishing a conformance statement.
Plan a repeatable block of work and keep evidence as you go. Record each page, browser, assistive technology, test step and result, then distinguish a technical defect from awkward content. This approach lets a small team improve the whole site and gives leaders a defensible view of risk, progress and remaining work.
Set a clear accessibility baseline
Choose WCAG 2.2 Level AA unless a contract, policy or regulator requires another version or conformance level. WCAG 2.1 AA remains a common procurement requirement in Australia, so record the exact standard being tested rather than treating every “WCAG compliant” claim as equivalent. The standard should guide the audit, while actual user tasks determine how severe each failure feels.
Translate the standard into a short test set. Cover keyboard access, focus visibility, meaningful page structure, alternative text, form labels and instructions, error prevention, colour contrast, zoom and reflow, and compatible input methods. For each check, define what “pass” looks like and save a screenshot or short note showing the result. This prevents a tool’s traffic-light score from becoming the only measure.
Limit the first audit to representative templates and high-traffic journeys. A small sample might include the home page, a search-results page, a long article, an item or service page, a form, a payment or booking flow, and an error state. Add pages built from each component library. A manageable first pass produces useful evidence quickly and identifies which templates need attention across the wider site.
Run automated checks across representative pages
Free tools such as WAVE, axe DevTools, Lighthouse and Accessibility Insights can inspect page structure, names, contrast and common ARIA errors. Run more than one checker where practical, because each uses different rules and some report the same issue differently. Treat findings as leads: verify them in the browser, record genuine impacts and avoid claiming that a clean automated report proves accessibility.
Use Webyzer as a complementary site-health check. Its technology, domain and loading data can reveal whether scripts, trackers or a heavy template are likely to complicate the pages you need to test. If a submitted domain is flagged as invalid or restricted, confirm the address and whether access is deliberately limited, then use a local copy when appropriate; neither step replaces an accessibility scan or manual keyboard and screen-reader review.
Save each report with the URL, date, tool version and template name, then group issues by cause rather than page. Repeated failures often come from one navigation component, form field or content style, so fixing the shared component can remove many findings at once. Where findings must move from a spreadsheet into a DNN reporting workflow, an overview of custom API development explains how data can be exposed securely, provided access controls and validation are in place.
Test keyboard navigation and focus order
Put the mouse aside and press Tab from the top of each core page. Every interactive control should receive focus in an order that matches the visual and logical sequence, while a visible focus indicator shows where the keyboard user is. Check links, buttons, menus, accordions, cookie choices, search fields and embedded media controls. A keyboard trap, hidden control or focus that jumps to the end of the page is a serious barrier.
Complete the main task without a pointing device. Use Space or Enter for buttons, arrow keys where the component supports them, and Shift+Tab to move backwards. Make sure error messages appear near the relevant field and that focus moves predictably after validation. Custom dropdowns, date pickers and modal windows are frequent trouble spots, particularly when they trap focus or close before the user can confirm the change.
Check the available skip link and heading sequence as part of the same pass. The skip link should be the first useful stop and move focus to the main content, not merely scroll the viewport. Headings should describe the content hierarchy, and landmarks should make major regions identifiable. These details improve orientation for screen-reader users and keyboard users alike, while also giving search engines a clearer understanding of the page.
Check screen readers, structure and forms
You do not need specialist screen-reader expertise for an initial audit. Learn enough of VoiceOver on macOS or iOS, NVDA on Windows, TalkBack on Android or Narrator to navigate headings, links, form fields and notifications. Testing with two platforms can expose different behaviour, but one familiar tool used consistently is more useful than several tools used without notes. Speak the interface aloud where possible so the spoken order becomes evidence.
Listen to the page before judging its appearance. Headings should move through a logical hierarchy, lists should announce their structure, and links should make sense out of context. Images need an accurate text alternative when they convey information; decorative images should be hidden from assistive technology. For video, check captions, audio description where needed and an accurate transcript, particularly for training, safety and customer-service content.
Forms deserve a separate screen-reader pass. Every control needs a programmatic label, required fields must be identified in text, and instructions should explain format or timing before submission. Error summaries should identify the field and how to fix the problem, while dynamic messages should be announced without stealing focus unexpectedly. Test successful submission too, because a polite confirmation may be the only feedback a screen-reader user receives.
Review contrast, zoom, reflow and mobile behaviour
Check text and meaningful interface colours with a contrast tool, then confirm the result visually. WCAG Level AA generally requires at least 4.5:1 for normal text and 3:1 for large text, while key controls and graphical objects also need sufficient contrast against adjacent colours. Never use colour as the only signal; pair a red error with text, an icon with a visible label, and a required marker with a programmatic requirement.
Test zoom and reflow at 200 per cent and at a 320 CSS-pixel viewport width without horizontal scrolling for ordinary content. Confirm that headings, fields, menus and error messages stay usable when text is enlarged. Check target sizes, spacing and touch behaviour on a real phone, while also trying a hardware keyboard if the site is used for travel booking or account management. Melbourne commuters and Sydney workers may open these pages on a phone between meetings, so responsive design must support touch as well as pointer input.
Accessibility and speed are related, though they are not the same. A person using VoiceOver on a phone in regional Western Australia may face both a variable mobile connection and an overbuilt page. Research on website speed and conversions explains the commercial cost of delay; slow pages also make it harder for users with cognitive disabilities to complete a task. Use browser throttling to check that scripts do not block essential controls and that the main content appears promptly.
Turn findings into fixes and a repeatable audit cycle
Write each confirmed issue as a short ticket with its URL, affected component, WCAG criterion, reproduction steps, user impact, suggested fix, owner and due date. Rank blockers first: an inaccessible login, payment, consent or navigation control can prevent the whole journey, while a minor caption issue on a rarely visited page may wait. This gives designers, developers, content teams and procurement owners a shared priority rather than a long, disconnected report.
Retest the fix in the same environment that exposed the problem. A component can pass after a code change but regress when a new script, cookie banner or campaign layout is added. Keep a short before-and-after record, retain the scan output and include accessibility checks in design reviews, CMS publishing rules and release sign-off. Return to Webyzer to check or update the domain and compare the broader technology and loading snapshot after major releases, while keeping the detailed accessibility evidence in the audit log.
Start now with one high-value journey: scan it, complete it by keyboard, test one form with a screen reader, record the blockers and assign the first fixes before the next release.
