diff --git a/.changeset/8438-richtext-maxlength-visible.md b/.changeset/8438-richtext-maxlength-visible.md
new file mode 100644
index 0000000000..a20cbde3cb
--- /dev/null
+++ b/.changeset/8438-richtext-maxlength-visible.md
@@ -0,0 +1,46 @@
+---
+'@object-ui/fields': minor
+'@object-ui/plugin-form': patch
+---
+
+An authored `max_length` on a rich-content field is now VISIBLE, not only enforced at
+submit (objectui#8438).
+
+**The defect.** `markdown`, `html` and `richtext` are three registry keys served by ONE
+widget, `RichTextField`. That widget read `maxLength` / `max_length` nowhere, while
+`buildValidationRules` — which has no field-type gate — compiled the same key into a
+react-hook-form rule for every field. So a cap authored on any of the three was enforced
+when the form was submitted and invisible before then: no native stop, no character
+counter, nothing named in `aria-describedby`. The person was told the limit only after
+writing the text, which is the worst of the three possible orderings.
+
+**The fix, and where it is NOT.** The card was filed as "`richtext` is missing from
+`ObjectForm`'s maxLength guard and `EmbeddableForm`'s `DEFAULT_MAX_LENGTH`". Re-measured,
+neither list could have carried the cap:
+
+- `ObjectForm`'s guard writes `formField.maxLength`, but a registered widget's metadata
+  carrier is `formField.field` — a different object. Ablating that assignment entirely
+  changed no rendered attribute, for any of the four types it names. It is left in place
+  (it is live for the other form-field producer) with the measurement recorded at the site.
+- `EmbeddableForm`'s `DEFAULT_MAX_LENGTH` did deliver 5000 for `markdown` and `html`, and
+  `RichTextField` then dropped it unread.
+
+⇒ The cap was lost for **all three** rich-content keys, not for `richtext` alone.
+`RichTextField` now dual-reads `maxLength ?? max_length` off its metadata carrier — the
+same read `TextAreaField` has carried since framework#1878 §3 — and forwards it to the
+native stop, the `CharacterCount` counter and the `aria-describedby` wiring, on both the
+inline surface and the fullscreen dialog.
+
+**What changes for you.** A `markdown`, `html` or `richtext` field that already declares
+`max_length` (or the spec-canonical `maxLength`) now shows a counter and stops typing at
+the cap, where before it silently accepted the overflow and failed on submit. A field with
+no authored cap is unchanged. In `EmbeddableForm`, a public form's `richtext` field is now
+capped at the 5000-character long-text default like its two siblings, instead of accepting
+unbounded input.
+
+**New export.** `@object-ui/fields` publishes `RICH_TEXT_FIELD_TYPES` (and the
+`RichTextFieldType` union), the key set of the widget's display table, so consumers stop
+hand-writing the list. `EmbeddableForm`'s cap table is derived from it. This answers the
+list question objectui#4831 raised and its fix declined to remove — the root cause behind
+objectui#4250, objectui#4831 and this card: a hand-written list that stops at two of one
+widget's three registry keys can no longer omit the third, because it no longer names one.
diff --git a/packages/fields/src/index.tsx b/packages/fields/src/index.tsx
index 0d6307af14..febc56d959 100644
--- a/packages/fields/src/index.tsx
+++ b/packages/fields/src/index.tsx
@@ -2522,6 +2522,10 @@ export function ColorSwatchCellRenderer({ value }: CellRendererProps): React.Rea
  * the widget's readonly branch read.
  */
 export { MarkdownCellRenderer, HtmlCellRenderer } from './widgets/richTextDisplay.js';
+// The KEY SET of that same table, published for the form-side consumers that
+// used to hand-write it (objectui#8438). See its docblock for why a runtime
+// list is needed next to the `RichTextFieldType` union.
+export { RICH_TEXT_FIELD_TYPES, type RichTextFieldType } from './widgets/richTextDisplay.js';
 import { RICH_TEXT_CELL_RENDERERS } from './widgets/richTextDisplay.js';
 
 /**
diff --git a/packages/fields/src/widgets/RichTextField.tsx b/packages/fields/src/widgets/RichTextField.tsx
index a744d6c772..5e55bb5bc7 100644
--- a/packages/fields/src/widgets/RichTextField.tsx
+++ b/packages/fields/src/widgets/RichTextField.tsx
@@ -1,6 +1,6 @@
-import React from 'react';
+import React, { useId } from 'react';
 import type { HtmlFieldMetadata, MarkdownFieldMetadata } from '@object-ui/types';
-import { cn, Textarea, EmptyValue, type FullscreenEditorAria } from '@object-ui/components';
+import { cn, Textarea, EmptyValue, CharacterCount, type FullscreenEditorAria } from '@object-ui/components';
 import { useObjectTranslation } from '@object-ui/react';
 import { FullscreenFieldEditor } from './FullscreenFieldEditor.js';
 import { FieldWidgetComponentProps } from './types.js';
@@ -38,6 +38,9 @@ function RichTextEditorSurface({
   autoFocus,
   textareaTestId,
   overlay,
+  counter,
+  maxLength,
+  describedBy,
   domProps,
   editorAria,
 }: {
@@ -55,6 +58,37 @@ function RichTextEditorSurface({
   textareaTestId?: string;
   /** Absolutely-positioned children over the textarea (the expand affordance). */
   overlay?: React.ReactNode;
+  /**
+   * The character counter for THIS surface, already constructed by the caller.
+   *
+   * Passed in rather than built here for the same reason `formatLabel` and
+   * `hint` are: the two surfaces differ in exactly one declared behaviour
+   * (`announceNearLimit`), and the difference belongs at the one place that
+   * knows which surface it is rendering. Positioned inside the `relative`
+   * wrapper below, over the textarea, exactly like {@link overlay}.
+   */
+  counter?: React.ReactNode;
+  /**
+   * The authored ceiling, forwarded to the `<Textarea>` as the native
+   * `maxLength` stop (objectui#8438).
+   *
+   * ⚠️ It is NOT reachable through {@link domProps}: `maxLength` is not on the
+   * `toDomProps` whitelist, and this widget read the key nowhere else — so
+   * before objectui#8438 a `max_length` authored on ANY of the three registry
+   * keys this widget serves reached no element at all, while the sibling
+   * `TextAreaField` had honoured it since framework#1878 §3.
+   */
+  maxLength?: number;
+  /**
+   * The composed `aria-describedby` for this surface's textarea.
+   *
+   * Composed by the CALLER and assigned after the `domProps` spread, because
+   * the two surfaces compose it from different sources: the inline one appends
+   * the counter's description id to the ids `<FormControl>` handed down, and
+   * the dialog's names only its own — the host's ids sit outside the modal,
+   * which Radix `aria-hidden`s while it is open.
+   */
+  describedBy?: string;
   /**
    * The host's DOM pass-through (objectui#4810), already filtered through the
    * `toDomProps` whitelist by the caller — the field's `id`, the
@@ -109,6 +143,7 @@ function RichTextEditorSurface({
           placeholder={placeholder}
           disabled={disabled}
           rows={fullHeight ? undefined : rows}
+          maxLength={maxLength}
           // `text-base` in the dialog for the same reason `TextAreaField` uses
           // it there: sub-16px inputs make iOS Safari zoom on focus, which is
           // exactly wrong for a surface the user opened to get more room.
@@ -128,6 +163,12 @@ function RichTextEditorSurface({
           // keeps that entry passing instead of handing the state back to a
           // host that may not have one.
           aria-invalid={!!error}
+          // After the spread so the COMPOSED value wins over the raw
+          // `aria-describedby` `toDomProps` forwarded — appended, never
+          // assigned, on the inline surface (see `describedBy`'s caller).
+          // Overwriting the host's ids would trade "no cap announced" for "no
+          // error announced", which is strictly worse and silent.
+          aria-describedby={describedBy}
           // LAST, and only ever non-empty on the dialog rendering: inside the
           // modal the primitive is the authority on both the name and the
           // validation state, and its `aria-invalid` must win over the `!!error`
@@ -135,6 +176,7 @@ function RichTextEditorSurface({
           // construction). On the inline surface this spreads nothing.
           {...editorAria}
         />
+        {counter}
         {overlay}
       </div>
     </div>
@@ -245,6 +287,20 @@ export function RichTextField({ value, onChange, field, readonly, error, ...prop
   const fieldType = resolveRichTextFieldType(field);
   const syntax = richTextSyntax(fieldType);
 
+  /**
+   * Two description ids off one `useId()` — one per editing surface, minted
+   * ABOVE the readonly early return because a hook may not sit behind a
+   * conditional return. The readonly branch renders no counter, so they go
+   * unused there; moving the call down would desync hook order the moment a
+   * field toggles readonly. Identical to `TextAreaField`, and for the same
+   * reason: the dialog edits a LOCAL draft, so the moment the user types in it
+   * the two surfaces are counting different strings and one shared id would
+   * point both textareas at whichever sentence rendered last.
+   */
+  const instanceId = useId();
+  const descriptionId = `${instanceId}-charcount`;
+  const fullscreenDescriptionId = `${instanceId}-fullscreen-charcount`;
+
   if (readonly) {
     const Display = richTextCellRenderer(fieldType);
     // Not a rich-content type: nothing to render as markup, and `prose` would
@@ -292,6 +348,38 @@ export function RichTextField({ value, onChange, field, readonly, error, ...prop
   // (which is what retired the `as any` that used to launder this carrier).
   const richField = field as MarkdownFieldMetadata | HtmlFieldMetadata;
   const rows = richField?.rows || 8;
+  /**
+   * The authored ceiling — the same dual read `TextAreaField` has carried
+   * since framework#1878 §3, and `max_length` is declared on all three of this
+   * widget's metadata faces (`MarkdownFieldMetadata`, `HtmlFieldMetadata`,
+   * `RichtextFieldMetadata`), so the cast above already admits it.
+   *
+   * ## Why this read did not exist until objectui#8438
+   *
+   * It was believed to be somebody else's job, in two places that measurement
+   * says were never doing it:
+   *
+   *  - `ObjectForm` sets `formField.maxLength` for a hand-written list of
+   *    types. For an object-schema-derived field that assignment lands on the
+   *    FORM FIELD, while the metadata carrier registered widgets read is
+   *    `formField.field` — a different object — so no registered widget has
+   *    ever seen it. Ablating the assignment entirely changes no rendered
+   *    attribute on either the registered or the builtin path.
+   *  - `EmbeddableForm`'s `DEFAULT_MAX_LENGTH` caps `markdown` and `html` at
+   *    5000. There the form field IS the carrier, so the value did arrive —
+   *    and then died here, unread.
+   *
+   * ⇒ The cap was invisible for ALL THREE registry keys, not just `richtext`:
+   * no native stop, no counter, and nothing named in `aria-describedby`, while
+   * `buildValidationRules` (which has no field-type gate) rejected the same
+   * text at SUBMIT. That is the worst ordering of the three possible ones —
+   * the person is told after writing — and it is what this read ends.
+   *
+   * The camelCase half stays a narrow structural read for the same reason it
+   * does in `TextAreaField`: the objectui metadata types deliberately do not
+   * declare the spec spelling.
+   */
+  const maxLength = (field as { maxLength?: number }).maxLength ?? richField?.max_length;
   // The stored syntax, DERIVED from the type's display pipeline rather than
   // read off a `format` key no rich-content type declares. Empty for a type
   // with no pipeline: the header names a syntax or it names nothing, it does
@@ -314,6 +402,17 @@ export function RichTextField({ value, onChange, field, readonly, error, ...prop
   // edit through `onCommit`. `disabled` also carries the form's `isSubmitting`.
   const disabled = Boolean(domProps.disabled);
 
+  /**
+   * APPENDED, never assigned. `<FormControl>` is a Radix Slot and has already
+   * handed this control an `aria-describedby` naming the field's description
+   * and error message; it arrives through `toDomProps`' `aria-*` pass-through.
+   * Overwriting it would trade "no cap announced" for "no error announced".
+   */
+  const describedBy =
+    [domProps['aria-describedby'], maxLength ? descriptionId : undefined]
+      .filter(Boolean)
+      .join(' ') || undefined;
+
   // Resolved once and handed to BOTH renderings of the editor, so the dialog
   // cannot drift into showing different copy than the inline surface.
   const formatLabel = t('fields.richText.format', { format, defaultValue: `Format: ${format}` });
@@ -333,7 +432,28 @@ export function RichTextField({ value, onChange, field, readonly, error, ...prop
       disabled={readonly || disabled}
       error={error}
       className={domProps.className}
+      maxLength={maxLength}
+      describedBy={describedBy}
       domProps={domProps}
+      counter={
+        maxLength ? (
+          /*
+            The INLINE surface's counter — `announceNearLimit`, exactly as
+            `TextAreaField`'s is: this is the surface the user types into with
+            the rest of the form around them, so the near-limit warning is the
+            one thing worth interrupting for, and `CharacterCount` gates and
+            debounces it.
+          */
+          <CharacterCount
+            length={(value || '').length}
+            maxLength={maxLength}
+            descriptionId={descriptionId}
+            announceNearLimit
+            className="absolute bottom-2 right-2 text-xs text-gray-400"
+            testId="richtext-character-count"
+          />
+        ) : null
+      }
       overlay={
         showFullscreenButton && (
           <FullscreenFieldEditor
@@ -351,6 +471,27 @@ export function RichTextField({ value, onChange, field, readonly, error, ...prop
               `aria-hidden` for as long as this dialog is open.
             */
             error={error}
+            /*
+              The FULLSCREEN surface's counter, with `announceNearLimit={false}`
+              — objectui#3417's ruling, adopted here unchanged rather than
+              re-decided: a fullscreen modal is opened deliberately to write at
+              length, the description already delivers the cap on focus, and
+              the dialog's textarea carries the same native stop. A second live
+              region would also put two of them in one document, since the
+              inline surface stays mounted behind the overlay.
+            */
+            footer={(draft) =>
+              maxLength ? (
+                <CharacterCount
+                  length={draft.length}
+                  maxLength={maxLength}
+                  descriptionId={fullscreenDescriptionId}
+                  announceNearLimit={false}
+                  className="text-xs text-muted-foreground self-center"
+                  testId="richtext-fullscreen-character-count"
+                />
+              ) : null
+            }
           >
             {(draft, setDraft, editorDisabled, editorAria) => (
               <RichTextEditorSurface
@@ -362,6 +503,16 @@ export function RichTextField({ value, onChange, field, readonly, error, ...prop
                 disabled={editorDisabled}
                 autoFocus
                 fullHeight
+                maxLength={maxLength}
+                /*
+                  ASSIGNED here, not appended — and that is a statement about
+                  this element rather than a relaxation of the inline rule.
+                  `domProps` never reaches the dialog copy (see `domProps`), and
+                  the ids the host would have supplied name nodes OUTSIDE the
+                  modal, which Radix `aria-hidden`s while it is open. There is
+                  nothing to preserve.
+                */
+                describedBy={maxLength ? fullscreenDescriptionId : undefined}
                 textareaTestId="richtext-fullscreen-input"
                 editorAria={editorAria}
               />
diff --git a/packages/fields/src/widgets/richTextDisplay.tsx b/packages/fields/src/widgets/richTextDisplay.tsx
index 1a46dd5286..45ce0a0cfc 100644
--- a/packages/fields/src/widgets/richTextDisplay.tsx
+++ b/packages/fields/src/widgets/richTextDisplay.tsx
@@ -173,6 +173,33 @@ export const RICH_TEXT_CELL_RENDERERS = {
 /** The rich-content field types, i.e. the keys of {@link RICH_TEXT_CELL_RENDERERS}. */
 export type RichTextFieldType = keyof typeof RICH_TEXT_CELL_RENDERERS;
 
+/**
+ * The same three types as a RUNTIME list, DERIVED from THE table rather than
+ * spelled a second time — the type-level {@link RichTextFieldType} cannot be
+ * enumerated at runtime, and a hand-written array beside it would be exactly
+ * the shape this export exists to retire.
+ *
+ * ## Why this export exists
+ *
+ * objectui#4831 asked, in its own body, whether the hand-written type lists
+ * that keep omitting the third of this widget's three registry keys should
+ * become "every type that resolves to the long-text widget". It was answered
+ * by adding one literal, and the omission recurred (objectui#4250,
+ * objectui#8438). This is that question answered in the other direction: a
+ * consumer that spreads this list cannot omit a key, because it never names
+ * one. Adding a fourth key to {@link RICH_TEXT_CELL_RENDERERS} extends every
+ * such consumer in the same commit that adds the key.
+ *
+ * ⚠️ It is NOT a general "long text" list and must not be used as one:
+ * `textarea` renders a `<Textarea>` too and is deliberately absent, because it
+ * is a different widget with its own registry key and its own metadata face.
+ * The invariant this list states is narrower and exact — *these are the keys
+ * `RichTextField` serves*.
+ */
+export const RICH_TEXT_FIELD_TYPES: readonly RichTextFieldType[] = Object.keys(
+  RICH_TEXT_CELL_RENDERERS,
+) as RichTextFieldType[];
+
 /**
  * The SYNTAX a rich-content type stores, derived from the renderer that type
  * resolves to rather than declared a second time.
diff --git a/packages/plugin-form/src/EmbeddableForm.tsx b/packages/plugin-form/src/EmbeddableForm.tsx
index 33da4b8943..caa9e177f2 100644
--- a/packages/plugin-form/src/EmbeddableForm.tsx
+++ b/packages/plugin-form/src/EmbeddableForm.tsx
@@ -24,6 +24,7 @@ import React, { useState, useCallback, useMemo, useRef, useEffect } from 'react'
 import type { DataSource, FormField } from '@object-ui/types';
 import { Button } from '@object-ui/components';
 import { CheckCircle2, Lock, Loader2, ShieldCheck } from 'lucide-react';
+import { RICH_TEXT_FIELD_TYPES } from '@object-ui/fields';
 import { ObjectForm } from './ObjectForm';
 import {
   useThankYouRedirectNavigation,
@@ -143,16 +144,40 @@ export interface EmbeddableFormProps {
   className?: string;
 }
 
-/** Hardened default caps applied to text-shaped customFields when the spec
- *  doesn't already define one. Mirrors Airtable/Tally defaults. */
+/** The long-form cap, shared by `textarea` and every rich-content type. */
+const LONG_TEXT_MAX_LENGTH = 5000;
+
+/**
+ * Hardened default caps applied to text-shaped customFields when the spec
+ * doesn't already define one. Mirrors Airtable/Tally defaults.
+ *
+ * ## The rich-content entries are DERIVED, not enumerated (objectui#8438)
+ *
+ * `markdown` and `html` used to be written out here while `richtext` — the
+ * THIRD registry key of the same one widget — was absent, so a public form's
+ * `richtext` field took unbounded input. That is the fourth instance of a
+ * root cause objectui#4831 named in its own body and its fix declined to
+ * remove: *hand-written type lists that stop at two of this widget's three
+ * keys* (objectui#4250 and objectui#4831 are the other two).
+ *
+ * Spreading {@link RICH_TEXT_FIELD_TYPES} is that question answered rather
+ * than deferred again: this table no longer names a rich-content type, so it
+ * can no longer omit one, and a fourth key added to the widget's display table
+ * arrives here in the same commit that adds it.
+ *
+ * ⛔ The four short-text entries above stay literal ON PURPOSE. Each is a
+ * distinct widget with a distinct cap, and there is no table to derive them
+ * from — a predicate wide enough to cover them would be an invention, not a
+ * derivation. The root cause being removed is "one widget, N keys, a list that
+ * knows N-1", which is a statement about the rich-content trio alone.
+ */
 const DEFAULT_MAX_LENGTH: Record<string, number> = {
   text: 200,
   email: 254, // RFC 5321
   url: 2048,
   phone: 32,
-  textarea: 5000,
-  markdown: 5000,
-  html: 5000,
+  textarea: LONG_TEXT_MAX_LENGTH,
+  ...Object.fromEntries(RICH_TEXT_FIELD_TYPES.map((t) => [t, LONG_TEXT_MAX_LENGTH])),
 };
 
 const DEFAULT_HONEYPOT_NAME = '_company_website_2';
diff --git a/packages/plugin-form/src/ObjectForm.tsx b/packages/plugin-form/src/ObjectForm.tsx
index be961dc04a..663507f03f 100644
--- a/packages/plugin-form/src/ObjectForm.tsx
+++ b/packages/plugin-form/src/ObjectForm.tsx
@@ -847,6 +847,33 @@ const SimpleObjectForm: React.FC<ObjectFormComponentProps> = ({
           formField.inputType = 'datetime-local';
         }
 
+        // ⛔ DO NOT ADD A TYPE TO THIS LIST TO GIVE IT A LENGTH CAP. Measured
+        // on this branch's base (objectui#8438): on THIS path the assignment
+        // below reaches nothing, for every one of the four types it names.
+        //
+        // `formField` is the FORM FIELD; the metadata carrier a registered
+        // `field:*` widget reads is `formField.field` — a DIFFERENT object,
+        // assigned from the raw object-schema `field` further down. So
+        // `TextAreaField` resolves its cap from `field.max_length` directly and
+        // never consults the key written here. Ablation, both configurations,
+        // with the two statements below replaced by a comment: the rendered
+        // `maxlength` attribute and the character counter were byte-identical
+        // to the unablated run (a `textarea` with `max_length: 111` kept
+        // `maxlength="111"` and its `0/111` counter; `markdown`, `html` and
+        // `richtext` rendered no `maxlength` either way).
+        //
+        // ⇒ objectui#8438 was filed as "`richtext` is missing from this list".
+        // It is — and adding it would have changed nothing observable, which is
+        // exactly the 假绿 objectui#4250 named and objectui#4831 warned about.
+        // The cap was unread for ALL THREE of the rich-content registry keys,
+        // and the fix is the widget reading it: see the `maxLength` docblock in
+        // `packages/fields/src/widgets/RichTextField.tsx`.
+        //
+        // Left in place rather than deleted: `formField.maxLength` IS live for
+        // the OTHER producer of form fields — `EmbeddableForm`'s
+        // `applyDefaultMaxLengths` writes it onto `customFields`, where the
+        // form field IS the carrier — and removing a dead assignment is a
+        // different question from this card's, on a shared file.
         if (field.type === 'text' || field.type === 'textarea' || field.type === 'markdown' || field.type === 'html') {
           // Spec FieldSchema declares camelCase; `max_length`/`min_length` is
           // the legacy objectui spelling. Dual-read like buildValidationRules
diff --git a/packages/plugin-form/src/richtextMaxLength.8438.test.tsx b/packages/plugin-form/src/richtextMaxLength.8438.test.tsx
new file mode 100644
index 0000000000..456668d17f
--- /dev/null
+++ b/packages/plugin-form/src/richtextMaxLength.8438.test.tsx
@@ -0,0 +1,216 @@
+/**
+ * ObjectUI
+ * Copyright (c) 2024-present ObjectStack Inc.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+/**
+ * objectui#8438 — an authored `max_length` on a rich-content field must be
+ * VISIBLE, not only enforced at submit.
+ *
+ * ## Pinned by behaviour, deliberately
+ *
+ * The card and its triage both ruled out the obvious pin: ⛔ asserting that
+ * `'richtext'` appears in some list. That is the 假绿 objectui#4250 named and
+ * objectui#4831 warned about — and this card is why. Re-measured on the
+ * branch base, the two lists the card pointed at could not have carried the
+ * cap at all:
+ *
+ *  - `ObjectForm`'s `text | textarea | markdown | html` guard writes
+ *    `formField.maxLength`; a registered widget reads `formField.field`. A
+ *    literal-only fix there would have been green and inert.
+ *  - `EmbeddableForm`'s `DEFAULT_MAX_LENGTH` did deliver 5000 for `markdown`
+ *    and `html` — and `RichTextField` read the key nowhere, so it died there.
+ *
+ * So every assertion below reads the DOM the person actually gets: the native
+ * stop, the counter, and the id the control names in `aria-describedby`.
+ *
+ * ## The ablations these must survive
+ *
+ * Both are one-shot proofs, run on the fix commit and recorded in the PR:
+ *
+ *  - delete the `maxLength` dual-read in `RichTextField` ⇒ BOTH suites red;
+ *  - delete `richtext` from `RICH_TEXT_CELL_RENDERERS` (THE table the
+ *    `EmbeddableForm` default is now derived from) ⇒ the default-cap suite red.
+ *
+ * ## The controls
+ *
+ * `markdown` and `html` are asserted beside `richtext` because they are the
+ * SAME widget: a fix that reached only the third key would leave the asymmetry
+ * this card is about. A rich field with NO authored cap, and a type outside
+ * the table, are the negative controls — without them a widget that rendered a
+ * counter unconditionally, or a cap table that answered every type, would pass.
+ */
+import React from 'react';
+import { describe, it, expect, vi } from 'vitest';
+import { render, waitFor } from '@testing-library/react';
+import { registerAllFields } from '@object-ui/fields';
+
+import { ObjectForm } from './ObjectForm';
+import { EmbeddableForm, applyDefaultMaxLengths } from './EmbeddableForm';
+
+registerAllFields();
+
+/** The three registry keys `RichTextField` serves, with distinct caps. */
+const AUTHORED_CAPS = { md: 222, htm: 333, rich: 444 } as const;
+
+const docSchema = {
+  name: 'doc',
+  fields: {
+    // The sibling that has always worked — a live control, not a claim.
+    note: { type: 'textarea', label: 'Note', max_length: 111 },
+    md: { type: 'markdown', label: 'MD', max_length: AUTHORED_CAPS.md },
+    htm: { type: 'html', label: 'HTML', max_length: AUTHORED_CAPS.htm },
+    rich: { type: 'richtext', label: 'Rich', max_length: AUTHORED_CAPS.rich },
+  },
+};
+
+const makeObjectDataSource = () => ({
+  getObjectSchema: vi.fn().mockResolvedValue(docSchema),
+  create: vi.fn(),
+  update: vi.fn(),
+  findOne: vi.fn(),
+});
+
+const makeEmbeddableDataSource = () => ({
+  create: vi.fn(async (_o: string, d: Record<string, unknown>) => ({ id: '1', ...d })),
+  update: vi.fn(),
+  delete: vi.fn(),
+  findOne: vi.fn(),
+  find: vi.fn(async () => ({ data: [], total: 0 })),
+  getObjectSchema: vi.fn(async (name: string) => ({ name, fields: {} })),
+});
+
+/** The control the person types into, by field name. */
+async function editorFor(container: HTMLElement, name: string): Promise<HTMLTextAreaElement> {
+  return waitFor(() => {
+    const el = container.querySelector(`textarea[name="${name}"]`) as HTMLTextAreaElement | null;
+    if (!el) throw new Error(`textarea[name="${name}"] not rendered`);
+    return el;
+  });
+}
+
+/**
+ * The accessible half of the cap: what a screen reader would actually read out
+ * for this control, i.e. the text of the nodes its `aria-describedby` NAMES.
+ *
+ * Resolving the ids (rather than asserting the id string) is the point — an
+ * `aria-describedby` that names a node which does not exist announces nothing,
+ * and that is the failure this family of bugs actually takes.
+ *
+ * ⚠️ Unresolvable ids are dropped rather than failed on: `<FormControl>` names
+ * its `-form-item-description` id unconditionally, including for fields that
+ * render no description, so a dangling entry is present on this repo's happy
+ * path and is not this card's subject.
+ */
+function describedText(el: HTMLTextAreaElement): string {
+  const ids = (el.getAttribute('aria-describedby') || '').split(/\s+/).filter(Boolean);
+  return ids
+    .map((id) => el.ownerDocument.getElementById(id))
+    .filter((n): n is HTMLElement => Boolean(n))
+    .map((n) => n.textContent || '')
+    .join(' ');
+}
+
+describe('objectui#8438 — ObjectForm: an authored max_length is visible on a rich-content field', () => {
+  it.each([
+    ['richtext', 'rich', AUTHORED_CAPS.rich],
+    ['markdown', 'md', AUTHORED_CAPS.md],
+    ['html', 'htm', AUTHORED_CAPS.htm],
+  ])('%s: the native stop, the counter and the description all carry the cap', async (_type, name, cap) => {
+    const { container } = render(
+      <ObjectForm
+        schema={{ type: 'object-form', objectName: 'doc', mode: 'create' } as any}
+        dataSource={makeObjectDataSource() as any}
+      />,
+    );
+
+    const editor = await editorFor(container, name);
+    // 1. the native stop
+    expect(editor.getAttribute('maxlength')).toBe(String(cap));
+    // 2. the visible counter, showing this field's own ceiling
+    const counter = await waitFor(() => {
+      const found = Array.from(container.querySelectorAll('[data-testid="richtext-character-count"]'))
+        .find((n) => (n.textContent || '').includes(String(cap)));
+      if (!found) throw new Error(`no counter naming ${cap}`);
+      return found;
+    });
+    expect(counter.textContent).toContain(`0/${cap}`);
+    // 3. the announcement — a real node, naming the ceiling
+    expect(describedText(editor)).toContain(String(cap));
+  });
+
+  it('the sibling textarea widget is unchanged', async () => {
+    const { container } = render(
+      <ObjectForm
+        schema={{ type: 'object-form', objectName: 'doc', mode: 'create' } as any}
+        dataSource={makeObjectDataSource() as any}
+      />,
+    );
+    const note = await editorFor(container, 'note');
+    expect(note.getAttribute('maxlength')).toBe('111');
+  });
+
+  it('CONTROL — a rich-content field with no authored cap gets no stop and no counter', async () => {
+    // Rendered ALONE, so "no counter anywhere in this form" is a statement
+    // about this field. A widget that rendered the counter unconditionally, or
+    // a cap resolved from something other than the authored key, fails here.
+    const ds = {
+      getObjectSchema: vi.fn().mockResolvedValue({
+        name: 'doc',
+        fields: { uncapped: { type: 'richtext', label: 'Uncapped' } },
+      }),
+      create: vi.fn(),
+      update: vi.fn(),
+      findOne: vi.fn(),
+    };
+    const { container } = render(
+      <ObjectForm
+        schema={{ type: 'object-form', objectName: 'doc', mode: 'create' } as any}
+        dataSource={ds as any}
+      />,
+    );
+    const uncapped = await editorFor(container, 'uncapped');
+    expect(uncapped.getAttribute('maxlength')).toBeNull();
+    expect(container.querySelectorAll('[data-testid="richtext-character-count"]')).toHaveLength(0);
+    expect(uncapped.getAttribute('aria-describedby') || '').not.toContain('charcount');
+  });
+});
+
+describe('objectui#8438 — EmbeddableForm: the hardened default cap covers every rich-content key', () => {
+  it.each([
+    ['richtext', 'rich'],
+    ['markdown', 'md'],
+    ['html', 'htm'],
+  ])('%s: an uncapped public-form field is capped at the long-text default', async (type, name) => {
+    const { container } = render(
+      <EmbeddableForm
+        config={{
+          objectName: 'lead',
+          customFields: [{ name, label: name, type }] as any,
+        } as any}
+        dataSource={makeEmbeddableDataSource() as any}
+      />,
+    );
+    const editor = await editorFor(container, name);
+    expect(editor.getAttribute('maxlength')).toBe('5000');
+    expect(describedText(editor)).toContain('5000');
+  });
+
+  it('an AUTHORED cap still wins over the default', () => {
+    const out = applyDefaultMaxLengths([{ name: 'rich', type: 'richtext', max_length: 40 } as any]);
+    expect((out![0] as any).maxLength).toBeUndefined();
+    expect((out![0] as any).max_length).toBe(40);
+  });
+
+  it('CONTROL — a type outside the rich-content table gets no long-text default', () => {
+    const out = applyDefaultMaxLengths([
+      { name: 'n', type: 'number' } as any,
+      { name: 'j', type: 'json' } as any,
+    ]);
+    expect((out![0] as any).maxLength).toBeUndefined();
+    expect((out![1] as any).maxLength).toBeUndefined();
+  });
+});
diff --git a/packages/types/src/field-types.ts b/packages/types/src/field-types.ts
index d69348056d..0eab9cefe3 100644
--- a/packages/types/src/field-types.ts
+++ b/packages/types/src/field-types.ts
@@ -345,12 +345,18 @@ export interface HtmlFieldMetadata extends BaseFieldMetadata {
  * is pinned separately, in
  * `packages/types/src/__tests__/select-option-spec-extension-7014.test.ts`.
  *
- * ⚠️ Two form-side sites do NOT reach `richtext`, and this key claims no
- * coverage there: `ObjectForm` forwards `max_length` to the HTML `maxlength`
- * attribute for `text | textarea | markdown | html` only, and
- * `EmbeddableForm`'s `DEFAULT_MAX_LENGTH` caps `markdown` and `html` only.
- * `richtext` is absent from both. Those omissions predate this member and are
- * not corrected here.
+ * ⚠️ The two form-side sites this docblock used to name as not reaching
+ * `richtext` were RE-MEASURED by objectui#8438, and the reading did not hold:
+ * `ObjectForm`'s `text | textarea | markdown | html` list writes
+ * `formField.maxLength`, which no registered widget reads (the carrier is
+ * `formField.field`), so it forwarded the cap for NONE of its four types; and
+ * `EmbeddableForm`'s `DEFAULT_MAX_LENGTH` did deliver 5000 for `markdown` and
+ * `html`, where `RichTextField` then dropped it unread. ⇒ the cap was invisible
+ * for all three of this widget's registry keys, not for `richtext` alone.
+ * objectui#8438 fixed it where it was actually lost — `RichTextField` now
+ * dual-reads `maxLength ?? max_length` — so a `max_length` authored here is
+ * honoured by the native stop, the character counter and `aria-describedby`,
+ * as well as at submit.
  *
  * Omitting the key would have left `richtext` the one type of the three whose
  * ceiling cannot be authored under an annotation, while the submit-time rule