Accessible by default, not as an add-on
Some of the people most likely to need a lawyer - for injury, disability, discrimination or estate matters - are exactly the people a careless website shuts out. The same is true for an elderly executor researching probate, a person with low vision navigating after an accident, or a deaf client trying to read transcribed video content. Australian solicitors who quietly serve these clients shouldn't be running websites that exclude them.
We build to WCAG 2.2 AA from the first wireframe, not as a retrofit. Accessibility-overlay widgets (the "accessibility button" plugins) are a separate, often counter-productive thing - we don't ship them.
What you actually get
- Semantic HTML structure - proper headings, landmarks, lists, tables, buttons-vs-links done correctly
- Keyboard operability on every interactive element - including the menu, the audit form, and modal dialogs
- Visible
:focus-visiblestates that tell keyboard users where they are - Skip-to-content link for screen reader and keyboard users
- Sufficient colour contrast on every text/background combination (AA minimum, AAA where feasible)
- Scalable, readable typography - zoom-friendly to 200% without layout breaking
- Descriptive alternative text on every meaningful image; decorative images marked as such
- Accessible, labelled forms - every input properly labelled, error messages programmatically associated
- Screen-reader testing on the critical paths - homepage, services, contact form, primary practice-area pages
- An accessibility statement and a remediation route for any issues reported
What we deliberately don't ship
Accessibility overlay widgets. The "click this floating button for accessibility options" plugins (UserWay, accessiBe and similar) frequently make screen-reader experience worse, are increasingly the subject of accessibility-law complaints, and do not constitute WCAG compliance. We build the markup correctly instead.
"Compliance certificates" from automated scans. Automated tools catch only 30–40% of WCAG issues. We use them plus manual testing, not in place of it.
Where this fits in the bundle
WCAG 2.2 AA is standard on every site we ship - in every band, at no extra line item. The build is the build; accessibility is part of how it's done. Pairs with:
- Law Firm Website Design - accessibility patterns built in at design time
- Legal Content Writing - heading structure, link text and reading level kept accessible
- Hosting & Care Plans - accessibility maintained through updates, not eroded
Especially impactful for: wills & estates (older audience) and personal-injury (clients with injuries) practices - the verticals where inaccessible sites exclude the most clients.
FAQ
Is WCAG compliance legally required for Australian law firms?
There is no single Australian "you must comply" statute for private websites, but the Disability Discrimination Act 1992 applies to information and services delivered online, and complaints have been successfully made against organisations whose sites excluded users with disabilities. Government-related sites have explicit WCAG mandates. For a law firm specifically - an industry built on access to justice - there's also a strong professional case.
Will accessibility slow my site down or make it ugly?
No - both are myths. Accessible markup is generally faster (lighter, semantic), and the design constraints (contrast, font size, focus states) tend to produce a cleaner, more professional aesthetic, not a clunkier one.
What's the difference between AA and AAA?
AA is the standard most organisations target - practical and broadly achievable. AAA includes stricter requirements (e.g. higher contrast ratios, sign language for all video) that aren't always feasible site-wide. We build to AA by default; AAA on specific components by request.
Can you audit my existing site for accessibility?
Yes - the free audit includes an accessibility pass on your key pages (homepage, services, contact form, one practice-area page). Specific WCAG remediation work is scoped separately.
