Websites get planned, reviewed and admired on a large screen. They get used in someone's hand: 88 percent (Eurostat) of people in the European Union go online with a mobile device, far more than with a laptop or a desktop machine. Between those two worlds sits a blind spot that quietly costs enquiries. What looks elegant on a 27-inch monitor with a mouse turns into a test of patience on a display the width of a palm, operated with one thumb. This article is deliberately not about loading time, which has its own piece, but about usability: text sizes, contrast, tap targets, phone numbers, opening hours, price tables and overlays. It ends with a test routine you can run on your own phone in twenty minutes.
The small screen is the default case
The device split is unambiguous, and it flipped a long time ago. Mobile devices are the most common way onto the internet in the EU at 88 percent (Eurostat), laptops follow at 56 percent (Eurostat), while desktop machines and tablets sit at 31 percent (Eurostat) each. In Germany 97 percent (Federal Statistical Office of Germany) of people aged 16 to 74 use the internet, and roughly nine in ten (Bitkom) own a smartphone. At the same time around 89 percent (Federal Statistical Office of Germany) of companies with internet access run a website of their own. The basic technical requirement is met almost everywhere: 94 percent (HTTP Archive Web Almanac) of pages requested on mobile pass the check for a correctly set viewport meta tag, so pages do scale. And that is exactly where the misunderstanding starts. A page that technically adapts to the screen width is still far from usable. It can have text that is too small, buttons the size of a stamp, a price table that disappears sideways and a phone number that cannot be tapped. Which pages a business actually needs is covered in the piece on the pages a business website needs; how those pages feel on a phone is decided by the details in this one.
The mobile version is the version that counts
A different grip
A large share of usage happens one-handed: the device rests in the palm and the thumb does the work. Anything outside its reach costs a change of grip, and every change of grip costs attention.
A different environment
People read in sunlight, on a bus, in a workshop. Ambient light, reflections and movement swallow contrast that a dimmed office monitor still renders generously.
A different intent
Mobile visits are often instant questions: when are you open, where are you, how do I reach you? Those three answers belong at the top, not somewhere on a subpage.
Readable: text size, line length and contrast
The first hurdle is mundane and widespread: text set too small. Sixteen pixels has become the working baseline for body copy on a phone, because it matches the default size of most browsers and because below it the character height becomes uncomfortable at normal reading distance. Anything smaller forces zooming, and zooming on a content page is not an interaction, it is a workaround. Automated checks fall short here: the classic Lighthouse audit only flagged a page once 40 percent (Google, Lighthouse documentation) of its text fell below 12 pixels, and 92 percent (HTTP Archive Web Almanac) of mobile pages pass it. Passing therefore only means the text is not tiny, not that it reads comfortably. More important than the absolute number is the unit: 66 percent (HTTP Archive Web Almanac) of mobile pages define font sizes in pixels, only 9 percent (HTTP Archive Web Almanac) in em and 4 percent (HTTP Archive Web Almanac) in rem. Relative units are the reason an enlarged system font has any effect at all. The standard is explicit on this point: text must be resizable without assistive technology up to 200 percent (W3C, WCAG 2.2, success criterion 1.4.4) without loss of content or functionality. How to write copy that carries in a narrow column is covered in the piece on writing website copy customers actually read.
| Element | Size on a phone | What happens otherwise |
|---|---|---|
| Body copy | 16 to 18 pixels | People zoom, the layout shifts and the line they were reading is lost |
| Subheading | 20 to 24 pixels | The structure disappears and the page reads as one uninterrupted block |
| Phone number and address | 18 pixels, as a button | The most important information becomes the hardest thing to hit |
| Form label | 16 pixels, above the field | Mobile browsers zoom in on focus and the layout jumps around |
| Notes and footer text | at least 14 pixels | Prices, deadlines and mandatory notices become effectively unreadable |
| Line length | 45 to 75 characters | Long lines make the eye lose its place when jumping back to the left |
The second half of readability is contrast, and here the picture is considerably worse than for text size. Only 29 percent (HTTP Archive Web Almanac) of mobile websites reach sufficient text contrast throughout, up from 23 percent (HTTP Archive Web Almanac) two years earlier. The bar is clearly defined: 4.5:1 (W3C, WCAG 2.2, success criterion 1.4.3) for normal text and 3:1 (W3C, WCAG 2.2, success criterion 1.4.3) for large text from 18 point, or 14 point bold, upwards. That sounds technical but has a very practical core. Light grey type on white looks refined in a dimmed office and is simply absent on a station platform in July. The same applies to text placed over photos, to pale captions on gradients and to placeholder text in form fields, which is often set lighter still than the content itself. Taking contrast seriously pays twice: for everyone with reduced vision, and for everyone else the moment the sun comes out. The legal backdrop is covered in the piece on accessible business websites.
Do not block zooming
- Set body copy to 16 pixels or more and define sizes in relative units
- Raise line height to roughly 1.5 times the font size, which makes line jumps easier
- Check text contrast against the real background, including photos and gradients
- Darken placeholder text in forms or replace it with a visible label above the field
- Avoid justified text, which creates large word gaps on narrow screens
- Keep paragraphs short and add subheadings so the text stays scannable
Tap targets: big enough, with room around them
A mouse hits a target a few pixels wide; a thumb does not. The contact area of a fingertip is considerably larger than the point a person is aiming at, and while tapping it covers exactly the spot that is meant to be hit. The standard therefore sets a floor: targets for pointer inputs should be at least 24 by 24 CSS pixels (W3C, WCAG 2.2, success criterion 2.5.8) at level AA. Exceptions apply when a smaller target has enough free space around it, when an equivalent larger control exists on the same page, or when the link sits inline within a sentence. Comfort only starts well above that: the enhanced requirement names 44 by 44 CSS pixels (W3C, WCAG 2.2, success criterion 2.5.5) at level AAA, and Google's developer documentation recommends around 48 pixels (web.dev) per side with roughly 8 pixels (web.dev) of spacing between neighbouring targets. So 24 pixels marks the edge of what is acceptable, not the goal. Controls also have to remain recognisable as controls: their visual boundary needs a contrast of 3:1 (W3C, WCAG 2.2, success criterion 1.4.11) against the adjacent surface, otherwise a button quietly becomes an invisible area.
Size
Bring buttons and menu entries to at least 44 pixels in height. That roughly matches the area a thumb hits reliably without the eye having to correct the aim first.
Spacing
Eight pixels of air between neighbouring targets prevents mis-taps. Icon rows, header bars with several symbols and tightly packed footer links are the usual offenders.
Feedback
Every hit needs a visible reaction: a pressed state, a colour change, a loading indicator. Without feedback people tap again and trigger the same action twice.
- Icon bars with several small symbols placed directly next to each other, with no separating space
- Two links in the same line of text, such as privacy and imprint divided by a slash
- Phone numbers and addresses as plain running text instead of a standalone button
- Consent checkboxes whose clickable area covers only the box and not the label
- Select fields where only the small arrow responds rather than the whole field
- Image galleries advanced through tiny dots along the bottom edge
The thumb zone: where important actions belong
Hold a phone in one hand and the thumb describes an arc. Comfortably reachable is the lower half of the screen on the side of the holding hand; the far top corner is the hardest point to reach and demands a change of grip or a second hand. Devices have grown considerably in recent years, which has amplified the effect. The design rule that follows is simple: what gets used often belongs low, what gets used rarely or carries consequences belongs high. The primary action of a page, whether that is calling, requesting a quote or booking an appointment, should be available in the lower area after the first scroll, not exist solely as a small link in the header. Conversely, deleting, signing out or resetting a form has no business in the thumb zone. A practical middle ground is repetition: the primary action appears once in the visible area at the top and once at the end of the content, so nobody has to scroll back up after reading. How to phrase those actions so they actually convert is covered in the piece on local visibility for local businesses.
What belongs in the lower half of the screen
- Define the primary action: there is exactly one most important step per page, not three of equal weight
- Place that action in the visible area and again at the end of the content, both as a large button
- Arrange secondary routes beside or below it, visually clearly subordinate
- Move actions with consequences upwards so they are not triggered by accident
- Re-check one-handed after the change: the left and right hand feel noticeably different
Call, directions, opening hours: the three mobile classics
Mobile visits are often instant questions, and there are three recurring answers. First the phone number: it belongs behind a link using the tel scheme so that a tap starts the call rather than offering digits to copy by hand. Second the address: a link that opens the device's map application with the right coordinates saves retyping a street name in a separate app. The geo scheme is standardised for exactly that, and the address should sit next to it as readable text so it can still be copied. Third the opening hours: they are the single most requested piece of content on many business sites, and they are surprisingly often published as a graphic, occasionally as a photograph of a printed notice. As an image they cannot be searched, read aloud, copied, and they blur when zoomed. As text they take six lines and work everywhere. Anyone who also maintains holiday exceptions answers the most frequent call of the day before it happens. How to handle the enquiries that follow is covered in the piece on contact forms and what to do with enquiries.
<!-- Phone number: tapping starts the call -->
<a class="button" href="tel:+4951239579000">
Call us now: +49 5123 9579000
</a>
<!-- Address: opens the map application on the device -->
<a class="button" href="geo:52.1873,10.0651?q=Sample+Street+1,+31185">
Get directions
</a>
<address>Sample Street 1, 31185 Example Town</address>
<!-- Opening hours as text, not as an image -->
<dl class="hours">
<dt>Monday to Friday</dt><dd>8:00 am to 6:00 pm</dd>
<dt>Saturday</dt><dd>9:00 am to 1:00 pm</dd>
</dl>Phone number
As a button with a tel link, at least 44 pixels high, visible without scrolling. Repeat the number as readable text so it can be noted down or read aloud.
Address
As a link that opens the device's map application, plus the postal address in plain text. Details such as parking or the yard entrance save calls asking for them.
Opening hours
As structured text with weekdays and times, readable without zooming. Holiday exceptions and closures directly underneath, with dates rather than vague wording.
The test takes ten seconds
Price lists and tables: reflow instead of sideways scrolling
Tables were invented for wide screens. On a phone they produce exactly the behaviour the standard sets out to avoid: scrolling in two directions. Content should be presentable at a width of 320 CSS pixels (W3C, WCAG 2.2, success criterion 1.4.10) without loss of information and without additional horizontal scrolling. For price lists that means the table becomes stacked blocks on narrow screens. A row with five columns turns into five labelled lines, and each service gets its own block with a heading, a price and any addition. On paper that looks verbose; on a phone it reads far better than a table shrunk to forty percent or one whose right-hand columns wait invisibly off the edge. Where a genuine comparison table is unavoidable, it belongs in its own scrollable container with a visible hint that it can be moved, while the page itself stays put. Prices should never be delivered as images either: anything published as a graphic cannot be enlarged, read aloud or updated without regenerating the file. How images should be handled instead is covered in the piece on image formats and alt text.
| Content | On a large screen | On a phone |
|---|---|---|
| Price list with variants | Table with four to six columns | Stacked blocks per service with label, price and note |
| Service comparison | Side by side in columns | Below each other as cards, most relevant option first |
| Technical specifications | Long table with a header row | Collapsible sections per group, label above the value |
| Appointment calendar | Month view as a grid | List view by date, with day and time on one line |
| Form with line items | Multi-column grid | Single column, label above the field, button at the end |
- Check every table at 320 pixels width, not only in a narrowed desktop window
- Hide low-value columns on phones instead of shrinking the whole table
- Keep label and value together so the mapping survives without a header row
- Give unavoidable tables their own scrollable container with a visible hint
- Mark up prices, deadlines and quantities as text rather than embedding graphics
- Review the order after the change: what should be read first should also come first
A PDF is no substitute for a page
Reaching for a PDF is understandable: the document already exists, it is designed, it rarely changes. On a phone it is still the weakest of all options. A PDF has a fixed page width, usually A4, and on a display six centimetres wide it shrinks to roughly a fifth. Reading requires zooming and then pushing in both directions, which is precisely what the reflow criterion sets out to prevent (W3C, WCAG 2.2, success criterion 1.4.10). On top of that, phone numbers inside are rarely dialable, links often lead nowhere, and depending on the device the file opens in a separate application that pulls visitors out of the page flow. Maintenance suffers too, because a price change means a new document while the old version lives on in caches. A PDF remains sensible as an addition for printing or as a formal document, such as a data sheet or a site plan. The content itself belongs on the web as a page, carrying the same information in text that reflows. Where both exist, link the page and mark the document as supplementary, including its format and file size.
A PDF is a document made for paper. A page is a document made for screens of every size. Replacing the second with the first moves work from the editor to the visitor.
- Menus and price lists as a page with text sections rather than a photographed notice
- Directions as text with a map link rather than a scanned sketch
- Job adverts as their own page so they can be shared and found individually
- Data sheets as a page plus an optional document for printing, clearly labelled
- Forms to be filled in as web forms, with documents reserved for signature requirements
Use sticky bars and overlays sparingly
On a phone the visible area is the scarcest resource the whole website has. A fixed header 120 pixels tall already occupies about a fifth of the viewport on a common device, and if an action bar sticks to the bottom as well, less than two thirds remains for the actual content. Hence the rule: at most one fixed bar, kept slim, and ideally collapsed while scrolling down. Overlays are trickier still. A dialog covering half the screen before anyone has read the first sentence is a far bigger intervention on a phone than on a desktop, because the close control is often tiny and sits in the top corner, which is the least reachable area of all. The cookie consent dialog is legally required and therefore a category of its own, but it should stay compact, offer equally weighted buttons and leave scrolling intact. Everything else, from discount banners to newsletter prompts and chat bubbles, deserves an honest question: does it bring in more enquiries than it covers up? What a clean consent flow looks like is covered in the piece on GDPR and cookie consent; how heavy embeds affect delivery is covered in the piece on PageSpeed and static delivery.
The close button is part of usability
- At most one fixed bar at a time, either top or bottom, not both together
- Keep fixed areas under 15 percent of screen height and shrink them while scrolling
- Show overlays only after a recognisable intent, not during the first paint
- Make the close control large, high in contrast and within reach of the thumb
- Lock scrolling behind a dialog so the page does not drift unnoticed
- Place chat bubbles and callback widgets so they never cover a button
Forms: only the essentials, large, in one column
Forms deserve an article of their own, so this is only the part that is specific to phones. First, length: every additional field costs completions, and anything that will be clarified in conversation anyway does not need to sit in the form. Second, arrangement: one column, label above the field, generous line spacing. Two-column forms wrap unpredictably on narrow screens. Third, the keyboard: a phone field should open the numeric pad, an email field the layout with the at sign, and autocomplete for name, address and phone number saves noticeable time on a device. Fourth, the text size inside inputs: below 16 pixels mobile browsers zoom in automatically on focus, which makes the layout jump. Fifth, error messages: they belong directly at the affected field, in words, not only as a change of colour. Everything beyond that, from the confirmation page to processing incoming enquiries, is covered in the piece on contact forms and enquiries.
The hands-on test: one hand, sunlight, large type, gloves
The most effective check needs no tooling, just your own phone and twenty minutes. The reason: a preview pane on a computer simulates screen width, but neither the hand, nor the light, nor the system settings your visitors use. Four conditions surface most of the problems. First, one-handed operation, because it honestly reproduces the thumb's reach and immediately shows which buttons sit too high. Second, a walk outside into sunlight, because every weak contrast that an office monitor still flatters becomes obvious there. Third, an enlarged system font, set to around 130 percent, because many people run their device that way permanently and layouts break surprisingly often under it. Fourth, gloves, or alternatively operating the device while walking, because both reduce precision and make undersized targets unusable straight away. Note down every point where you zoom, tap twice or shift your grip. That list is your task list, sorted by frequency.
- Open the home page one-handed and check without zooming whether service, phone number and opening hours are legible
- Reach every button in the visible area with your thumb, without changing your grip
- Step outside and read the same page again in direct sunlight
- Set the system font size to about 130 percent and check for clipped text or overlapping blocks
- Zoom the page to 200 percent and check that all content and controls remain available
- Trigger the three most important actions while wearing gloves or walking, and count the mis-taps
- Open a price list and a detail page and check whether sideways scrolling becomes necessary
- Fill in and submit the contact form completely, using the phone's own keyboard
Two devices are enough to start
How XICflow handles this
In XICflow the blocks are built for small screens from the outset rather than adapted afterwards. Text sizes, line heights and spacing come from a shared design system, buttons arrive from the template with adequate height and spacing, and colour combinations are laid out against the contrast requirements of WCAG 2.2 at level AA. Tables and price blocks stack automatically on narrow screens instead of disappearing sideways. Phone numbers and addresses are emitted as tappable elements, opening hours as structured text. The editor switches to the mobile view directly, so the narrow version stays visible while you write instead of surfacing only after publication. The consent dialog is part of the delivery rather than a foreign element inserted later that brings its own usability problems. What is included at which level is shown in the overview of features, and the path from input to delivered page is described in the workflow in detail. How the result feels on your own phone can be tried out on the demo websites.
- Blocks with predefined breakpoints instead of rebuilding layouts for small screens
- Buttons with adequate height and spacing straight from the design system
- Colour pairings with checked contrast, including text on images and coloured areas
- Mobile view switchable in the editor, with the preview matching the published page
- Contact details emitted as tappable elements rather than plain text or graphics
- Accessibility to WCAG 2.2 AA and a consent dialog included in every site by default
What you can change this week
Mobile usability is rarely a project and usually a series of small corrections that add up. Start with what affects every page: base text size, contrast and the size of buttons. Then handle the three instant answers, phone, address and opening hours, because they account for the largest share of mobile visits. Only after that does it pay to look at tables, documents and overlays. The order matters, because a new layout helps little while the text remains too small. Anyone already considering a rebuild should make the mobile version the basis of sign-off rather than an afterthought: scope and prices are shown in the pricing overview, and the comparison with other routes is laid out in why XICflow. For an assessment of your existing site, a short conversation via the contact page is enough.
- Raise base text size to 16 pixels and remove zoom restrictions from the viewport tag
- Check text colour contrast and sharpen every value below 4.5:1
- Move phone number, address and opening hours up as tappable elements
- Bring every button to at least 44 pixels in height and add the missing spacing
- Rebuild price tables as stacked blocks and move PDF content onto pages
- Run the hands-on test one-handed, in sunlight and with an enlarged system font
In the end what decides the outcome is not how a page looks on the conference screen at sign-off, but how it feels when somebody sits on a bus with one hand free and wants to know whether you are still open. That perspective cannot be simulated, only tried. The effort involved is small and the effect is immediate: every spot you find where somebody has to zoom, tap twice or shift their grip is one spot fewer where an enquiry quietly disappears.