Skip to content

Methodology

This audit evaluates Krux's display interface on four axes: text legibility, color contrast, layout consistency, and navigation clarity. It covers all 9 supported devices, grouped into 3 hardware tiers.

Hardware scope

Krux runs on 9 devices with very different screens:

Tier Devices Screen Font Input
Large Amigo 480x320 12x24px Touch
Standard TZT, Dock, Yahboom, WonderMV, WonderK, EmbedFire 320x240 8x16px Touch and/or buttons
Minimal M5StickV, Cube 240x135 / 240x240 8x14px Buttons only

The primary pass uses one representative device per tier: Amigo, TZT, and M5StickV. When a result looks device-specific, other devices in that tier get checked before the finding is treated as general.

The four axes

1. Text legibility

Can you actually read everything at arm's length?

  • Characters per line, measured against the active text surface (representative pass: 16-27 ASCII chars per line)
  • CJK and wide glyph handling across 11 locales, source/test verified
  • Font-to-screen ratio at ~30cm viewing distance
  • What happens when wallet addresses and mnemonic words get truncated

2. Color contrast

Do text/background pairs meet WCAG 2.1 ratios?

  • Convert RGB565 byte-swapped color values to standard RGB
  • Compute relative luminance per the WCAG formula
  • Check every foreground/background pair in each theme
  • AA needs 4.5:1, AAA needs 7:1

3. Layout consistency

Is spacing predictable across screens and devices?

  • Does anything render into the reserved status bar or prompt area?
  • Are the two padding constants (10px, 5px) used consistently?
  • Does dynamic menu scaling produce even spacing or weird gaps?
  • Does a layout that works on TZT also work on M5StickV?

For layout, the audit separates current screen failures from maintainability debt. A current failure means overlap, clipping, or a device tier where the screen becomes hard to use. Maintainability debt means the UI works today, but the code uses hardcoded offsets, duplicate centering math, or parallel layout algorithms that can drift later.

4. Navigation clarity

Can you understand the current state, choose the right branch, and recover from a mistake without carrying unnecessary choices through the common path?

  • Screens and required selections for each target flow
  • Number and meaning of choices at each branch
  • Whether the label predicts the result
  • Whether common and specialist operations receive equal prominence
  • Whether the required context is visible before commit
  • Minimum M5StickV button presses and wrong-choice recovery
  • Smallest touch targets in practice (WCAG 2.2 SC 2.5.8 minimum: 24x24px; WCAG 2.5.5 enhanced target: 44x44px)
  • Source, screenshot, test, user report, and current upstream overlap

Menu length and flow depth remain descriptive measurements. They are not pass conditions. The earlier "7 plus or minus 2" rule was removed because it did not measure attention cost, label clarity, or task relevance.

The v3 navigation pass applies this method to mnemonic creation, wallet confirmation, mnemonic loading, and numeric settings. Exposure uses flow categories such as "every mnemonic load" or "settings users only" instead of invented usage percentages.

M5StickV and Cube are not treated as touch-target failures. They are button-only for this axis, so the relevant navigation question is how many presses are needed and whether state is clear after each step.

Evaluation order

  1. Contrast first (computed ratios, binary pass/fail, least subjective)
  2. Legibility (source-derived metrics, focused tests, then screenshots)
  3. Layout (annotate screenshots, compare across devices)
  4. Navigation (trace actual user flows, measure depths and input effort)

Contrast came first because it produces the clearest pass/fail data. Layout and navigation need more judgment, so they came after the structured evidence was in place.

Evidence refreshes

Not every audit update needs a full screenshot rerun. A targeted refresh is enough when the relevant source points are unchanged and the existing annotated screenshots still match the claims. For navigation, targeted screenshots are enough when the question is a specific flow, menu position, or button-navigation state. A full cross-device capture is reserved for behavior changes, new device-specific claims, or screens where the existing evidence is missing or stale.

Severity scale

Level Meaning
Critical Blocks task completion or makes text unreadable
High Significantly hurts usability for some users
Medium Noticeable friction, but you can work around it
Low Cosmetic inconsistency, nothing breaks

What goes into a finding

Each one needs:

  • The actual measurement or observation
  • Which device(s) and theme(s) are affected
  • A severity rating and why
  • Screenshot if applicable
  • Possible fix (saved for implementation phase)

Tools

  • The Pygame simulator (runs all 9 device profiles)
  • Sequence-driven screenshot scripts (354 captures per run, 3 devices)
  • WCAG luminance calculations from the raw RGB565 color values
  • Manual screenshot annotation for layout comparisons