`kessai_views` takes the `<caption>` off the screen on its four listings and leaves it in the page, for a reason its stylesheet states at length and is right about: > The caption is the table's accessible name, and the summary is what a screen reader is offered in place of a glance at the shape of the table; neither is furniture to somebody who cannot see the headers sitting below. So they stay in the markup and leave the screen, which is what visually-hidden is for. What is inside that caption is not only text. All four shipped views set a non-empty `summary`, and `ViewsThemeHooks::preprocessViewsViewTable()` turns a non-empty summary into ```php $variables['summary_element'] = [ '#type' => 'details', '#title' => $handler->options['summary'], ... ]; ``` which `views-view-table.html.twig` renders inside the `<caption>`. So each caption holds a `<details>`, and `<summary>` is in the tab order natively. ## What a keyboard user meets Tabbing through *Payments*, *Claims*, *Refunds* or *Reversals*, focus lands on the disclosure control for the table summary. The rule that hides it is core's `.visually-hidden` written out: ```css position: absolute !important; overflow: hidden; clip: rect(1px, 1px, 1px, 1px); width: 1px; height: 1px; ``` so the focused control is one pixel square, clipped, and out of flow. There is nothing on screen to see, anywhere. That is **WCAG 2.1 AA 2.4.7 Focus Visible**: focus moves to a control with no visible indicator. Pressing Enter expands a `<details>` that stays invisible, so the keyboard user is now two tab stops into content they cannot see and were never shown. The module ships for institutional sites, where this is a legal requirement rather than a preference. ## The first resolution, and why it was the wrong layer `system/css/components/hidden.module.css` does not stop at `.visually-hidden`. It carries `.visually-hidden.focusable:focus-within` immediately below, for exactly a hidden thing that can take focus, and that rule was added to the four caption selectors. It works: the caption returns to the flow while the disclosure holds focus, measured in Chrome at `static`, 87x130, `clip: auto`. It also leaves a keyboard user tabbing onto a control, watching a caption appear, pressing Enter, and being shown nothing - because `description` is empty on all four views, so the `details` opens onto nothing at all. The premise the hiding rested on was wrong too. The stylesheet called the summary *"what a screen reader is offered in place of a glance at the shape of the table"*. That was true of HTML4's `summary` **attribute**, which was screen-reader-only and is obsolete in HTML5. The views `summary` option is not that attribute: core renders it as a visible `details`, to everyone. And WCAG requires neither - 1.3.1 wants programmatically determinable structure, which `<th scope="col">` already gives; `<caption>` (H39) and the old attribute (H73) are sufficient techniques, never requirements. ## Resolution The control should not be there, so it is not. - `summary` is removed from all four views. `caption` stays: it names the table, and it is what keeps the caption rendering at all. What the summary said was the column names, which are the table headers on the next line. - The `:focus-within` rule goes with it. Nothing inside the caption can take focus any more, and a selector that can never match is a rule nobody can explain. - The four French catalogue entries for those sentences are removed, so the catalogue keeps no orphans. - `assertTableIsNamedAndSaysWhenEmpty()` asserts there is no summary **and** no description, since core builds the disclosure from either. Verified against a rendered listing: the caption is still there, still says *Payments*, and holds no `details` and no `summary`. Pre-1.0 with no update hooks, so this lands on fresh installs; an installed site needs the four views updated by hand. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)