The short answer
Put services, locations (when you have more than one office), new patients, and the phone in the primary navigation as ordinary links. On a phone, a bar fixed to the bottom with Call and Request can stay visible if it does not cover focused controls, each target is at least 24 by 24 CSS pixels, contrast holds, and the bar does not animate when the visitor prefers reduced motion. A location switcher should list real office links, not a script-only menu. The appointment form should collect a name, a phone number, the office, and a time window, with visible labels, and it should not send those personal details to analytics. None of this produces a universal conversion rate. Measure calls and requests on your own site.
What the primary nav is for
The HTML nav element is a section of links to other pages or to parts of the same page. MDN makes the same point: use it for major navigation, and do not wrap every set of links in a nav. One primary nav, plus a footer, is enough for most dental sites. Give the primary nav a label such as "Primary" when the page also has a footer nav, so the two landmarks are distinct. A skip link remains the way past repeated blocks, which is the idea behind WCAG 2.4.1 Bypass Blocks.
| Item | Where it goes | Single office | Several offices |
|---|---|---|---|
| Services | Index of treatments you actually offer, each linking to its own page | In the primary nav | Same pages, with a note of which offices offer the treatment |
| Locations | A locations index of real offices | Skip it. Put the address in the header and footer. | In the primary nav. One link per office. |
| New patients | What to expect, how to request a visit, what to bring | In the primary nav | In the primary nav, and repeated on each location page with that office's phone |
| Phone | A tel: link using the public number | Header and sticky bar | The number for the office in view, not a switchboard unless that is truly how calls are answered |
Google's link guidance says links should be anchor elements with an href that Googlebot can see. A menu that builds its links only after JavaScript runs, or a button that navigates without an href, is a weak primary nav. Put the same destinations in HTML.
The first screen of the homepage is a different job from the nav. That layout is in homepage design. Ad-specific landing pages, which often hide the full nav on purpose, are in landing pages for dental ads. This guide is the site chrome patients use on ordinary pages.
Mobile call and book bar
A sticky control stays in view while the rest of the page moves. CSS position offers two tools. Sticky keeps the element in normal flow until a scroll threshold, then holds it. Fixed takes it out of flow and pins it to the viewport. A bottom bar on a phone is usually fixed. Either way, the bar is author-created content that can cover the page. Plan for that before you add the shadow.
| Check | What to implement | Source |
|---|---|---|
| Focus not covered | When a link or field receives keyboard focus, the bar must not hide it completely. Add scroll-padding-bottom at least as tall as the bar, and padding at the end of the page. | WCAG 2.4.11 |
| Target size | Aim for at least 24 by 24 CSS pixels on Call and Request. If a control is smaller, the spacing exception still wants enough gap that the 24-pixel squares do not overlap. | WCAG 2.5.8 |
| Contrast | Normal text needs a contrast ratio of at least 4.5:1 against the bar. Check the focused and pressed states too, not only the resting blue. | WCAG 1.4.3 |
| Reflow | At 320 CSS pixels wide, the bar stays inside the viewport. Two buttons with long labels wrap or shorten. They do not force sideways scrolling. | WCAG 1.4.10 |
| Motion | If the bar slides, bounces, or hides itself on a timer, turn that off under prefers-reduced-motion. Show the resting bar immediately. | MDN, WCAG 2.2.2 |
Practical pattern for a dental page:
- •Two actions, named in text. "Call" and "Request a visit." An icon alone needs an accessible name. Do not rely on color to tell them apart.
- •Do not cover the form the bar opens. When the request form is on screen, hide the bar or collapse it so the submit button can receive focus. A bar that sits on top of its own form is the usual keyboard failure.
- •Respect reduced motion in CSS. The media query prefers-reduced-motion: reduce is the user's request. Match it and skip non-essential animation. A transition on a progress meter can use the same query.
- •Keep it out of the way of the skip link and the menu button. Fixed bars at the top and the bottom at the same time leave a short reading strip on a phone. Pick one persistent bar.
Run an automated check such as axe on the page at a phone width and a desktop width, then tab through the bar with the form focused. Automated tools do not replace that keyboard pass. They do catch missing names, contrast failures, and a bar that overflows. Mobile layout beyond the bar is in optimizing for mobile patients.
Location switcher and finder
A group site has to answer "which office?" before it answers "what time?" Put the current office name where the phone number is, and make changing it a list of links.
- •Each office is a URL. /locations/office-name, linked from the switcher and from the locations index. The location page guide covers what belongs on that page. The switcher does not replace it.
- •Show the current office. Use aria-current="page" on the link for the office the visitor is on. Do not only change a label in a closed menu.
- •A finder filters links. It does not invent pages. City or postal code can hide offices that are far away, as long as the remaining items are still anchors to real location pages. A page per nearby town that only swaps the city name is a doorway risk, already covered in the location page guide.
- •The sticky phone follows the office. After a switch, Call uses that office's public number and Request posts to that office's route. A group-wide number is acceptable only when someone at that number can book the office the visitor picked, and the page says so.
Naming the brand versus the office, and pointing Dentist markup at the group with parentOrganization, is in AI search for multi-location groups. A brand-new door's first version of this page is the coming-soon page in the de novo launch playbook.
Shorter appointment requests
Friction here means work the visitor must do before you can call them back. It is not a license to quote a lift in conversion rate. Published percentages from other sites do not transfer to a dental form. Count your own requests and your own booked visits.
| Keep | Why it is enough | Leave off this form |
|---|---|---|
| Name | So the person who calls back knows who asked | Date of birth, Social Security number |
| Phone | The number you will dial | A second phone, unless you truly need it |
| Office | Required when more than one office could answer | A free-text city when you already have a location list |
| Time window | Morning, afternoon, or a day they prefer | Symptoms, medications, insurance member ID, clinical history |
- •Visible labels. WCAG 3.3.2 asks for labels or instructions when a field expects input. Placeholder text that disappears on focus is not a label.
- •Autocomplete tokens. The autocomplete attribute can be name and tel so the browser can offer saved values. It does not remove the need for a label.
- •Errors in text. WCAG 3.3.1 says that when you detect an input error, you identify the field and describe the error in text. A red border alone does not do that.
- •Trust cues you can prove. Show the office address, the hours, and one sentence: we will call this number. Do not add star ratings you do not have, and do not invent a "most patients book in X minutes" line.
- •Analytics stays coarse. Google's rule against sending personal information covers names, emails, and phone numbers in event parameters and URLs. Send appointment_request and the office id. Store the person's details in the system your front desk actually uses. Tag setup is in conversion tracking. Online scheduling that writes to the live book is a later step, covered in online scheduling.
Clinical intake belongs on a form built for that purpose, after the patient has a visit, not on the marketing request. If you are unsure whether a field is appropriate, ask your own counsel before you add it.
Conversion UX checklist
Twelve checks for navigation, the sticky bar, the location control, and the request form. Ticks stay in this browser only.
Sticky CTA checklist
12 items
DDS Web Solutions designs the navigation, the phone bar, and the request form as part of practice websites. Our team has been building websites since 2014, and we have served 100+ practices. Offices are in Sacramento, California (primary) and San Mateo, California. Call (415) 800-1127. Groups comparing scope can start at DSO and multi-location marketing. SmileTrak is our marketing analytics platform, included with client engagements, and it is where call and form counts can be read. It does not set a conversion-rate target. ToothRank is a curated directory for DDS clients, not a public listings site. Smyly is a consult preview and is separate from site navigation.
FAQ
What has to be in the primary navigation?
Services, new patients, and a phone number, as links. Add locations when patients can visit more than one office. Team, insurance notes, and patient forms can live one level down or in the footer. A nav element is for a block of navigation links, not for every group of links on the page. The phone should also exist in the page body, not only in a bar that appears after scrolling.
Does a sticky call bar fail accessibility by default?
No. It fails when it hides the control that has keyboard focus, when the targets are smaller than 24 by 24 CSS pixels without an allowed exception, when text contrast is too low, or when motion keeps running after the visitor asked for less motion. Padding and scroll-padding keep focused fields in view. Test with a keyboard at a phone width and with reduced motion on.
How should a multi-office site let someone change location?
Show the current office, and link each other office to its own location page with a normal anchor. A script-only dropdown that never exposes those URLs is easy for visitors and for Google to miss. A postal-code filter is fine when the result is still a list of real office links. Do not generate a new town page just to hold the switcher.
Which fields belong on an appointment request?
Name, phone, the office they mean, and a time window are enough to return the call. A short note field should say it is for scheduling, not clinical history. Visible labels beat placeholder-only fields. Describe errors in text next to the field that failed.
Should the sticky bar slide in?
Only if it still works with motion turned off. The prefers-reduced-motion query is the signal. When it matches, show the bar in its resting position with no slide, bounce, or auto-hiding loop. A bar that moves on its own for more than a few seconds also needs a way to pause it.
Sources
Wording on these pages can change, so confirm the live page. This is marketing guidance, not legal advice.
- •WHATWG HTML: the nav element
- •MDN: the nav element
- •MDN: CSS position
- •MDN: prefers-reduced-motion
- •MDN: the autocomplete attribute
- •W3C: Understanding Focus Not Obscured (Minimum)
- •W3C: Understanding Target Size (Minimum)
- •W3C: Understanding Contrast (Minimum)
- •W3C: Understanding Reflow
- •W3C: Understanding Pause, Stop, Hide
- •W3C: Understanding Bypass Blocks
- •W3C: Understanding Labels or Instructions
- •W3C: Understanding Error Identification
- •Google Search Central: Link best practices
- •Google Analytics Help: Avoid sending personally identifiable information