Before, when autosaving a draft, removing a repetition row would
send `_destroy` inputs to the controller – but not remove the row
from the DOM. This led to the `_destroy` inputs being sent again
on the next autosave request, which made the controller raise
(because the row fields were already deleted before).
To fix this, we let the controller response remove the deleted
row(s) from the DOM.
Doing it using a controller response avoids the need to keep track
of operations on the Javascript side: the controller can easily
know which row was just deleted, and emit the relevant changes for
the DOM. This keeps the autosave requests robust: even if a request
is skipped (e.g. because of a network interruption), the next request
will still contain the relevant informations to succeed, and not let the
form in an unstable state.
Fix#5470
- in the 'N° de dossier' column for mouse users and screen reader users.
- in the 'Démarche' column for mouse users, screen reader users and keyboard users.
Also added a sr-only class for text which should be read by screen-readers but not visible or accessible to other users
In Sentry, when an `ActionController::InvalidAuthenticityToken` error
occurs, the breadcrumbs mention that before hitting the error, the user
clicked on one of those links.
Unfortunately we don't know which one. For debugging purposes, adding
classes to the links should allow us to see which links users are
navigating to.
We use a placeholder (which is not made for this, but we have reasons to do that)
so using a visible labels or paragraph duplicates the information
I picked aria-describedby, which is not the ideal solution (it seems to be aria-labelledby) but which is the most widely supported
https://www.w3.org/WAI/tutorials/forms/instructions/#using-aria-describedby
When navigating away from the page, the field receives the 'focusout'
event – but stops to be present in the DOM.
Thus we need to check that the DOM element is actually present.
