01 / INTERACTION REVIEWIntroduction

A supplier demonstrates a product menu by swiping quickly across the screen. Each flick opens another category. On a phone, a two-finger pinch enlarges the product image. The demonstration feels fluid, but the buying team has not yet asked how the same customer reaches the next category or enlargement using a simple tap. A polished gesture is evidence of one input route, not of every customer’s ability to use that route.

For a B2B vending project, this question matters wherever the offered experience includes a web menu, QR landing page or browser-based operator tool. Some people cannot perform precise paths or simultaneous touch points. Others use adapted pointing devices. Procurement should identify the actual gesture-controlled functions and ask for alternatives before approving the interface configuration.

The evidence for this guide is W3C’s Understanding SC 2.5.1: Pointer Gestures, reviewed on 11 October 2026. It explains the Level A criterion for web content and distinguishes custom gestures from operating-system, browser and assistive-technology actions. The article applies that distinction to purchasing questions; it does not assert that the three products below use the example gestures or have passed an accessibility assessment.

02 / INTERACTION REVIEWQuick Answer

SC 2.5.1 says functionality using multipoint or path-based gestures can be operated with a single pointer without a path-based gesture, unless the complex gesture is essential. The criterion applies to web content that interprets pointer actions, not actions required to operate the user agent or assistive technology.

A next-category button can provide the same navigation as a custom horizontal flick. Plus and minus controls can provide the same zoom function as a pinch. A keyboard shortcut alone does not answer this specific requirement. In WCAG 2.2, an alternative that exclusively relies on dragging also raises the separate SC 2.5.7 question.

The procurement decision starts with confirmed behaviour. A touchscreen does not prove that its application is web content, and an image of a menu does not reveal its event handling. Ask the supplier which parts of the offered experience are web-based, what input they interpret and which functions remain available through simple pointer controls.

03 / INTERACTION REVIEWComparison Table

These are listing-based candidates for different retail formats. The gesture questions are demonstration requests, not features claimed from the public pages.

The conditional wording matters. None of the three listings establishes a pinch-to-zoom function, custom flick navigation or a web implementation of the cabinet menu. Resolve those details on the exact interface proposed for your project.

04 / INTERACTION REVIEWWho Should Buy This

This guide is for equipment purchasers approving a touchscreen concept, operators commissioning QR ordering pages and distributors coordinating cabinet software with a separate web team. It is especially useful when a sales demonstration uses gestures that are absent from the written specification. Without a function list, the final delivery may depend on an interaction the buyer never evaluated.

Bring the user-interface supplier, project buyer and a representative operator into the review. Include customer-facing functions such as category navigation, image enlargement and option selection when those functions are actually offered. Include operator functions only when the proposed web tool interprets the relevant gestures; do not infer a gesture simply because a chart or list can move.

A single controlled demonstration can establish what to ask next, but it should not be described as a complete accessibility review. Physical access, screen reach, text readability, keyboard support and payment safeguards involve additional questions. This guide isolates the input-route decision so it can be specified and checked clearly.

05 / INTERACTION REVIEWHow We Evaluate Smart Vending Machines

Our evaluation uses public product descriptions and W3C’s explanatory guidance. We have not operated these machines or tested their application event handling. We recommend a supplier-led review using the actual offered interface, with each gesture recorded against a function and an alternative.

1. Confirm the surface. Identify the cabinet application, QR page or operator web view and who supplies it. State whether the reviewed component is author-provided web content.
2. Classify the input. Note simultaneous touch points, required direction or shape, speed conditions and whether a picked-up object may move freely.
3. Record the result. Describe the function in observable terms: next category opened, image enlarged or selected view changed.
4. Use the alternative. Complete the same function with one pointer without the required path. Compare reachability and state, not just the presence of an icon.
5. Retain the evidence. Record the application version, settings and unresolved cases for the production acceptance review.

A screenshot can show the controls and resulting view. It cannot, by itself, prove which event handling recognises a gesture. Request a demonstrated operation and the supplier’s explanation of the implementation where classification remains uncertain.

06 / INTERACTION REVIEWKey Buying Factors

Multipoint input. W3C gives examples including pinch/spread zoom, split taps and two- or three-finger taps or swipes. Ask whether each offered function requires more than one point at a time. A single-finger user should not have to discover an undocumented workaround.

Prescribed paths. A path-based gesture depends on how the pointer moves, such as a mainly straight flick or a drawn shape. Its start and end coordinates may be less important than direction, shape, length or speed. Ask the supplier to explain what the interface recognises instead of classifying all visible motion as the same kind of gesture.

Dragging distinction. Freely moving a grabbed object between two positions is generally dragging, rather than path-based input. A slider may allow movement off its visible track because of pointer capture. If it requires a precise track and loses the grip when the pointer strays, the guidance discusses it as potentially both dragging and path-based. Keep the separate dragging review on the acceptance list.

Equivalent function. An alternative must achieve the same result. A button that returns to the home menu does not substitute for moving to the next category if customers lose their selection. Confirm that the relevant category, zoom level or view is reachable using the alternate route.

Ownership and exceptions. Native browser scrolling and screen-reader navigation gestures are outside this criterion’s author-content scope. An essential exception concerns inherently necessary complex input; a preferred visual effect is not evidence that a gesture is essential. Ask the supplier to document the function and rationale rather than declaring every swipe mandatory.

07 / INTERACTION REVIEWBest Smart Vending Machines

The three candidates below are real WEIMI listings. This is a procurement shortlist based on public descriptions, not an independent interface test or accessibility ranking. Select the retail format first, then resolve the actual offered software and input alternatives.

08 / INTERACTION REVIEWFeature Comparison

Compare interaction functions rather than marketing labels such as intuitive or touch-friendly. Complete this matrix using the final proposed implementation.

Do not mark an alternative as complete because a keyboard route works. W3C explains that some people rely on pointing devices and simple single-point actions. Keyboard accessibility remains an additional review, while this criterion requires the relevant pointer route.

09 / INTERACTION REVIEWCost & ROI Analysis

A gesture-alternative requirement should be priced as defined interface work. Ask which controls already exist, which need configuration, which require development and which belong to a third-party web service. Agree the acceptance evidence and change support along with the equipment quotation.

Hypothetical review budget: assume the proposed web interface has eight confirmed gesture-controlled functions. Reviewing each function for ten minutes takes 80 minutes. Rechecking two unresolved functions for fifteen minutes each adds 30 minutes. The combined review time is 110 minutes, or approximately 1.83 hours. At an assumed $48 per hour, the illustrative review labour is $88.

The assumptions are for planning only, not supplier prices, observed test times or a forecast of ROI. They exclude development, translation, participant recruitment, hardware access and broader accessibility assessment. Request a separate quote for adding controls or changing software.

There is no measured customer-conversion gain in this article. During a pilot, record whether the required functions can be completed through the agreed input routes and what defects remain. Commercial decisions can then use actual delivery effort and usability evidence instead of an invented percentage increase in sales.

10 / INTERACTION REVIEWBest Choice by Scenario

Web product images accompanying direct-access retail: investigate the AI fridge format for compatible packaged stock. If the supplier offers detailed web images, review any enlargement gesture. Single-pointer controls should provide the same information access; a larger cabinet display is not automatically a solution.

Category-heavy screen selection: investigate WM22 with actual product packs and the intended menu. Where custom flick navigation is offered, request visible, understandable controls reaching the same product groups. Demonstrate them with the final language and menu configuration.

Two-section assortment: investigate the dual-cabinet station if the additional selling area fits the project. Confirm how customers identify the intended section and item. Review gesture alternatives for any web-based section navigation without assuming that the hardware arrangement dictates one interface.

Gesture-free offered interface: do not invent a failure where no multipoint or path-based content function exists. Record that scope finding and continue the other acceptance reviews. Procurement should follow observed functionality rather than force every candidate through an irrelevant pinch test.

11 / INTERACTION REVIEWApplications

For a QR product-information page, inspect the author-controlled image viewer and category navigation. The phone’s browser may provide its own gestures, while a custom image component may interpret a separate pinch or swipe. Document which layer handles each action so the supplier is asked to fix the correct component.

For a browser-based operator tool, review any confirmed custom chart zoom, navigation strip or gesture-only view change. The task may involve a desktop pointer or adapted device rather than a finger. A plain control achieving the same function can make the task available through a simpler input method.

For a cabinet demonstration, first confirm whether the application under review is web content. The WCAG source does not by itself establish conformance requirements for an unspecified native kiosk application or the complete physical machine. A buyer may still request equivalent simple controls as a project usability requirement, with that contractual scope stated clearly.

For a multilingual rollout, repeat the functional review where labels, layout or available controls change. A control visible in one configuration should not disappear from another without review. This is a proposed acceptance practice, not evidence that any current WEIMI menu has such a defect.

12 / INTERACTION REVIEWFAQ

13 / INTERACTION REVIEWFinal Recommendation

Ask the supplier to name the gesture-controlled function and demonstrate the same result through a simple single-pointer route. Keep the original gesture if it is useful, but make the alternative part of the accepted configuration. Verify the function after the interface is translated, configured and connected to the actual retail flow.

Use the correct boundary: author-provided multipoint and path-based web interactions belong in this review; native scrolling and freely moving dragged objects need their own classification. Keyboard support alone does not settle SC 2.5.1, and a drag-only alternative leaves a separate WCAG 2.2 issue to evaluate.

Source: W3C — Understanding SC 2.5.1: Pointer Gestures, reviewed 11 October 2026. The page is explanatory guidance. The three linked manufacturer listings support the stated product facts; they do not establish gesture behaviour, accessibility conformance or local legal conclusions.

14 / INTERACTION REVIEWCTA

Send WEIMI the destination country, location type, intended product range, machine quantity and payment preferences. Include any cabinet menu, QR page or operator web tool required for the project, and name the input routes your buyers or staff need.