# People Markets: user experience and implementation guide

Version 1.4 · 24 September 2026  
Companion files: `people-markets-design-system-v1.4.html` and `people-markets-messaging-v1.4.md`  
Status: implementation specification and proposed acceptance criteria. It does not certify production readiness, financial safety, licensing or accessibility conformance.

## Version 1.4: dropdown highlight and card-first collections

The approved identity, type, colors, messaging, icons and other interactions remain unchanged. Dropdown options use the existing pale active background and saved-choice checkmark, without a left border or inset highlight. Keyboard focus and forced-colors outlines remain.

At **1,024 CSS px and below**, markets, discovery, watchlists and comparable record collections default to cards. The Markets navigation entry no longer opens a wide table at these widths. Desktop and small-screen view choices are separate: entering the small-screen range starts from its card preference rather than inheriting a desktop table. Returning to desktop restores the desktop preference. Resizing preserves the search, filters, sort direction, saved markets and current route.

The small-screen view selector offers **Cards** and **Compact cards**. The latter is an explicit denser record view, with visible labels, all values, sorting and watch actions; it does not require sideways scrolling. Above 1,024 px, the existing **Cards / Table** choices remain. Supporting tables in the reference and chart-data example also reflow into labeled record cards. The existing 640, 960 and 1280 px grid/layout boundaries remain unchanged.

Use the same record-first pattern for future balances, positions, orders and activity lists: preserve each record's identity, status, unit, timestamp and available action. Do not hide important fields to make a card fit. A genuinely two-dimensional comparison or matrix is an explicit, labeled exception, not the default for a list of records. Keep any essential horizontal scroll local; never conceal overflow at the page root.

The shared CSS contains the `.pm-data-table`, `.pm-cell-label` and `.pm-cell-value` contract. Static reference tables include this markup without requiring JavaScript. `people-markets-responsive-v1.4.js` progressively adds it to simple tables marked `data-pm-records`; it deliberately skips merged-cell matrices. Column headers and explicit table/row/cell roles remain available when CSS changes the visual presentation. Decorative repeated labels use `aria-hidden="true"`; values and controls remain accessible. Test the production pattern with assistive technology.

## Version 1.3: controls and icons

The first-visit teaching, responsive layouts and financial-state requirements remain. This revision changes the smaller visual controls and records a single icon family.

Checkboxes now have a 16 px visible box, 3 px corner radius and a true SVG check with a short downstroke and longer rising stroke. Radio buttons use the same 16 px footprint with a 6 px central dot. Their full label rows retain at least 44 px target height. A smaller mark is not a smaller tap target.

Scrollbars use a 4 px visible line in a 6 px lane, transparent track and no arrow buttons where the browser exposes the necessary parts. Standard-only engines retain native thin rendering. Use system scrollbars is available, and forced-colors mode restores native controls. Wheel, touch, keyboard and native dragging are preserved. This specification supersedes the earlier platform-width default in this guide.

Lucide is the sole interface icon library. Use 16, 20 and 24 px sizes, 2-unit source strokes and a bounded semantic registry. The 14 px checkbox check uses a documented 2.5-unit optical stroke. Check, ChevronDown, Minus and CircleCheck have distinct selection/disclosure/status meanings. The logo and partner marks are not part of the icon library.

The HTML applies the same controls to the reference and embedded product screens. `people-markets-icons-v1.4.md` contains the full icon registry, source rules, Vue component example and review checklist. `people-markets-controls-v1.4.css` contains the shared control treatment and requires the approved palette tokens.

The Vue example is a handoff pattern. The production repository and package build have not been changed or compiled here. The current official package is `@lucide/vue`; an existing `lucide-vue-next` installation requires the package’s documented migration. [W22–W24]

## 1. What this revision is solving

The approved visual direction stays in place: Bricolage Grotesque for headlines and names, Instrument Sans for interface text, Plex Mono for structured values, and warm paper, ink and cobalt. No card lift, photo zoom, animated number counting or replacement logo is introduced.

Version 1.3 completes the shared controls, replaces slogan-like callouts with usable reference notes, and makes responsive behavior directly inspectable. The introduction to the new concept remains the same: first explain what the contract is, then show what a trade does.

### What changed

| Area | Revision 1.2 decision |
|---|---|
| Dropdowns | A custom select-only popup with keyboard exploration, explicit commit/cancel, disabled states, viewport placement and native fallback. |
| Checkbox/radio inputs | Consistent squares, ticks, mixed states, circles and selection cards built on real inputs. |
| Other controls | Immediate switches, amount groups, text areas, steppers, a range input, tabs and disclosures. |
| Scrolling | Neutral custom scrollbar styling without replacing native scrolling; ordinary records become cards at 1,024 px and below, with local table scrolling reserved for wider screens or justified two-dimensional content. |
| Notes | Topic labels, specific examples and restrained horizontal rules instead of slogan headings and blue side rails. |
| Quotations | Separate quoted content from guidance; require attribution and explicitly identify layout-only invented text. |
| Responsive reference | Actual viewport dimensions, measured layout, landscape scenarios, breakpoint-edge controls, long-name stress data and a container-width specimen. |
| Product behavior | Full-screen review below 640 px; sticky order panel only when both width and available height permit it; explicit type/label retention. |
| Unchanged | Approved fonts, palette, stationary cards, first-visit teaching, financial-field distinctions and disabled real-order execution. |

All market data is illustrative. No account, funds, order service or consent record is connected. The approved logo asset remains outstanding.

### The first-visit learning sequence

A first-time visitor should be able to move through these steps without opening an account:

1. Recognize the category through a familiar person and a clear definition.
2. Understand that the financial contract can gain or lose as its market price changes.
3. See that they do not own a share of the person or receive their income.
4. Follow one simple trade through both possible price directions.
5. Understand that more public attention does not guarantee a rise or profit.
6. Open an example person market, read what its values mean or save it to follow.

This is a reading sequence, not a forced onboarding funnel. A visitor who already understands the product can explore immediately. A returning trader can go straight to their workspace. Screen size never determines expertise.

### The teaching component

The example begins at 100 points and shows outcomes at 110 and 90. It explains the direction of gains or losses before costs; it does not show a cash return or estimate a return on collateral. It states that the trade remains open for the example and that forced closure is not modeled.

The two direction controls are educational. They must not share state with order-direction controls. Changing to Short in the lesson must never populate a real order, select leverage or change an existing position.

Both outcomes stay on screen together. On narrow viewports they stack in a stable order. A visible qualifier explains that a 10-point change is not automatically a 10% return on the user’s money. No confetti, rising balance counter, gain-only scenario or profit-oriented default amount belongs here.

The trade-direction buttons are native buttons with an announced pressed state. Updating the example announces the new result without shifting keyboard focus. The visual hierarchy should not mark one direction as the morally correct or recommended view.

### What must remain visible early

The no-ownership explanation and the possibility of financial loss remain near the opening action. Reading about detailed fees or liquidation can be deferred until the relevant point, but those details cannot be hidden from someone preparing to trade.

“Public influence” is the introductory phrase for the working financial guide’s measure of changing public relevance. The product must not claim that it objectively prices human worth, fame or approval. The exact contract definition and price labels remain the responsibility of the approved financial specification.

## 2. The intended user journeys

### A visitor arriving through a person’s name

They should land on the person, see what the contract represents, understand the displayed value, and find supporting context. They should be able to watch or explore without being pushed into sign-up before learning anything.

### A culturally engaged visitor learning the product

They should first understand why a person has a market, what the trade concerns and how it can gain or lose. Then they can find familiar people, inspect named values and reference information, and explore without trading. Explain unfamiliar terms where they occur. Do not require a sequence of introductory popovers or assume that recognizing a person is trading expertise.

### An experienced trader returning to a market

They should be able to open Markets, restore their selected layout, use search and filters, inspect execution conditions and manage orders without traversing editorial features. Density preferences should change spacing and visibility of optional columns, not the meaning of financial fields.

### A person checking an existing position

They need position value, costs, funding, margin status, order history and available risk-reducing actions. Discovery promotions are not the priority on this screen. An existing position must remain visible when the associated market is suspended or settled.

### An operator dealing with an exceptional state

The system needs named authority, effective times, market notices, auditable changes and consistent user-facing states. The frontend should not invent a trading restriction from a failed chart request or decide that a market is open because it has a recent-looking price.

## 3. Information architecture

### Marketing surface

Proposed routes: `/`, `/how-it-works`, `/market-rules`, `/methodology`, and the appropriate legal/support pages. Publish only content whose ownership and maintenance are assigned.

The homepage contains the opening, a real available-market sample or clearly labeled demo, a short explanation of trading, the contract definition, the reference explanation and a closing browse action.

### Product surface

| Area | Purpose | Core information |
|---|---|---|
| Discover | Find people and relevant context | Search, categories, editorial selection, watch controls |
| Markets | Compare instruments efficiently | Named values, change periods, activity measures, status, sorting |
| Watchlist | Return to chosen markets | Saved identities, current or unavailable values, status changes |
| Market detail | Understand and inspect one instrument | Identity, contract, chart, data sources, rules, order entry |
| Portfolio | Understand existing exposure | Positions, collateral, open P&L, funding, costs and risk |
| Orders | Track instructions and outcomes | Accepted, partial, filled, canceled, rejected and unknown states |
| Account | Manage access and funds | Verification, balances, deposit/withdrawal status, security |

The current design-system examples exercise marketing, discovery and market detail. Portfolio, Orders and Account are specified here as implementation requirements, not presented as functioning features in the file.

Pairs, events and People 500 should not occupy full-priority navigation merely to make the product appear complete. Gate real-money availability on actual financial and technical controls. A read-only benchmark must say it is read-only. A feature flag is not a substitute for authorization. [P1, “The Four Product Types,” “What should not ship just to complete the story”]

## 4. Global navigation and orientation

Keep the selected destination visible. Use real links for navigation, buttons for in-page actions and form submits for form actions. Preserve browser open-in-new-tab and Back behavior in production.

Deep links should include a stable subject or instrument ID. A display ticker is not a sufficient permanent identifier if symbols can be renamed. Search query, category, sort direction and layout can be encoded in the route; never put sensitive account or order information in an exposed URL.

Returning from a person detail should restore the prior search, filters, scroll position and focused result where practical. Do not force a user to re-find the same card after every visit.

For small screens, prioritize Discover, Watchlist and Portfolio/Orders according to actual availability. Overflow links belong in a labeled menu. Do not hide an active order or urgent market-state notice inside it.

A top-level menu should open without moving the content unexpectedly. It must have an accessible name, an expanded state, a predictable dismissal control and sensible focus behavior. At high zoom or short viewport heights, avoid sticky elements consuming most of the screen.

## 5. Discovery

### Entry state

Provide search before a long editorial feed. One editorial feature is enough to establish character. Its relevance should be visible; an oversized photograph without useful context is not an editorial feature.

A returning user’s watchlist can take precedence over the feature. Do not manufacture personalization from a preselected list of names. Explain locally stored watchlists and provide a clear empty state.

### Search

Match names, approved aliases and tickers. Normalize for search, preserving the correct displayed identity. Handle leading dollar signs, case, whitespace and accent-insensitive input where appropriate. Disambiguate people with the same name using relevant verified category information.

Keep the label outside the field. The placeholder is an example, not the label. On narrow screens, the clear control must not overlap typed text. Do not trigger global search shortcuts while the user is editing another field or using a modal.

A search without results should distinguish a spelling mismatch from an active-filter mismatch. Provide a specific reset action. Do not silently discard the query when changing the category.

Search results should announce a concise result count after a settled update, not interrupt the user after every keystroke. No automatic focus jump when the result set changes.

### Card anatomy

Order the fields consistently: identity, category and instrument type, named value with units, period change, relevant state, watch action. Optional context must be attributable and useful.

Use a separate watch control outside the navigation link’s interactive area. Do not nest a button inside a clickable card link. A card must be operable without hover and understandable without its photograph.

The full name must remain accessible and visible at the principal identity location. Allow multiple lines. Do not shrink the font automatically for long names. Abbreviated compact tickers never replace the complete name everywhere.

### List and table mode

Use a semantic table for genuine column comparisons. Numeric columns align right and use tabular figures. Declare the active sort on the relevant column header. Keep sorting stable when incoming values update; do not reorder rows under the pointer without an explicit user request or a clearly announced refresh.

At 1,024 CSS px and below, default to cards for ordinary browsing and comparable record lists. The optional Compact cards view retains column labels, values, sorting and actions without horizontal scrolling. A genuinely two-dimensional matrix is an explicitly justified exception, with a labeled local scroll region. Search, title and actions still fit the page.

Do not present unavailable values as zero. Do not sort missing values as if they were legitimate prices. Distinguish zero activity from missing activity data.

### Optional introductory help

Place **New to People Markets?** between the discovery heading and search. It should open in place without covering market controls, and link to the same worked example used on the website. Its expanded state can be dismissed; browsing should not depend on opening it.

In a production product, a dismissed learning prompt can be remembered locally with a deliberate reset or help route. In this standalone reference, the watchlist and learning state are in memory; they are not synchronized, and reopening the example starts fresh.

### A direct link to a person must still introduce the concept

Someone arriving from a shared person link may never see the website. The detail page must identify this as a financial contract linked to changing public relevance and state the ownership boundary. It should offer the worked example without requiring the user to leave the person permanently or lose their place.

Do not rely on a homepage disclaimer or a completed tutorial to make a detail page understandable.

## 6. Person-market detail

### Opening hierarchy

The opening should identify the person, category, instrument type, listing/trading status and the meaning of the contract. Place the mark price and period change next, then the chart. Keep a nearby explanation that mark price is not an execution quote.

The external reference, last trade and execution estimate have different jobs. They need distinct labels, source timestamps and value types. The financial guide defines Mark Price as the protected Safety Price used for open-position valuation and margin decisions. [P1, “Pricing Strategy”]

### Charts

The default chart should state the series and unit. A comparison switch should not quietly change the basis of the headline number. For two-series charts, use a line style as well as a color distinction; the reference should be dashed and directly named.

Each time period must change the actual range, not merely the highlighted control. The headline change must match that range and series. A young market without a full day of history should not display an invented 24h change.

Avoid dramatic area fills, truncated axes that exaggerate small changes, or repeated price-count animations. Make axis units legible. Show a chart summary and an accessible data view; important data cannot depend entirely on a hover tooltip.

On touch devices, make crosshair or point inspection explicit and avoid trapping ordinary vertical scrolling. On keyboard, provide a reasonable alternative to stepping through thousands of points. A summarized table with downloadable data can be more useful than a complex inaccessible chart widget.

Do not interpolate across missing-data intervals without indicating the gap. Show “No price history” when appropriate, retaining the market’s identity and rules.

### Context and sources

Separate relevant developments, external observations and trade data. A headline can be timely without proving causation. Do not use the label “Why it moved” for an automatically assembled list of coincident events.

Every production context item needs source, publication time, subject mapping and an edit/correction path. Data freshness and the age of the news item are separate values.

### Trading rules

Provide readable definitions and full terms. At minimum cover the settlement asset, contract point value or multiplier, supported order types, applicable margin, funding schedule, fees, risk restrictions and exceptional closure. Put information relevant to the proposed order in the review as well; do not use a rules page to hide it.

### Explain values without renaming them

Keep **Mark price** as the displayed field label when that is the actual value. Provide **What does “mark price” mean?** nearby. Explain its use to value open trades and assess backing, then distinguish it from execution. Explain that points are the quotation unit, not a dollar balance.

Do not replace Mark price with a more inviting label that suggests a different field. Do not turn the reference value into a popularity rating. A first-visit helper adds meaning; it does not redefine the financial instrument.

## 7. Order entry and review

### Default state

Do not preselect a financially consequential direction in a new session. Do not populate an amount or maximum leverage merely because a mockup needs visual weight. The prototype’s sample figures are fixtures, not defaults for production.

The form should identify the instrument, direction, amount basis and settlement asset. Explain whether the amount is collateral, quantity or exposure. Changing the basis must recalculate and relabel dependent values rather than reusing the same number under a new heading.

### Validation

Use visible labels, input descriptions and persistent inline errors. Associate errors programmatically with fields. Validate format during editing when helpful; avoid repeatedly reporting an error before a user has finished entering a decimal value.

On review attempt, focus the first invalid field or an error summary that links to fields. Preserve the user’s valid inputs. An error must not reset the side, instrument or amount.

Production amounts must use approved decimal or integer-minor-unit handling. Do not treat JavaScript floating-point display examples as financial calculations. Backend risk checks remain authoritative.

### Review contents

| Information | Required behavior |
|---|---|
| Instrument and side | Full name, ticker, contract type and explicit long/short direction |
| Amounts | Collateral, quantity, exposure and settlement asset, each correctly labeled |
| Leverage | Current authorized value, not a frontend-invented setting |
| Execution | Order type, estimate where meaningful, limit or price protection, time in force |
| Charges | Applicable entry fee, any known exit-fee convention, network/route charges if applicable |
| Funding | Who pays, rate, interval, next effective time and a position-specific estimate if supported |
| Margin | Initial and maintenance requirements as applicable; source and timestamp |
| Liquidation | Approved estimate or explanation, trigger basis and important qualifications |
| Availability | Verified current trading mode and user authorization |
| Quote freshness | Version/ID, timestamp, expiry and explicit re-review after material changes |
| Action | Exact action in the final button; no misleading simulated confirmation |

A missing essential estimate must not become a dash beside an enabled real-order button. Explain what is unavailable and block the action when the actual system requires that information.

The companion HTML deliberately allows inspection of a sample review layout while keeping order execution unavailable. It does not model funding, liquidation or market execution and is not an economic simulator.

### Submission and reconciliation

The frontend should create or request an idempotent order intent under the approved API contract and keep its reference through retries. Disabling the button after a click helps usability but does not prevent duplicate orders by itself.

Distinguish a request that was never sent from a sent request with an unknown outcome. After a timeout, look up the existing intent/order before offering a new submission. “Try again” can duplicate an action when the first one succeeded but its response was lost.

The final response should distinguish accepted, partially filled and filled. Order acceptance is not proof of a position. Reconcile authoritative events and refreshes; do not infer a fill from a balance animation.

## 8. Position and order management

Portfolio should separate available collateral, reserved amounts, position collateral, unrealized P&L, realized results, cumulative fees and funding. The guide’s implementation needs determine the exact field map; no sum should be reconstructed from unrelated frontend snapshots.

Show what has changed since the last confirmed state. A stale P&L needs a timestamp and indication, not an apparently current green number.

Closing a position is an execution task with its own review. It may fail, partially fill or be subject to a restriction. Explain whether a close request is reduce-only and whether it can reverse the position. Default ordinary closing to the approved risk-reducing behavior rather than silently opening an opposite exposure.

For canceling an order, show “Cancellation requested” until confirmation arrives. A partial fill before cancellation must remain visible. Keep the resulting position reachable from the order record.

A liquidation or auto-deleveraging event needs a durable record, trigger basis, affected quantity, execution/settlement details and a support path. Do not reduce it to a disappearing red toast.

## 9. Market and data states

Treat three dimensions independently:

**Market lifecycle:** proposed, listed, open, close-only, paused, settling, settled or delisted as defined by the backend.

**Data condition:** current, delayed, stale, missing, disconnected or disputed as defined for each feed.

**User eligibility:** signed out, verification required, authorized, region-restricted or account-restricted.

Do not derive any of those solely from another. A paused market can have current data. A delayed chart can coexist with an authoritative execution feed. A signed-out user can read an open market without being permitted to trade.

| State example | Keep visible | Restrict or explain |
|---|---|---|
| Initial loading | Identity, reserved chart area, headings | Show explicit loading labels; no shimmer required |
| No trades yet | Reference if available, rules, trading mode | Last trade is a dash; no fabricated activity |
| No history | Identity, current authoritative values if available | Explain history start or absence |
| Stale display | Last known values plus source timestamp | Label staleness; obtain trading mode independently |
| Execution unavailable | Existing positions and order status | Disable relevant new submissions; show the actual reason |
| Close-only | Position and permitted actions | Block opening/increasing exposure under server rules |
| Paused | Position, history, notice and update time | State exactly which actions remain possible |
| Settled | Closing notice, settlement value and final account effects | Replace the open-market ticket with settlement information |
| Unknown submission | Existing order reference and last known state | Reconcile before offering another submit |
| Offline | Cached reading explicitly dated, draft input | No fake current quote; no offline real-money submission queue |

Thresholds for “stale,” quote expiry and protected mode must be configured by the relevant service, not hard-coded from this design document. A frontend timer can display freshness but should not silently grant execution permission.

## 10. Pairs, events and benchmark views

The split visual composition remains distinctive and useful. Keep both identities the same visual scale, with balanced nameplates and neutral identity colors. Red/green describes financial direction or movement, not a permanent judgment about either person.

A pair direction must reveal its two legs, sizing rule, execution requirement and combined risk. When either leg becomes unavailable, show the actual effect on the pair. Do not submit the remaining leg simply to make the button work. [P1, “Pair Market,” launch controls]

Event views need outcome, resolution source, deadline with timezone, dispute rules and lifecycle. A “Yes” button in an event must not share an indistinguishable card treatment with a long person-market action.

A benchmark needs the methodology, coverage, base date, update time and read-only/tradable status. Do not rank people’s inherent value by comparing separately initialized reference levels. The financial guide distinguishes change-over-time references from a separate cross-person Relevance Score. [P1, “Key Concepts: External Reference”]

## 11. Responsive specification

The rules below match the delivered HTML. They describe available CSS space, not a user’s expertise or a device brand. Financial permissions, trading direction, leverage and consent must never be inferred from width.

### Product layouts

| CSS viewport | Main gutter | Discover | Website | Market detail and review |
|---|---|---|---|---|
| 320–359 px | 16 px | One column of compact person cards; 56 px portrait; full names wrap | Opening and lesson stack; both outcomes remain visible | Order form follows chart and context. Direction choices stack. Review fills the viewport. |
| 360–639 px | 20 px | Compact cards; 76 px portrait; search and view control use separate rows | Opening and lesson stack | Order form remains in document flow. Review fills the viewport; its close/header stays reachable. |
| 640–959 px | 24 px | Two card columns | Introductory text and feature remain stacked | One reading column; order form is at most 600 px wide below chart/context. |
| 960–1279 px | 32 px | Three card columns | Text and feature sit beside one another | Flexible chart column, 24 px gap and 320 px order column. |
| 1280 px and wider | At least 48 px | Four card columns | Same two-column arrangement; reading widths remain capped | Same 320 px order column. Main content is capped at 1280 px in this reference. |

Gutters are inside the usable document area. A classic scrollbar can occupy additional viewport space. The lab therefore reports measured content width instead of deriving it from a device name. At large widths, surplus space becomes outside margin; forms do not become progressively wider. The prior suggestion to expand the trading workspace beyond 1280 px is not part of this fixture.

The documentation shell changes independently at 1120 px: the sidebar is replaced by a labeled section dropdown. The theme selector remains available. This is a reference-navigation pattern, not a proposal to put documentation navigation inside the product.

### Decisions for each screen

**Website.** Preserve the definition, no-ownership explanation, risk statement and exploration action at all widths. The familiar person sits beside the copy at 960 px and above, and after it below that width. The teaching example shows both the rising-price and falling-price outcomes. They become one reading column below 640 px; the losing outcome is never omitted to save height.

**Discover.** Below 640 px, move from image-led cards to compact cards rather than shrinking a four-column grid. The full name, market type, labeled mark, signed period change and watch control remain. Search keeps its label. Category filters wrap. The view control moves onto its own row. At 1,024 px and below, Cards is the default, including the Markets route. The optional Compact cards view keeps all comparison fields and actions in labeled records without horizontal scrolling. Above 1,024 px the existing Table mode remains available, with local scrolling only when needed and a fixed person column. The surrounding page must not acquire a horizontal scrollbar.

**Market detail.** Read identity, named value, explanation, chart and context before the order form in document order. At 960 px, CSS places the order form beside the reading column without changing the keyboard/source order. Below 960 px, the explicit order-example anchor reaches the form. It is not a floating trading button that covers the chart or hides risk information.

**Height.** A wide but short window is not the same layout problem as a tall desktop. The order panel is sticky only when the viewport is at least 720 px high and the measured panel fits with 24 px above and below. If copy expands, text enlarges, or a disclosure makes the form too tall, it returns to normal flow. There is no nested order-form scroll trap.

**Review.** Below 640 px, the product review dialog uses the viewport with `100dvh`, a sticky header/close control, internal scrolling and safe-area padding. On wider screens it is a centered constrained dialog, no taller than the available viewport. Short landscape layouts must still allow the last line and action to be reached. The background becomes inert while the modal is open and is not a second scroll target. Escape and the visible close action dismiss it; focus returns to the opener. [W8]

### Page breakpoints and component breakpoints

Page breakpoints decide how large regions relate. Container queries decide how a reusable component behaves in the space it actually receives. A 1440 px desktop can contain a 300 px sidebar; a card in that sidebar needs its compact form. [W21]

The component-width specimen uses these rules:

```css
.person-card-host {
  container: person-card / inline-size;
}
.person-card {
  display: grid;
  grid-template-columns: 48px minmax(0, 1fr) 44px;
}
.person-card__values {
  grid-column: 1 / -1;
}
@container person-card (min-width: 420px) {
  .person-card {
    grid-template-columns: 72px minmax(0, 1fr) 44px;
  }
  .person-card__values {
    grid-column: 2 / -1;
  }
}
```

At 419 px the values sit beneath the full identity row. At 420 px they align beneath the name, beside the portrait. This specimen demonstrates a reusable component rule; it does not silently override the viewport-based grid used by Discover. Keep both rules named and test them independently when porting to the shared component library.

The slider requests 260–620 px. The container remains capped by available space, and the readout reports its actual measured width. A requested 620 px card inside a 300 px column should not force the page to 620 px.

### Using the viewport lab

Choose Website, Discover or Market detail. Width controls the iframe’s actual CSS viewport; height controls its visible vertical area. Width supports 320–1920 px and height supports 320–1400 px. “Fit to view” visually scales the iframe to fit its documentation panel without changing its internal layout.

For example, a 390 px preview at 80% display scale still runs a 390 px layout. It is not a 312 px layout, and it is not evidence that the on-screen text is comfortable at 80%. Turn fitting off for 1:1 interaction. “Open at full size” opens the example in a normal browser tab using that tab’s dimensions, not the selected preset.

The measurement strip reports the actual viewport, main-content width, navigation arrangement, collection columns, order-panel placement/stickiness and page-level horizontal overflow. These values come from the embedded example, not static captions. Layout outlines expose the real content boundaries. The long-name option substitutes an expressly fictional stress-test identity; it does not create a new public listing.

Scenario buttons apply both width and height. Use 390 × 844 for compact discovery, 768 × 1024 for a two-column collection, 844 × 390 for a short landscape workspace, 1024 × 768 for a chart/order split, and 1440 × 900 for the four-column collection. Additional buttons inspect 639/640, 959/960 and 1279/1280 without changing the data.

### Type, controls and overflow

Display headings resize; interface body copy stays readable rather than scaling with the entire page. Mobile form fields use 16 px at the default text size. Full names wrap before font size is reduced. Do not clip a principal identity or shorten an amount to fit. Allow helper text to add height.

Every grid/flex item containing a table, code sample or long label needs a shrinkable boundary, normally `min-width: 0`. At 1,024 px and below, reflow ordinary record tables into labeled cards. Reserve intentional horizontal scrolling for explicitly justified two-dimensional content, on its own wrapper rather than the page. Do not “fix” an overflow bug with `overflow-x: hidden` on the root: that can make controls and content unreachable.

Custom dropdowns stay within the current visual viewport. They open above the trigger when that side has more space, scroll internally for long lists, and dismiss if the trigger leaves the visible viewport. A popup inside the product iframe cannot paint outside that iframe. Popup placement is a different issue from scaling the documentation preview.

### Test cases and acceptance criteria

| Test | Procedure | Acceptance |
|---|---|---|
| Breakpoint boundaries | Check 639/640/641, 959/960/961, 1023/1024/1025 and 1279/1280/1281 CSS px | Layout changes at the documented threshold without losing labels, values or controls. |
| Narrow reflow | Open each screen at 320 px | The page has no horizontal overflow. Market collections and ordinary data records use cards without sideways scrolling; only genuinely two-dimensional content may use a labeled local scroll region. [W1] |
| Card-first collection | Open Markets at 320, 768 and 1024 px; switch to Compact cards; resize a desktop table across 1024/1025 px | Small-screen entries default to cards. Compact records retain every value, sort and watch action without horizontal scroll. Desktop view preference returns above 1024 px. |
| Portrait and landscape | Check 390 × 844 and 844 × 390 | The content order stays meaningful; no oversized sticky element traps the lower part of the screen. |
| Component sizing | Set the component specimen to 419 then 420 px | Values move as documented; requested and measured widths are distinguished. |
| Long identity | Turn on the fictional long-name fixture, then open its market | The complete name remains available in rows, cards, table and detail. |
| Text size | Test real 200% browser text enlargement | No clipping, missing instructions, hidden control labels or blocked action. CSS stress checks are supplementary. [W2] |
| Browser zoom | Test 400% zoom from a 1280 px-wide desktop view | Reflow behavior is assessed with actual browser zoom, not a preview transform. [W1] |
| Keyboard on phone | On actual iOS and Android devices, focus the amount field | Label, unit, error and review action remain reachable with the on-screen keyboard open. |
| Edge dropdown | Open a dropdown near the bottom of a short window | Popup opens into visible space; highlighted option stays visible; Escape restores the previous choice. |
| Focus and review | Reach the form by keyboard, open the review and close it | Focus is visible, stays in the modal while open and returns to the invoking control. [W7, W8] |
| Touch | Use a real touchscreen | Full choice labels are tappable; no explanation depends on hover; native scrolling is preserved. |
| Content failure | Block fonts and images, provide an unavailable price | Identity remains readable; missing numbers are not replaced with zero. |

The lab is a design and debugging aid. It does not reproduce a device’s keyboard, browser chrome, assistive technology, touch ergonomics or physical screen density. Its successful layout checks are not an accessibility certificate.

## 12. Visual system rules

### Typography

Bricolage Grotesque: display headings and prominent person names, usually 600–750 weight with optical sizing. Instrument Sans: body, controls, descriptions and table labels, usually 400–600. IBM Plex Mono: point values, balances, tickers and tabular numbers, usually 400–500.

Do not use Bricolage for every small label. Do not make descriptions monospaced. Use weight and layout before adding colored badges. Load only the required weights and character coverage; do not generate faux italics or an unrequested fourth family.

The HTML references remotely served fonts and includes no font binaries. Production should use the team’s approved hosting and licensing approach, with fallback metrics tested. The named font families’ own source repositories are listed below. [W10–W12]

### Color

Paper `#F7F5EF`; surface `#FFFFFF`; ink `#181A20`; muted `#60646F`; cobalt `#2452FF`; blue wash `#E9EEFF`; butter `#F3E5AB`; gain `#087452`; loss `#BF3545`.

Separate raw palette values from semantic roles. The default blue can be a brand swatch, while actionable link/focus colors have a different accessible value in dark mode. Gain/loss colors describe movement, not identity. Funding should state payer direction rather than depend on a color interpretation.

Decorative separators can be subtle. Boundaries needed to identify input controls must use the stronger control-border token. The HTML includes calculated contrast examples; those checks do not audit every rendered combination.

### Geometry and spacing

Use a 4 px base with a limited sequence: 4, 8, 12, 16, 20, 24, 32, 48, 64 and 96. Controls use a 10 px radius, normal panels 16 px and a large editorial composition 20 px. Reserve pills for genuine small tags or filters.

Do not wrap every paragraph in a card. Use horizontal rules and spacing for document sections. Use a container when content behaves as a unit: a market, a review panel, a menu, or a self-contained notice.

### Portraits and identity

Reserve a consistent aspect ratio, set a focal point, and test the crop on multiple subjects. Do not cut off important facial features to satisfy an arbitrary rectangle. Place names in a dedicated area, not across a busy face. On hover, the crop, position, filter and scale remain unchanged.

A name-led fallback must look intentional and preserve identification. Do not invent a silhouette or substitute an unrelated person. Use initials only alongside the complete name, and handle people who share initials.

The locally hosted reference photographs are not approved production assets. Keep the source and license credits on the photo-credits page. A license notice alone is not a complete endorsement or personality-rights review. [W13]

### Logo

Do not invent another monogram. Keep a neutral text placeholder until the original approved vector asset is supplied. Preserve its aspect ratio, approved clear space and variants. Test real legibility at the small header size before specifying a favicon or app icon. A typed name is not a restored logo.

## 13. Interaction rules

Cards do not lift, zoom, tilt, change photographs, or animate entry. Hover may change a border or underline immediately. Selection needs a persistent non-color cue. Keyboard focus is visible independently of hover.

Avoid animated counters, moving tickers, automatic carousels, confetti and skeleton shimmer. A stable loading block is sufficient. Do not animate through every intermediate price when a quote changes.

Respect reduced-motion preferences even if the first version contains little animation. New components should default to no essential motion. Useful transitions must not determine whether someone can perceive an order state.

Loading and success feedback should be anchored near the action. A toast is acceptable for a watchlist update; it is not the only record of a filled order, failed withdrawal or forced position closure.

### Shared control layer

The reference and embedded product screens now use the same control CSS and dropdown enhancement. The goal is not to replace browser behavior wherever possible. It is to give the controls a consistent appearance while retaining reliable semantics and familiar interaction.

**Single-select dropdown.** A labeled select-only combobox opens a listbox. The trigger displays the committed value. The saved choice has a checkmark; the option being explored has an independent pale background, with no left border or inset highlight. Arrow keys, Home and End explore; Enter, Space or Tab commits; Escape cancels; typing moves to a matching label. Disabled values are visible but skipped. Keyboard focus remains on the trigger and the active option is exposed with `aria-activedescendant`. The source select retains the form value and receives a change event only when a choice is committed. The custom popup requires browser and assistive-technology testing before production adoption. [W16]

Keep a styled native select when JavaScript is unavailable. Do not hide it before enhancement succeeds. Do not apply this value-selection pattern to a menu of commands such as “Export” or “Sign out.” Programmatic value changes must update the trigger as well as the hidden form value; the reference exposes `PMControls.sync()` for that purpose. Mirror required, disabled, description and invalid states. In a framework, bind a shared value rather than maintaining divergent DOM state.

**Checkbox.** Use a real checkbox input. The custom square is 20 px, but the clickable label area is at least 44 px high. The selected state has a tick; the mixed group state has a short horizontal mark. The mixed state is derived from the children, not stored as an unrelated choice. Space toggles the field; selecting the mixed “All categories” checkbox selects the entire group. Forced-colors mode restores native appearance. Never preselect consent or treat an acknowledgement checkbox as evidence of comprehension. [W17]

**Radio and selection card.** Use one named native radio group for one mutually exclusive decision, with a fieldset and legend. A surrounding card may enlarge the target but must not become a second interactive element. A dot identifies the selected radio; the card border/background reinforces it. Arrow keys change the choice. Defaulting a display preference is different from defaulting a consequential trading direction: the order example begins with neither Long nor Short selected. A multi-select card uses a checkbox instead of a radio. [W18]

**Switch.** Use it for an immediate, reversible setting. “Show external reference” keeps the same label in both states. The underlying checkbox uses switch semantics; its checked state is the value. Use a checkbox instead when the value is part of a form saved later. A switch is not an order button, a payment instruction or a consent shortcut.

**Amount field.** Keep the visible unit with the input, and associate it through an accessible description. The focus ring surrounds the input group. Do not write a unit only as placeholder text. Keep financial parsing, precision, balance checks and current permissions in the appropriate domain layer; a styled amount field is not an execution engine.

**Stepper and range.** Use explicit increments only for quantities that warrant them. The rows-per-page specimen supports 5–50 in steps of five, direct editing and disabled boundary buttons. The range slider controls a layout specimen; its numeric alternative permits exact input. Do not reuse either as a silent production leverage default.

**Tabs.** Tabs identify related panels. The specimen uses manual activation: Left/Right/Home/End move focus; Enter or Space opens the focused panel. The active underline is stable. Tab panels retain a label relationship. Do not turn independent filters into fake tabs, or nest tab controls inside another composite toolbar without defining the keyboard behavior.

**Disclosure and contextual help.** Use an in-flow disclosure for secondary explanations. Its plus/minus indicator changes without rotation or transition. Critical fees, selected direction, unresolved status and trading restrictions stay visible rather than being relegated to a tooltip. Help must be usable with keyboard and touch.

**Scrollbar and text selection.** Keep native scrolling. Use the shared neutral thumb and transparent track, with a platform-sized page scrollbar. Reserve a scrollbar gutter where supported to reduce layout movement. Do not hide scrollbars, draw a fake draggable thumb, intercept the wheel or add inertial animation. System overlay settings may control visibility, and browser styling support differs. Text selection uses cobalt and a contrasting foreground. In forced colors, return scrollbar colors to the system. [W19, W20]

### Supporting notes and quoted content

Ordinary reference notes use a small topic label, restrained horizontal rules and direct copy. An operational notice uses a persistent, explicitly named state and any currently available next step. A quotation uses a real source and attribution; the quotation specimen in the HTML is labeled as invented layout text and is not research evidence.

Do not give every rule a blue background and a motivational heading. The actual price example is “+4.12% over 24 hours.” A funding explanation names who pays whom. Those concrete details are more useful than “Keep financial meaning explicit.”

### Control acceptance checks

Each control needs default, active/focused, selected, disabled and invalid behavior where applicable. Check accessible names, full-label hit areas, value synchronization and native fallback. Test closing a popup through selection, Escape, outside pointer interaction, tabbing away, and moving the anchor out of view. Verify the distinction between exploring a dropdown option and committing it.

Checkbox tests include none, some and all selected. Radio tests include an initially empty trade direction and keyboard movement through an ordinary defaulted preference. Verify that a switch changes only its stated setting. Dialog tests include scroll-to-end, Escape, visible close, focus return, and short landscape height. The financial submit action remains unavailable in this reference.


## 14. Accessibility requirements

Target WCAG 2.2 AA through implementation and testing, not through a label on the design file.

| Area | Requirement |
|---|---|
| Text contrast | At least 4.5:1 for ordinary text and the applicable 3:1 threshold for large text; use unrounded calculations for pass/fail [W3] |
| Non-text contrast | Necessary control boundaries and graphical distinctions need appropriate 3:1 contrast against adjacent colors [W4] |
| Color | Pair color with labels, signs, line styles or icons [W5] |
| Targets | Use 44 px hit areas as the product design target; WCAG 2.2 AA’s 24×24 CSS px criterion includes exceptions and is not identical to this recommendation [W6] |
| Focus | Visible keyboard focus; no complete obstruction by sticky UI; focus return after a modal [W7, W8] |
| Forms | Persistent labels, field instructions, associated errors and sensible keyboard order [W9] |
| Feedback | Concise programmatic status messages without unnecessary focus theft [W14] |
| Reflow | Ordinary content fits at 320 CSS px; independently scroll only genuinely two-dimensional regions [W1] |
| Text resizing | Test 200% text resizing without lost information or functionality [W2] |

Use native elements before constructing custom ARIA widgets. Where custom tabs are necessary, implement their keyboard behavior; do not add tab roles to ordinary buttons without the associated behavior.

Screen-reader testing must cover the market identity, every price label and unit, chart alternative, order form, review, unknown submission, partial fill and return-focus behavior. Automated tests cannot establish that a risk explanation is understandable.

Include forced-colors/high-contrast mode, touch-only use, keyboard-only use and at least one real mobile screen reader in the release audit. The companion file’s automated checks are limited to the environment stated inside it.

## 15. Data and frontend contracts

Each market value should carry its identity and freshness, not arrive as an anonymous number.

```ts
type ValueKind =
  | 'external_reference'
  | 'event_aware_reference'
  | 'market_fair_estimate'
  | 'last_trade'
  | 'mark_price'
  | 'settlement_price';

type ValueState = 'available' | 'missing' | 'stale' | 'disputed';

interface MarketValue {
  instrumentId: string;
  kind: ValueKind;
  value: string | null;       // Decimal string, never a fabricated zero.
  unit: 'points';
  precision: number;
  observedAt: string | null;  // ISO timestamp with timezone.
  state: ValueState;
  sourceVersion: string | null;
}

interface TradingPermissions {
  canOpen: boolean;
  canIncrease: boolean;
  canReduce: boolean;
  canClose: boolean;
  reasonCode: string | null;
  effectiveAt: string;
}
```

This is a proposed presentation contract, not an assertion about existing API names. Reconcile it with the actual backend. Keep instrument metadata and contract multiplier distinct from market prices. P&L must come from approved calculations and authoritative account state.

Parse dates and amounts centrally. Retain full precision internally and apply an explicit display policy. Never interpret a locale-formatted string as a financial value through a generic `parseFloat` call. Keep null, zero and stale last-known values distinct throughout the view model.

Handle out-of-order realtime messages, duplicate events and reconnects. Display sequence/version conflicts as a reconciliation issue where needed; do not flash contradictory balances. Snapshot and incremental feeds need a clear precedence rule.

## 16. Component contracts

| Component | Inputs | Key states | Required behavior |
|---|---|---|---|
| PersonIdentity | Stable ID, name, category, ticker, approved image | Image missing, long name, unverified relationship | Complete identity remains readable; badges retain distinct meanings |
| MarketValue | Typed value, unit, timestamp, source state | Present, missing, stale, disputed | No invented zero; accessible name includes type and unit |
| WatchControl | Saved state, subject ID, storage mode | Unsaved, saved, failed | Independent action; pressed state and clear feedback |
| MarketCard | Identity, mark, period change, lifecycle | Open, restricted, preview, no data | Navigation and watch button do not nest |
| PairHeader | Two identities, instrument and leg definition | Preview, open, leg unavailable | Balanced layout; full relationship retained on mobile |
| ContextItem | Subject, text, source, timestamps, verification | Verified, corrected, removed | No implied causation; source remains available |
| PriceChart | Series kind, units, period, source state | Current, empty, missing interval | Matching summary, accessible alternative, no misleading interpolation |
| OrderTicket | Permissions, instrument config, account state | Pristine, invalid, quote pending, ready, blocked | No frontend authorization; preserves draft |
| OrderReview | Versioned intent, amounts, quote, costs and risk | Current, expired, changed, incomplete | Explicit re-review after material change; no submission with missing essentials |
| OrderStatus | Authoritative order ID and lifecycle | Accepted, partial, filled, cancel pending, unknown | Persistent history and reconciliation path |

Primitive controls also have contracts:

| Component | Source of truth | Important behavior |
|---|---|---|
| SelectField | Committed value, options, disabled/required/invalid flags | Preserve draft highlight separately; cancel with Escape; synchronize programmatic changes. |
| CheckboxGroup | Individual child values | Derive all/mixed/none; the group checkbox cannot contradict its children. |
| RadioGroup | One selected value or null | Native grouped input behavior; a null trade direction is meaningful. |
| Switch | Boolean immediate setting | Stable label; change only the stated reversible effect. |
| ScrollRegion | Browser scroll position and content | Native wheel/touch/keyboard; visible affordance and region name when needed. |
| ReferenceNote | Topic and body | Plain guidance, not an operational status or fabricated quotation. |
| OperationalNotice | Known condition, timestamp/reference, available actions | Persist until resolved; do not claim a service or action exists when it does not. |
| SourceQuote | Exact text, source, date/context | Attribution travels with the quote at all widths. |

Component documentation should include a populated, empty, error and narrow-width example. A button gallery alone is not a complete financial product design system.

## 17. Performance and resilience

Use an explicit performance budget rather than “make it fast.” Proposed starting budgets: avoid loading the full trading chart bundle on the marketing route; lazy-load secondary portraits; reserve media dimensions; and keep reading and navigation usable before external fonts or images finish loading.

Measure the deployed product against Core Web Vitals at the 75th percentile, segmented by relevant device conditions. The published “good” thresholds are LCP at or below 2.5 seconds, INP at or below 200 ms and CLS at or below 0.1. These are external measurement thresholds, not results achieved by this prototype. [W15]

Do not use a slow page transition to hide a slow data request. Render stable identity and explicit loading states. Preserve an order draft on reconnect, but never queue an offline real-money submit for silent later execution.

On poor connections, distinguish assets failing from financial data failing. Missing Bricolage changes typography; missing the authoritative quote changes what a user can safely do. The UI must not treat those as equivalent errors.

## 18. Validation plan

### Functional checks

Test search, filters, empty results, watch toggling, route restoration, chart periods, reference visibility, form validation, review opening/closing, and status changes. Verify that each control performs the action its label describes.

Test order duplicates, response loss, late fills, cancel/fill races, quote expiry, a market switching to close-only during review and a session expiring during an attempted submission. These need backend test environments, not a visual mockup.

### Responsive and visual checks

Review light and dark themes at the widths in section 11. Test long names, large positive and negative values, narrow order panels, missing images, remote font failure, translated labels, decimal input and long source titles. Test both touch and pointer conditions.

Do not accept a screenshot merely because nothing overlaps. The price, unit, status and next action must remain readable and appropriately prioritized.

### Usability sessions

Recruit separately for people familiar with the cultural subjects and for experienced trading-product users. Suggested first rounds: five to eight participants in each segment, followed by fixes and another round. This is a research plan, not a statistical guarantee or a claim of completed testing.

Ask users to explain the contract, identify different values, save and revisit a market, understand a pair, inspect an order’s costs, and recover from an unknown submission. Record confusion and false confidence as carefully as completion time.

### Metrics

Measure time to a relevant market, successful search, revisit success, comprehension of contract and risk, error recovery, duplicate-intent prevention and task completion. Exploration-to-account conversion can be observed, but more deposits or higher leverage are not sufficient evidence of improved UX.

### Staged newcomer comprehension test

Recruit readers who have not seen People Markets and are not briefed by the founding team. Include culturally engaged people without derivatives experience as well as people familiar with trading. This is a proposed test, not research already performed.

**Stage 1: the opening.** Ask “What does this product let you do?” and “What would you own or receive after making a trade?” Do not suggest the expected answer. Check for mistaken interpretations involving ownership, artist payments, donations or guaranteed returns.

**Stage 2: the example.** Ask what happens to a long trade when the price falls. Then ask whether a growing audience guarantees a profit and what information is missing before calculating a cash result.

**Stage 3: a person page.** Ask the reader to explain the large displayed value, distinguish it from a cash balance, find the source of its explanation and locate a non-trading next action.

**Stage 4: the review.** Ask what money is being committed, what could be lost, which costs apply and whether the order has actually been placed. Test unknown submission and partial-fill states separately from marketing comprehension.

Record the person’s actual explanation, not merely whether they clicked the intended button. Rewrite repeated misunderstandings before expanding the acquisition funnel. Do not call a headline successful only because it increases trading clicks.

### Reference-file checks for this revision

Verify that section links and deep source links open the correct documentation page, browser Back restores the preceding section, reading view exposes all sections, mobile navigation remains usable and keyboard focus reaches the newly opened section. Verify that the frame’s selected CSS width and height differ correctly from its display scale. Resetting the frame is allowed for a design lab but must not be confused with production state persistence.

The actual test record is maintained inside the delivered HTML. It is limited to the tests run in the available environment; no production accessibility or real-device certification is implied.

## 19. Build sequence and release gates

**Foundation.** Integrate approved tokens and typography, apply the original logo, establish the typed market-value layer, and replace inconsistent primitive components. Keep the existing app routing and service boundaries unless a separate engineering decision changes them.

**Core reading journey.** Implement homepage, discovery, watchlist and person detail with real and failure fixtures. Validate responsive layouts and comprehension before adding more product categories.

**Transaction journey.** Wire permissions, order entry, quote review, submission, reconciliation, orders and position management. Verify against actual risk and execution services. Do not port the design-system’s numeric examples as configuration.

**Operational states.** Implement close-only, paused, stale, unknown, settled and account-restricted flows. Test notices and support paths with operations.

**Release audit.** Complete real-device/browser testing, assistive-technology testing, source/claim review, asset review, performance measurement and the financial/technical release checks. Launch scope follows proven capability, not the size of the navigation menu.

### Outstanding approvals

Original logo asset and variants; portrait and likeness suitability; current repository/API mapping; market eligibility; contract units and multiplier; default/supported order types; leverage and fee policy; funding presentation; liquidation disclosures; freshness thresholds; quote-expiry policy; regional eligibility; pair/event/benchmark availability; source licensing; final customer copy.

## 20. Sources and evidence boundaries

**[P1]** *People Markets – Financial, Trading and Quant Design.docx*, project-accessible Library, retrieved 24 September 2026. Relevant sections are named at the points of use. This is the working financial design source, not proof that all proposed behavior is implemented.

**[W1]** W3C: [Reflow](https://www.w3.org/WAI/WCAG22/Understanding/reflow.html).  
**[W2]** W3C: [Resize Text](https://www.w3.org/WAI/WCAG22/Understanding/resize-text.html).  
**[W3]** W3C: [Contrast (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html).  
**[W4]** W3C: [Non-text Contrast](https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html).  
**[W5]** W3C: [Use of Color](https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html).  
**[W6]** W3C: [Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html).  
**[W7]** W3C: [Focus Not Obscured (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/focus-not-obscured-minimum.html).  
**[W8]** W3C ARIA Authoring Practices: [Modal Dialog Pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/).  
**[W9]** W3C: [Labels or Instructions](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html).  
**[W10]** Instrument: [Instrument Sans](https://github.com/Instrument/instrument-sans).  
**[W11]** Mathieu Triay: [Bricolage Grotesque](https://ateliertriay.github.io/bricolage/).  
**[W12]** IBM: [IBM Plex](https://github.com/ibm/plex).  
**[W13]** Wikimedia Commons: [Tems reference-image source](https://commons.wikimedia.org/wiki/File:Tems_Afro_Plus_Fest_(55514652102).jpg).
**[W14]** W3C: [Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html).  
**[W15]** Google/web.dev: [Web Vitals](https://web.dev/articles/vitals).


**[W16]** W3C ARIA Authoring Practices: [Select-only combobox example](https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/).  
**[W17]** W3C ARIA Authoring Practices: [Checkbox pattern](https://www.w3.org/WAI/ARIA/apg/patterns/checkbox/).  
**[W18]** W3C ARIA Authoring Practices: [Radio group pattern](https://www.w3.org/WAI/ARIA/apg/patterns/radio/).  
**[W19]** MDN: [CSS scrollbar styling](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Scrollbars_styling).  
**[W20]** MDN: [Scrollbar gutter](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/scrollbar-gutter).  
**[W21]** MDN: [CSS container queries](https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Containment/Container_queries).

References W16–W21 were reviewed for this revision on 24 September 2026. Code patterns remain illustrative and require the product’s browser, device and assistive-technology verification.

The layout, copy, component API examples, performance budgets and research plan are proposed People Markets design decisions. External standards are cited where they supply specific requirements or thresholds. The HTML’s test record states the actual checks performed on the reference artifact and explicitly separates them from production verification.

**[W22]** Lucide: [Design specification](https://lucide.dev/contribute/icons/specification).  
**[W23]** Lucide: [Vue getting started](https://lucide.dev/guide/vue/getting-started).  
**[W24]** Lucide: [Vue migration](https://lucide.dev/guide/vue/migration).  
**[W25]** MDN: [Scrollbar styling precedence](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/::-webkit-scrollbar).