Skip to content

The menu can be read - #893

Merged
sridharkalaibala merged 1 commit into
developfrom
fix/the-menu-can-be-read
Sep 18, 2026
Merged

sridharkalaibala merged 1 commit into
developfrom
fix/the-menu-can-be-read

Conversation

@sridharkalaibala

Copy link
Copy Markdown
Contributor

The first accessibility pass over the customer pages. It leaves behind a ratchet rather than a one-off, because contrast is the thing that regresses silently: a colour is always chosen by eye, and the eye choosing it is looking at a good screen in a well-lit room.

One value was wrong

#0f8a3d, used for "ok" and for the veg marker on both pages, is 4.45:1 on white against the 4.5:1 that AA asks of body text.

Close enough that nobody would notice by looking, and either side of a line that is not a judgement call. It is #0e8038 now - 5.04:1, and the same green to look at.

What was already right, checked rather than assumed

  • every other text colour on both pages clears AA, in both themes
  • the menu's dark palette is comfortable: nothing under 6.9:1
  • the language attribute is correct. I suspected this one - the pages ship lang="en" and switch to Tamil at runtime, which would have a screen reader read Tamil in an English voice. It turns out i18n.js overwrites it at load, and the toggle reloads rather than swapping text in place, so it can never disagree with the words on screen. I was wrong, and checking was the right call
  • focus styles exist, reduced motion is honoured, images carry alt text, buttons carry labels, and the sort radios are wrapped in their labels rather than orphaned

The test checks its own arithmetic

A contrast test with a wrong formula passes everything, so it verifies itself against known WCAG values: black on white is 21:1, white on white is 1:1, and #767676 on white is the canonical 4.54:1.

What is still missing, and is not a colour

/order has no dark mode at all while /menu has one. A menu read across a dinner table in the evening is the common case, and the ordering page is the one people spend longer on.

That is a real gap and I have not built it: adding a second theme to a five-thousand-line stylesheet wants somebody watching it render, not a ratio. Named here rather than guessed at.

Checks

  • 6 new tests; root suite 2,961 of 2,964 (the three need frontend/public built, which CI does); check-locally.js all 7 pass

The first accessibility pass over the customer pages, and it leaves behind
a ratchet rather than a one-off. Contrast is the thing that regresses
silently: a colour is always chosen by eye, and the eye choosing it is
looking at a good screen in a well-lit room.

ONE VALUE WAS WRONG. `#0f8a3d`, used for "ok" and for the veg marker on
both pages, is 4.45:1 on white against the 4.5:1 that AA asks of body text.
Close enough that nobody would notice by looking, and either side of a line
that is not a judgement call. It is #0e8038 now - 5.04:1, and the same
green to look at.

WHAT WAS ALREADY RIGHT, and I checked rather than assumed:

  - every other text colour on both pages clears AA, in both themes
  - the menu's dark palette is comfortable: nothing under 6.9:1
  - the language attribute is set from the chosen language at load, and the
    toggle RELOADS rather than swapping text in place, so it can never
    disagree with the words on screen. I suspected this one and was wrong
  - focus styles exist, reduced motion is honoured, images carry alt text,
    buttons carry labels, and the sort radios are wrapped in their labels
    rather than orphaned

The test checks its own arithmetic against known WCAG values, because a
contrast test with a wrong formula passes everything.

WHAT IS STILL MISSING, and is not a colour: /order has no dark mode at all
while /menu has one. A menu read across a dinner table in the evening is
the common case, and the ordering page is the one people spend longer on.
That wants somebody watching it render, not a ratio, so it is named here
rather than guessed at.
@sridharkalaibala
sridharkalaibala merged commit f6275c7 into develop Sep 18, 2026
9 checks passed
@github-actions github-actions Bot added the ready for QA Merged to develop and live on develop.posnic.io - anyone can test it label Sep 18, 2026
@github-actions

Copy link
Copy Markdown
Contributor

Merged to develop. Anyone can test this - you do not need write access.

Try it at https://develop.posnic.io, or run it yourself:

git fetch origin develop && git checkout develop
npm install && npm --prefix api install
npm run dev   # then http://localhost:3000

When you have tested it, say what you did and what happened, and set
QA passed or QA failed. If you cannot set labels, just comment -
a maintainer will.

Reporting that something is broken is as useful as fixing it. It is
better found here than by a shopkeeper.

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

Labels

ready for QA Merged to develop and live on develop.posnic.io - anyone can test it

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant