Practice websites: the privacy and accessibility obligations nobody mentions

When a practice website is being planned, the conversation tends to circle colours, photos and where the phone number sits on the page. Two questions rarely come up, and both matter more than the colour palette. First, what happens to the information a visitor hands over through a form, a chat widget or a booking calendar. Second, whether the site actually works for someone who cannot see it clearly, hold a mouse steadily, or read small pale text. Neither question is exotic. Both quietly decide whether a patient books or gives up and calls somewhere else.

The Privacy Act does not care how small you are

Most small businesses in Australia sit under a turnover threshold that exempts them from the Privacy Act altogether. Health service providers do not get that exemption. Any organisation that provides a health service and holds health information is covered by the Privacy Act regardless of size, which means a solo practitioner working from one room carries the same handling obligations as a large hospital group for the health information it holds. That includes information collected through the website, not only information collected in the treatment room.

This matters because a website form is a collection point whether anyone thinks of it that way or not. A name, an email address and a reason for getting in touch are personal information the moment they are typed into a box and submitted. If that reason for getting in touch mentions a symptom, a diagnosis or a medication, it becomes health information, which the Privacy Act treats as sensitive information attracting stricter handling. The practical implication is straightforward: the Australian Privacy Principles apply to what your website collects, not just to what your practice management software stores.

What that means for your contact form

The safest form is the smallest one that still does its job. Name, a way to contact the person back, and a general reason for the enquiry is usually enough. Resist the temptation to add a field inviting more detail, such as an open box asking a visitor to describe their symptoms before anyone has assessed them. It feels helpful and triage-minded, but it does the opposite of minimising collection: it invites sensitive health information onto a public web form, over a channel that was never designed to carry it, before there is any clinical relationship in place to justify holding it.

Beyond field count, check the plumbing. The form should submit over an encrypted connection, which any modern website provides by default, but it is worth confirming rather than assuming. Find out where submissions actually land: a plain inbox, a spreadsheet, a third-party form service. Know who can read them, and whether that list of people has grown quietly over a few years without anyone reviewing it. None of this requires technical expertise. It requires someone to actually ask the question once and write the answer down.

Booking widgets and scripts you did not build

Embedding a booking widget from a third-party platform is one of the fastest ways to get online booking working, and it is a completely reasonable choice. It also means a piece of someone else's software is now running on your website and handling your patients' details before those details ever touch your own systems. Before embedding anything, it is worth knowing, in plain terms, what happens to a booking once it is submitted: where the data is processed, whether it moves overseas as part of that processing, and whether the platform has its own consent language that a patient should be shown before they book.

The same logic applies to smaller scripts that get added over time: a chat bubble here, a heatmap tool there, a marketing pixel someone installed for a campaign two years ago and never removed. Each one is a small additional flow of visitor data to a third party. None of them is necessarily a problem. The problem is not knowing they are there, because a privacy policy that does not mention a script that is actively running is already out of date the day it is published.

Analytics that respect the visitor

Understanding how people use the website is genuinely useful, and there is nothing wrong with analytics on a health practice website. The judgement call is in what you measure and how granular it gets. Session recording tools that capture every keystroke, including what someone typed into a form before deciding not to submit it, go further than most practices need or want to go. Standard, aggregate analytics that show which pages get visited and where people drop off is usually all that is needed to make sensible decisions about the site.

It is also worth thinking about where that data flows next. A visitor reading a page about a sensitive condition, and then seeing unrelated advertising for that condition follow them around the internet for weeks afterwards, has had their visit used in a way most people would find uncomfortable if they thought about it. Choosing analytics and advertising settings with a lighter touch on sensitive pages is a reasonable, low-cost way to respect that discomfort before it becomes a complaint.

Why a real privacy policy beats boilerplate

Most practice websites carry a privacy policy, and most of those policies were copied from somewhere else with the practice name swapped in. That approach produces a document that satisfies the letter of having one while describing almost nothing about what the practice actually does. A policy that says data may be used for research partnerships the practice has never entered into, or omits the booking widget the practice embedded last year, is not protecting anyone; it is a liability dressed as compliance.

A policy worth having names the forms and widgets that actually exist on the site, says plainly what is collected and why, and gives a real way to make a complaint if something goes wrong. It should be reviewed whenever a new tool gets added to the website, not written once at launch and left untouched for years. This is one of the areas where a website provider who understands health practices earns their fee: someone should be checking the policy against the site's actual behaviour, not filing it away as a formality alongside the terms and conditions nobody reads.

Accessibility as decency and good business

A meaningful share of the people trying to book with a health practice are older, are managing a vision or motor condition, or are simply reading a phone screen in bright sunlight in a car park. A website built only for a designer's laptop, at full brightness, with a steady mouse hand, quietly excludes a good number of the people it exists to serve. Getting this right is not really a technical project. The Web Content Accessibility Guidelines set out the internationally recognised standard, but the practical version fits in a few plain sentences: text should be large enough and contrast strongly enough with its background to read easily; every part of the site should work using a keyboard alone, not only a mouse or a finger; every meaningful image needs alt text describing it; and every form field needs a visible label, not a placeholder word that disappears the moment someone starts typing.

None of this is about ticking a legal box. It is about the fact that a website is the practice's front door for people who have never walked through the physical one, and a front door that is hard to open does not get a second attempt from most visitors. Treating accessibility as basic decency, the same instinct that puts a ramp beside the front step, tends to produce better decisions than treating it as a checklist item handed to a developer at the end of a project.

How accessibility failures quietly cost bookings

The frustrating part of an accessibility problem is that it rarely shows up as an obvious error. An older patient who cannot read pale grey text on a white background does not file a complaint; they close the tab and call whoever answers the phone at a practice down the road. A patient using a screen reader who hits a booking form with no labels does not report a bug; they give up and try somewhere with an actual phone number visible above the fold. None of this appears as a crash in any analytics dashboard. It appears as a slightly higher bounce rate that nobody investigates, because nothing looks broken to the person looking at it on their own screen with their own eyesight and their own steady hands.

This is also where accessibility and plain good website practice overlap almost completely. Large, legible type, clear contrast, sensible spacing and forms that behave predictably are the same qualities that make a site convert well for every visitor, not only the ones with a diagnosed impairment. Fixing accessibility gaps is one of the rare pieces of practice marketing where doing the right thing and doing the profitable thing point in exactly the same direction.

• A working privacy and accessibility checklist
• List every form, widget and script currently running on the siteYou cannot write an honest privacy policy about something you have not counted
• Strip contact forms back to the fields you actually needName, a way to reply, and a general reason for the enquiry is usually enough
• Confirm submissions travel over an encrypted connectionStandard on modern hosting, but worth checking rather than assuming
• Check the privacy policy actually mentions every third-party tool in useBooking widgets, chat tools and analytics scripts all count
• Run the homepage and booking flow through a contrast checkerPale grey text on white is common and quietly unreadable for many visitors
• Tab through the whole booking journey using only a keyboardIf you cannot reach and complete a booking without a mouse, some visitors cannot either
• Add alt text to every meaningful image, including team photosDescribe what is actually in the photo, not just the file name
• Check every form field has a visible label, not only placeholder textPlaceholder text disappears the moment someone starts typing, taking the instruction with it

Working through both lists at once tends to be a half-day exercise for an existing site, and it is one worth doing before the next redesign rather than during it, because it is much cheaper to fix a form field than to rebuild a template. If the site is due for a rebuild anyway, both privacy and accessibility belong in the brief from the first conversation, alongside the advertising rules that govern what the site can actually say. A free growth plan is a reasonable place to have both conversations at once, in plain language, before anything gets built.