Checked 8/31/2026 · https://www.heise.de/
4 critical barriern · plus 3 to check.
How is the score formed? (100 starting points)
| {n} of {total} images without an alt attribute | -18 |
| {n} form fields without a recognisable label | -18 |
| {n} link(s) without a recognisable name in the HTML | -18 |
| {n} button(s) without a name in the HTML | -18 |
| No <h1> heading in the delivered HTML | -7 |
| {n} duplicate id attributes | -7 |
| {n} CSS rule{nPlural} with possibly too low text contrast | -7 |
| Result | 7 / 100 |
Perceivable
{n} of {total} images without an alt attribute
Images loaded via JavaScript are not counted here.
img
This is what you should do: Give each <img> an alt: a short description for meaningful images, alt="" for purely decorative ones.
{n} form fields without a recognisable label
Check whether there is an aria-label set via JavaScript.
input, select, textarea
This is what you should do: Link each field to a <label for> element or set aria-label / aria-labelledby. A placeholder alone is not enough.
{n} CSS rule{nPlural} with possibly too low text contrast
Required: 4.5:1 (normal) or 3:1 (large text). With an “assumed page background” the actual background could not be determined reliably — check in the browser if in doubt. Found among others: {examples}
.text-ho-text, .text-yellow-50, .text-heisegrau-50, .text-green-50, .text-red-50
This is what you should do: Darken the text colour or lighten the background until the relevant minimum value is reached. Never use colour as the only distinguishing feature.
Operable
{n} link(s) without a recognisable name in the HTML
Empty links or just an icon/image without alt. An aria-label set via JavaScript is not recognised here.
a
This is what you should do: Add visible link text, or use aria-label or an image with alt for icon links.
{n} button(s) without a name in the HTML
Buttons without text and without an aria-label are mute to screen readers — unless the name is set via JavaScript.
button
This is what you should do: Add button text or set an aria-label.
No <h1> heading in the delivered HTML
Each page should begin with exactly one h1. On pages built via JavaScript the h1 may only appear in the browser — then check in the rendered DOM.
body
This is what you should do: Insert a meaningful <h1> as the first heading (ideally already server-side).
Robust
{n} duplicate id attributes
e.g. {examples}. Breaks label-for and aria links.
[id]
This is what you should do: Assign unique ids.
Next steps
- {n} of {total} images without an alt attribute. Give each <img> an alt: a short description for meaningful images, alt="" for purely decorative ones.
- {n} form fields without a recognisable label. Link each field to a <label for> element or set aria-label / aria-labelledby. A placeholder alone is not enough.
- {n} link(s) without a recognisable name in the HTML. Add visible link text, or use aria-label or an image with alt for icon links.
- {n} button(s) without a name in the HTML. Add button text or set an aria-label.
- No <h1> heading in the delivered HTML. Insert a meaningful <h1> as the first heading (ideally already server-side).
Weekly re-scan, JS-rendered, email on new barriers — coming soon.
Create an accessibility statement →
Method & limits
On 8/31/2026 the HTML that www.heise.de delivers on a first visit without login was checked, plus up to four linked CSS files from the same domain. Checked: colour contrast (from CSS), text alternatives, form labelling, names of controls, heading structure, page title and page language, zoom lock, duplicate ids, positive tabindex values, landmarks.
Not checked: anything that arises via JavaScript, keyboard operability, visible focus, focus order, screen-reader announcement, content behind login, subpages. The automated test finds roughly 20–35% of WCAG breaches — the rest needs a manual check. A snapshot, not a legal decision.
Overlay widgets (accessibility buttons that switch contrast or font size) do not make a site conformant — the barriers found have to be fixed in the source code. Why overlays don't help