Web accessibility means designing and building websites so people with visual, hearing, mobility, or cognitive differences can use them just as well as anyone else. If you’re starting from zero, the fastest way in is to run a quick automated scan against WCAG 2.2 AA, note what fails, then fix your headings and alt text first. That single check will show you more than an hour of reading theory ever could.
TL;DR:
- Running an automated scan against WCAG 2.2 AA identifies key issues like missing alt text, poor heading structure, and vague link labels, which are quick to fix.
- Prioritizing fixes such as descriptive alt text, skip links, and accessible form labels can significantly improve accessibility with minimal effort.
- Manual testing using keyboard navigation and screen readers reveals issues that automated tools cannot catch, like content order and meaningful error messages.
- Ensuring your site complies with Australian standards and legal requirements involves aiming for WCAG 2.2 Level AA and documenting your testing process.
- Incorporating accessibility into the initial design phase costs less than retrofitting, making early planning and audits essential for effective implementation.
Table of Contents
- Web accessibility basics: the four principles you need to know (POUR)
- Make your website accessible: a practical checklist for beginners
- How to test your website’s accessibility properly
- Australian standards and legal context: DDA, AHRC, and WCAG 2.2
- Where to go next: resources and a simple 3-step plan
- Our approach to building accessibility into every website project
- Get a website built with accessibility in mind from the start
- Sources
- FAQ
Web accessibility basics: the four principles you need to know (POUR)
Every accessibility rule you’ll come across traces back to four ideas, laid out by the W3C’s Web Accessibility Initiative: Perceivable, Operable, Understandable, and Robust. Together they’re known as POUR, and they’re the backbone of WCAG 2.2, currently the standard version Australian guidance points to.
Here’s what each one actually means on a real page:
- Perceivable — people need to be able to sense your content, whatever device or sense they’re using. A photo of your storefront needs alt text describing what’s in it, not just “image1.jpg”.
- Operable — every function has to work without a mouse. If someone can tab through your entire checkout using only a keyboard, you’ve got this one covered.
- Understandable — content and navigation behave predictably and read in plain language. Avoid jargon-heavy button labels like “Submit query” when “Send message” says the same thing more clearly.
- Robust — your code works across browsers, devices, and assistive technology. This usually comes down to using proper HTML elements (buttons as
<button>, not a styled<div>) instead of clever workarounds.
You don’t need to memorise the full WCAG 2.2 spec to start applying POUR. Most beginners find that once they understand these four categories, spotting a barrier gets a lot easier.
Make your website accessible: a practical checklist for beginners
Some fixes take five minutes. Others need a developer and a sprint. Sort your list by effort, and you’ll clear most of the impact before lunch.
Quick wins (do these first):
- Write meaningful alt text for every image that carries information, and leave decorative images with empty alt attributes.
- Add a skip link so keyboard users can jump past your navigation menu straight to the main content.
- Structure headings in logical order (H1, then H2, then H3), never skipping levels just because a smaller heading looks nicer visually.
- Replace vague link text like “click here” with descriptive phrases such as “download the pricing guide”.
- Label every form field clearly, and make sure error messages tell people exactly what to fix.
- Add captions to videos and transcripts to podcasts or audio content.
Bigger technical fixes (plan these in):
- Check your keyboard focus order matches the visual reading order of the page.
- Add ARIA roles only where semantic HTML can’t do the job alone. Overusing ARIA often causes more confusion than it solves.
- Confirm colour contrast meets a 4.5:1 ratio for normal text, and check that font sizes scale properly when a reader zooms in.
The W3C’s accessibility fundamentals guide lists these same techniques as the practical foundation most sites are built on, and smaller organisations get the best return by knocking over the text alternatives, headings, and form labels before touching a full component rewrite.
Pro Tip: Run your quick wins list on your homepage and one other high-traffic page first. If you find the same three issues repeating across both, you’ve likely found a pattern in your template, and fixing it once will fix it everywhere it’s used.

How to test your website’s accessibility properly
Automated tools are a great starting point, but they’re not the whole story. They catch things like missing alt text and poor colour contrast reliably. What they routinely miss is whether your content actually makes sense in the order a screen reader announces it, or whether a form error message is genuinely useful. The W3C notes that automated scans typically catch only some accessibility issues, but not all, so a clean scan result doesn’t mean a clean page.
Three manual checks catch most of the rest:
- Unplug your mouse and navigate the entire page using only Tab, Shift+Tab, and Enter.
- Turn on a screen reader (VoiceOver on Mac, Narrator on Windows) and listen to how your headings, links, and forms get announced.
- Check that every heading follows a logical order and every form field has a label a screen reader will actually read out.
Once you’ve handled the basics, testing with a small group of real assistive technology users is worth more than another automated pass. Even three or four sessions with people who rely on screen readers or switch devices daily will surface issues no checklist predicts. Keep a simple log of what you find and fix, and use it as the basis for an accessibility statement describing your site’s current state and how people can report a problem.
Australian standards and legal context: DDA, AHRC, and WCAG 2.2
The Disability Discrimination Act 1992 (DDA) is the legal foundation for digital accessibility in Australia, and it applies to websites the same way it applies to physical premises. On top of that legal baseline, the Australian Human Rights Commission’s guidance recommends WCAG 2.2 Level AA as the practical benchmark organisations should work toward.
The benchmark, in numbers: WCAG 2.2 defines multiple conformance levels, commonly A, AA, and AAA. The Australian Human Rights Commission treats Level AA as the defensible standard for most organisations, with AAA reserved for specific content types rather than a whole-site requirement.
Beyond WCAG, AS EN 301 549 is the Australian standard covering accessibility across a broader range of ICT products and services, not just websites. Government bodies also work to the Digital Inclusion Standard, which requires inclusion to be built into service design from the start rather than bolted on afterwards. If you’re building or rebuilding a site, aiming for WCAG 2.2 AA and documenting your testing gives you a genuinely defensible position, standard-wise and legally.
Where to go next: resources and a simple 3-step plan
You don’t need a six-month roadmap to start. Run a quick automated scan today, fix your quick wins list this week, then book a proper audit with real assistive technology users once the basics are solid.
For deeper reading, three sources cover almost everything else you’ll need:
- W3C’s Introduction to Web Accessibility for the full WCAG technical detail.
- Australian Human Rights Commission’s digital accessibility guidance for the Australian legal and policy angle.
- The Style Manual’s accessible content guidance for writing and publishing an accessibility statement.
Our approach to building accessibility into every website project
Mybusinessmarketingcoach treats accessibility as a brief item, not an afterthought fixed post launch. Every site project starts with the requirements written into our web design brief example, so contrast, headings, and keyboard navigation get planned before a single page gets built. Fixing that in the brief costs far less than fixing it in production.
— MYBMC
Get a website built with accessibility in mind from the start
Retrofitting accessibility onto an existing site usually costs more than building it in from day one, because you end up rewriting components you’ve already paid for once. Mybusinessmarketingcoach builds accessibility checks into the website design process itself, working as an extension of your team rather than handing back a generic template and disappearing.

A short accessibility audit from Mybusinessmarketingcoach gives you a prioritised list of fixes mapped to WCAG 2.2 AA, sorted the same way this guide sorted them: quick wins first, structural fixes second. That means you get a clear action plan instead of a wall of jargon. If you’re planning a new site or a redesign in Melbourne, get in touch through our website design page and request a brief audit before your next build starts, not after it launches.
Sources
- Guidelines for equal access to digital goods and services — Australian Human Rights Commission
- Accessible and inclusive content — Style Manual (Australia)
- Digital
- Introduction to web accessibility — W3C WAI
FAQ
What are the four principles of web accessibility?
They’re Perceivable, Operable, Understandable, and Robust, known together as POUR. Every WCAG 2.2 success criterion falls under one of these four categories, from alt text (Perceivable) to keyboard navigation (Operable).
Is WCAG a legal requirement in Australia?
WCAG itself isn’t written into law, but the Disability Discrimination Act 1992 is, and it applies to websites. The Australian Human Rights Commission recommends WCAG 2.2 Level AA as the practical benchmark for meeting your obligations under the DDA.
What are the 7 pillars of accessibility?
There’s no single official “7 pillars” framework in WCAG itself. Most beginner guides that use this phrase are describing an expanded, informal breakdown of the four POUR principles into practical categories like navigation, content, and forms rather than a separate standard.
What is the difference between WCAG and ADA?
WCAG is a technical standard published by the W3C describing exactly how to make content accessible. The ADA is US civil rights legislation; Australia’s equivalent legal framework is the Disability Discrimination Act, which references WCAG as its practical benchmark rather than writing separate technical rules.
How do I start improving web accessibility on my site today?
Run a free automated scan against WCAG 2.2 AA, then fix your alt text, heading order, and form labels first since they’re the cheapest wins. From there, test with a keyboard only and a screen reader before considering a fuller audit.