fix(a11y): increase annotation toggle touch target to 44×44px minimum #354

New Issue

marcel · 2026-04-26T21:26:51+02:00

marcel commented

2026-04-26 21:26:51 +02:00

Problem

The annotation toggle button in PdfControls.svelte uses px-2 py-1 which computes to approximately 28×24px — below the 44×44px minimum required by WCAG 2.2 and the project's own standard for its 60+ transcriber audience.

This was surfaced as a pre-existing issue during the PR #349 review by Leonie Voss (UI/UX).

Affected file

frontend/src/lib/components/PdfControls.svelte — the annotation toggle button (lines 89–123 in the PR #349 state).

Acceptance Criteria

The annotation toggle button has a minimum touch target of 44×44px
Existing visual appearance is preserved (text + icon layout unchanged)
A unit test asserts the button carries min-h-[44px] or equivalent

Proposed fix

class="flex items-center gap-1.5 rounded px-3 py-2 min-h-[44px] font-sans text-xs transition {showAnnotations
    ? 'text-ink-2 hover:bg-surface/10'
    : 'bg-surface/10 text-primary'}"

Changing px-2 py-1 → px-3 py-2 min-h-[44px] increases the tap area to comply with the project standard.

Background

Raised by Leonie Voss in PR #349 review
Original fix PR: #349 (issue #341 — contrast fix)
Project audience: 60+ users transcribing Kurrent/Sütterlin letters on laptops/tablets

## Problem The annotation toggle button in `PdfControls.svelte` uses `px-2 py-1` which computes to approximately 28×24px — below the 44×44px minimum required by WCAG 2.2 and the project's own standard for its 60+ transcriber audience. This was surfaced as a pre-existing issue during the PR #349 review by Leonie Voss (UI/UX). ## Affected file `frontend/src/lib/components/PdfControls.svelte` — the annotation toggle button (lines 89–123 in the PR #349 state). ## Acceptance Criteria - [ ] The annotation toggle button has a minimum touch target of 44×44px - [ ] Existing visual appearance is preserved (text + icon layout unchanged) - [ ] A unit test asserts the button carries `min-h-[44px]` or equivalent ## Proposed fix ```svelte class="flex items-center gap-1.5 rounded px-3 py-2 min-h-[44px] font-sans text-xs transition {showAnnotations ? 'text-ink-2 hover:bg-surface/10' : 'bg-surface/10 text-primary'}" ``` Changing `px-2 py-1` → `px-3 py-2 min-h-[44px]` increases the tap area to comply with the project standard. ## Background - Raised by Leonie Voss in PR #349 review - Original fix PR: #349 (issue #341 — contrast fix) - Project audience: 60+ users transcribing Kurrent/Sütterlin letters on laptops/tablets

marcel added the P2-medium bug ui labels 2026-04-26 21:26:57 +02:00

marcel referenced this issue

2026-04-26 21:27:04 +02:00

fix(viewer): fix "Annotieren anzeigen" contrast and add lint rule (#341) #349

marcel commented

2026-05-07 17:48:51 +02:00

👩‍🎨 Leonie Voss — UI/UX Design Lead & Accessibility Strategist

Observations

The annotation toggle at px-2 py-1 with a text-xs label and a h-3.5 w-3.5 icon renders at approximately 28×24 px — well below the WCAG 2.2 §2.5.8 minimum of 44×44 px. This is a Critical accessibility failure for the 60+ transcriber audience using laptops and tablets.
The proposed fix (px-3 py-2 min-h-[44px]) is correct and matches the pattern already used in BackButton.svelte, ConfirmDialog.svelte, and Pagination.svelte.
The four icon-only buttons (prev, next, zoom-in, zoom-out) each use rounded p-1 with a h-4 w-4 (16 px) icon, producing a ~24×24 px tap area. These are also below the 44 px floor and need the same treatment — this issue scopes them out, but they are the same violation in the same file.
The annotation toggle is a stateful toggle (show/hide), but it lacks aria-pressed. Screen readers will announce it as a generic button with no indication that it represents an on/off state. The aria-label text compensates partly, but aria-pressed is the correct semantic.
The nav button aria-label values (Zurück, Weiter, Verkleinern, Vergrößern) are hardcoded German strings — not wired through Paraglide. This is a pre-existing issue, not introduced here, but worth flagging while the file is open.

Recommendations

Apply the proposed fix exactly as written in the issue body — px-3 py-2 min-h-[44px] on the annotation toggle. Also add min-w-[44px] to guard against the button becoming too narrow when the label is very short in any locale.
Add aria-pressed={showAnnotations} to the annotation toggle button. This communicates toggled state to screen readers without relying on the label text changing.
While in the file, raise the icon-only buttons to min-h-[44px] min-w-[44px] p-2 — the visual change is imperceptible (icon is centered) but the tap area doubles. Open a separate micro-issue if you want to keep this PR atomic.
Replace the four hardcoded German aria-label strings with Paraglide message calls — but file that as a separate cleanup issue rather than expanding this one.

Open Decisions

Scope of this fix: The issue targets only the annotation toggle. The four icon-only buttons are the same violation. Accept the narrow scope and create a follow-up, or widen the fix now? Given the file is already being touched, widening costs three lines and avoids a second PR on the same file.

## 👩‍🎨 Leonie Voss — UI/UX Design Lead & Accessibility Strategist ### Observations - The annotation toggle at `px-2 py-1` with a `text-xs` label and a `h-3.5 w-3.5` icon renders at approximately 28×24 px — well below the WCAG 2.2 §2.5.8 minimum of 44×44 px. This is a **Critical** accessibility failure for the 60+ transcriber audience using laptops and tablets. - The proposed fix (`px-3 py-2 min-h-[44px]`) is correct and matches the pattern already used in `BackButton.svelte`, `ConfirmDialog.svelte`, and `Pagination.svelte`. - The four icon-only buttons (prev, next, zoom-in, zoom-out) each use `rounded p-1` with a `h-4 w-4` (16 px) icon, producing a ~24×24 px tap area. These are **also** below the 44 px floor and need the same treatment — this issue scopes them out, but they are the same violation in the same file. - The annotation toggle is a stateful toggle (show/hide), but it lacks `aria-pressed`. Screen readers will announce it as a generic button with no indication that it represents an on/off state. The `aria-label` text compensates partly, but `aria-pressed` is the correct semantic. - The nav button `aria-label` values (`Zurück`, `Weiter`, `Verkleinern`, `Vergrößern`) are hardcoded German strings — not wired through Paraglide. This is a pre-existing issue, not introduced here, but worth flagging while the file is open. ### Recommendations - Apply the proposed fix exactly as written in the issue body — `px-3 py-2 min-h-[44px]` on the annotation toggle. Also add `min-w-[44px]` to guard against the button becoming too narrow when the label is very short in any locale. - Add `aria-pressed={showAnnotations}` to the annotation toggle button. This communicates toggled state to screen readers without relying on the label text changing. - While in the file, raise the icon-only buttons to `min-h-[44px] min-w-[44px] p-2` — the visual change is imperceptible (icon is centered) but the tap area doubles. Open a separate micro-issue if you want to keep this PR atomic. - Replace the four hardcoded German `aria-label` strings with Paraglide message calls — but file that as a separate cleanup issue rather than expanding this one. ### Open Decisions - **Scope of this fix**: The issue targets only the annotation toggle. The four icon-only buttons are the same violation. Accept the narrow scope and create a follow-up, or widen the fix now? Given the file is already being touched, widening costs three lines and avoids a second PR on the same file.

marcel commented

2026-05-07 17:49:04 +02:00

👨‍💻 Felix Brandt — Fullstack Developer

Observations

The fix is a two-token swap: px-2 py-1 → px-3 py-2 min-h-[44px]. The diff is trivial and the proposed class string in the issue body is ready to paste.
The existing spec file (PdfControls.svelte.spec.ts) covers annotation visibility, label text, and contrast class — but has no test asserting the min-h-[44px] class. The acceptance criterion says "a unit test asserts the button carries min-h-[44px]," so the test needs to be added. The pattern from PersonMentionEditor.svelte.spec.ts applies directly:

it('annotation toggle has min-h-[44px] touch target (WCAG 2.2)', async () => {
  const { container } = render(PdfControls, {
    ...defaultProps,
    annotationCount: 2,
    showAnnotations: false
  });
  const btn = Array.from(container.querySelectorAll('button')).find((b) =>
    b.getAttribute('aria-label')?.toLowerCase().includes('annotierungen')
  );
  expect(btn).not.toBeNull();
  expect(btn!.className).toContain('min-h-[44px]');
});

The spec uses vitest-browser-svelte + render — this fits the existing pattern in the file perfectly.
I notice the four icon-only buttons (p-1, ~24 px) violate the same rule. They are out of scope for this issue, but should be tracked separately.
$props() destructuring and type annotation are correct Svelte 5 style. No rune issues.

Recommendations

Write the failing test first (red), then apply the class change (green). The acceptance criterion is explicit — do not apply the fix before the test exists.
Keep the test in the existing describe block structure, or add a new describe('PdfControls — touch targets', ...) block to group the WCAG-related assertions.
Do not use waitFor or expect.element for a className check — a synchronous DOM query after render is sufficient and faster (matches the project's established pattern for class assertions in this file).

## 👨‍💻 Felix Brandt — Fullstack Developer ### Observations - The fix is a two-token swap: `px-2 py-1` → `px-3 py-2 min-h-[44px]`. The diff is trivial and the proposed class string in the issue body is ready to paste. - The existing spec file (`PdfControls.svelte.spec.ts`) covers annotation visibility, label text, and contrast class — but has **no test asserting the `min-h-[44px]` class**. The acceptance criterion says "a unit test asserts the button carries `min-h-[44px]`," so the test needs to be added. The pattern from `PersonMentionEditor.svelte.spec.ts` applies directly: ```typescript it('annotation toggle has min-h-[44px] touch target (WCAG 2.2)', async () => { const { container } = render(PdfControls, { ...defaultProps, annotationCount: 2, showAnnotations: false }); const btn = Array.from(container.querySelectorAll('button')).find((b) => b.getAttribute('aria-label')?.toLowerCase().includes('annotierungen') ); expect(btn).not.toBeNull(); expect(btn!.className).toContain('min-h-[44px]'); }); ``` - The spec uses `vitest-browser-svelte` + `render` — this fits the existing pattern in the file perfectly. - I notice the four icon-only buttons (`p-1`, ~24 px) violate the same rule. They are out of scope for this issue, but should be tracked separately. - `$props()` destructuring and type annotation are correct Svelte 5 style. No rune issues. ### Recommendations - Write the failing test first (red), then apply the class change (green). The acceptance criterion is explicit — do not apply the fix before the test exists. - Keep the test in the existing `describe` block structure, or add a new `describe('PdfControls — touch targets', ...)` block to group the WCAG-related assertions. - Do not use `waitFor` or `expect.element` for a className check — a synchronous DOM query after `render` is sufficient and faster (matches the project's established pattern for class assertions in this file).

marcel commented

2026-05-07 17:49:14 +02:00

🏗️ Markus Keller — Application Architect

Observations

This is a pure UI change confined to a single leaf component (PdfControls.svelte). No architectural boundaries are crossed, no new routes or packages are introduced, and no backend changes are required. There is nothing architecturally significant to flag.
The fix and its test live correctly in frontend/src/lib/document/viewer/ — the right domain package for a PDF viewer control component.
The doc-update checklist from my working rules: this change does not add a route, a backend package, a Flyway migration, a new error code, or a Docker service. No diagram update is needed. The checklist is clean.

Recommendations

Accept the change as-is from an architecture standpoint. The fix is well-scoped and does not introduce coupling or abstraction debt.
If the four icon-only buttons are also fixed (as Leonie recommends), the same verdict applies — still no architectural concern.
No ADR required for a WCAG touch target fix.

## 🏗️ Markus Keller — Application Architect ### Observations - This is a pure UI change confined to a single leaf component (`PdfControls.svelte`). No architectural boundaries are crossed, no new routes or packages are introduced, and no backend changes are required. There is nothing architecturally significant to flag. - The fix and its test live correctly in `frontend/src/lib/document/viewer/` — the right domain package for a PDF viewer control component. - The doc-update checklist from my working rules: this change does not add a route, a backend package, a Flyway migration, a new error code, or a Docker service. No diagram update is needed. The checklist is clean. ### Recommendations - Accept the change as-is from an architecture standpoint. The fix is well-scoped and does not introduce coupling or abstraction debt. - If the four icon-only buttons are also fixed (as Leonie recommends), the same verdict applies — still no architectural concern. - No ADR required for a WCAG touch target fix.

marcel commented

2026-05-07 17:49:27 +02:00

🔒 Nora "NullX" Steiner — Application Security Engineer

Observations

No security surface is affected by this change. The annotation toggle is a pure client-side visibility toggle (showAnnotations prop) — it does not perform API calls, modify data, or expose privileged information.
The aria-label driven by m.pdf_annotations_hide() / m.pdf_annotations_show() (Paraglide) is safe — these are compile-time string lookups, not user-controlled input.
One general hygiene note: accessible interfaces are more secure because users understand what an action does before triggering it. A too-small button that is accidentally tapped (especially by senior users on touch devices) is a minor safety concern for destructive UI patterns. This toggle is non-destructive, so the risk is low here, but the principle is why touch target standards matter beyond pure compliance.

Recommendations

No security action required for this fix.
Proceed with the change; it has no negative security implications.

## 🔒 Nora "NullX" Steiner — Application Security Engineer ### Observations - No security surface is affected by this change. The annotation toggle is a pure client-side visibility toggle (`showAnnotations` prop) — it does not perform API calls, modify data, or expose privileged information. - The `aria-label` driven by `m.pdf_annotations_hide()` / `m.pdf_annotations_show()` (Paraglide) is safe — these are compile-time string lookups, not user-controlled input. - One general hygiene note: accessible interfaces are more secure because users understand what an action does before triggering it. A too-small button that is accidentally tapped (especially by senior users on touch devices) is a minor safety concern for destructive UI patterns. This toggle is non-destructive, so the risk is low here, but the principle is why touch target standards matter beyond pure compliance. ### Recommendations - No security action required for this fix. - Proceed with the change; it has no negative security implications.

marcel commented

2026-05-07 17:49:46 +02:00

🧪 Sara Holt — QA Engineer & Test Strategist

Observations

The existing PdfControls.svelte.spec.ts covers three describe blocks: visibility, label text, and contrast class. The touch target is not currently tested — the third acceptance criterion (A unit test asserts the button carries min-h-[44px]) is unmet.
The existing touch target pattern in PersonMentionEditor.svelte.spec.ts (checking className.toContain('min-h-[44px]')) is the correct model. The test for PdfControls should follow the same shape.
The spec uses container.querySelectorAll('button') + getAttribute('aria-label') to locate the annotation button — this works and is already used in the contrast test in the same file. Consistency is good.
The test should be written before the production fix (TDD). The test failing on the current px-2 py-1 class proves it is meaningful.
This is a vitest-browser-svelte test (real Chromium DOM). A plain className string check does not require async expect.element — synchronous after render is fine, as proven by the contrast test at line 53–66 of the existing spec.

Recommendations

Add one test case to the existing spec:

describe('PdfControls — touch targets (WCAG 2.2)', () => {
  it('annotation toggle button carries min-h-[44px]', async () => {
    const { container } = render(PdfControls, {
      ...defaultProps,
      annotationCount: 2,
      showAnnotations: false
    });
    const allButtons = container.querySelectorAll('button');
    const annotationBtn = Array.from(allButtons).find((b) =>
      b.getAttribute('aria-label')?.toLowerCase().includes('annotierungen')
    );
    expect(annotationBtn).not.toBeNull();
    expect(annotationBtn!.className).toContain('min-h-[44px]');
  });
});

Run the test before applying the fix — confirm it is red (min-h-[44px] absent from px-2 py-1). Apply the fix. Confirm green.
No new E2E test is warranted for this change — the class assertion at the unit layer is the right level. E2E for this would be over-engineering a one-token diff.

## 🧪 Sara Holt — QA Engineer & Test Strategist ### Observations - The existing `PdfControls.svelte.spec.ts` covers three describe blocks: visibility, label text, and contrast class. The touch target is **not currently tested** — the third acceptance criterion (`A unit test asserts the button carries min-h-[44px]`) is unmet. - The existing touch target pattern in `PersonMentionEditor.svelte.spec.ts` (checking `className.toContain('min-h-[44px]')`) is the correct model. The test for `PdfControls` should follow the same shape. - The spec uses `container.querySelectorAll('button')` + `getAttribute('aria-label')` to locate the annotation button — this works and is already used in the contrast test in the same file. Consistency is good. - The test should be written **before** the production fix (TDD). The test failing on the current `px-2 py-1` class proves it is meaningful. - This is a vitest-browser-svelte test (real Chromium DOM). A plain className string check does not require async `expect.element` — synchronous after `render` is fine, as proven by the contrast test at line 53–66 of the existing spec. ### Recommendations - Add one test case to the existing spec: ```typescript describe('PdfControls — touch targets (WCAG 2.2)', () => { it('annotation toggle button carries min-h-[44px]', async () => { const { container } = render(PdfControls, { ...defaultProps, annotationCount: 2, showAnnotations: false }); const allButtons = container.querySelectorAll('button'); const annotationBtn = Array.from(allButtons).find((b) => b.getAttribute('aria-label')?.toLowerCase().includes('annotierungen') ); expect(annotationBtn).not.toBeNull(); expect(annotationBtn!.className).toContain('min-h-[44px]'); }); }); ``` - Run the test before applying the fix — confirm it is red (`min-h-[44px]` absent from `px-2 py-1`). Apply the fix. Confirm green. - No new E2E test is warranted for this change — the class assertion at the unit layer is the right level. E2E for this would be over-engineering a one-token diff.

marcel commented

2026-05-07 17:50:03 +02:00

🚀 Tobias Wendt — DevOps & Platform Engineer

Observations

This is a frontend-only, zero-infrastructure change. No Docker Compose modifications, no CI workflow changes, no new services or volumes.
The test runs in vitest-browser-svelte (Playwright/Chromium). CI already handles this test layer. No new tooling or runner configuration is needed.
The existing npm run test invocation in CI picks up new spec content automatically — no pipeline changes needed.

Recommendations

No DevOps action required. Approve and merge when tests are green.
If the four icon-only buttons are fixed in the same PR (as discussed), the CI impact is still zero — same test runner, same pipeline.

## 🚀 Tobias Wendt — DevOps & Platform Engineer ### Observations - This is a frontend-only, zero-infrastructure change. No Docker Compose modifications, no CI workflow changes, no new services or volumes. - The test runs in vitest-browser-svelte (Playwright/Chromium). CI already handles this test layer. No new tooling or runner configuration is needed. - The existing `npm run test` invocation in CI picks up new spec content automatically — no pipeline changes needed. ### Recommendations - No DevOps action required. Approve and merge when tests are green. - If the four icon-only buttons are fixed in the same PR (as discussed), the CI impact is still zero — same test runner, same pipeline.

marcel commented

2026-05-07 17:50:23 +02:00

📋 Elicit — Requirements Engineer

Observations

The issue is well-specified: problem statement, affected file + line range, three acceptance criteria, a concrete proposed fix with the class delta, and audience context. It meets the Definition of Ready on all counts.
AC-1 ("minimum touch target of 44×44 px") — measurable, verifiable via class assertion.
AC-2 ("existing visual appearance is preserved") — this is testable in principle but the spec does not include a visual regression snapshot. For this change the risk is low (adding padding does not break layout), but it is worth noting.
AC-3 ("a unit test asserts min-h-[44px]") — the criterion is clear and implementation-ready.
One requirement gap: the aria-pressed semantic for the toggle state is not mentioned. The button communicates its state through changing label text, which is WCAG-compliant, but aria-pressed would be the more semantically precise solution per ARIA Authoring Practices. This is a "should" improvement, not a blocker.
A second gap: the four icon-only navigation buttons (prev, next, zoom-in, zoom-out) have the same 24 px touch area and the same audience. The issue deliberately scopes them out, but no follow-up issue is referenced. This is a requirements debt item.
The hardcoded German aria-label strings on nav buttons ("Zurück", "Weiter", "Verkleinern", "Vergrößern") are not i18n-compliant. Same file, pre-existing, not in scope — but should be tracked.

Recommendations

Accept the issue scope as written. The fix is small and the AC are testable.
Add aria-pressed to the acceptance criteria as a "should" (not "must") to improve semantic correctness without blocking the fix.
Create a follow-up issue titled fix(a11y): increase touch targets on PdfControls nav and zoom buttons to close the gap on the remaining four buttons in the same component.
Create a separate micro-issue for the hardcoded German aria-label strings so they are tracked rather than forgotten.

Open Decisions

aria-pressed scope: include in this issue as an additional AC, or file separately? Given the file is being touched anyway and the change is two tokens (aria-pressed={showAnnotations}), folding it in costs almost nothing and closes a real semantics gap.

## 📋 Elicit — Requirements Engineer ### Observations - The issue is well-specified: problem statement, affected file + line range, three acceptance criteria, a concrete proposed fix with the class delta, and audience context. It meets the Definition of Ready on all counts. - **AC-1** ("minimum touch target of 44×44 px") — measurable, verifiable via class assertion. - **AC-2** ("existing visual appearance is preserved") — this is testable in principle but the spec does not include a visual regression snapshot. For this change the risk is low (adding padding does not break layout), but it is worth noting. - **AC-3** ("a unit test asserts `min-h-[44px]`") — the criterion is clear and implementation-ready. - One requirement gap: the `aria-pressed` semantic for the toggle state is not mentioned. The button communicates its state through changing label text, which is WCAG-compliant, but `aria-pressed` would be the more semantically precise solution per ARIA Authoring Practices. This is a "should" improvement, not a blocker. - A second gap: the four icon-only navigation buttons (prev, next, zoom-in, zoom-out) have the same 24 px touch area and the same audience. The issue deliberately scopes them out, but no follow-up issue is referenced. This is a requirements debt item. - The hardcoded German `aria-label` strings on nav buttons (`"Zurück"`, `"Weiter"`, `"Verkleinern"`, `"Vergrößern"`) are not i18n-compliant. Same file, pre-existing, not in scope — but should be tracked. ### Recommendations - Accept the issue scope as written. The fix is small and the AC are testable. - Add `aria-pressed` to the acceptance criteria as a "should" (not "must") to improve semantic correctness without blocking the fix. - Create a follow-up issue titled `fix(a11y): increase touch targets on PdfControls nav and zoom buttons` to close the gap on the remaining four buttons in the same component. - Create a separate micro-issue for the hardcoded German `aria-label` strings so they are tracked rather than forgotten. ### Open Decisions - **`aria-pressed` scope**: include in this issue as an additional AC, or file separately? Given the file is being touched anyway and the change is two tokens (`aria-pressed={showAnnotations}`), folding it in costs almost nothing and closes a real semantics gap.

marcel commented

2026-05-07 17:50:52 +02:00

🗳️ Decision Queue

Two open decisions were raised across the review. Both are genuine tradeoffs needing human judgment.

1. Scope: fix only the annotation toggle, or also the four icon-only buttons?

Raised by: Leonie (UX), Sara (QA), Tobias (DevOps)

The four nav/zoom buttons (p-1, ~24 px) have the same WCAG 2.2 §2.5.8 violation as the annotation toggle. Fixing them in this PR costs three lines of Tailwind changes and no additional test overhead (class-level assertions). Deferring means a second PR touching the same file.

Options:

A (wider) — Fix all five buttons now. Keeps the codebase consistent, avoids a second PR on the same file. The PR title and AC would need updating.
B (as scoped) — Fix only the annotation toggle per the current issue. Create a follow-up issue for the four nav/zoom buttons immediately on merge.

2. `aria-pressed`: fold into this issue or file separately?

Raised by: Leonie (UX), Elicit (RE)

The annotation toggle lacks aria-pressed={showAnnotations}. Adding it is two tokens in the template and closes a genuine ARIA semantics gap (the button conveys its state through label text changes today, which is functional but not the ARIA Authoring Practices recommendation for toggle buttons). No new test is needed — the existing label-based assertions remain valid.

Options:

A (fold in) — Add aria-pressed={showAnnotations} to this PR. AC-1 and AC-2 are unaffected; AC-3 could optionally assert aria-pressed too. Low risk, minimal diff.
B (separate) — File a micro-issue and defer. Keeps this PR strictly minimal.

These items do not block the core fix. The class change and its test can be implemented under any combination of these decisions.

## 🗳️ Decision Queue Two open decisions were raised across the review. Both are genuine tradeoffs needing human judgment. --- ### 1. Scope: fix only the annotation toggle, or also the four icon-only buttons? **Raised by:** Leonie (UX), Sara (QA), Tobias (DevOps) The four nav/zoom buttons (`p-1`, ~24 px) have the same WCAG 2.2 §2.5.8 violation as the annotation toggle. Fixing them in this PR costs three lines of Tailwind changes and no additional test overhead (class-level assertions). Deferring means a second PR touching the same file. **Options:** - **A (wider)** — Fix all five buttons now. Keeps the codebase consistent, avoids a second PR on the same file. The PR title and AC would need updating. - **B (as scoped)** — Fix only the annotation toggle per the current issue. Create a follow-up issue for the four nav/zoom buttons immediately on merge. --- ### 2. `aria-pressed`: fold into this issue or file separately? **Raised by:** Leonie (UX), Elicit (RE) The annotation toggle lacks `aria-pressed={showAnnotations}`. Adding it is two tokens in the template and closes a genuine ARIA semantics gap (the button conveys its state through label text changes today, which is functional but not the ARIA Authoring Practices recommendation for toggle buttons). No new test is needed — the existing label-based assertions remain valid. **Options:** - **A (fold in)** — Add `aria-pressed={showAnnotations}` to this PR. AC-1 and AC-2 are unaffected; AC-3 could optionally assert `aria-pressed` too. Low risk, minimal diff. - **B (separate)** — File a micro-issue and defer. Keeps this PR strictly minimal. --- _These items do not block the core fix. The class change and its test can be implemented under any combination of these decisions._

marcel referenced a pull request that will close this issue

2026-05-09 15:50:08 +02:00

fix(a11y): increase PdfControls touch targets to 44×44px (#354) #493

marcel commented

2026-05-09 15:50:18 +02:00

Implemented in PR #493 (fix/issue-354-annotation-touch-target), commit d4abe994.

Changes:

All 5 PDF viewer buttons now carry min-h-[44px] min-w-[44px] (WCAG 2.2 §2.5.8)
Icon-only buttons: p-1 → p-2 min-h-[44px] min-w-[44px]
Annotation toggle: px-2 py-1 → px-3 py-2 min-h-[44px] min-w-[44px]
aria-pressed={showAnnotations} added to annotation toggle (ARIA 1.2 toggle semantics)

Tests added: 5 new assertions in the WCAG 2.2 §2.5.8 suite — min-h/min-w for each button type + aria-pressed state.

Implemented in PR #493 (`fix/issue-354-annotation-touch-target`), commit `d4abe994`. **Changes:** - All 5 PDF viewer buttons now carry `min-h-[44px] min-w-[44px]` (WCAG 2.2 §2.5.8) - Icon-only buttons: `p-1` → `p-2 min-h-[44px] min-w-[44px]` - Annotation toggle: `px-2 py-1` → `px-3 py-2 min-h-[44px] min-w-[44px]` - `aria-pressed={showAnnotations}` added to annotation toggle (ARIA 1.2 toggle semantics) **Tests added:** 5 new assertions in the WCAG 2.2 §2.5.8 suite — min-h/min-w for each button type + aria-pressed state.

marcel referenced this issue

2026-05-09 15:51:41 +02:00

fix(a11y): increase PdfControls touch targets to 44×44px (#354) #493

marcel referenced this issue

2026-05-09 15:51:52 +02:00

fix(a11y): increase PdfControls touch targets to 44×44px (#354) #493

marcel referenced this issue

2026-05-09 15:56:40 +02:00

fix(a11y): increase PdfControls touch targets to 44×44px (#354) #493

marcel closed this issue

2026-05-09 16:09:21 +02:00

Sign in to join this conversation.