Deep dive
Accessibility as design
AX5 as design baseline, not accommodation. Who Lanai is for, and why legibility is the aesthetic rather than the compliance.
Most apps that get praised for accessibility start the same way. There’s a design — built for a sighted 25-year-old with a high-density display — and then there’s the accessibility pass. Dynamic Type is added at the end. A VoiceOver review is run. A contrast audit catches the worst offenses. The release notes mention the improvements. The work is real. It is also additive: the design exists, and then accessibility is bolted onto it.
Lanai inverts that order.
AX5 first, default size as the derivative
The biggest type size iOS offers — AX5, the one designed for readers whose eyes are getting older — is not the accommodation case in Lanai. It is the design baseline. We compose layouts at AX5 first and verify them at default size, not the other way around. The screenshots at AX5 are as carefully arranged as the screenshots at default. The High Contrast theme is as crafted as the Day theme. The accessibility settings aren’t a menu of allowances; they are the brand.
That sentence sounds like a slogan. It is meant to be a constraint. Starting from AX5 as the primary visual target means every other decision sits downstream of it. A typography ramp that has to be beautiful at AX5 stops being beautiful at any smaller size — because the ramp is real, the type is calibrated, and the eye gets what it expects at every Dynamic Type step from .xSmall to .accessibility5. A spacing system that has to hold at AX5 stops collapsing at default. A touch-target rule that has to clear 56 points at AX3+ stops being cramped at 44 at default. Each layer of the design is built to scale.
If a design choice makes the app prettier at default size but breaks at AX3, the choice is wrong. If a design choice scales gracefully to AX5 and still feels deliberate, it’s right. This is the only test.
Two audiences on the same porch
Lanai’s audience isn’t “accessibility users.” It is two groups who happen to share an aesthetic.
Readers whose eyes are getting older. The 45-year-old who’s started reaching for reading glasses. The 60-year-old who’s noticed they’re zooming web pages more often than they used to. The 75-year-old widow whose son set up Bluesky on her iPad so she could keep up with old friends, and who will quietly stop opening the app if the type is too small or the buttons too cramped. The adult child who is themselves the support tech for an aging parent — the person who wants to recommend an app and know it will work.
Design-and-aesthetics-conscious users. People whose attention has been mistreated by software and whose taste rewards care. They’ve bought Things 3 and Reeder and iA Writer and Tot. They notice typography. They notice motion. They feel the difference between an app that respects their attention and one that doesn’t.
The two groups overlap more than they don’t. The 45-year-old who reaches for reading glasses is often the same person who has bought every editorial-typography app available. The 75-year-old reader is usually the parent of a designer who introduces them to it. The audience choice is what makes the design language coherent. Aesthetic care and accessibility care are the same care; they only look different when you’re optimizing for the demographic that doesn’t need either.
What this looks like, concretely
Body text starts at 17pt minimum and only goes up. Most feed apps default to 13–15pt for body; this is where readability starts to break for readers over forty, and the only way to fix it later is to make the app’s “accessibility setting” the actual design.
Touch targets are 44pt minimum at default size and 56pt at AX3 and above. Avatar images are intentionally smaller than text height, not larger — because the post is the point, not the face. The visual hierarchy says read this; the author is a small label. That is the opposite of what most apps choose.
Default contrast lands above APCA Lc≥75 in every theme. We verify both APCA — the candidate WCAG 3 — and WCAG 2 AA, because the latter is the legal floor and the former is the actual ceiling. The High Contrast theme targets Lc≥105, the level at which text becomes legible for users in bright sunlight or with significant low-vision needs.
Five themes coexist at equal polish. The brand promise is that all five — Day, Dusk, Miami, Late Night, High Contrast — feel equally crafted. High Contrast is not the accessibility variant of one of the others. It is a first-class design that is also the most legible. The kind of theme a sighted designer would choose because it reads cleanly on a screen in afternoon sun, even though it was built to be accessible.
Hyperlegible mode
Bundle the variable font, swap it for the body and display typefaces when the toggle is on, and watch what happens. A great many users turn on Hyperlegible mode for reasons that have nothing to do with vision and everything to do with comfort. The font — Atkinson Hyperlegible Next, from the Braille Institute — was designed to disambiguate characters that often look alike (lowercase l from the digit 1, the letter O from the digit 0, the letter G from C). The result is faster, less effortful reading, in or out of an accessibility context.
That this is a setting and not a permanent state is the right architecture. That the setting has equal aesthetic dignity with the default — Atkinson is a beautiful typeface; the design system grants it the same care as New York and SF Pro — is what makes the toggle inviting rather than alienating.
VoiceOver as a first-class user
A Bluesky post is one unit of meaning, not twelve. A VoiceOver user shouldn’t have to navigate through avatar → name → handle → timestamp → body → like → repost → reply → share to get through one post. They should be able to read the post and then choose an action from a menu.
Lanai treats every post as a single VoiceOver element with custom actions. The label is computed: “Alice, posted two hours ago: …” and then the body. The custom actions are Reply, Repost, Like, Bookmark, Open thread, Open profile, Share as image. The Bluesky reference app does the twelve-stop version. We don’t.
Four custom rotors ship in v1.0: Posts (the default reading rotor), Posts with media, Mentions of you, and Links (for keyboard-first link navigation). Apple’s WWDC21 session 10119 is the canonical reference; the discipline is to remember that rotors are how a VoiceOver user reads, not how they discover features.
Motion that yields
Every animation in Lanai has a reduced-motion path built in from the start, not retrofitted. Springs become crossfades; durations stay the same; haptics still fire. The visual rhythm of the app is preserved even when the visual motion is stripped. This matters because a user with vestibular sensitivity should not have a different experience of Lanai. They should have the same experience with less motion.
Why this isn’t compliance plus
Calling Lanai “accessibility-first” is technically accurate and rhetorically lossy. Most accessibility-first apps still treat accessibility as a separate axis from beauty. The pitch is we are beautiful, and we are also accessible. The two are tracked as different goods.
Lanai’s claim is stronger than that. Legibility is the aesthetic. Big type, generous line height, honest hierarchy, high contrast — these are the design language. They are how a beautifully designed reading app looks before they are how it accommodates anyone. The accessibility settings aren’t an accommodation menu; they are the brand.
That is also the test. If a Lanai screenshot at AX5 looks composed and a screenshot at default size looks composed, the design is on-thesis. If one looks composed and the other looks improvised, the design is wrong. Both screenshots must be on the wall of the gallery.
This is the whole reason we are building Lanai instead of using one of the existing Bluesky clients. The existing apps are fine, mostly. They were not designed with this audience in mind. We are.