The iPad sits in an awkward place for a website designed around two tidy categories: phone and desktop. Its screen can be large enough for a familiar desktop layout, while the person using it is still reaching for controls with a finger.
That makes it a useful device to think about when I am designing a WordPress website. It exposes assumptions that a desktop browser can hide: hover-only navigation, controls with very small targets and layouts that only make sense with a mouse nearby.
A screen width is not an input method
I still need breakpoints. They help decide when a navigation fits or when a column has become too narrow to read. What they do not tell me is whether somebody has a mouse, a keyboard, a touch screen or a mixture of those things.
Recent iPad software makes that distinction harder to ignore. Safari can provide a more desktop-like browsing experience, and a keyboard or pointing device can change how someone uses the same screen. A desktop-style browser does not make a small link comfortable to press with a finger.
I prefer a navigation that works by an explicit action. If a submenu is necessary, its button needs a clear state and a usable way to open and close it. Hover can be a useful addition, but it should not be the only route to the links.
Give the content room to change
A tablet held upright and the same tablet in landscape are different reading spaces. Multitasking can make the available width smaller again. I cannot reliably design around one screenshot and call that the iPad version.
For content-heavy pages, I start with a readable column and let additional space earn its purpose. Sometimes two columns help. Sometimes they just split a paragraph away from the heading that explains it.
That is especially relevant to client-editable websites. Headings get longer, images arrive in different shapes and the number of items changes. I want the design to tolerate those normal changes before I start polishing its ideal state.
Interaction needs another pass
Forms are worth checking on the device itself. A virtual keyboard changes the visible space, input types affect the available controls and a field can become awkward to use when its label or error has scrolled away.
I want labels that remain visible, errors that explain the next action and a layout that does not depend on a fixed-height panel. Placeholder text is useful for an example; it is not a substitute for the field's name.
The same care applies to galleries and menus. Can someone use them without hovering? Can they get back out? Does a keyboard focus indicator remain visible? A layout can be responsive in its CSS and still be difficult to operate.
Design around the job
For an ecommerce website, the useful question is whether someone can examine a product, choose an option and understand the next step. For a service website, it might be whether they can find a clear answer and make an enquiry.
Those jobs give me a better test than deciding whether a design looks sufficiently tablet-like. I can move through a real journey, change orientation and check where the interface starts asking the user to compensate for it.
Working between design and development helps here. I can question a visual decision while also thinking about how the content and controls will behave once they are built.
The iPad is not a reason to maintain a separate website for every device. It is a reminder that the person using a website has more possible contexts than my desk offers. I want the same underlying content and actions to remain understandable in each of them.
Further reading
WebKit's Safari 13 feature overview describes the changing browser capabilities. My article on accessible, readable websites covers why the content and structure matter alongside the layout.