QA: English detail scrolling, mobile preview overlap, and accessibility/localization defects

[Microck]

Both production portfolios have reproducible responsive and accessibility defects. The most disruptive regression is on the English deployment: wheel scrolling moves the catalogue behind an open project instead of scrolling the project panel, hiding content and actions on short viewports.

Tested on 2026-09-07 using Computer Use in desktop Chrome and the Codex in-app Chromium browser. This issue consolidates findings for micr-dev/projects and micr-dev/proyectos; the English-only regression is identified separately.

Coverage

• Opened every catalogue entry through the rendered UI: 105 English + 106 Spanish = 211 project entries.
• Every entry opened with a heading and description. No failed images were found in the rendered image elements during the catalogue passes.
• All 211 observed project URLs returned HTTP 200 on direct requests.
• Checked all 114 distinct outbound destinations. 109 returned HTTP 200; four npm pages returned HTTP 403 and the BDSS Vercel preview returned HTTP 429 to the HTTP client. All five challenged destinations subsequently loaded their expected content in Chrome. These are not reported as broken links.
• Inspected screenshots and measured responsive layouts. The homepage matrix covered both locales at 320x568, 375x667, 390x844, 430x932, 768x1024, 1024x768, 1366x768, 1920x1080, and 2560x1440. English homepage also checked at 844x390.
• The Akron detail panel was measured in both locales at all ten sizes above, including 844x390. Neither document nor detail panel exceeded viewport width.
• Checked long-title wrapping at 320px, keyboard navigation, Escape, backdrop dismissal, browser Back/Forward, sampled direct-load/reload rendering, unknown routes, locale metadata, and captured console warnings/errors.
• No console warnings/errors were captured during the complete catalogue passes.

1. [P1] English project detail panel does not respond to wheel scrolling

Affected: English deployment. Reproduced at 390x844 and 1366x768; also observed at 320x568.

Steps:

1. Open the English portfolio's /akron route and let the opening animation finish.
2. With a 390x844 viewport, scroll downward with the pointer over the project description.
3. Observe that the description and buttons remain in the same position while the background catalogue scrolls.

Evidence from a settled 390x844 run:

• Detail panel: clientHeight=844, scrollHeight=973, scrollTop=0 before and after scrolling.
• Document scroll moved from 0 to approximately 4209.
• At 1366x768, the panel had scrollHeight=1042, clientHeight=768, and still stayed at scrollTop=0 after scrolling.
• Keyboard Tab can scroll the panel to its action links, providing a workaround.
• The Spanish panel successfully scrolls. At 1024x768 its scrollTop reached approximately 314 for a 1082-pixel panel.

Expected: wheel input over the open panel scrolls that panel, with background scrolling suppressed.

Suggested fix: review the English smooth-scroll integration and nested-scroll handling against the working Spanish behavior. Add a regression test that checks panel scroll position and background stability after wheel input.

2. [P2] Fixed preview image covers the homepage project list on mobile/tablet

Affected: both deployments. Visually reproduced at 320px and 390px widths, and on the Spanish site at 768x1024.

Steps:

1. Open either homepage at 390x844.
2. Scroll down through the project catalogue.
3. Observe the fixed preview image covering several project names as the list passes behind it.

At 390px, the preview occupies approximately x=20..371 and y=81..277, overlapping the single-column catalogue. At 768px, the preview remains centered over the list and covers names/category content.

Expected: users can read and target the project list without another element covering it.

Suggested fix: use a separate non-overlapping preview region at narrow breakpoints, make the image flow with content, or hide the preview while scrolling the mobile catalogue.

3. [P1] Project catalogue cannot be navigated with the keyboard

Affected: both deployments.

Steps:

1. Load a homepage.
2. Press Tab repeatedly, then try Enter to open a project.
3. No project entry receives keyboard focus.

Rendered entries are clickable li elements with cursor-pointer, but no anchor, button, keyboard role, or focusable tabindex. The Spanish homepage had zero elements matching a, button, input, [tabindex="0"]. The accessibility tree exposes project entries as list items/text, not actionable links.

Expected: each project can be focused and opened using the keyboard, with a visible focus indication.

Suggested fix: render project navigation as real links to the already-working project routes. Preserve ordinary link behavior, including opening in a new tab.

4. [P2] Detail overlays lack accessible dismissal and dialog semantics

Affected: both deployments.

Steps:

1. Open any project, such as /akron.
2. Try to find a Close/Back control or press Escape.
3. No control exists and Escape leaves the panel and URL unchanged.

Backdrop clicking closes the panel, and browser Back works, but these are the only discovered dismissal mechanisms. The detail UI has no button, role="dialog", or aria-modal="true". On English open, focus remained on BODY.

Expected: provide an explicit, keyboard-accessible Close/Back control. If the interface remains modal, use dialog semantics, meaningful initial focus, Escape dismissal, and focus restoration.

5. [P2] 43 entries label the source repository as a live preview

Affected: 21 English entries and 22 Spanish entries.

Steps:

1. Open /anonq, /calendar-peek-extension, or /gitquarry.
2. Compare the two action links.
3. "Live Preview"/"Vista previa" and the source-code button point to exactly the same GitHub repository.

Affected in both locales:
anonQ, calendar-peek-extension, dialogue-textbox, gitquarry, glob, kagi-cli, omp-kagi-cli, micr/ai, micr/blog, micr/micr.dev, micr/thinko, micr/tokens, mullgate, ollama-quota-bench, opencode-studio, sincronizado, squircle, tailstick, tuireel, tuneport, kagi-mcp.

Spanish additionally: micr/proyectos.

Expected: a live-preview button opens a usable preview. If none exists, omit the duplicate action or label the destination accurately. Package/download links should likewise have accurate labels rather than implying a running demo.

6. [P3] Spanish Boilify heading and catalogue label are misspelled

Affected: Spanish /bolify.

The catalogue and H1 display "bolify", while the description says "Boilify" and the source URL points to the boilify repository. English consistently uses "boilify".

Expected: use the canonical project name consistently. Decide explicitly whether the public slug should change.

Other naming differences observed, but not asserted to be bugs without product intent: bdss-website vs bdss-club-website, and Celeste-SkinMod vs Celeste-QuartzSkin.

7. [P3] Spanish 404 page remains in English

Steps:

1. Visit an unknown path on the Spanish deployment, e.g. /qa-nonexistent-project-20260907.
2. The page displays "This page could not be found." and the title is "404: This page could not be found.", although the document language is es.

Expected: localize the error message and title. An accessible link back to the portfolio would also improve recovery.

Acceptance checks

• English wheel input scrolls the open detail panel at phone and short-laptop sizes without scrolling the catalogue underneath.
• Preview images do not obscure catalogue entries at 320px, 390px, and 768px.
• All project entries can be focused and opened using the keyboard.
• Detail UI has an accessible dismissal control and correct focus/dismissal behavior.
• Preview buttons point to actual previews or are labeled/removed appropriately.
• Spanish Boilify naming is consistent.
• Spanish 404 content and title are localized.

Limits

This is a production browser/UI QA pass, not a source-code or security audit. Viewport emulation does not establish physical-device touch behavior, mobile Safari, Firefox, screen-reader speech output, reduced-motion behavior, or network-throttled performance. Every project was exercised at desktop size; representative shared layouts were checked across resolutions, not every project at every size. Outbound testing checks destination availability, not the complete functionality of the linked products. Initial animation/transient observations were rechecked before inclusion.