fix(a11y): accessibility fixes across the ui, and an accessible show password button

[BatLeDev]

Accessibility fixes on the pages served by simple-directory, coming from the RGAA re-audit of a customer portal, plus two regressions of the Vuetify 4 upgrade found along the way.

Also closes the "show the password behind an eye icon" ticket, which turned out to belong here.

Login page

• the logo alternative was the generic Site logo i18n string, it now uses the site title when there is one (RGAA 1.7)
• the served document had no <title>, only the one the SPA sets at runtime, so the W3C validator rejected it. The built index.html now carries a {SITE_TITLE} placeholder filled by the site title, HTML-escaped before injection. title is optional on the site schema, so an empty one falls back to the default rather than producing <title></title>
• vite injects <meta property="csp-nonce" nonce="…"> for html.cspNonce without the content attribute the HTML spec requires next to property, the second error the validator reported. A small transformIndexHtml plugin adds it (RGAA 8.2)
• the three fields that all carried id="password" get a unique id, they sit in the DOM at the same time inside the window items

Showing the password

The login password field had no way to reveal what was typed, and the two new password fields relied on a bare v-icon with a click handler: an <i> element, so not focusable, not operable with a keyboard, with no accessible name and no state restitution. The two confirmation fields had nothing at all and shared their reveal state with the field above them.

A new password-reveal component now sits in the append-inner slot of the five password fields. It renders a real <button type="button">, carries a title and a matching aria-label that follow the state, and states the new state in a screen reader only live region without ever exposing the password itself.

Deliberately no re-masking after a delay, which the ticket suggested. RGAA has no criterion on revealing a password, and the only one that speaks about delays is 13.1, "l'utilisateur a-t-il le contrôle de chaque limite de temps modifiant le contenu" (WCAG 2.2.1 / 2.2.2) — an unrequested timer works against it, and five seconds is not enough to re-read a long password. No re-masking on blur either, since blur fires when reaching for the button. The password is re-masked when the form is submitted, which is what the GOV.UK component does, and the DSFR password component has no timer either.

Account page

• the email address was displayed in a disabled field, dimmed to 38% opacity, dropping its contrast well below 4.5:1. It is now readonly, which keeps it readable and focusable, with a hint saying it cannot be changed (RGAA 3.2)
• the avatar image had no alt attribute (RGAA 1.1)

The page keeps starting its titles at h2: it is always embedded in an iframe, the h1 belongs to the host page.

Organization page

• the four menus opened by a v-fab (create a department, edit the departments, invite a partner organization) had no accessible name: v-fab renders a <div> root and only forwards the props v-btn declares, so title and the menu activator's v-bind="props" (aria-haspopup, aria-expanded, id, the click handler) all landed on that wrapper. The button was neither named nor keyboard operable. They go back to v-btn, like the invite member button right next to them, which was already correct (RGAA 7.1, 7.3)
• the organization, department, member and partner avatars were v-img without alt, so img elements with no alt attribute at all (RGAA 1.1)

Naming every icon-only button

An icon-only button has no text content, so its accessible name came from the title attribute alone. That is only the last resort of the accessible name computation and auditors flag it, while the tooltip stays useful to sighted users, so both are kept: 35 buttons get an aria-label mirroring their title.

Five buttons on the admin pages had neither, so no accessible name at all: editing a user email, dropping a user 2FA, editing the created orgs quota, and opening an organization from the two organization tables. They are named from the labels their own dialogs already use, plus a new common.seeTitle.

Translations

Reviewing the aria-label above surfaced one that mirrored a title holding a raw french string, so the six locale files and every template literal went through an audit.

The locale files themselves had no gap, but they did hold one wrong value: api/i18n/pt.js carried the french htmlCaption of one of the login mails, while the very same sentence sits translated fourteen lines above it in that same file. Portuguese users received a bilingual mail. Found by diffing long values that stayed identical to the french ones.

The templates held literals that never went through i18n at all:

• the contact page, which any user can reach, had its three field labels, its send button and its success message written in french, and its heading pointed at common.createOrganization, so the contact page announced "create an organization"
• the three invitation menus labelled their redirect select in french while common.redirectSite was already translated in the six locales right there, unused
• the password lists page had its two help paragraphs, its file input label, its list subtitles and its delete confirmation in french, plus a $t('charger') that is not a key path and resolved to nothing
• the sites admin table had the raw Se connecter sur le site on the login button

Every one of them now goes through a key present in the six locales. The tree is checked by an audit that asserts no key is missing in any direction, no template literal is left in a title / label / aria-label / placeholder / subtitle, no $t() call is missing its key path, and no long value stayed identical to the french one: 394 keys, six locales, no gap.

Vuetify 4 upgrade leftovers

• the 2FA roles select and the members role filter were fed the raw role keys (admin, contrib, user) while the readable labels sit right next to them in rolesLabels, which the same page even lets you edit. Both now build their items from those labels, with the configured defaults as fallback, and the role shown under each member follows
• the upgrade replaced the removed default uppercase on buttons with text-transform: capitalize, which capitalizes every word: "Renouveler Le Mot De Passe". The rule is dropped and buttons render their label as written. That left the main action buttons inconsistent, four carrying an inline text-transform: uppercase and six none at all, so on the login page a single button stood out in capitals. Every bottom right action button is uppercase again, through the text-uppercase utility class: no inline styles and no text-transform declaration of our own left in the ui

Security

The site title reaches the served HTML through getSiteExtraParams, which microTemplate applies before the CSP_NONCE pass, so a title holding the literal {CSP_NONCE} came back with the request nonce inside <title>. And microTemplate interpolates via String.replace, so $&, $` and $' in a title were read as replacement patterns. { is neutralized and $ doubled alongside the existing HTML escaping.