Writing Mode Compliance: The Legal Exposure Developers Ignore

In their recent analysis of CSS writing-mode and logical properties, Jamie frames the issue primarily as a technical and ethical gap — developers treating load-bearing accessibility infrastructure as decorative afterthought. That framing is accurate. But it undersells the real harm to users and the legal exposure organizations carry when multilingual rendering failures prevent equal access to digital content.

The legal dimension here deserves its own examination — not because lawsuits are the reason to care, but because legal frameworks exist to enforce the equal access that multilingual users with disabilities are already owed.

What the Law Actually Requires

The Americans with Disabilities Act (opens in new window) doesn't enumerate CSS properties. Neither does Section 508 of the Rehabilitation Act (opens in new window). What both frameworks require — through regulatory guidance, DOJ settlements, and accumulated case law — is that digital content be equally accessible to people with disabilities. That principle extends to language-based accessibility barriers in ways that practitioners frequently underestimate.

Screen reader users who rely on Japanese, Chinese, Arabic, or Hebrew interfaces aren't a hypothetical population. When writing-mode renders incorrectly, or when logical properties collapse layout for right-to-left scripts, the result is content that assistive technology cannot parse in the expected reading order. WCAG 2.1 Success Criterion 1.3.2 (opens in new window) requires that the reading sequence conveyed through presentation can be programmatically determined. A broken writing mode breaks that sequence.

This isn't a technicality. It's a direct mapping from CSS failure to WCAG non-conformance to a real user who cannot access content they have every right to access.

The DOJ's Expanding Interpretation

The Department of Justice has been explicit since its 2022 guidance on web accessibility under the ADA (opens in new window) that Title II and Title III entities must provide accessible web content. That guidance doesn't carve out multilingual interfaces. It doesn't exempt sites that serve non-English-speaking users from a different server path.

What the DOJ guidance establishes is that the standard for accessibility is functional equivalence — can a person with a disability access the same information and services as a person without one? When writing mode failures prevent a screen reader from navigating a Japanese-language government portal in the correct reading order, the answer is no. The disability in question may be visual. The barrier in question is CSS.

Organizations operating under Title II — state and local governments, public universities, transit authorities — face particular exposure here. Many of these entities serve linguistically diverse communities by legal mandate. A transit authority that publishes multilingual route information with broken RTL rendering for Arabic-speaking riders has compounded one compliance failure with another, and has failed real riders in the process.

Where Risk Concentrates

Not all organizations carry equal exposure, and practitioners advising clients need to understand where risk actually concentrates.

Government and quasi-government entities face the sharpest risk. Title II requirements are non-negotiable, DOJ enforcement has intensified, and the Great Plains ADA Center (opens in new window) and other regional centers have documented the frequency with which multilingual accessibility failures appear in technical assistance requests.

Healthcare organizations are a close second. Patient portals, appointment systems, and health information that fails to render correctly for non-English-speaking users with visual disabilities creates liability under both the ADA and Section 1557 of the Affordable Care Act, which prohibits discrimination on the basis of national origin in health programs receiving federal funding.

E-commerce and financial services face growing private litigation exposure. The volume of ADA web accessibility lawsuits has remained high — over 4,000 federal filings annually in recent years according to UsableNet's research (opens in new window) — and plaintiffs' firms have become sophisticated at identifying WCAG failures that affect specific user populations.

The Audit Gap

Here is where the risk compounds: most accessibility audits don't test writing mode behavior at all.

Automated scanning tools — axe, WAVE, Lighthouse — are built around WCAG success criteria that map cleanly to HTML semantics and ARIA. They check for alt text, label associations, color contrast ratios, and keyboard focus management. They do not render a page in a vertical writing mode and verify that Flexbox layout behaves correctly. They do not switch to an Arabic locale and confirm that logical properties produce the expected RTL reading sequence.

This means organizations can pass an automated audit, receive a clean report, and still be running a site that is functionally inaccessible to users of CJK scripts or RTL languages. As explored in the original analysis, the problem is infrastructural — it lives in how CSS understands layout direction, not in surface-level markup errors that scanners catch.

Manual testing with actual assistive technology in the relevant locales is the only reliable detection method. That testing is expensive, requires specialized expertise, and is rarely included in standard accessibility retainer work. Organizations that haven't explicitly scoped it are almost certainly not doing it.

Procurement and Vendor Risk

A dimension that receives almost no coverage in accessibility discourse: third-party vendor liability transfer.

When an organization procures a content management system, an e-commerce platform, or a patient portal from a vendor, the accessibility obligations don't transfer to the vendor — they remain with the procuring organization. Section 508 procurement requirements (opens in new window) mandate that federal agencies request Voluntary Product Accessibility Templates (VPATs) from vendors, but VPATs don't test writing mode behavior either. A VPAT can be technically accurate and still miss multilingual rendering failures entirely.

Organizations serving multilingual populations need to build explicit writing mode and logical property testing into vendor evaluation criteria. That means specifying test scenarios in RFPs, requiring demonstration in the target locales, and including multilingual accessibility warranties in contracts. Most procurement teams aren't doing this.

The Proportionality Problem

One counterargument practitioners sometimes raise: the affected population is small, so the risk is proportionally low. This argument fails on two grounds.

First, the affected population is not small. The U.S. Census Bureau (opens in new window) consistently documents that over 67 million people in the United States speak a language other than English at home. The subset of those users who rely on assistive technology and encounter RTL or vertical-script interfaces is smaller, but it is not negligible — and the law does not permit organizations to calculate acceptable exclusion thresholds.

Second, proportionality is not a recognized defense under the ADA or Section 508. The standard is equal access, not statistically significant access.

What Remediation Actually Requires

Building on this framework for understanding writing mode as infrastructure, organizations need to approach remediation at the system level rather than the property level. Retrofitting logical properties into an existing codebase built with physical properties throughout is not a quick fix — it requires auditing every layout component for writing-mode sensitivity, testing in vertical and RTL configurations, and establishing regression testing that catches failures when new components are added.

The W3C's Internationalization resources (opens in new window) provide the technical foundation for this work. The Pacific ADA Center (opens in new window) and regional ADA centers offer technical assistance for organizations navigating compliance questions.

But the organizational commitment to treat multilingual rendering as a legal requirement — and more fundamentally, as a matter of equal access for real users — has to come first. The CSS is the tractable part. The harder work is convincing stakeholders that a Japanese-language screen reader user's reading sequence is not a product roadmap item. It is a right.