Questions forms should implement browser's built-in HTML5 client side Validation Form's API by avoiding to submit the page if validation is unsuccessful.

1. Not really for LimeSurvey, except for one or two questions. Because when submit : data are saved
2. It's really another issue here : must be reported as a separate issue
3. Must use JS heavily due to relevance etc … You can test with https://gitlab.com/SondagesPro/SurveyThemes/skelvanilla/-/blob/master/scripts/aria-live.js?ref_type=heads done for 5.X, i have to adapt it for 6.X …

I'm globally against « Page must not be reloaded if validation can't pass. » if we can not disable it.

Hello Denis, thanks for caring of a11y.
I guess having client-side validation not sending the form, can be an issue for intermediate-saving of responses. But, from a blind perspective, and in general UX speaking, the context must vary the less possible.

If client-side validation brings to a extremely hard work, I also agree a negotiable solution can be found.
The main problem here, is the behavior of the screen-reader to read the whole page also if nothing has changed (because validation brought back you to the same page). The risk is to have participant stuck, in a loop, for not provided reason.

The goal is to having warnings and solving suggestions read before the whole page reloaded.
In this actual situation, the modal window is set too late in the page, at bottom body and probably never get read (also is not accessible).

Modal window is a parallel layer, who extract you from reading the context. In this situation is a wrong UI/UX component.
If the page gets the whole reloaded, then role="alert" message must be inline in the context at first in the <main> area context.
So that by reloading the page, can be read at first glance. (also the <title> should be altered accordingly, i guess)

When using REACT/VUE frontend app frameworks, you have no reload of the page, although data can be saved asynchronously by API requests to backend.
This is not the situation. Page gets the whole reloaded and read from scratch.

In my opinion, the less expensive fix is to keep the reloading page and move alerts on top.
Otherwise page validation change and saving must happen asynchronous, without reloading the context just giving feedback of local-side warnings.

This is an example of accessible modal window (in italian)
https://italia.github.io/bootstrap-italia/docs/componenti/modale/#scroll-di-contenuti-allinterno-della-modale

But, from a blind perspective, and in general UX speaking, the context must vary the less possible.

Yes, i know, it's the reason why i add it in skelvanilla :)

The main problem here, is the behavior of the screen-reader to read the whole page also if nothing has changed (because validation brought back you to the same page). The risk is to have participant stuck, in a loop, for not provided reason.

I'm totally OK here :)

1. Title must be updated and add Error infprmation (you have an error when submit
2. Best is to have a list of link to error, but can be complex
3. Minimal : show "There are error " in page (option in skelvanilla)
4. If show a modal dialog box : it must be accessible

This is an example of accessible modal window (in italian)

Minimal (really minimal) update :
We must follow https://www.w3.org/WAI/ARIA/apg/patterns/alertdialog/examples/alertdialog/ and set the focus to the dialog box when come back to this page.

I just found "vanilla" theme options have room for "inline" (at-page) warnings. This makes disappear the anti a11y modal window.

immagine.png (8,342 bytes)   

immagine.png (8,342 bytes)   

I just found "vanilla" theme options have room for "inline" (at-page) warnings. This makes disappear the anti a11y modal window.

It's OK ? It work ?

PS : still : the dialog A11Y bug must be foxed in vanilla and twentythree :)