Mobile Optimization: For Patients on the Go

What patients do on a phone

The tasks are simple and urgent. Find the phone number and call. Check whether the practice is open today. Get directions. Confirm that the practice treats a problem, such as a broken tooth or a child’s first visit. Request an appointment. If any of those tasks takes more than a few taps, a patient may simply call another practice instead.

We list these tasks for your practice and design the mobile layout so each one is reachable from every page.

The mobile checklist we work through

• A header with the practice name, a menu button and a one-tap phone link.
• An appointment button that stays easy to reach as the patient scrolls.
• Body text of at least 16 pixels, with comfortable line spacing and contrast.
• Tap targets of at least 24 by 24 CSS pixels, the minimum in WCAG 2.2 success criterion 2.5.8, and larger where space allows.¹
• No pop-ups that cover the screen on arrival.
• Hours and address in plain text, not inside an image.
• Forms with as few fields as possible, the right keyboard for each field and clear error messages.
• Tables that turn into readable stacked cards on narrow screens.
• Images sized for phones, so a 4 MB photo is never sent to a small screen.

Speed on mobile networks

A page that loads in a second on office Wi-Fi can take much longer on a phone in a parking lot. Google’s Core Web Vitals give three targets measured at the 75th percentile of page loads: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less and Cumulative Layout Shift of 0.1 or less.² We measure mobile and desktop separately. If a page misses a target, we find out why and fix it. See speed optimization for the full approach.

Accessibility on small screens

Mobile and accessibility overlap. Patients who zoom text to 200 percent, use a screen reader or move around the page with a switch device need the same care. Ontario requires organizations with 50 or more employees to meet WCAG 2.0 Level AA on public websites.³ We build to that level for every practice, and we test zoom, keyboard focus and screen reader labels on mobile layouts as well as desktop ones.

How the service runs

We start with an audit of your current site on phone widths. You receive a short report listing each problem, why it matters and the fix. Some fixes are quick changes to CSS or templates. Others, such as a long contact form or a menu that hides the phone number, need a small redesign of that part of the site.

If your site runs on a platform we can edit, we make the changes directly. If not, we provide specifications your current developer can follow. Either way, we test again after the changes and send you before and after notes.

When mobile problems point to a bigger issue

Sometimes the audit shows that the site cannot be fixed cheaply: an old theme, page builders that load several megabytes of code or a structure that was never planned for phones. In that case we will tell you, with an estimate for both the fix and a redesign, so you can decide.

What you receive

• A mobile audit report with each issue, its impact and the fix.
• The fixes applied, or developer-ready specifications.
• A retest on phone widths with a short summary of what changed.
• Core Web Vitals measurements before and after, where data is available.

Common mobile problems on dental websites

• A phone number shown as an image or plain text that cannot be tapped.
• A menu that hides the appointment button and phone number behind several taps.
• Pop-ups announcing offers or newsletters that cover the page on arrival.
• Body text smaller than 16 pixels, which forces patients to zoom.
• Booking widgets that do not fit narrow screens or cannot be used without a mouse.
• Large background videos that slow the page on mobile data.

Each one is fixable, and most can be fixed without a full redesign.

Frequently asked questions

My site already resizes on phones. Is that enough?

Resizing is the minimum. A page can shrink to fit and still be hard to use: tiny buttons, a menu that hides the phone number, pop-ups that cover the screen or a form with too many fields. We test the tasks patients actually do, not just the layout.

Will mobile changes affect the desktop site?

The desktop site usually improves too, because the same discipline applies: clear priorities, fewer distractions and faster pages.

Do you test on real devices?

We test in browsers at common phone widths, including narrow screens around 360 to 390 pixels, and check key pages on physical phones before launch.

Should the phone number or the form come first on mobile?

Both should be easy to reach. A tappable phone number in the header suits patients who want to talk now, and a visible appointment button suits those who prefer to write. We place both so neither is more than one tap away.

Sources

1. W3C: Web Content Accessibility Guidelines (WCAG) 2.2 Standard
2. web.dev: Web Vitals Google developer documentation
3. Government of Ontario: How to make websites accessible Government

Checked on 29 October 2026. Rules change, so confirm the current version with the regulator before you publish.