Can customers still use your catalogue when they zoom in?

Choose the task your repair must protect

For a Hong Kong B2B supplier with an established catalogue, the immediate decision is whether the existing layout needs a targeted repair or a more substantial component change. Start with one buyer task: find a suitable item, verify its specification and pack quantity, then reach the enquiry control. Ask a sales colleague which details distinguish easily confused variants. Those details belong in the acceptance check; a tidy screenshot alone cannot establish that a buyer can choose correctly.

Keep the initial scope to the current catalogue template and the states it actually uses. Include a long product name, a long model identifier, selected filters, no results and a results page with another page available. Use representative English and Traditional Chinese records independently. A short English label passing does not settle what happens to a Chinese product name containing an uninterrupted model code. The proposed checks below are an editorial working method, not findings from a customer project or a forecast of additional sales.

Check the effective width, then complete the task

W3C’s explanation of WCAG 2.2 Reflow sets a reference width of 320 CSS pixels for vertically scrolling content, preserving information and functionality without two-dimensional scrolling except where a two-dimensional layout is necessary. A 1280-CSS-pixel viewport at 400% browser zoom is an equivalent example. Measure the content viewport rather than relying on the monitor resolution. This article uses that technical reference to define a catalogue repair check; passing this check alone does not establish whole-site accessibility conformance.

1. Prepare matching test records

   Record the page URL, language, product identifiers and selected filters. Keep the same records for the repair retest.

2. Set and record the viewport

   Check at a 320-CSS-pixel viewport and repeat with desktop browser zoom giving an equivalent width. Record browser, zoom and effective viewport dimensions; include intermediate zoom levels if a layout changes there.

3. Operate the catalogue

   Search, apply and remove a filter, open a product, return to results and use pagination. Repeat with keyboard navigation and inspect focus visibility, open menus and the enquiry action.

4. Repeat in the other language

   Run the complete task with that language’s long records, including empty results and active filter labels. Save the failing state, not just the first screen.

Compare repairs against the information buyers need

For ordinary product cards, propose a single-column layout that gives names and specifications room to grow. Ask the developer to inspect fixed widths, minimum widths and fixed-height text areas before replacing the entire catalogue. A collapsed filter panel is another option when a permanent sidebar consumes the available space, but budget for its open, apply, clear and close states. Hiding the filter without an accessible way to reopen it would remove part of the task. Avoid shortening names merely to make the sample fit: the distinguishing suffix may be exactly what a buyer needs.

These are proposed design alternatives, not measured before-and-after outcomes. Choose according to the existing components and buyer task.

Keep the table exception inside the table

W3C permits an exception for tables whose meaning needs two-dimensional layout; it does not automatically cover their headings, search or pagination, and ordinary cell content still needs to reflow. For a proposed valve catalogue, retaining a comparison table may help buyers compare connection size and material across models. Put its sideways scrolling in a dedicated region, while the surrounding controls fit the page. Check keyboard access to that region and whether users can follow row and column relationships after scrolling.

If comparison across models is not essential, an alternative is a stacked specification list for each item. That creates a longer page and may make cross-model comparison slower, so decide with the sales team before commissioning it. A developer should not classify a grid of unrelated product cards as an essential comparison table simply because both have columns. Document which specific relationship requires the table, what can move outside it, and how buyers reach all remaining controls.

Turn one failed task into a bounded repair brief

With a small front-end budget, prioritise missing product distinctions and unreachable actions ahead of cosmetic alignment. Give the developer a reproducible record: language, URL, product, viewport dimensions, zoom, selected filters, steps, expected behaviour and the observed failure. Request separate estimates for changes to the shared card, filter and pagination components. A shared component repair may cover several categories, but verify another category rather than assuming that every template uses identical rules.

Your next action is to choose one representative category and have a catalogue owner run the bilingual task with a developer. Keep the resulting issue sheet as the repair’s acceptance brief. After the change, repeat the recorded failures, check intermediate widths and return to the normal desktop layout to catch regressions. Broader bilingual content testing can follow the existing guide below. If the task remains blocked after simple layout changes, use the issue sheet to scope design support around the affected components.