Your form says the description is required, yet it accepts an empty-looking editor. Another form refuses to submit and complains that an invalid control cannot be focused. Both can arise when an HTML editor replaces a textarea but the application still treats it as an ordinary text field.
Nonempty HTML is not the same as a completed field
An editor may keep a paragraph and a line break so the caret has somewhere to sit. The value <p><br></p> is a nonempty string, but it does not contain a description. Formatting an empty paragraph can add even more markup without adding any text.
Comparing the document to one special empty string is brittle: different editor settings and editing actions can leave different markup. Stripping tags with a regular expression is also a poor foundation for parsing HTML. Define a content rule, then evaluate the parsed document against that rule.
Write the policy before writing the validator
A support ticket can reasonably require explanatory text. A photo post can reasonably accept a single image. A contract form may require a minimum text length and a separate attachment. None of these rules is equivalent to “the HTML string has characters.”
For text-only requirements, decide how whitespace and line breaks count. For minimum lengths, account for the languages and emoji your users type. For image-based content, confirm the upload has finished and the asset is valid; a temporary preview is not a completed attachment.
The hidden textarea creates a second problem
Browser validation applies to native form controls. When an editor hides the textarea, the browser may try to focus a control that the user cannot reach. An editor integration may provide its own replacement behavior; do not assume every editor or wrapper handles this identically.
Implement an explicit rule for the editing surface, and keep native validation for ordinary fields such as a subject or email. Show a visible field error, preserve the draft and focus the editor. Keyboard and screen-reader testing matters as much as the red border.
Validate the value you are actually sending
A background change notification or React state value may lag behind the last edit. Content inserted programmatically can also differ from the backing textarea. Read the current editor content in the submission flow and synchronize the submitted field before validating and sending it.
The form validation guide includes a tested text-presence helper, submission wiring and a server checklist. Try the working form demo to see HTML included alongside an ordinary subject field.
Client validation improves feedback; the server decides acceptance
A direct HTTP request does not need to run your JavaScript. Apply authorization, payload limits, HTML sanitization and the content policy on the server. Evaluate required content after sanitization too: removing disallowed markup can leave an otherwise nonempty request with no accepted content.
Keep validation separate from storage and security. A nonempty string can still contain unsafe HTML; a safe document can still fail a required-text rule. See storing rich text and stored XSS in editor content for those separate responsibilities.
Test the awkward inputs
Use blank paragraphs, nonbreaking spaces, formatted text, image-only content, emoji and IME input in your acceptance tests. Check failed submissions on a phone: the keyboard should not hide the error, the draft should remain, and the user should have a clear way to correct the field.
Reference: MDN documents native required-field validation. CKEditor 4 documents an editor-specific required event, illustrating why native and editor validation are separate integration concerns. That event is not a RichTextEditor API.
RichTextEditor is a perpetual-licence JavaScript editor — one purchase, self-hosted, no metered editor loads. Download the evaluation or see how it compares.