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
- Enable Alt Text Validation and configure rules (e.g. rules that clearly fail on trivial alt text).
- Confirm validation on Media UI:
- Visit
/media/add/image(or your image media bundle), set alt text that violates a rule, save → validation error appears (expected). - Edit an existing item at
/media/{mid}/edit, violate a rule, save → error appears (expected).
- Visit
- On a content type (e.g. Article), use a Media field configured with the Media Library widget.
- 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.
- 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:
- https://www.drupal.org/project/alt_text_validation/issues/3541613
- https://git.drupalcode.org/project/alt_text_validation/-/merge_requests/...
#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.
Issue fork alt_text_validation-3588342
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
Comment #5
swirtThanks for all your work on this joncjordan