Picture a foreman on a job site. He is standing by a stack of roofing sheets, a phone in one hand, a work glove on the other, and he needs to check thickness and coating against what is on the supplier’s site. On a computer the supplier has a fine specifications table with eight columns. On the phone, what is left of it is narrow columns where the digits wrap one by one.
The foreman tries to zoom in, the table slides sideways, and the column headings are lost. The certificates section, which on a computer sat right under the table, was hidden in the mobile version at some point so the page would be shorter. In the end he does the most sensible thing in his position: he calls the manager. The site is formally responsive. Using it from a phone is almost impossible.
What a responsive site means
A responsive site rearranges itself to the screen width: columns stack, the menu hides behind a button, images get smaller. According to the Tilda help on the mobile version, standard blocks do this automatically. Rearranging the grid is only half the job. The other half is that, after the rearrangement, a person can still do everything on the site that they can do on a computer.
The W3C puts this well in the understanding of success criterion 1.4.10, “Reflow”: content should be presented without loss of information or functionality, and without scrolling in two directions, at a width equivalent to 320 CSS pixels. A curious detail: those 320 pixels correspond to a screen 1280 pixels wide at 400% zoom. So this is not only about phones. It is also about people who zoom a page on a computer in order to read it.
One caveat right away: passing this check does not yet make a site comfortable. It is the minimum bar, and the conversation about comfort only starts after it.
Tables and filters: what you cannot simply squeeze
The W3C states outright that some content cannot be reflowed into one column without losing meaning. Data tables, maps, diagrams and video need a two-dimensional layout, and an exception is made for them. The exception covers only the table itself. The heading above it, search, pagination and the text around it must still reflow normally, and the W3C suggests showing the table in its own scrollable container, so that it moves sideways and the whole page does not.
This shows most clearly in a catalog. A specifications table with eight columns can stay a table, but then the first column should be the thing a person is looking up, and it should stay fixed. Sometimes another format works better: a card where the specifications run as a list, “parameter — value”. Filters that sit in a column on the left on a computer usually move into a separate panel on a phone, and it helps when, after a choice, a person sees how many products remain and how to reset the filter. If the catalog is still being designed, it is easier to build these decisions into the structure of the online store at the start than to force them onto the screen later.
Hiding a block means deciding that this information is not needed
In Tilda a block has a setting, “Visibility range on devices”. According to the help, it exists so that different blocks can be shown on phones and on computers. That is a useful option: you can show a simplified diagram on a phone instead of a wide infographic, or a different layout of the first screen.
The danger is that “show something else” easily turns into “show nothing”. A block was hidden because it looked bad on a phone, and a replacement was never made. The W3C has a separate failure for this: content disappears and becomes unavailable after reflow. I think every block hidden on a phone should be checked with a simple question: where will the mobile visitor find this information now? If there is no answer, our foreman still will not get the certificates.
A phone is not a spare screen
If a large share of visitors arrives from a phone, the mobile version is better designed together with the main one: decide how tables, filters and forms will behave before any of it is drawn for a large monitor.
Large text and sticky elements
Responsiveness is usually checked on one phone at the normal font size. But text size is easy to increase in the system or browser settings. The W3C understanding separately mentions the link with criterion 1.4.4: even with reflow, it must be possible to enlarge all text to at least 200%. A button whose label just fitted on one line gets cut off at a larger font, or runs into the next button.
The second common problem is fixed elements. A header, a bar with a phone number, a messenger button and a promotion banner each take little space on their own. On a small screen, or when zoomed, together they can cover half the page. The W3C strongly advises making such elements ordinary and unfixed on narrow screens, or giving the user a way to hide them.
How this works on Tilda
Standard Tilda blocks, according to the help, have separate typography and spacing settings for the mobile version, and some blocks also have extra mobile settings for elements. If the standard responsiveness is not enough, a block can be converted to Zero Block and the layout set by hand across five screen-width ranges, or across your own. But the help warns: after conversion, content and design return to the default settings, and text and images have to be added again. There is the opposite extreme too: a checkbox that turns responsiveness off, and then on a phone the page looks the same as on a computer.
Another detail from the same help: switching the view in the editor is not a full preview, and some blocks look different on the published page. So I would check the mobile version in preview and on a real phone, better on two different ones. In my projects, responsiveness for all devices is included by default. The most useful way to look at the result is through the eyes of that same foreman.
He does not, by the way, need a site that looks as striking on a phone as on a monitor. He needs to find the sheet thickness and download the certificate without taking the glove off. If that works, the mobile version has done its job.