Writing Mode, Logical Properties, and the Accessibility You're Missing

For a developer building an English-language site, writing-mode: vertical-rl looks like a design flourish — something you reach for when a sidebar heading needs a little visual interest. For a developer building a site that serves Japanese, Chinese, or Korean speakers, the same property is load-bearing infrastructure. Same CSS. Radically different stakes.

This gap — between treating writing modes as aesthetic choices versus accessibility requirements — sits at the center of a real problem in how the web gets built for multilingual communities.

What writing-mode Actually Controls

The CSS-Tricks Almanac entry on writing-mode (opens in new window) describes five values: horizontal-tb (the default), vertical-rl, vertical-lr, sideways-rl, and sideways-lr. Each combines a text orientation with a block progression direction. That's the surface explanation.

The deeper story is what writing-mode actually does to the CSS layout model. When you change writing mode, you don't just rotate text. You redefine which axis is inline and which is block. In horizontal-tb, inline runs left-to-right and block runs top-to-bottom. Flip to vertical-rl, and those axes swap. Inline now runs vertically. Block runs horizontally.

This matters enormously for Flexbox, Grid, and logical properties. A flex-direction: row container lays items along the inline axis — which means in a vertical writing mode, that row is now vertical. Grid respects writing mode when placing and sizing items. Alignment properties like align-items and justify-items follow the same logic.

The CSS Writing Modes Level 4 specification (opens in new window) isn't a niche extension. It's foundational to how modern CSS understands layout direction.

Logical Properties Are the Correct Way to Write CSS

Once you understand writing modes, logical properties stop feeling like optional syntax sugar and start feeling like the correct way to write CSS.

Properties like inline-size and block-size describe dimensions along the logical axes, not physical screen directions. In horizontal-tb, inline-size maps to width. In vertical-rl, it maps to height. The same rule works correctly in both contexts without modification.

The same applies to margin-inline-start, padding-block-end, and the full family of flow-relative properties. They describe relationships — start, end, before, after — rather than fixed physical sides. For a stylesheet that needs to support both left-to-right and right-to-left scripts, or both horizontal and vertical writing systems, logical properties aren't just convenient. They're the only approach that scales.

The accessibility argument here is direct: when developers hard-code physical properties (margin-left, padding-top, width) without considering writing mode, they create layouts that break or become unusable when writing direction changes. Text overlaps. Containers don't resize. Spacing collapses. The result is an experience that works for the default English horizontal reader and fails everyone else.

Who Gets Left Out

Chinese, Japanese, and Korean are the most commonly cited examples, and they're significant — these are among the most widely spoken languages globally. Traditional Chinese and Japanese publishing conventions use vertical text extensively. A web experience that can't render vertical text correctly, or that renders it with broken spacing and misaligned containers, isn't just aesthetically wrong. It's communicatively degraded.

But the scope extends further. Arabic and Hebrew require right-to-left horizontal text. Mongolian uses a vertical script that flows left-to-right. These aren't edge cases. They represent hundreds of millions of readers whose native reading experience is not horizontal-tb.

When government services, healthcare information, financial tools, or emergency resources are built without writing mode support, the people most likely to need those services in their native language — often recent immigrants, elderly community members, or people with lower English proficiency — are the ones who encounter broken layouts and inaccessible content. The ADA's Title III requirements (opens in new window) don't explicitly enumerate CSS properties, but the principle of equal access to services doesn't stop at the edge of a stylesheet.

The Developer Knowledge Gap

The CSS-Tricks almanac frames writing-mode as primarily useful for aesthetics in English contexts. That framing reflects how most front-end education approaches the property — as a visual trick rather than an internationalization requirement.

This is a capacity problem as much as a knowledge problem. Most development teams working on accessibility focus on WCAG 2.1 success criteria: color contrast, keyboard navigation, ARIA labels, focus management. These are real and important. But WCAG's Success Criterion 1.3.4 (Orientation) (opens in new window) and the broader principle of adaptable content point toward something writing mode directly affects: content should not be locked to a single presentation mode.

Our research on testing methodology gaps found that automated tools catch at most 37% of accessibility barriers. Writing mode failures — broken layouts in vertical text contexts, logical property errors that only manifest in RTL or vertical writing systems — are almost certainly in the 63% that automated tools miss entirely. You can't catch a layout that collapses in Japanese vertical mode if you're only testing the English horizontal version.

The compliance framework complexity that organizations already face makes this worse. Teams stretched thin across WCAG, Section 508, and state-level requirements rarely have bandwidth to test internationalization scenarios. Writing mode support gets deferred indefinitely.

What Practical Implementation Looks Like

For development teams, the shift isn't dramatic — but it requires intentionality.

Adopt logical properties as a default. Replace width with inline-size, height with block-size, margin-left with margin-inline-start. This isn't just future-proofing; it's writing CSS that correctly adapts to the writing mode of the content it displays. The MDN documentation on logical properties (opens in new window) provides a comprehensive reference.

Test with actual writing mode values. Add writing-mode: vertical-rl to your test matrix. Check that Flexbox containers reflow correctly. Verify that Grid tracks resize appropriately. Confirm that text doesn't overflow or collapse. This takes minutes to set up and catches failures that will affect real users.

Audit your component library. If your design system hard-codes physical properties throughout, writing mode support will fail at the component level regardless of page-level settings. The fix needs to happen in the components themselves.

Involve multilingual users in testing. If your service reaches Chinese, Japanese, Korean, Arabic, or Hebrew speakers, those communities should be part of your accessibility testing process — not as an afterthought, but as a core validation step.

The Strategic Case

For organizations making resource decisions, the case for writing mode support is straightforward: the global population of readers whose native scripts are not horizontal-tb numbers in the hundreds of millions. Japanese alone represents a $5 trillion economy. Chinese-language internet users are among the largest online populations in the world.

More directly: if your organization serves diverse communities — and most public-facing organizations do — writing mode support is part of serving those communities equitably. The Southwest ADA Center (opens in new window) consistently emphasizes that accessibility planning must account for the actual demographics of the communities being served, not just the majority use case.

The CSS is not the hard part. writing-mode: vertical-rl is four words. The hard part is building organizational awareness that these four words matter — that the default horizontal-tb is a choice with consequences for real readers, and that equal access to web content means those readers deserve layouts that work.

Start with your logical properties audit. It will tell you more about your internationalization readiness than any automated scan.