Distinguish missed taps from an action with no result
Record the intended choice and where activation actually happens. Large text can still be difficult when only the letters are clickable. A decorative border adds no usable area if taps there do nothing.
If the intended button activates but state does not change, inspect the input, action and result chain in buttons with no response. Here the problem is small targets, crowding or unreadable choices; resizing should still preserve their original action.
Available space depends on viewport, browser bars, safe areas and orientation. Supply the actual interface and target input method. A desktop poster cannot prove mobile usability, and accurate mouse clicking cannot prove easy finger tapping.
Enlarge the target while preserving action and cost
W3C’s explanation of WCAG 2.2 minimum target size gives 24×24 CSS pixels with spacing, equivalent-control, inline, user-agent and essential-presentation exceptions. Measure the actual target, not its icon or physical display pixels. The example below selects a 48-pixel minimum height as its own starting choice, not a universal compliance threshold. Meeting one sizing condition does not establish whole-game accessibility.
| Interface problem | Revision |
|---|---|
| Only letters activate | Include padding in the same active button; its edges perform the same action. |
| Adjacent choices touch | Separate active areas and add spacing; enlarged layers must not cover a neighbor. |
| Long labels truncate | Preserve action and local cost with complete wrapping, not a hidden payment suffix. |
| Repeated explanations crowd out choices | Keep decision-critical information, cut repetition or split beats instead of shrinking fonts. |
game-art-direction requires readable current text, choices and necessary feedback in the target viewport, emphasizing verbs and each option’s cost. Larger buttons still need a readable play panel. On-demand history can have a separate, clear scroll boundary. Color can help, while words and shapes must also identify actions instead of relying only on red versus green.
Complete paper example: choose the shuttle, confirm cost and arrive
In an original medicine-delivery game, the player holds a medicine case at a mountain pass with four coins. This section has no countdown. The author has defined two actions: a shuttle reaches the clinic for two coins and one turn; walking also reaches it for no coins and two turns. Both can deliver. The example invents no lateness failure.
The old interface places adjacent “Ride” and “Walk” text links in an illustration corner, with only letters active and costs farther below. The revision stacks two actual buttons in the choice area: “Take the shuttle to the clinic” and “Walk to the clinic,” each beside its own coin and turn cost.
The layout starts from a 390×844 CSS-pixel portrait viewport, 48-pixel minimum button height and 12-pixel gap. Height grows for complete text; active and visible button areas match. These are author-selected specifications to test with target devices and real long labels, not proof of fitting on screen.
Current state: Mountain pass; medicine case held; four coins.
Choices: Shuttle to clinic (two coins, one turn); walk to clinic (no coins, two turns).
The player taps inside the shuttle button’s padding. This design opens confirmation: “Spend two coins to take the shuttle to the clinic? You will bring the medicine case.” Controls: “Confirm ride” and “Return to choices.”
The player returns first. Location, four coins, the case and turns remain unchanged.
They choose the shuttle again and confirm. The rules commit one journey: two coins remain, one turn passes, location becomes the clinic and the case stays held. Feedback reads “You arrive at the clinic with the medicine case,” followed by a handover action.
The revision addresses difficult tapping and detached cost information. Confirmation is this example’s decision for a paid action. Walking does not become a failure, and merely opening confirmation does not charge. Repeated confirmation must not settle twice; every cost-free advance need not gain a confirmation screen.
Give AI the actual interface and rules, then walk it on a phone
With GAME_DESIGN and PRODUCT_BRIEF in place, give game-art-direction a bounded request:
Target portrait mobile touch input. Here are the current delivery-choice interface and two approved actions. Revise only active areas, spacing, wrapping and current information layout. Keep costs, turns, case possession and both arrival outcomes. Propose shuttle confirmation with no settlement on opening or returning. Do not shrink fonts to cram content or add routes or failure rules.
After direction is settled, game-build can revise actual controls and their existing bindings. QA methods focus on visible results. On the target phone, tap centers and edges, return from confirmation, confirm, and walk the neighboring route. Check actions, charges, turns, location and possession. Rapid repeated taps should commit once; the next action must remain readable and usable after the result.
Increase text size, use supported orientations and try the longest real choices to find overlap or truncation. Record devices beyond the supported scope accurately. Article layout and desktop automation do not establish the game’s touch usability, legibility or feedback. This page’s example has not been implemented as a game.
FAQ
Is making every button 48 pixels enough?
Forty-eight is the example’s choice. Check active area, spacing, full text, binding and target devices. WCAG minimum size and its exceptions are a specific criterion; one number cannot establish the whole experience.
Does every choice need confirmation?
No. Decide by cost, reversibility and consequences of mistakes. Describe the actual action, leave state unchanged on opening or returning, and settle a submitted result once.
Do it with the skill
Provide the product brief, game design, target mobile viewport and current interface. Ask game-art-direction to revise targets, legibility and choice layout while preserving actions and costs, then build and verify the adopted direction on target devices.
Read the method: Target viewport, hierarchy and non-color feedback · UI callbacks and committed state · Actual input, overflow and outcome paths