Skip to content

feat(ARC-3818): configure labels on the overzichtsblok - #372

Open
RobbeBierebeeck wants to merge 8 commits into
release/v6.0.0from
feature/ARC-3818_overview-block-labels
Open

feat(ARC-3818): configure labels on the overzichtsblok#372
RobbeBierebeeck wants to merge 8 commits into
release/v6.0.0from
feature/ARC-3818_overview-block-labels

Conversation

@RobbeBierebeeck

@RobbeBierebeeck RobbeBierebeeck commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Content page labels get a background colour, and the labels selected on an overzichtsblok are drawn over the item images as generated visual labels.

Admin — required "Achtergrondkleur" on the label form (default white), a preview chip in the overview table right of "Aangepast op", and a swatch on the detail page. No preview for FAQ_ITEM labels: an faq overview block renders accordions, so there is no thumbnail to draw a label over.

Block — the labels already selected in the block config get a chip flush in the top left of the item image, on every item style that renders one. Grid, news list and project list draw one; the accordion styles render whole content pages and have no image.

Everything is gated on isHetArchief(), block rendering included — PAGE_OVERVIEW is a shared block and avo labels have no colour, so avo renders exactly as before.

Requires hetarchief-hasura#410 to be deployed first. That migration adds color text not null default '#FFF', which is where the FA's "verplicht, default = wit" is actually enforced — the DTO leaves color optional because avo shares it, and existing labels come back as white until someone sets a colour. Expect existing overzichtsblokken with labels selected to show white chips right after deploy.

No new block configuration: the FA points at the labels already selected on the block ("Bij het configureren van deze blok voegen we nu de contentpagina labels toe die we willen zien in het overzichtblok"), so those are the ones drawn.

Robbe Bierebeeck added 5 commits August 7, 2026 11:59
Content page labels get a background colour, and the labels already selected
on an overzichtsblok are drawn over the item images as generated visual labels,
so meemoo no longer has to bake them into the thumbnail by hand.

The colour is required with a white default and is picked from the archief
background colours, minus the entries that are not a flat css fill. Only
hetarchief has the column, so every colour touchpoint is gated on isHetArchief.

The chips are gated behind a new showLabelsOnImage checkbox that defaults to
off, so existing overview blocks are unchanged until an editor opts in.

The design fixes the label text to white, but that fails WCAG AA on 14 of the
16 allowed colours, white on white worst of all. The FA requires that every
colour is allowed, that the default is white, and that the labels are "altijd
goed gevisualiseerd", so the text colour follows the background instead. A test
asserts every colour in the picker meets AA.
The FA is leading over the design and over the earlier scoping, so three things
move back in line with it.

The showLabelsOnImage checkbox is gone. The FA has no such toggle: the labels
selected on the block are drawn, full stop. Existing overview blocks that
already have labels selected will start showing them, which is the intent.

The label is drawn on every item style that renders an image, not only on the
grid, since the FA says it appears "bovenop de afbeeldingen van een blogposts
of pagina's" without restricting the item style.

The overview table only previews a label for the content types that get a
visual label. The FA shows nothing when none is available, "e.g. voor
FAQ-items", and describes the label as belonging to blogposts and pages.

Still narrower than the FA on one point: "alle kleuren zijn toegestaan" links a
list that includes Geen, meemoo logo and the black/white gradient. None of
those is a flat fill, so a chip using them renders no background at all, which
contradicts the FA's own requirement that the labels are always well
visualised. The picker keeps the 16 real colours; raised with Philip.
Comment thread api/src/modules/content-page-labels/services/content-page-labels.service.ts Outdated
Comment thread ui/src/react-admin/modules/content-page-labels/views/ContentPageLabelDetail.scss Outdated
Comment thread ui/src/react-admin/modules/content-page-labels/views/ContentPageLabelDetail.tsx Outdated
Comment thread ui/src/react-admin/modules/content-page-labels/views/ContentPageLabelEdit.tsx Outdated
Comment thread ui/src/react-admin/modules/content-page/const/get-color-options.ts Outdated
Comment on lines +157 to +168
/**
* The label background colours that get white text instead of black, following the rule meemoo set:
* black text on the colour, unless white text on that colour passes WCAG AA. Of the archief
* background colours only these two clear 4.5:1 against white: black (21:1) and old pink (4.87:1,
* the "Pareltjes" label). The chip text is 1.6rem/700, so the 3:1 large text threshold does not
* apply. https://meemoo.atlassian.net/browse/ARC-3818
*
* Deliberately not GET_DARK_BACKGROUND_COLOR_OPTIONS: that list predates the rule and would put
* white on e.g. ocean green, which only reaches 2.13:1.
*/
export const CONTENT_PAGE_LABEL_COLORS_WITH_WHITE_TEXT: string[] = [Color.Black, Color.OldPink];

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ik zou dit nog niet implementeren omdat we van JN nog een lijst gaan krijgen. Voorlopig mogen de kleuren gewoon blijven zoals ze zijn. We gaan dit voor meerdere blokken nog moeten goed zetten

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants