Godot 4.8-dev AccessKit Mobile Smoke - First Indie Worksheet 2026

If you searched godot accesskit android (or iOS) after 4.8-dev7, you do not need another “accessibility is finally solved — ship the mobile build tonight” thread. You need a fill-in worksheet that locks six decisions before Discord invents a studio-wide “pin 4.8-dev for TalkBack” sprint:

1. Lab project only — disposable 4.8-dev copy, not the production SKU
2. Branch honesty — 4.8-dev7 is a dev snapshot under feature freeze; still pre-release
3. Platform pick — Android and/or iOS smoke named; don’t claim both untested
4. Screen-reader path — TalkBack / VoiceOver (or equivalent) actually enabled for the session
5. Honesty limits — mobile AccessKit is not desktop parity; iOS editable text still limited
6. Decision latch — LAB_SMOKE, HOLD, or PAIR — refuse PROD_PIN

This URL is that worksheet. It is not the live Stop shipping production on 4.8-dev after feature freeze (Steam/export refusal). It is not the July 4.8-dev1 snapshot explainer. It is not the 4.6 floatable dock tools listicle. Those own production pins, earlier editor UX, and dock toolkit surface. This URL owns the first indie AccessKit mobile smoke evening on a disposable 4.8-dev project with gates outsiders can footnote.

Why this matters now

On September 29, 2026, Godot published Dev snapshot: Godot 4.8 dev 7: feature freeze for 4.8, plus a last feature round-up. Under Platforms: AccessKit for iOS and Android, the team notes desktop screen-reader support arrived in 4.5 via AccessKit; logistics had kept mobile off that first wave. 4.8-dev7 opens the door: iOS (Ben Humphries, GH-119750) and Android (bruvzg, GH-117785). Feature depth on mobile may not match desktop yet — the post asks for testing and feedback. The iOS implementation still has inherent limitations (e.g. lack of support for editable text fields), with progress tracked on an AccessKit repository issue.

October 2026 is when accessibility-minded indies either (a) run a careful lab smoke and file notes, or (b) paste “AccessKit on mobile” into a Steam changelog and pin 4.8-dev because freeze landed. Without a worksheet, teams skip VoiceOver/TalkBack setup, claim parity they did not measure, or conflate lab curiosity with production support.

Direct answer: Fill Sections A–F this week on a disposable 4.8-dev7 (or newer 4.8-dev) project. Choose LAB_SMOKE, HOLD, or PAIR. Do not treat mobile AccessKit as a production pin — read the production Stop first if Discord is mid-sale.

Who fills this worksheet

Time: 60–120 minutes first lab smoke (device setup dominates); 30 minutes to re-run after UI changes.
Honest limit: Snapshot posts are the authority for what landed; mobile feature parity and editable-text limits may change. Re-read 4.8-dev7 and grab builds from the download archive. Pre-releases are testing-only — backups / VCS required.

Non-repetition

Pair Godot craft with the Godot guide. Community paste: 25 free game development Discord servers. Production pins stay on the Stop — not this smoke.

Official facts you must quote (not invent)

From Dev snapshot: Godot 4.8 dev 7 and the download archive:

1. 4.8-dev7 (29 Sept 2026) declares feature freeze for 4.8 and prepares the beta transition.
2. Desktop AccessKit / screen-reader support arrived in Godot 4.5; mobile was deferred for logistics, not “accessibility doesn’t matter.”
3. 4.8-dev7 adds native AccessKit for iOS and Android.
4. Mobile feature depth may not match desktop yet — testing + feedback requested.
5. iOS AccessKit still has limitations (e.g. editable text fields unsupported as noted in the post).
6. Snapshot builds are pre-release — use backups / VCS; not production pins.
7. Builds: 4.8-dev7 archive (and later 4.8-dev / beta when published).

Pasteable diligence line:

We are evaluating Godot 4.8-dev AccessKit on iOS/Android using a disposable lab project, with screen-reader smoke, honesty about mobile vs desktop parity and iOS text-field limits, and a filed receipt. Production SKUs stay on supported 4.7.x until the production Stop’s diligence passes. No Steam pin from this lab.

Section A — Project + branch lock (fill in)

A-gate: If lab path equals the only production checkout and you have no VCS backup, stop. Duplicate the project or branch first. If Discord wants a store upload tonight, open the production Stop and SIT OUT.

Section B — Platform + device matrix (fill in)

B-gate: Claiming “AccessKit mobile works” after only an emulator without a screen reader enabled is folklore. Name the reader. If you only smoke Android, do not write iOS in the public note (and vice versa).

Beginner device setup (do once per platform)

Android

1. Install lab APK/AAB from your 4.8-dev export (debug is fine).
2. Enable TalkBack (or preferred reader) in system accessibility settings.
3. Confirm spoken feedback on the Android home screen before opening your game.
4. Open the lab game; navigate primary UI with reader gestures.
5. Note focus order, unlabeled buttons, and silent controls.

iOS

1. Install lab build via your usual device provisioning path.
2. Enable VoiceOver.
3. Confirm spoken feedback in Settings / Home before the game.
4. Navigate primary UI; note rotor / swipe behavior.
5. Explicitly test whether editable fields behave (expect limits per Godot’s note).

Section C — UI smoke script (fill in)

C-gate: Record at least three concrete observations (not “felt fine”). Partial success still counts as LAB_SMOKE if honesty is written.

Minimum scenario list

1. Cold launch — first focus announcement.
2. Primary CTA — start / continue / play.
3. Settings row — one toggle or slider if present.
4. Back stack — leave a submenu without getting stuck silent.
5. Fail case — one unlabeled control you will fix later (write it down).
6. iOS text — if iOS, attempt an editable field and document the limit.

Section D — Engine + export honesty (fill in)

D-gate: If export templates and editor disagree, fix that before blaming AccessKit. If you plan a store sentence about “full mobile screen-reader support,” rewrite it to match what Section C actually observed.

Section E — Team PAIR + feedback (fill in)

E-gate: PAIR means a second human or device reproduces — not “I watched a YouTube VoiceOver demo.” Godot explicitly invited testing feedback on mobile AccessKit; filing a clear issue is part of being a good lab citizen.

Section F — Decision + receipt (fill in)

Decision meanings

Gates A1–A8 (pass / fail)

Fail closed on A1–A4 before you write “AccessKit mobile supported” anywhere public.

Beginner path — 90 minutes

1. Read the AccessKit mobile paragraph in 4.8-dev7 aloud.
2. Read the production Stop sit-out if anyone mentions Steam.
3. Duplicate project → install 4.8-dev7 from the archive.
4. Fill Sections A–B.
5. Export one platform; enable the screen reader.
6. Run minimum scenarios (Section C).
7. Latch LAB_SMOKE or HOLD; file receipt (Section F).
8. Open production project once to prove it still opens on 4.7.x.

Common beginner mistakes:

• Enabling AccessKit curiosity on the only production checkout.
• Claiming iOS + Android after one Android emulator run.
• Skipping TalkBack/VoiceOver and “eyeballing” focus rectangles.
• Promising editable-text a11y on iOS despite the documented limit.
• Equating feature freeze with production support.
• Filing zero notes and saying “it works.”
• Shipping a Steam build “to get real a11y data.”

Developer path — a11y engineering depth

Labeling checklist (fix after smoke)

Exact Godot node properties evolve — verify against current 4.8-dev docs/class reference in your build. This worksheet owns the smoke ritual, not a frozen API encyclopedia.

Desktop vs mobile honesty table

Bug-report hygiene (Godot invited feedback)

1. Search GitHub issues for AccessKit / Android / iOS keywords first.
2. Include Godot version string (4.8-dev7 + commit if known), device, OS, reader.
3. Steps: enable reader → open scene → expected vs actual speech.
4. Separate engine bugs from your UI labeling bugs in the ticket.
5. Link the receipt id in your internal tracker.

What not to automate yet

• CI that asserts “a11y pass” from a headless export with no reader.
• Store copy generators that insert “full screen-reader support” from a green lab APK.
• Auto-promoting LAB_SMOKE artifacts to the production depot.
• Single pipeline that always tracks latest 4.8-dev for release.

Failure modes this worksheet catches

Anti-patterns (reject in review)

• “AccessKit on mobile — ship 4.8-dev.”
• “Freeze means a11y is production-certified.”
• “Emulator without TalkBack counts.”
• “Desktop AccessKit already proved mobile.”
• “iOS text fields will just work.”
• “This worksheet replaces the production Stop.”
• “July dev1 article already covered mobile AccessKit.” (It didn’t.)
• “We’ll gather feedback from paying players on the live build.”

Worked decisions

Studio A — Android phone, no iOS device

Do: LAB_SMOKE Android only; say so in Discord.
Don’t: Claim iOS VoiceOver.

Studio B — wants a11y for Winter Sale page

Do: Keep production on 4.7.x; lab 4.8-dev; write honest “exploring” language.
Don’t: PROD_PIN for marketing screenshots.

Studio C — iOS text-entry heavy game

Do: HOLD or LAB_SMOKE with explicit editable-field fail notes; track upstream.
Don’t: Promise form-heavy VoiceOver flows yet.

Studio D — two QA devices

Do: PAIR; compare focus order notes; file one engine issue if shared.
Don’t: Duplicate vague “broken” reports without version strings.

Studio E — also mid Unity GLES matrix week

Do: Separate tracks — this worksheet for Godot a11y lab; GLES matrix stays Unity.
Don’t: One megathread titled “mobile everything.”

CapEx four-liner

1. Asset at risk: Store trust, a11y reputation, cert narratives, refund optics.
2. Change proposed: Pin production to 4.8-dev “for AccessKit mobile.”
3. Cost if wrong: Pre-release regressions + overclaimed a11y + partner diligence fail.
4. Decision owner: Tech/a11y lead; default = LAB_SMOKE on disposable 4.8-dev + 4.7.x production.

Two-week calendar

Discord shortlist (paste)

Godot 4.8-dev AccessKit mobile — first lab smoke
1) Disposable 4.8-dev project only (production stays 4.7.x)
2) Name platform: Android TalkBack and/or iOS VoiceOver
3) Export templates match editor
4) ≥3 UI observations with reader on
5) Honesty: mobile ≠ desktop parity; iOS editable text limited
6) Decision: LAB_SMOKE / HOLD / PAIR — refuse PROD_PIN
Receipt: godot_48dev_accesskit_mobile_smoke_receipt_v1.json
Sources: 4.8-dev7 snapshot · download archive
≠ production 4.8-dev Stop · ≠ July dev1 explainer · ≠ 4.6 dock tools

Receipt — godot_48dev_accesskit_mobile_smoke_receipt_v1.json

{
  "receipt_type": "godot_48dev_accesskit_mobile_smoke_receipt_v1",
  "project_lab": "REPLACE_48dev_lab",
  "filled_at": "2026-10-14",
  "godot_lab_version": "4.8-dev7",
  "production_godot_version": "4.7.x",
  "platforms_smoked": ["android"],
  "screen_readers": ["TalkBack"],
  "ui_observations_count": 0,
  "mobile_desktop_parity_claimed": false,
  "ios_editable_text_limit_acknowledged": false,
  "export_templates_match_editor": false,
  "decision": "LAB_SMOKE",
  "prod_pin_refused": true,
  "gates_a1_a8_pass": false,
  "owner": "",
  "notes": ""
}

Latch the same hour you finish reader smoke (or HOLD).

Key takeaways

1. 4.8-dev7 adds AccessKit for iOS and Android.
2. This worksheet owns the lab smoke, not a Steam pin.
3. Keep production on supported 4.7.x.
4. Enable a real screen reader — TalkBack / VoiceOver.
5. Pass A1–A8 before public a11y claims.
6. Mobile may not match desktop AccessKit depth yet.
7. iOS editable text remains limited per Godot’s note.
8. Default decision: LAB_SMOKE or HOLD.
9. Refuse PROD_PIN — see the sibling Stop.
10. File bugs with version + device + reader details.
11. File the receipt JSON.
12. Primary keyword: godot accesskit android.

FAQ

Does Godot 4.8-dev support AccessKit on Android and iOS?

4.8-dev7 announces native AccessKit support for both platforms, with the caveat that mobile feature depth may lag desktop and iOS still has limitations (e.g. editable text). See the snapshot post.

Should I ship my Steam build on 4.8-dev to get mobile AccessKit?

No. Use a lab project. Production pins on 4.8-dev are refused in Stop Shipping Production Godot Games on 4.8-dev After Feature Freeze.

How do I test AccessKit on Android?

Export a lab build from 4.8-dev, enable TalkBack, verify spoken OS UI, then navigate your game’s primary screens and record observations in Section C.

Is mobile AccessKit as complete as desktop?

Godot states mobile may not offer the same feature level as desktop yet and asks for testing feedback. Measure; don’t assume parity.

What about iOS text fields?

The 4.8-dev7 post notes inherent iOS limitations such as lack of support for editable text fields. Document fails honestly; track upstream progress.

What primary keyword does this page target?

godot accesskit android — first indie mobile AccessKit lab smoke worksheet (iOS covered in-body).

Related reading

• Godot 4.8 AccessKit - One Mobile Platform Smoke (2026) — one platform, one control
• Stop Shipping Production Godot Games on 4.8-dev After Feature Freeze - 2026 — production pin refusal
• Stop Shipping Godot 4.8 C Sharp Projects Without .NET 10 - 2026 — SDK floor sibling
• Godot 4.8 .NET 10 First Indie C Sharp Migrate Worksheet 2026 — C# migrate lab sibling
• Godot 4.8 Dev Snapshot - What Changed for Indie Devs July 2026 — earlier snapshot commentary
• 12 Free Godot 4.6 Floatable Dock Editor Tools After Dock Rework - 2026
• Stop Upgrading Unity Mid Steam Next Fest Week - Pin 6.3 LTS 2026
• Stop Quoting RimWorld Waylith 4x Gains as Your Unity Studio Exit Plan - 2026
• Steam Winter Sale 2026 Prep Worksheet - Lock Before Dec 17
• Godot Guide
• Unity Guide
• 25 Free Game Development Discord Servers

Primary sources: Dev snapshot: Godot 4.8 dev 7 · Godot download archive · 4.8-dev7 downloads.

Conclusion

AccessKit on iOS and Android in 4.8-dev7 is a real accessibility milestone — and a lab ritual, not a production pin. Duplicate the project. Match export templates. Turn the screen reader on. Write three honest observations. Admit parity gaps and iOS text limits. Latch LAB_SMOKE. Keep Steam on supported 4.7.x.

Print Sections A–F. Paste Discord. Treat mobile a11y as measured smoke — not freeze-week marketing.