Page MenuHomePhabricator

On Page rename error, error message not read by NVDA and page name input field lacks focus
Open, Needs TriagePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Create a page
  • Rename it with the same name
  • An error appears but the focus is not on the title page input and the error is not vocalized

What happens?:
An error appears but the focus is not on the title page input of the rename form and the error is not vocalized (see printscreen of speech viewer NVDA bellow)

What should have happened instead?:

  • The focus must be put on the field that raised the error
  • The error message must be vocalized

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):
Bug reproduced on Mediawiki 1.43.0

Other information (browser name/version, screenshots, etc.):
Bug reproduced on Chrome, Edge and Firefox. Bug reproduced on Vector, Vector/2022 and Timeless skin

Les erreurs d'encodage doivent être renseignées, vocalisées et prendre le focus :

  • Pour renseigner correctement une erreur, on va ajouter un <code>aria-invalid="true"</code> sur chacun des champs invalides en plus du signalement visuel (couleur, symbole). Cet attribut peut être mis sur un groupe de champ (fieldset).
  • Chaque champ invalide aura également un message d'erreur qui précise l'erreur et la correction attendue. Ce message doit lui aussi être visible, pertinent et relié au champ, soit en étant présent directement dans le <code>label</code>, soit à côté du champ mais relié à celui-ci par l'attribut <code>aria-describedby</code>. Ce message peut être mis sur un groupe de champ (fieldset) quand c'est adéquat (groupes de cases à cocher, boutons radio). Une alternative acceptable est d'utiliser un message général qui liste les champs erronés.
  • Si un message global d'erreur ou de validation est présent, on va ajouter un <code>role="alert"</code>.
  • Le focus clavier doit être placé sur le premier champs erroné. Si seul le message général renseigne les erreurs, on force le focus sur ce message avec un attribut tabindex="-1" (dans ce cas-ci le role="alert" n'est plus nécessaire).

VisionneuseErrorMessage.png (486×493 px, 30 KB)

ErrorMessageNoFocus.png (803×764 px, 40 KB)

Event Timeline

Aklapper renamed this task from Accessibility bug error messages non vocalized to On Page rename error, error message not read by NVDA and page name input field lacks focus.Dec 5 2025, 11:01 AM

"The focus must be put on the field that raised the error"

I'm not certain about this.. This is not field validation feedback. It is our standard implementation of submit action errors. The WCAG advise for this used to be "list error before the form".

this can probably be improved by adding role=alert to these messages.

Also, it's impossible to implement. MediaWiki doesn't distinguish between errors caused by the title field (common case), errors caused by the namespace dropdown (you can't move a page into MediaWiki namespace for example unless you're an admin, and moves into the "MOS:" namespace an enwiki are stopped by the title blacklist), errors caused by the comment field (think abuse filters that catch profanity in edit summaries, although no wiki I know of does this for moves), and errors caused by none of the above (think the page being move-protected while you have the form loaded).

Thank you for your feedback and for taking the time to analyze this issue. I understand the technical constraints you’ve highlighted, and I appreciate the complexity of distinguishing between different error sources in MediaWiki’s current implementation.

However, as my accessibility specialist colleague pointed out, compliance with WCAG 2.1 Success Criterion 2.4.3 (Focus Order, Level A) requires that, after a form submission with errors, the focus should be programmatically moved to the error message (or error summary). This ensures a logical and meaningful focus order, allowing users—especially those relying on assistive technologies—to return directly to the part of the interface that requires their attention.
As you suggested, adding role="alert" to the error message would be a great first step to ensure it is immediately announced by screen readers like NVDA. This would already significantly improve the experience for users with disabilities, even if the focus management is more complex to implement.

Would it be possible to:

  1. Add role="alert" to the error messages as a quick win?
  2. Explore a solution to move the focus to the error message or the problematic field (even if it’s a generic approach for all form errors) in a future iteration?

This would align MediaWiki with accessibility best practices while acknowledging the current limitations.
Thanks again for your work on this!

I wonder if all "Html::errorBox" calls should use role=alert on the error box ...

(Right now that method has no way of specifying a role)

I wonder if all "Html::errorBox" calls should use role=alert on the error box ...

Yeah i also realised this recently. Seems like a good idea

I wonder if all "Html::errorBox" calls should use role=alert on the error box ...

Yeah i also realised this recently. Seems like a good idea

Codex Message component already follows this – exclusively for error messages.