The Baseline, Not the Bonus
Here's a question that exposes a lot about how an agency thinks: when in the project timeline do you address accessibility? If the answer is "at the end" or "when the client asks for it," you're building inaccessible websites by default and retrofitting compliance as an afterthought. That's expensive, incomplete, and in 2026, legally risky. One in five Australians lives with a disability. Globally it's over a billion people. These aren't edge cases — they're a massive segment of your audience that most websites actively exclude through lazy markup and untested interfaces. The Web Content Accessibility Guidelines (WCAG) 2.2 AA standard isn't some aspirational framework. It's the baseline that Australian discrimination law effectively references, and the standard that the EU's European Accessibility Act now enforces with real penalties. So let's skip the "why" and get into the "how." Start with semantic HTML Most accessibility problems aren't solved with ARIA attributes — they're solved by using the right HTML elements in the first place. A <button> is focusable, activatable via keyboard, and announced correctly by screen readers. A <div onclick="..."> is none of those things without significant extra work. Use <nav> for navigation. Use <main> for primary content. Use <h1> through <h6> in logical order. This single practice eliminates roughly 50% of accessibility issues before you write a line of CSS. Keyboard navigation is non-negotiable Try using your website with only a keyboard. Tab through every interactive element. Can you reach the navigation? Can you open the mobile menu? Can you submit the contact form? Can you close a modal? If the answer to any of these is "no," your site fails a basic WCAG requirement. Every interactive element must be reachable via Tab and activatable via Enter or Space. Focus states must be visible — and no, removing the outline because it's "ugly" is not acceptable. Style it, don't hide it. Colour contrast matters more than you think WCAG AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large text. That light grey placeholder text on a white background? It fails. That trendy low-contrast design with slate-400 on slate-100? It fails. Check every text/background combination with a contrast checker. We use the WebAIM contrast checker or the built-in Chrome DevTools audit. Beautiful design and accessible contrast are not mutually exclusive — it just means you need to be intentional about your palette. Images need real alt text "Image" is not alt text. "IMG_4032.jpg" is not alt text. The alt attribute should describe the content and function of the image. If a hero image shows a team collaborating at a desk, say "Team of four collaborating around a shared desk in our Gold Coast office." If an image is purely decorative, use an empty alt attribute — alt="" — so screen readers skip it entirely. Every informational image without meaningful alt text is invisible content to screen reader users. Forms are where most sites completely fail Every input needs a visible, associated <label>. Placeholder text is not a label — it disappears when the user starts typing and offers no persistent context. Error messages need to be programmatically associated with their fields using aria-describedby. Required fields need to be indicated both visually and programmatically. Form validation errors should be announced to screen readers, not just shown in red text that a colour-blind user might not notice. Test with actual tools Automated testing catches about 30-40% of accessibility issues. Tools like axe DevTools, Lighthouse, and WAVE will find missing alt text, contrast failures, and missing form labels. But they won't catch logical heading order issues, keyboard traps, or whether your custom dropdown is actually usable with a screen reader. Manual testing is essential. We test with VoiceOver on Mac, keyboard-only navigation, and browser zoom at 200%. If you've never used a screen reader on your own website, do it today. The experience is humbling. The business case is straightforward Accessible websites perform better in search engines because they use semantic markup that Google can parse more effectively. They convert better because they're usable by a wider audience. They're more resilient because they don't depend on a single interaction modality. And they protect you from legal liability — accessibility lawsuits have increased 300% since 2018 in the US alone, and Australia is following the same trajectory. We build accessibility into every project from day one. It's not a line item on the invoice. It's baked into how we write markup, how we choose colours, how we test before launch, and how we structure content. If your current website hasn't been audited for accessibility, it almost certainly has issues. The good news is that most of them are straightforward to fix — you just have to decide that your entire audience matters, not just the ones using the latest Chrome on a MacBook.