Help where the question is asked: a field's in a tooltip, a card's behind a question mark that opens a drawer #302
Labels
No labels
accessibility
authentication
breaking change
bug
documentation
enhancement
interface
internationalisation
observability
performance
security
tier
1
tier
2
tier
3
tier/4
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Postulo/postulo#302
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
From the interface review of 2026-09-29. The rule asked for, for every page:
circle-question-mark) in its top corner, at the inline end. Hovering over it shows one sentence. Clicking it opens a drawer at the inline end holding the full help for that card, taken from the wiki.Your details is where this was asked for card by card, so it is the first page to do: Your picture (with the accepted files and the limits), Your name, Contact block, Telephone numbers, Social profiles, Code repositories, Websites, Postal addresses and Identifiers. For the last six, the sentence under the card's title may be what the tooltip replaces.
What is there today
help_textdrawn by<c-field-feedback>and named in the control'saria-describedby. Nothing is hidden, and a screen reader reads it with the field.<c-section-title>, or a<p>under a<legend>on Your details.tooltip.css, anddrawer.csswithdrawer.js.What Basecoat's pieces do, and what they do not
[data-tooltip="…"]draws the attribute's text in a::before: one line, truncated, on hover only. It is hidden on:focus-visible, so a keyboard never shows it. Screen readers do not reliably read a pseudo-element's generated text. Nothing dismisses it with Escape, and a phone has no hover. WCAG 2.2 1.4.13 (content on hover or focus) asks for the opposite on every count. So the text has to be an element in the page, reachable by focus and by touch, named byaria-describedby, and dismissible. That could be Basecoat's look painted onto something else, or the Popover API anchored with CSS anchor positioning, using its fallback positions for "wherever there is room" and a fixed side where a browser has none.<dialog>that its script opens. With scripts off, the question mark has to be a link to a page holding the same text, which the script opens in the drawer instead. A menu here works the same way: it is a<details>first.tests/test_template_lint.pyrefuses a physical side.Decisions to take
Which help moves into a tooltip. A sentence saying what a field is for can move. A format the field requires (a date, an IBAN, "the whole address is fine") is an instruction, which WCAG 3.3.2 wants available before the mistake; behind a hover it is out of sight for everybody who does not think to look for it. Proposal: the tooltip takes the explanation and the format stays visible. Either way, the text stays in the DOM as the field's description.
Where the drawer's text comes from. The wiki is a separate repository, written in English, and not part of an installed instance. Fetching it at run time would mean a self-hosted server calling this Forgejo, an outage whenever it is down, and help nobody can translate. The options are:
The first keeps the promise that the interface speaks the reader's language; the second keeps a single copy of the text. The rest of this issue waits on this decision.
A card with nothing more to say gets no question mark. An icon that opens the same sentence the tooltip gave is a control that does nothing.
Done when
CONTRIBUTING.mdsays when to use which, so the next page follows the rule without having to ask.Decided (2026-09-29): the help is written as templates in the application, translated through the catalogues like every other string, and the wiki points at the same text. Nothing is fetched from the wiki at run time, and nothing is bundled from it.