# Review a clipped interface label at a fixed viewport [Read as HTML]() When a label clips, first record the visible loss, then inspect the element's layout constraints. Our small browser example below keeps the label, font, and button width fixed while changing wrapping and height. It shows why a complete accessible name can coexist with an unreadable visible label. ## Define a repeatable comparison Record the route, state, full label, viewport width and height, zoom, data fixture, and loaded font for both baseline and revision. Note whether text clips, wraps, or pushes another control out of view. Hold these conditions constant while checking the proposed change. Chrome Device Mode lets you set width and height and capture from DevTools' screenshot menu. Emulation approximates a mobile screen; it is not a real phone test. Attach a screenshot or export directly for a one-off review; use screen sharing only when the local state is hard to export. ## Treat the image as a symptom, then find the cause A still shows where text disappears, not whether a constrained parent, font, sibling, stale render, or interaction state caused it. Avoid hiding overflow or shrinking text before diagnosis; either can mask the symptom. Inspect the DOM, element box, computed layout, font loading, and console in DevTools. Record a cause as a hypothesis until that evidence confirms it. Use the table to choose the next native check. | Question | What the still can show | Next evidence | | --- | --- | --- | | Where is it clipped? | Visible text and button edge | Inspect the element box in DevTools | | What caused it? | The symptom in one state | Check DOM, computed layout, fonts, and console | | Does it work? | Visible label and position | Test pointer, keyboard, focus, and accessible name | | Does content reflow? | One viewport at a time | Test narrower widths for lost information or function | ## Worked example: wrapping a clipped action label Copy the complete HTML below into ui-label-clipping.html and open it locally in a browser. Each test panel is 390 CSS pixels wide; that is a container width, not a simulated phone viewport. Both buttons say “Continue to checkout” and use a 144-pixel width and the same 16-pixel Arial font. The first combines a fixed height, no wrapping, and hidden overflow. The revision permits wrapping and automatic height. In our browser run, the first button clipped the label; the second displayed it on two lines. Both exposed the complete accessible name. Tab reached both buttons, with visible focus on the revised one. This fixture has no checkout action, so it establishes layout and focus observations only. The source lets you repeat the comparison in your browser. ```text Observed example, October 17, 2026 Button width: 144 CSS px in both versions Before: clientWidth 142; scrollWidth 170; height 38 After: clientWidth 142; scrollWidth 142; height 58 CSS before: height:38px; white-space:nowrap; overflow:hidden CSS after: height:auto; white-space:normal; overflow:visible Result: full visible label after wrapping; accessible name was complete in both Unproven here: a real checkout action, other browsers, page-wide reflow ``` ## Choose the fix from the intended behavior Use that CSS change only when wrapping and a taller control fit your design. In your page, confirm the cause, make the chosen change, and render the same state again. Check neighboring controls and separately exercise pointer, keyboard, focus, and accessible-name behavior. For ordinary vertical content, WCAG Reflow addresses information or function loss at a width equivalent to 320 CSS pixels, with exceptions for two-dimensional content. A 390-pixel screenshot cannot establish conformance. Check the criterion against the real page with browser and accessibility testing. ## Keep a compact review record Keep this with the issue or pull request. Attach before/after screenshots if useful; preserve DOM, console, and test evidence as text. ```text Route and state: [ ] Viewport / zoom / font: [ ] Expected label: [ ] Baseline symptom: [ ] Cause hypothesis and DOM evidence: [ ] Change and same-state result: [ ] Pointer / keyboard / accessible-name check: [ ] Uncertainty: [ ] ``` ## Reproduce the example Save this complete source as ui-label-clipping.html, then open it in your browser. It uses no scripts, external assets, or services. ```text Clipped action label: reproducible visual review example

Clipped action label: controlled browser example

Each panel is 390 CSS pixels wide. This is a visual fixture, not a working checkout.

Before: fixed height, no wrapping

Two items are ready.

height: 38px; white-space: nowrap; overflow: hidden;

After: wrap and grow

Two items are ready.

height: auto; white-space: normal; overflow: visible;

The label, font, button width, padding, and content are unchanged. Both buttons retain the full accessible name. Neither performs a checkout action.

Compare the visible label, then inspect computed styles, horizontal overflow, keyboard focus, and accessible names separately. This example is not a universal CSS fix.

``` ## Prompt to adapt > The [full label] clips at [viewport dimensions] on [route/state]. Use my attached before/after screenshots, or request a still if a screen source is connected. Compare the same data, state, zoom, and loaded font. Describe the visible loss and compare it with my computed-style evidence: [ ]. I will choose the layout change and test pointer, keyboard, and accessible-name behavior. What changed visually, and what remains unverified? ## Source documentation - [Chrome DevTools: Device Mode]() - [W3C: Understanding WCAG 2.2 Reflow]() ## Connect your source Add https://letitsee.com/mcp using remote MCP, Streamable HTTP, OAuth, and image results. Sign in with the same account and choose your source. [Share a screen or window with an MCP assistant]() or [Use a phone camera with an MCP assistant]() cover setup and browser requirements. ## Set up without starting a capture [Set up your MCP client](https://letitsee.com/for-agents) with the full tool reference. The separate [capture page](https://letitsee.com/live) can replace the active capture page for your account. It does not take a photo by itself. ## Related guides - [Learn CAD sketch constraints by predicting how a line changes]() - [Get help with a no-code app builder]() [All camera and screen guides](https://letitsee.com/guides)