Files
jobtrackingapp/docs/redesign/phase-5/p5-15/p5-15-02/RESPONSIVE_RESULTS.md
T

11 KiB
Raw Blame History

P5-15-02 responsive measurements

This supporting record reports fresh browser geometry and interaction evidence. It does not decide the complete audit, certify screen-reader or physical-device acceptance, or report a fresh full browser suite. No application or document-renderer code was changed for these measurements.

Evidence provenance

Raw report under the ignored .artifacts/p5-15-02/browser/ directory Recorded start / duration Result SHA-256
zoom.json 2026-10-10 18:22:11.787 UTC / 43.912 seconds 2 collection cases passed; 0 failed/skipped/flaky ec2688b919aac5eade1613c94405d889dacd649cfa932e83f9faea748edc4e1a
audit-attempt3.json 2026-10-10 18:25:41.491 UTC / 197.611 seconds 2 collection cases passed; 4 interaction cases failed; 0 skipped/flaky 89af6297f09ad03072e5a617e0e4b0dd55cd8ebe1a8b310872525a8d1d81319d

zoom-observations.json is a parsed view of zoom.json; its actual-browser-zoom-observations attachments contain the measurements. The responsive measurements below were read directly from JSON attachments embedded in audit-attempt3.json, including drawer-focus-recovery and emulated-touch-boundary. These are successive runs, not independent sets to sum into a larger acceptance count.

The collection cases intentionally retain findings without asserting that every measured screen passes accessibility. A green collection result means the native route was loaded and evidence was collected. Those four historical runner failures are retained; one was a subsequently corrected Job-tab test assumption, not an unresolved product defect.

Actual browser zoom

The zoom test used Chromium 151.0.7922.34 with a temporary extension invoking chrome.tabs.setZoom, an unmanaged browser viewport (viewport: null), and an unchanged 1280 × 900 outer window. The actual tab zoom and device-pixel ratio were asserted. This is browser layout zoom, not a CSS transform, viewport-only emulation, or pinch zoom.

Tab zoom Inner CSS viewport Device-pixel ratio Visual viewport scale Outer window
100% 1264 × 805 1 1 1280 × 900
200% 632 × 402 2 1 1280 × 900
400% 316 × 201 4 1 1280 × 900

The 400% inner width is slightly narrower than 320 CSS pixels because the browser's available content width is 1264 pixels. The unchanged outer size and increasing pixel ratio demonstrate actual zoom rather than resizing alone.

The final Playwright400% raster captures show only a cropped top-left header, not a full-window visual comparison. They are retained with that limitation and cannot establish content/focus readability or complete visual reflow acceptance. The asserted tab zoom, inner dimensions and geometry ledger remain valid independently; human full-window/task review is still required.

There are 102 geometry records: 78 measurements across 13 areas × 3 zoom levels × 2 language/theme combinations, plus 24 text-spacing measurements across the 12 protected areas × 2 combinations. The combinations are English/light and Bokmål/dark. Authentication is measured before sign-in; the protected routes use synthetic owned records and native API responses. The 13 areas are Authentication, Shell, Jobs, Board, Dashboard, Analytics, Job workspace, Documents, Career Profile, CV Builder, Settings, Administration, and Correspondence.

All 102 records reported 0 pixels of outer-page horizontal overflow. All measured application main containers reported 0 pixels of horizontal overflow; the public sign-in page has no main landmark, so that field is null. This does not prove every control is visible: an enclosing container can clip content while keeping the outer page narrow.

Interpreting controls outside the viewport

Measurement Interpretation / required follow-up
Jobs desktop row actions extend beyond the initial view at 100%, with and without text-spacing overrides These are inside the named, horizontally scrollable Jobs table region. This is intentional two-dimensional table content, not outer application overflow. Scroll/focus access must remain verified separately.
Board cards and quick-status actions extend to later columns at 100%, 200%, and 400% They are inside the Board's horizontal scroller. Off-screen columns alone do not demonstrate lost controls. Physical touch scrolling and dragging remain unverified.
Job workspace tabs extend beyond the initial visible strip at 200% and 400%; CV studio tabs do so at 400% Both use MUI scrollable tabs. The simple zoom collector marks them intentionalScroller: false because its selector recognises tables, Board cards, and document pages, not tab strips. The richer responsive collector confirms overflow-x: auto ancestors. Do not promote these flags alone into a reflow defect. Keyboard activation/focus findings are separate.
Jobs next-page action at 400%: English x=316.1, Bokmål x=315.1, width 44 CSS pixels in a 316-pixel viewport A clipping candidate for the pagination footer, rather than an allowed table exception. This zoom fixture has four jobs and 15 rows per page, so it does not prove that enabled next-page navigation is unusable. Verify with multiple pages and actual activation before assigning that impact.
Settings switch input at 200%/400%: x=-16, width 114 CSS pixels; landscape text spacing: x=-4, width 114 This is the transparent MUI switch input hitbox for allowing approved external AI processing, not the visible switch track or text label. Geometry alone does not establish a clipped or unnamed user-facing control. Inspect visible styling and keyboard/pointer activation separately. No AI setting was changed by this audit.
Administration Delete actions at English 100%: x=1225.8, width 64 in a 1264-pixel inner viewport The richer native responsive sample identifies an overflow-x: auto ancestor. Treat this as a horizontally scrollable administration data surface, not a demonstrated dead action. Full destructive-action testing is outside this measurement.

The document canvas remains a distinct two-dimensional surface. Its pages and iframe renderer were not given the parent application's text-spacing overrides or modified geometry. Outer UI reflow must not be achieved by changing print dimensions or pagination.

Responsive and landscape collection

The responsive test retained 42 scan/geometry attachments in audit-attempt3.json. All reported zero outer-page horizontal overflow. The distributed samples include 320, 390, 767, 768, 899, 900, 1023, 1024, 1280, and 1440 CSS-pixel widths; heights include 844/900 portrait and 390 landscape. These are a representative distribution, not every route at every width.

Coverage Fresh available evidence Limit
Shell breakpoint transitions Jobs samples at 767/768, 899/900, and 1023/1024 pixels Drawer focus fails in the separate reduced-motion interaction case. Geometry does not replace that failed contract.
Narrow application chrome Sign-in320; Jobs320; job Timeline320; Documents320; Settings320; command dialog390; profile/CV390 Loaded controls and geometry were collected. Complete workflows and human reading were not executed at every width.
Desktop/data-rich surfaces Jobs/Profile/CV/Dashboard1440; Board/Admin1280; Analytics/Documents1024 Intentional table/Board scrolling is classified separately.
Landscape text spacing Dashboard, Analytics, Jobs, Documents, Settings, CV at844 × 390, Bokmål/dark User stylesheet simulation, not browser font-size preference or physical orientation.
CV touch-mode transition Emulated taps in390 × 844 portrait and844 × 390 landscape; native CV data equality verified Physical touch, orientation sensor, native touch drag, and software keyboard are explicitly NOT VERIFIED. The later drawer focus-return assertion failed.

Text-spacing collection applies line-height1.5, letter-spacing0.12em, word-spacing0.16em, and paragraph end spacing2em to the parent UI. The native landscape attachments record the applied method. The 24 additional zoom-suite spacing samples use the same values at100% zoom. Both approaches leave the document iframe unchanged. No outer overflow was measured, but that does not certify all text remains readable or that every clipped field can be operated.

Reduced-motion drawer recovery

At390 × 900, English/light, keyboard Enter opened the mobile Navigation drawer. The drawer-focus-recovery attachment records:

  1. Before axe runs, focus remained on the background Open navigation button; focusedInDialog=false.
  2. After axe runs, focus still remained there. Therefore the lost entry focus was already present before scanning.
  3. Immediate Escape left the drawer visible and focus outside it.
  4. Tab followed by Escape closed the drawer. Focus then returned to a contained primary ButtonGroup button, not the navigation trigger.

This proves a recoverable but broken focus-entry/Escape-return contract in that scenario. It does not prove an inescapable keyboard trap. The Bokmål/dark emulated-tap case independently failed its Escape focus-return assertion. These failures must remain in the defect register and cannot be converted into successful keyboard acceptance because geometry collection passed.

The separate keyboard journey reached global commands and the Add Job dialog, then failed when the test incorrectly expected Match selection after ArrowRight. The existing Job tabs use manual activation: arrows move focus and Enter selects. Its later CV checks were not reached in that initial run. The corrected audit-controls.json rerun subsequently passed command/dialog, manual tab activation, CV section selection, persisted keyboard reorder and preview entry/scroll/exit (25.5seconds). Native proof records that separate success without erasing the failed test-assumption evidence. Drawer failures remain genuine and unresolved.

Preservation and remaining verification

Related groups are PRES-E07 (shell/navigation/focus), PRES-J05/J07 (Jobs table/Board), PRES-W01/W08 (workspace sections/documents), PRES-C06/C07/C10/C12 (CV panes, order, focus/history and preview/export), PRES-S01/S03 (reports/Settings), and PRES-A01 (admin controls). This evidence alone does not promote any entire group to PASS.

The zoom cases asserted unchanged Career Profile and CV API state after inspection. No document content, source overrides, revisions, submitted references, provider settings, or production configuration were modified. Rendering-fidelity and full regression results remain separate evidence.

Human screen-reader operation, physical touch/software keyboard, browser text enlargement preferences, complete action activation at400%, and wider browser/device combinations remain outstanding. The owner has reported an available screen-reader operator; actual operator announcements/results are required by the manual acceptance script. Availability is not acceptance.

P5-13 qualification/UI remains deferred and Production-withheld. F04, backup/restore, configuration/schema, rollback, and other release-critical production evidence remain open. This supporting record neither activates AI review nor changes the Production NO-GO decision.