Website Accessibility Audit Guide for Hobart Businesses

A useful website accessibility audit checks whether people can perceive, understand and operate your key pages—not simply whether an automated tool shows a high score. For a Hobart business, the audit should combine automated scans, keyboard testing, screen-reader checks, mobile and zoom testing, content review and representative user feedback. It should finish with evidence, priorities, responsible owners and clear retest criteria.

Start with the journeys that matter most: finding contact details, understanding a service, completing a form, making a booking, buying a product or accessing an account. Fix barriers that stop those tasks before spending time on low-impact cosmetic warnings.

What a website accessibility audit should cover

A professional audit examines content, design and code together. The Web Content Accessibility Guidelines, or WCAG, organise accessibility around four principles: content should be perceivable, operable, understandable and robust. WCAG 2.2 contains testable success criteria at Levels A, AA and AAA; the W3C WCAG overview explains how those criteria are structured.

An accessibility audit should normally review:

• page structure, headings, landmarks and reading order;
• keyboard access, focus order and visible focus indicators;
• text and interface contrast;
• image alternatives and meaningful media descriptions;
• links, buttons, labels and instructions;
• forms, errors, validation and status messages;
• zoom, text resizing, reflow and mobile behaviour;
• menus, dialogs, accordions, sliders and other interactive components;
• captions, transcripts and audio controls where relevant;
• documents and downloads included in essential journeys; and
• compatibility with representative assistive technologies.

The outcome should not be a generic list copied from a scanner. Each finding needs the affected URL or component, evidence of the barrier, relevant criterion, impact, recommended change and a way to confirm the repair.

Automated scan vs manual accessibility audit

Method	What it does well	What it cannot confirm alone
Automated scanning	Finds repeatable code patterns quickly across many pages	Whether text alternatives are meaningful, focus order makes sense or instructions are understandable
Keyboard testing	Reveals unreachable controls, focus traps and unclear focus movement	The complete screen-reader experience or every visual barrier
Screen-reader testing	Tests names, roles, states, announcements and reading order	All experiences across every assistive technology and browser combination
Visual and responsive review	Checks contrast, zoom, reflow, target size and content hidden at different widths	Programmatic relationships and announcements that are not visually apparent
User testing	Shows whether real people can complete important tasks in context	Formal coverage of every applicable success criterion

Automated tools are valuable for early detection and regression checks, but they cannot make every human judgement. W3C’s accessibility evaluation overview treats assessment as a combination of initial checks, tools, conformance evaluation and people. A credible audit states which pages, states, browsers, devices and assistive technologies were actually tested.

Why accessibility matters to an Australian business

Accessible design helps more people use a service independently. Improvements such as clear headings, descriptive links, visible focus, readable contrast and helpful errors can also make a website easier for customers using small screens, temporary injuries, slow connections or unfamiliar processes.

The Australian Human Rights Commission published Guidelines on equal access to digital goods and services in April 2025. They are intended to help organisations meet obligations under the Disability Discrimination Act, but the Commission expressly notes that the guidelines are not legally binding and should be read with the legislation and relevant state or territory laws.

This article is practical information, not legal advice. A business dealing with a complaint, contractual accessibility requirement or regulated procurement should obtain advice appropriate to its circumstances.

Choose the right pages for the first audit

Auditing every URL at the same depth may not be the best first use of time. Select a representative sample that covers:

• the home page and primary navigation;
• one or more important service or product pages;
• contact, enquiry, booking and checkout flows;
• login, account and password-recovery screens where applicable;
• common templates such as blog articles and category pages;
• interactive widgets, pop-ups and embedded third-party tools;
• error states, confirmation messages and empty states; and
• high-traffic or high-value pages identified in reliable analytics.

For a Hobart restaurant, the sample might include the menu, booking form, opening-hours page and online ordering. A tourism operator may prioritise accommodation details, availability, payment and confirmation. A professional service business should test service comparison, enquiry and document-download journeys.

DanSol’s practical website improvements guide can help identify other usability and content priorities that should be reviewed alongside accessibility rather than treated as a separate project.

A practical eight-step accessibility audit process

1. Define scope and target

Document the website, essential user journeys, page sample, technologies, supported browsers and intended WCAG version and level. Record what is outside the audit so the report cannot be mistaken for complete-site certification.

2. Map components and content types

Identify shared headers, footers, menus, forms, tables, cards, videos, PDFs, dialogs and third-party embeds. A defect in a shared component may affect hundreds of pages, while a one-off content issue may require a different owner.

3. Run automated checks

Use more than a headline score. Review each result in context, remove false positives and look for repeated causes. Scanning several representative templates can reveal missing labels, invalid relationships, contrast failures and structural problems, but passing a scan is not proof of conformance.

4. Test without a mouse

Use the keyboard to move through the page and complete essential tasks. Confirm that focus is visible, follows a sensible order, reaches every control and never becomes trapped. Menus, date pickers, pop-ups and cookie controls deserve particular attention.

5. Check zoom, reflow and mobile use

Increase text size and browser zoom, then check whether content remains readable and usable without unnecessary two-dimensional scrolling. Test small-screen layouts, orientation changes, touch targets and controls that appear only on mobile.

6. Review with assistive technology

Use representative screen-reader and browser combinations to inspect headings, landmarks, control names, states, errors and dynamic updates. Test meaningful tasks rather than reading the page from top to bottom only.

7. Include human judgement and user feedback

Review whether alternatives explain the purpose of images, link text makes sense, instructions are clear and error recovery is practical. When possible, include people with disability in research and task testing. W3C notes that evaluating accessibility benefits from combined technical and user expertise.

8. Report, remediate and retest

Group findings by impact and underlying cause. Assign owners across content, design, development and third-party suppliers. After changes, retest the exact failure and a suitable regression sample; closing a ticket is not evidence that the barrier is gone.

What a useful accessibility report includes

Ask for a report that another designer, developer or content editor can act on. It should include:

• scope, exclusions and testing date;
• standards, level and evaluation method;
• browsers, devices and assistive technologies used;
• an executive summary of barriers affecting essential journeys;
• findings with URLs, steps, evidence and expected behaviour;
• severity or priority defined in plain language;
• recommended fixes tied to the actual implementation;
• owners and dependencies, including third-party services;
• a remediation sequence; and
• retest results and unresolved limitations.

The W3C provides a recommended accessibility evaluation report format. A business report can adapt that structure while keeping its conclusions and limitations clear.

How to prioritise accessibility fixes

Prioritisation should consider user impact, task importance, reach and the chance of introducing regressions. A sensible order is:

1. Blockers in essential journeys: inaccessible checkout, booking, login or contact steps.
2. Shared component failures: navigation, templates or form controls that repeat across the site.
3. Severe content barriers: missing instructions, unusable documents, absent captions or images carrying essential information without alternatives.
4. Frequent usability problems: weak contrast, unclear focus, vague links and confusing errors.
5. Maintenance controls: editor guidance, design-system rules, testing and release checks that prevent recurrence.

A long issue count can be misleading. Fixing one faulty menu component may remove the same barrier from every page. Conversely, a single inaccessible payment step can matter more than dozens of low-impact warnings.

Audit and repair or redesign the website?

Repair is normally appropriate when the platform is supportable, the design system can be corrected and the main problems are contained in templates, components or content. A redesign or rebuild may be more economical when inaccessible patterns are embedded throughout an obsolete theme, custom code is no longer maintainable or major business and content changes are already planned.

Do not decide from an automated score alone. First estimate the number of shared causes, the risk in essential journeys and the remaining life of the platform. DanSol’s website redesign vs rebuild guide provides a broader framework for choosing the least disruptive route.

If a new or revised site is needed, DanSol’s Hobart web design service can incorporate accessibility requirements into discovery, page structure, component design, development, testing and handover rather than treating them as a final launch check.

Common accessibility audit mistakes

• Calling an automated score an audit. Tools cannot judge every criterion or real task.
• Testing only the home page. Forms, checkouts and account states often contain the most important barriers.
• Ignoring mobile and zoom. A desktop-only review misses reflow, orientation and touch issues.
• Using generic fixes. Adding ARIA attributes without understanding the component can make the experience worse.
• Writing vague tickets. “Improve accessibility” does not identify the barrier or acceptance test.
• Forgetting third parties. Booking engines, maps, payment tools and chat widgets are still part of the customer journey.
• Skipping retesting. A code change may not solve the original problem and can create a new one.

Forms deserve their own detailed review because labels, instructions, errors and status messages work together. Use DanSol’s guide to accessible contact forms for Hobart businesses when reviewing enquiry and lead-generation flows.

Questions to ask an accessibility auditor

1. Which pages, components and user journeys will you test?
2. Which WCAG version and conformance level will guide the work?
3. What proportion is automated, manual and user testing?
4. Which browsers, devices and assistive technologies are included?
5. How do you define severity and business priority?
6. Will findings include evidence, repair guidance and acceptance checks?
7. Can you review fixes and report retest results?
8. How will third-party tools and downloadable documents be handled?
9. What is explicitly excluded from the audit?
10. How will sensitive test data and account access be protected?

Frequently asked questions

Can an automated checker prove that a website is accessible?

No. Automated tools identify some code-based issues efficiently, but many requirements need manual inspection and human judgement. A scan can support an audit; it cannot replace keyboard, assistive-technology and task testing.

What WCAG level should a small business target?

WCAG 2.2 Level AA is a common technical target, but the appropriate requirement depends on the organisation, contract, audience and legal context. Record the chosen target and obtain relevant advice where obligations are uncertain.

How often should a website be audited?

Use a full review after major platform or design changes, then combine scheduled checks with testing during ordinary content and feature releases. High-risk journeys and shared components should be monitored more frequently than stable informational pages.

Will an accessibility audit hurt the website’s design?

No. Accessibility does not require every website to look the same. It asks the design to provide understandable content, sufficient contrast, usable controls, flexible layouts and alternatives where needed. Those constraints can support a clearer design system.

Does fixing accessibility also improve SEO?

Some practices—such as descriptive headings, meaningful links and useful text alternatives—also improve content structure and clarity. Accessibility and SEO remain different disciplines, however. Do not claim that WCAG conformance guarantees rankings or that an SEO score proves accessibility.

Turn the audit into a maintained standard

An audit is valuable when it changes the live experience and the way future work is produced. Fix essential blockers, repair shared components, update content practices and add accessibility checks to design, development and publishing workflows.

Keep the report’s scope and limitations visible, retest completed work and involve users in important journeys. That approach produces more reliable evidence than a one-off score—and helps a Hobart business build a website that more people can actually use.