Therapy website essentials: pages, accessibility, privacy, hosting

This lesson is for a clinician about to put up a practice website, or who has one and is not sure it is doing its job. It covers the pages I think a practice site needs, the accessibility basics the W3C spells out, what I keep out of a contact form, what the federal government has and has not said about analytics and ad pixels on a health website, the difference between a domain and hosting, and the phone check I do before launch. The video above is the W3C Web Accessibility Initiative's own introduction to accessibility, a companion to its written introduction, and is worth the few minutes before you read on.

What the site has to do

A practice website has two jobs. It has to convince a stranger, often anxious and often reading at eleven at night, that you are a real, licensed person who treats what they are dealing with. And it has to make the next step obvious: a phone number, an email address, or a short form. A page that does neither probably does not need to exist.

The six pages I would build first

This is my opinion, not a rule. A solo practice can run on six pages; more than that usually means the work of keeping them current gets skipped.

1. Home. Who you are, who you help, where you are, and how to reach you, all visible on a phone before anyone scrolls.
2. About. Your license type and number, your training, and a current photo of your face. People are choosing a person.
3. Services and specialties. Specific beats general. "Anxiety in adults, EMDR for trauma, couples work" tells a reader more than "individual and couples therapy."
4. Fees and insurance. Your rate, whether you slide, and which plans you are in network with. Leaving this out sends people to someone who answered the question.
5. Contact. Phone, email, and a form that asks for very little (more on that below).
6. Privacy policy. A real one that describes what the site collects and who sees it, linked from the footer of every page.

Accessibility basics, from the people who write the standard

The W3C's Web Accessibility Initiative introduction to web accessibility (updated February 3, 2026) describes the goal as sites built so that people with disabilities can "perceive, understand, navigate, and interact with the Web." The same page notes that accessibility "is required by law in many situations" and points to WCAG 2.2 as the standard. For a small practice site the floor is not hard to reach, and the page names it plainly.

• Alt text on every image. A screen reader speaks the alt text; a filename like IMG_4471 tells a blind visitor nothing. Describe what the photo shows.
• Keyboard operability. In the W3C's words, "an accessible website does not rely on the mouse; it makes all functionality available from a keyboard." Tab through your own site once. If you cannot reach the form's submit button, neither can someone using assistive technology.
• Transcripts and captions. The page says a text transcript makes audio accessible to people who are deaf or hard of hearing, and adds that it is easy and relatively inexpensive to provide. If you post a welcome video, caption it and paste the transcript below it.

Three more things I check that follow from that page: text has enough contrast to read in daylight on a phone, headings are real headings rather than bold paragraphs, and link text says where the link goes instead of "click here." The checklist attached to this lesson has all of these as line items.

The contact form: what I ask for, and what I leave out

My habit is to keep clinical details out of web forms entirely. The form asks for a name and a way to reach the person, and nothing else. I do not ask what brings them in, and I do not invite them to type it. A web form is for reaching me, not for intake. The conversation about what they need happens on the phone or in the first session, in a channel you control.

Say so in the form's own words. A sentence above the fields, something like "Please share only your name and the best way to reach you. I will follow up by phone," sets the expectation before anyone starts typing.

Analytics and ad pixels: what HHS said, and what a court undid

If your site runs an analytics script, an advertising pixel, or anything similar, the relevant federal document is the HHS Office for Civil Rights bulletin on the use of online tracking technologies by HIPAA covered entities and business associates. What happened after it was written matters more than the original text. On June 20, 2024 a federal court in the Northern District of Texas, in American Hospital Association v. Becerra, vacated the guidance to the extent it treated connecting a visitor's IP address with a visit to an unauthenticated public web page about specific health conditions or health care providers as HIPAA-regulated. The bulletin has not been withdrawn. As archived by the Internet Archive on September 4, 2026 (snapshot here), it carries the court's order at the top and says: "HHS is evaluating its next steps in light of that order."

What that means for a solo practice is not something I can tell you, and I will not pretend the answer is settled when HHS itself says it is still deciding. What I can say is that a practice that uses analytics or ad pixels should read that bulletin and check it with whoever advises the practice on HIPAA, before the scripts go on the site rather than after. I link the archived copy as well because hhs.gov refused every automated fetch from my network while I was writing this.

A privacy policy that describes your actual site

A privacy policy copied from a template that mentions cookies your site does not set and a newsletter you do not send is wrong, which is worse than missing. Write down what the site really does: what the contact form collects, whether any analytics or pixel scripts run, who hosts the site, and who can see what visitors submit. Then link it from every page. I have not researched whether Oregon or federal law requires particular policy text for a practice site, so treat this as a habit, not a legal claim.

Domain and hosting are two purchases

These are two separate purchases, usually from two separate companies, and confusing them is how practices lose their sites. The domain is the name, yourpractice.com. You do not own it outright; a registrar leases it to you for a fixed term, typically one to ten years, and it has to be renewed or it lapses. Hosting is the separate service that stores the site's files and serves them to visitors. A site builder bundles the hosting in and will often sell you the domain too, but the domain is still a lease with a renewal date.

My habit: turn on auto-renew for the domain the day you register it, keep the card on file current, and register it with an email address you will still read in five years. A lapsed domain takes the website, and often the practice email, down at once, and getting a dropped name back can be slow or impossible. Two things to confirm with the host before launch: the site serves over HTTPS (the padlock in the browser), and the host keeps backups you can restore yourself.

Check it on a phone before anyone else does

I assume the first visit from any new client happens on a phone, and I build for that reader first. Before launch I open the site on my own phone and check that the phone number is a tap-to-call link, the form works with one thumb, nothing depends on hovering, and text is readable without zooming. Ten minutes, and it catches most of what a desktop preview hides.

After launch

Make sure the name, address, and phone number on the site match your directory listings character for character, including your listing here. Search engines compare those, and so do clients. The local SEO lesson covers why that matters, and the directories lesson covers keeping every listing in sync. Then put a reminder on the calendar to reread the fees page every six months; a stale fee costs you money in both directions.

This is how I build and maintain a practice site and what the W3C and HHS pages linked here say; it is not legal or HIPAA compliance advice, and whoever advises your practice on privacy gets the final word on analytics, forms, and your policy text.

Further reading

• W3C WAI: Introduction to Web Accessibility. The source for the quotes above, and the page that makes alt text and keyboard operability the floor rather than an advanced feature.
• HHS OCR: Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates. The bulletin itself, now headed by the court's June 2024 order; read the top before the body.
• Internet Archive: the same HHS bulletin, captured September 4, 2026. The copy I verified against, for anyone whose network hhs.gov refuses.