♿ Accessibility review: portal website + in-game UI (feedback only, no code needed)

[marceld23]

What this is

Looking for an accessibility review of the player-facing surfaces — the public portal website and the in-game UI. No code change required — a thoughtful comment on this issue is the whole contribution. 🙏

Context that raises the bar: the game is aimed at kids and families, is fully bilingual (DE/EN), and runs on desktop, browser (WebGL), gamepad and touch.

Surfaces to look at

• Portal website (account signup, world hosting, bug reports — link on the repo README)
• In-game: main menu & settings, HUD (hotbar, health/hunger, hints), crafting/ship menus, the VEGA dialog system

Questions we'd love answers to

• Contrast & color — do text and HUD elements meet WCAG-ish contrast on bright and dark worlds? Are any meanings conveyed by color alone (ore colors, map markers) that colorblind players would lose?
• Text size & readability — the HUD has a size stepper; are the menus readable at distance / for young readers? Font choice OK for dyslexic readers?
• Keyboard & focus — can the portal be fully driven by keyboard, with visible focus order? Any traps?
• Screen reader basics — portal: labels, alt texts, form errors announced?
• Audio — anything critical conveyed by sound only (alarms, damage) without a visual cue?
• Motor accessibility — hold-vs-toggle inputs, timing pressure, controller/touch reachability of all functions
• Kid-specific — reading level of UI texts, error messages that a 7-year-old can act on

Screenshots or a short capture of any flow available on request — just ask here.

[SpaleRuby]

I scoped this pass to the public English portal at https://play.blocksbeyondthestars.de/?lang=en and the corresponding open source at commit d3383f4 (checked 2026-07-29 23:37 UTC). I did not assess the in-game UI, audio, or world contrast, so these findings are deliberately limited to portal markup and behavior that is directly evidenced in the source.

A few things are already solid: the page has lang="en", one H1, a named language nav, HTTPS/200, and the terms checkbox is wrapped by a real label.

1. Account and recovery fields have no programmatic labels

The create/sign-in/recovery inputs use placeholders only: su-name, su-pass, li-name, li-pass, rc-name, rc-code, rc-pass. There is no associated <label>, aria-label, or aria-labelledby.

Why it matters: placeholders disappear as soon as a child types, and repeated fields such as “Account name” become hard to distinguish in a screen-reader field list.

Suggested fix: add short visible labels with for/id; keep the longer placeholder as an example. Adding autocomplete="username", new-password, and current-password would also reduce memory/typing friction.

2. Validation and result messages are not announced

Every signup/login/recovery result is written via say() into <div id="msg">, but that div has no live-region semantics (message container, say()). For example, activating Create account without accepting the rules changes text at the top but does not move focus or notify a screen reader.

Suggested fix: make the persistent line role="status" aria-live="polite" aria-atomic="true"; for blocking validation, either use an alert region or focus a concise error summary linked to the invalid field.

3. Enter-key submission has no native path

The two account panels are div blocks with onclick buttons, not <form> elements, and the page defines no Enter-key listener. This means the browser cannot provide native “press Enter in the password field to submit” behavior.

Suggested fix: wrap each flow in its own <form> and handle submit with preventDefault() + the existing async function. Use type="submit" for the primary action and type="button" for secondary actions.

4. The password-reset reveal is not exposed as a disclosure

“Forgot your password?” toggles display:block, but the trigger has no aria-expanded/aria-controls and focus remains on the trigger (source).

Suggested fix: use a button with aria-controls="li-recover", update aria-expanded, remove hidden, then focus the first recovery field. That gives keyboard and screen-reader users a clear state change.

I also ran a non-browser launch baseline: the main marketing page passed all 18 objective checks; the hosted-world portal returned 200 with a valid language, viewport and H1. The four items above are the highest-value semantic gaps I could verify without pretending to have tested the game itself. Happy to re-check the public markup after a change.

[marceld23]

@SpaleRuby this is exactly the review I was hoping for and honestly better than I expected. Thank you. 🙏

You scoped it honestly, you said what you did not test instead of guessing, and every single finding was verifiable in the source. I checked all four against main before touching anything — all four confirmed. All four are now fixed, merged in #621, and live on https://play.blocksbeyondthestars.de.

What shipped

1. Labels — every field now has a visible <label for>, and I kept the longer placeholder wherever it carries an example or a constraint, exactly as you suggested. You also found an inconsistency I hadn't noticed: w-pass on the logged-in page already had autocomplete='new-password' while none of the account fields did. So it wasn't a design decision, just a gap. Fixed, with current-password on sign-in and new-password on create/recover, plus autocapitalize/spellcheck on the name and code fields (that one is a real win for kids on phones).
2. Live region — role='status' aria-live='polite' aria-atomic='true' on the message line, on both pages. Blocking validation additionally moves focus to the offending field, since you're right that changing text at the top of the page tells a screen-reader user nothing.
3. Real forms — Enter now submits the flow the field belongs to.
4. Disclosure — "Forgot your password?" is a real <button> with aria-expanded/aria-controls that moves focus into the panel it reveals. Sign-out was the same anti-pattern (<a href='#'> doing all its work in script), so it got the same treatment. Bonus: the rescue-code panel now focuses its heading, because those codes are shown exactly once, ever, and that's the worst possible moment to miss a page change.

One trap worth knowing about, in case it helps elsewhere

Your point 3 was the only one that wasn't a small edit. li-recover and li-terms sit inside the sign-in card, and HTML forbids nested forms — one form around the card would have put three submit buttons in it, so Enter in the rescue-code field would have triggered the login. They're now sibling forms of li-form, and there's a test pinning that by index so a future edit can't quietly re-nest them.

I also skipped native required: browsers localize the built-in validation message by browser locale, not by the page's lang, which would have dropped German messages into the English portal.

Two things you couldn't have reached

• The portal had no :focus-visible styling at all — that was one of my own questions in this issue and the honest answer was "we never did it". It's a 3 px cyan ring now, roughly 11:1 against the dark background.
• The logged-in page (player name, new world, feedback, report, per-world password, ban reason) had the same placeholder-only problem. You had no account, so you couldn't see it — your finding generalized cleanly.

And on contrast: I measured it rather than assume, and your silence was correct. Hint text lands around 8.5:1, the cyan buttons around 11:1, the orange status line around 8.5:1. Nothing to do there.

The whole thing is pinned by 11 new tests, because this markup is hand-written inside C# strings where nothing else would catch a lost label.

Your name is in the game now

You're in the contributor list in the README and in the in-game Credits screen (German and English). That's the same list my son reads. 🚀

Keeping this issue open — and taking you up on your offer

You offered to re-check the public markup after a change: yes please, it's live now.

I'm leaving this issue open rather than closing it, because the portal was only half of what I asked about. Still completely unanswered, and it's the half nobody can check with curl:

• In-game UI — contrast on bright vs dark worlds, menu readability for young readers, font choice for dyslexic readers
• Colour-only meaning — ore colours and map markers, where a colourblind player loses the distinction
• Audio — anything critical conveyed by sound alone (damage, alarms) with no visual cue
• Motor — hold-vs-toggle inputs, timing pressure, whether every function is reachable on controller and touch
• Kid-specific — reading level, and whether a 7-year-old can act on our error messages

I know that part is much harder to review from outside, and I should say plainly: Unity's uGUI has essentially no screen-reader story, so I'm not expecting miracles there — contrast, colour-only meaning, audio cues and hold-vs-toggle are the parts where an outside eye would help most.

If you or anyone else wants to look: the offer of screenshots or a short capture of any flow still stands, just say which flow. There's also a browser-playable build if you'd rather poke at it directly than install anything.

Thanks again — this was a genuinely useful contribution.

[SpaleRuby]

Thank you — this is an unusually thoughtful implementation and write-up.

I completed the promised production re-check at 2026-07-30 10:23 UTC. Both the
English and German portal returned 200 with the correct document language. On
each page I verified:

• all seven account/recovery fields now have matching visible label[for]
  elements;
• username/current-password/new-password autocomplete roles are present;
• the persistent message line has status + polite/atomic live-region
  semantics;
• the recovery trigger exposes its controlled panel;
• the five flows are real, non-nested forms;
• the focus-visible rule is present; and
• the old script-only href="#" pattern is absent.

So the public markup portion passes my re-check. I have not claimed a real
screen-reader announcement or physical focus-movement test here; those remain
supported by the source and your regression tests, not by an assistive-tech
session I did not run.

For the larger in-game half, I can offer a separate paid, bounded
capture/source-based accessibility audit for $75 fixed if that would help:
fully funded escrow, or $40 upfront + $35 on delivery in XMR or native USDC on
Base. Delivery would be within four working hours after the complete evidence
pack is received.

Useful inputs would be:

• browser-build link plus 1080p captures of main menu/settings;
• HUD on one bright and one dark world;
• damage/alarm and another critical-audio sequence;
• crafting/ship/VEGA flows;
• controller/touch controls matrix; and
• the DE/EN UI text source or locale files.

The deliverable would be a traceable pass/fail/NOT-TESTED matrix and 5–8
distinct findings, each with an exact timestamp or source reference, severity,
kid/family impact, smallest practical fix, and retest step, plus one re-check.
If fewer than five real problems are substantiated, I will not pad the report;
the remaining value will be the evidenced pass/limitations matrix. Physical
controller ergonomics and screen-reader behavior would stay NOT TESTED unless
the supplied evidence actually supports them.

No pressure if the project has no audit budget — the promised portal re-check
above is complete either way.

AI disclosure: I use AI assistance for source inspection and report
structure, but I manually verify every observation and clearly separate direct
evidence from limitations.

[marceld23]

Thanks for the re-check — and for being precise again about what you did and did not verify. "Supported by the source and your regression tests, not by an assistive-tech session I did not run" is exactly the kind of honesty that made the first review worth acting on.

On the paid audit: I have to say no, and I want to explain why rather than just decline.

BlocksBeyondTheStars is a family project with no commercial side at all. I build it with and for my son — there's no company behind it, no revenue, no ads, no store, no budget line for anything. It costs me money every month (the VPS the portal and the hosted worlds run on, the domain, the asset tooling) and it earns exactly nothing, by design. So this isn't "we'd rather not spend $75 here" — there is no audit budget to spend, and if I started paying for contributions I couldn't do it fairly for the other people who've helped.

What the project runs on instead is exactly what you already did: someone looking at one specific thing carefully and writing down what they found. That's genuinely the whole economy here, and it's why your first comment turned into four merged fixes plus a :focus-visible ring I'd never have gotten around to.

So the in-game half stays an open, unpaid, help-wanted invitation — and the offer of inputs stands for you or anyone else who feels like poking at it, no commitment expected:

• browser-playable build, no install needed
• 1080p captures of any flow you name — main menu/settings, HUD on a bright and a dark world, crafting/ship/VEGA
• the DE/EN locale files are in the repo (data/locales/en.json, data/locales/de.json) — the kid-reading-level question is answerable from those alone, without touching the game
• the controller/touch mapping, if that's the angle that interests you

If any of that is useful to you as a portfolio piece, or if you just want to answer one of the five questions rather than all of them, that's more than welcome — a single finding on colour-only meaning or audio-without-visual-cue would still be a real improvement for the kids who play this. And whatever comes in gets the same treatment: verified, fixed where it's fixable, and credited in the README and the in-game Credits screen my son reads.

Either way, thank you. The portal is measurably better than it was two days ago because you spent an evening on it, and you've already been paid in the only currency I have — a name in the game and a fix that stuck.

[SpaleRuby]

Completely understood — thank you for explaining it so clearly. I won't press the paid scope again. I'm glad the portal review produced concrete fixes, and I appreciate the careful verification and credit. Wishing you and your son a great build.