Problem/Motivation

AltTextRules validation behaves correctly when editing or creating media on dedicated media routes (e.g. /media/add/{type}, /media/{id}/edit). On content types that use a Media reference field with the Media Library widget, users observe no validation (or validation appears inconsistent), even though the same media type and image field are subject to alt text rules when saved from the media UI.

This creates an inconsistent editorial experience and can allow media with invalid alt text to be attached to nodes without surfacing the same errors that appear on the media form.

Steps to reproduce

  1. Enable Alt Text Validation and configure rules (e.g. rules that clearly fail on trivial alt text).
  2. Confirm validation on Media UI:
    1. Visit /media/add/image (or your image media bundle), set alt text that violates a rule, save → validation error appears (expected).
    2. Edit an existing item at /media/{mid}/edit, violate a rule, save → error appears (expected).
  3. On a content type (e.g. Article), use a Media field configured with the Media Library widget.
  4. Create new media from the library or attach media in a way that would previously only be validated on the media form. Use alt text that should fail rules where the UI allows editing alt.
  5. Click "Save and select" or "Save and insert"

Actual result: No alt text validation (or no validation in the same way as /media/...).

Expected result: The same (or clearly documented equivalent) alt text rules should apply when media is created or edited in the Media Library context, and/or when saving content that references media whose alt rules matter for accessibility.

How the issue was introduced

Validator exits early on “AJAX” requests
AltTextRulesConstraintValidator::validate() returns immediately when HTTP_X-Requested-With: XMLHttpRequest is present (see isAjaxRequest()). Media Library flows often use Drupal AJAX; media saves initiated from those flows may skip validation entirely even when the media entity is the one being validated.

This issue was first introduced here:

#3541613 (“Clicking the Add paragraph button triggers validation”) showed that AJAX-driven partial updates on entity forms (paragraphs “Add”, image field widgets, etc.) were causing full entity validation, so AltTextRules ran at the wrong time and surfaced errors/warnings above unrelated UI.

The issue was fixed in !61 by detecting AJAX and bypassing validation in AltTextRulesConstraintValidator::validate(). It was noted that #limit_validation_errors is not available from a field constraint, so a form-level fix was not practical for this module as written. That approach correctly stops spurious validation on intermediate AJAX requests on large entity forms.

Proposed resolution

Narrow the AJAX bypass
Replace the blanket “skip on every XHR” rule with a narrower condition that still matches the original failure mode, for example:

  • Only skip when the entity being validated is of a type that exhibited the bug, starting with node (and optionally other types added via config if the same problem appears on block_content, etc.).
  • Do not skip when the entity is media (or whatever types must enforce alt on AJAX saves).
  • Check route name: if the current route is something like media_library.ui (modal) or a deliberate media save endpoint, don't skip. If it's a generic entity form with AJAX, skip.

But there could be other solutions I'm no aware of.

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

joncjordan created an issue. See original summary.

swirt made their first commit to this issue’s fork.

  • swirt committed 19c6277b on 1.0.x authored by joncjordan
    #3588342: Alt text rules not enforced when using Media Library
    
swirt’s picture

Status: Active » Fixed

Thanks for all your work on this joncjordan

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.