kubernetes / kubernetes/website

Homepage: hamburger button has no accessible name (4.1.2); dark-mode link contrast is 2.77:1 (1.4.3)

Open
#56,924 2 comments 0 reactions 0 assignees View on GitHub
kind/bug needs-triage
Dominant language
HTML
Stars
5.4k
Forks
15.7k
Avg merge
4d 18h
Merged PRs (30d)
204

Description

**This is a Bug Report**

Two accessibility defects on the homepage. Both are invisible to a desktop, light-mode scan, which is why I suspect they have survived: one element is `display: none` above the mobile breakpoint, and the other only changes colour under `prefers-color-scheme: dark`.

**Problem:**

**1. The mobile navigation button has no accessible name — WCAG 4.1.2 Name, Role, Value (Level A)**

```html

```

The button is empty. No text content, no `aria-label`, no `aria-labelledby`, no `title`, no child image. The icon is drawn by Font Awesome through a CSS `::before` pseudo-element, and CSS-generated content is not reliably exposed to assistive technology — so a screen reader announces this as just "button".

On a phone this is the only way to reach the site navigation.

Verified with `getComputedStyle` at two widths: at 1280px the element is present but not visible; at 390px it is visible. So an automated check that only ever renders a desktop viewport cannot see it.

**2. Link contrast in dark mode is 2.77:1 — WCAG 1.4.3 Contrast Minimum (Level AA)**

Under `prefers-color-scheme: dark`, links in the body render as `rgb(50, 108, 229)` on `rgb(48, 48, 48)`. Measured ratio **2.77:1**.

| Link | Font | Required | Actual |
|---|---|---:|---:|
| "Kubernetes" (`a[href$="overview/"]`) | 14px / 400 | 4.5:1 | 2.77:1 |
| "download" (`a[href$="download/"]`) | 14px / 400 | 4.5:1 | 2.77:1 |
| "Case Studies" (`a[href$="case-studies/"]`) | 24px / 500 | 3:1 (large text) | 2.77:1 |

The same blue passes comfortably in light mode against the white background, so this is specifically a dark-palette regression. The same colour is used on the case-study links (`/case-studies/babylon/`, `booz-allen`, `booking-com`, `appdirect`).

**Proposed Solution:**

1. Give the button an accessible name, e.g. `aria-label="Open navigation menu"` (or a visually hidden span), and consider `aria-expanded` reflecting the toggle state.
2. Lighten the link colour used under `prefers-color-scheme: dark` so it clears 4.5:1 against `#303030`. The colour is the brand blue `#326ce5` used unchanged, which measures 2.77:1 on `#303030`. As reference points on that background: `#6fa8ff` is 5.48:1, `#82b5ff` is 6.29:1, `#8ec0ff` is 7.00:1.

**Page to Update:**
https://kubernetes.io/

---

Found while running axe-core across several user-preference states rather than just the default one, as part of a small study of 36 public homepages. Happy to open a PR for either fix if that is useful — just say which.

I have not checked whether these repeat on inner pages; the scan covered homepages only.

Contributor guide

Open the contributing guide

Research direction

Start at the homepage source and locate the #hamburger button plus the dark-mode link styles described in the report. Verify the mobile button has an accessible name and that links meet the stated contrast ratio against #303030, then rerun the accessibility checks at mobile and dark-mode viewport or preference states.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, html
Domain
accessibility, frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.