The language menu does not say which language each option is written in #64

New issue

Closed

opened 2026-09-06 16:05:56 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-09-06 16:05:56 +00:00

Owner

What is wrong

Every option in the language picker is written in its own language, which is right:

<option value="bg">български — machine translation, awaiting review</option>
<option value="cs">čeština — machine translation, awaiting review</option>
<option value="el">Ελληνικά — machine translation, awaiting review</option>

None of them carries a lang attribute. Counted on the rendered page: 0 options with
lang=.

A screen reader pronounces text with the voice and rules of the page's language, which
base.html declares as the person's current one. So somebody using Postulo in English is
read български with English letter-to-sound rules, and Ελληνικά is very often skipped
entirely or spelled out one character at a time. The list of languages is precisely the
place where somebody who cannot read the current interface language has come to escape it,
and it is the one list where this matters most.

This is WCAG 2.2 success criterion 3.1.2, Language of Parts, level AA — a criterion
Postulo's stated commitment covers, and one axe-core has no rule for, which is why the
suite is green.

Shape

Each option gets lang="<code>". The code is already the option's own value, so this is
a widget that renders lang from the choice rather than new data.
The trailing note — machine translation, awaiting review — is in the interface
language, not the option's, so it must not be inside the lang scope. Either split it
into its own element, or put lang on a <span> around the name only, which means the
picker stops being a bare <select>. A <select> allows lang on <option> and
nothing inside it, so the simplest honest answer is: mark the option with the language's
code and move the review note out of the option text into the field's help, or accept
that four words are read in the wrong voice and mark the option anyway.
The same applies anywhere else a language name appears in its own language: the profile,
and a CV's language field.

Classification

Bug, accessibility. Not breaking.

Depends on

Nothing. #52 adds flags to the same list and should build on whatever shape this settles,
rather than the two being fitted into the option text separately.

## What is wrong Every option in the language picker is written in its own language, which is right: ```html <option value="bg">български — machine translation, awaiting review</option> <option value="cs">čeština — machine translation, awaiting review</option> <option value="el">Ελληνικά — machine translation, awaiting review</option> ``` None of them carries a `lang` attribute. Counted on the rendered page: **0** options with `lang=`. A screen reader pronounces text with the voice and rules of the page's language, which `base.html` declares as the person's current one. So somebody using Postulo in English is read *български* with English letter-to-sound rules, and *Ελληνικά* is very often skipped entirely or spelled out one character at a time. The list of languages is precisely the place where somebody who cannot read the current interface language has come to escape it, and it is the one list where this matters most. This is **WCAG 2.2 success criterion 3.1.2, Language of Parts, level AA** — a criterion Postulo's stated commitment covers, and one axe-core has no rule for, which is why the suite is green. ## Shape - Each option gets `lang="<code>"`. The code is already the option's own value, so this is a widget that renders `lang` from the choice rather than new data. - The trailing note — *machine translation, awaiting review* — is in the **interface** language, not the option's, so it must not be inside the `lang` scope. Either split it into its own element, or put `lang` on a `<span>` around the name only, which means the picker stops being a bare `<select>`. A `<select>` allows `lang` on `<option>` and nothing inside it, so the simplest honest answer is: mark the option with the language's code and move the review note out of the option text into the field's help, or accept that four words are read in the wrong voice and mark the option anyway. - The same applies anywhere else a language name appears in its own language: the profile, and a CV's language field. ## Classification Bug, accessibility. Not breaking. ## Depends on Nothing. #52 adds flags to the same list and should build on whatever shape this settles, rather than the two being fitted into the option text separately.

tiagoagueda added this to the 0.2.0 milestone

2026-09-06 16:05:56 +00:00

tiagoagueda added the

labels

2026-09-06 16:05:56 +00:00

tiagoagueda added a new dependency

2026-09-06 16:05:59 +00:00

#52 Show each language's flag in the language menu