Juno
How it worksExample reportPricing
Start free audit
© Juno
Deutsch
ImprintPrivacyTermsWithdrawal
IndustryBakery chainRehab centresRestaurant chainElectrical contractorOnline shopFood producerMetal engineeringElectronics maker

Real exampleA real German company’s website, checked with the free quick check on 24 Oct 2026. Name and address removed.

Homepage · 24 Oct 2026

reha-zentren.example

Poor overall: 23 things to improve, with Conversion scoring lowest. Start with comfortable body text. Quick audit: only the code-measured checks ran, so design and copy judgement is still missing. 4 checks need a person to confirm.

critical
3
major
5
minor
15
Checked55%quick audit
53of 100Poor3 high-impact fixes you can make in minutes

Scores by audit

If you only do three things

  1. Comfortable body text

    Small text, long lines and tight line spacing tire readers quickly, especially on phones.

    Fix→Set body text to at least 16 px, line length to 45–75 characters (max-width around 65ch) and line height to 1.4–1.6.

  2. Controls announce what they are

    Screen readers announce controls by their name. A button without one is announced as just “button”.

    Fix→Give icon-only buttons and links an aria-label, connect form fields to their <label>, and make sure the accessible name contains the visible text.

  3. Motion can be paused and calmed

    Moving content can make some people dizzy or unable to focus, and flashing can trigger seizures.

    Fix→Add a pause button to anything that moves for more than five seconds, avoid flashing, and turn off non-essential animation under prefers-reduced-motion.

UI

Poor 36/100

UI is where visitors struggle most. I'd start with "comfortable body text".

  • major

    Comfortable body text

    Body text: ≈80 characters per line, line height 1.75 (outside comfortable range). Small text, long lines and tight line spacing tire readers quickly, especially on phones.

    Fix→Set body text to at least 16 px, line length to 45–75 characters (max-width around 65ch) and line height to 1.4–1.6.

    For your developer
    • #c31093 > p · ✓ body 16px (desktop) · ✓ body 16px (mobile) · ✗ ≈80 characters per line · ✗ line height 1.75 · ✓ weight 400

    Matthew Butterick: Practical Typography — line length, point size, line spacing

  • major

    Consistent components

    24 buttons in 7 distinct styles. When buttons come in many styles, visitors can’t tell which action matters most or even what’s clickable.

    Fix→Reduce buttons to three styles (primary, secondary, text) and use each one for the same kind of action everywhere.

    For your developer
    • #search-autocomplete-field · 1× "": rgb(255, 255, 255), radius 4px, weight 400
    • #form_kesearch_searchfield > label.search-toggler > button.btn · 1× "": rgba(0, 0, 0, 0), radius 4px, weight 400
    • div.container > div.row > div.col-12:nth-of-type(1) > div.left-inner-wrap > a.btn-pill · 13× "> Jetzt [brand] finden": rgb(212, 2, 50), radius 20px, weight 500
    • #c9683 > div.info-banner > div > div.info-green-btn > a.btn-pill · 1× "> mehr Info": rgb(8, 115, 35), radius 20px, weight 500

    Jakob Nielsen, NN/g: 10 Usability Heuristics for User Interface Design

  • minor

    Interactions feel direct

    0% of tested controls respond the moment they're pressed. Buttons that react a moment late feel unresponsive, even if the site is fast.

    Fix→Show a pressed state immediately (:active), open menus from the element that triggered them, and use CSS transitions so animations can be interrupted.

    For your developer
    • #header > div.anniversary-banner:nth-of-type(1) > a · "30 Jahre [brand] – Jetzt mitfeiern und gewinnen!": no change until release
    • #header > div.header-inner:nth-of-type(2) > div.logo-col:nth-of-type(1) > a · "": no change until release
    • #[brand] > ul.nav > li.hover-item:nth-of-type(2) > a · "Angebot [brand] Gruppe": no change until release
    • #[brand] > ul.nav > li.hover-item:nth-of-type(3) > a · "Antrag & Info": no change until release

    Apple: Designing Fluid Interfaces (WWDC 2018)

  • minor

    A deliberate type scale

    1 font family, 10 sizes, 90% on a consistent scale. Too many font sizes and families make a page feel unplanned and blur the difference between a heading and body text.

    Fix→Pick two families at most and a scale of six to eight sizes (for example 14, 16, 20, 25, 31, 39 px), then map every text style onto it.

    For your developer
    • font families (excl. icons): 1
    • distinct font sizes: 10 (target 8)
    • sizes on a modular scale: 90 %
    • Families: Roboto

    Adam Wathan & Steve Schoger: Refactoring UI — hierarchy, spacing systems, limited palettes

  • minor

    Spacing on a system

    57% of spacing values sit on a 5 px grid; text aligns to 16 left edges. Random spacing makes a layout feel slightly off even when visitors can’t say why.

    Fix→Choose a spacing base (4 or 8 px), define a short set of steps (8, 16, 24, 32, 48, 64), and replace one-off values with the nearest step.

    For your developer
    • spacing on 5 px grid: 57 % (target 80)
    • distinct left text edges: 16 (target 4)

    Adam Wathan & Steve Schoger: Refactoring UI — hierarchy, spacing systems, limited palettes

Accessibility

Poor 47/100

Accessibility is where visitors struggle most. I'd start with "controls announce what they are".

  • critical

    Controls announce what they are

    2 controls without a usable accessible name or valid ARIA (label-content-name-mismatch). Screen readers announce controls by their name. A button without one is announced as just “button”.

    Fix→Give icon-only buttons and links an aria-label, connect form fields to their <label>, and make sure the accessible name contains the visible text.

    For your developer
    • a[target=""][href$="long-covid"][data-loc="Startseite"] · "&gt; mehr Info": Text inside the element is not included in the accessible name
    • a[target=""][href$="reha-antrag"][data-loc="Startseite"] · "&gt; Anträge &amp; Infos": Text inside the element is not included in the accessible name

    WCAG 2.2 SC 4.1.2, 2.5.3

  • critical

    Motion can be paused and calmed

    Content moves on its own (1 element) with no pause or stop control. Moving content can make some people dizzy or unable to focus, and flashing can trigger seizures.

    Fix→Add a pause button to anything that moves for more than five seconds, avoid flashing, and turn off non-essential animation under prefers-reduced-motion.

    For your developer
    • animations at load: 20
    • with reduced motion: 0
    • #swiper-container-137 > div.swiper-wrapper:nth-of-type(1) · Changes on its own (4× in 6 s)

    WCAG 2.2 SC 2.2.2, 2.3.1

  • critical

    Everything works with a keyboard

    40 interactive elements are not reachable with the keyboard. People who can’t use a mouse rely on the keyboard. Anything they can’t reach is something they can’t use.

    Fix→Use real <button> and <a href> elements for anything clickable, don’t remove them from the tab order, and add a “Skip to content” link.

    For your developer
    • focus stops: 1
    • unreachable controls: 40 (target 0)
    • backward jumps: 0 (target 1)
    • #header > div.anniversary-banner:nth-of-type(1) > a · Not reachable with Tab: "30 Jahre [brand] – Jetzt mitfeiern und gewinnen!"

    WCAG 2.2 SC 2.1.1, 2.1.2

  • major

    Structure is real, not just visual

    No main landmark; screen-reader users can't jump to the content. Screen reader users jump by headings and landmarks. A page without real structure is one long stream.

    Fix→Use one <h1>, nest headings in order (h2 under h1, h3 under h2), and wrap the page in <header>, <nav>, <main> and <footer>.

    For your developer
    • h1 count: 1 (target 1)

    WCAG 2.2 SC 1.3.1, 1.3.2

  • minor

    Targets are easy to hit

    6 tap target(s) smaller than 24×24 px and crowded by neighbours. Small, tightly packed targets are hard to hit for people with limited dexterity and for everyone on a phone.

    Fix→Make every clickable target at least 24 × 24 px (44 px for main actions), or leave enough space around smaller ones.

    For your developer
    • #form_kesearch_searchfield > label.search-toggler > button.btn · 16×24px: "button"
    • #swiper-container-137 > div.swiper-pagination:nth-of-type(4) > span.swiper-pagination-bullet:nth-of-type(1) · 8×8px: "span"
    • #swiper-container-137 > div.swiper-pagination:nth-of-type(4) > span.swiper-pagination-bullet:nth-of-type(2) · 8×8px: "span"
    • #swiper-container-137 > div.swiper-pagination:nth-of-type(4) > span.swiper-pagination-bullet:nth-of-type(3) · 8×8px: "span"

    WCAG 2.2 SC 2.5.8, 2.5.1

  • minor

    Forms can be completed by everyone

    5 field(s) labelled only for screen readers, with no visible label; 4 personal-data field(s) without autocomplete. Error handling needs the judge stage. Forms are where accessibility problems cost you leads and sales directly.

    Fix→Give every field a visible label, mark required fields in text, link error messages to their field, and use the right autocomplete attributes.

    For your developer
    • #search-autocomplete-field · Label only for screen readers (aria-label): "Search"
    • #powermail_field_receiver · Label only for screen readers (aria-label): "Ihre Angabe auswählen"
    • #powermail_field_vorname · Label only for screen readers (aria-label): "Vorname*"
    • #powermail_field_vorname · Personal-data field without autocomplete: "Vorname*"

    WCAG 2.2 SC 3.3.1, 3.3.2

SEO

Needs work 61/100

SEO needs some love. I'd start with "core web vitals in the green".

  • major

    Core Web Vitals in the green

    Lab data: LCP 4569 ms, CLS 0.00, Total Blocking Time 9 ms. Slow, jumpy pages rank lower and lose visitors before they load.

    Fix→Shrink and preload the largest above-the-fold image, defer non-critical JavaScript, and reserve space for images and embeds to stop layout shift.

    For your developer
    • LCP (lab, mobile): 4569.02 ms (target 2500)
    • CLS: 0 (target 0.1)
    • Total Blocking Time (lab, stands in for INP): 9 ms (target 200)

    web.dev: Core Web Vitals thresholds (LCP 2.5 s, INP 200 ms, CLS 0.1)

  • minor

    Structured data for what the business is

    No structured data found; search engines have to guess what the business is. Structured data tells search engines what your business is and can earn richer search results.

    Fix→Add JSON-LD for your business type (Organization, LocalBusiness, Product or Article) with name, logo, contact details and links, and validate it in Google’s Rich Results Test.

    For your developer
    • JSON-LD blocks: 0

    Google Search Central: Structured data general guidelines

  • minor

    Looks right when shared

    Missing og:title, og:description, og:image; shared links will look bare. Links shared without a preview image and description get far fewer clicks.

    Fix→Add og:title, og:description and a 1200 × 630 px og:image to every key page, and check them with a link preview tool.

    For your developer
    • No og:title
    • No og:description
    • No og:image

    Google Search Central: SEO Starter Guide

  • minor

    Images are light and described

    Image delivery can improve: Improve image delivery (Est savings of 676 KiB). Heavy images slow every page, especially on mobile data.

    Fix→Serve images as WebP or AVIF at the size they are shown, set width and height, and add loading="lazy" to images below the fold.

    For your developer
    • Improve image delivery (Est savings of 676 KiB)

    Google Search Central: SEO Starter Guide

Copy

Good 82/100

Copy is solid with a few rough edges. I'd start with "c3 · about the reader, not the company".

  • minor

    C3 · About the reader, not the company

    Homepage says "you" 15× and "we" 21×. Visitors care about their problem, not your company. Copy full of “we” reads like it’s about you.

    Fix→Rewrite key sections from the visitor’s side: lead with “you” and what they get, then say what you do.

    For your developer
    • reader words: 15
    • company words: 21

    Government Digital Service: GOV.UK content design: writing for the web

  • minor

    C5 · Plain, readable language

    Harder to read than needed: Amstad 28 (aim ≥ 60). Long sentences and difficult words lose readers, including experts reading on a phone.

    Fix→Aim for sentences under 20 words, prefer everyday words, write in the active voice, and explain any jargon the first time it appears.

    For your developer
    • Amstad (Flesch, German): 28.03
    • average sentence length: 18.33 words (target 20)

    plainlanguage.gov: Federal Plain Language Guidelines

Conversion

Not checked yet 23% measured

Conversion is where visitors struggle most. I'd start with "fast on a phone".

  • major

    Fast on a phone

    Landing page: LCP 4.6 s, 4.8 MB on mobile. Later funnel steps are measured by the funnel walk. On phones, every extra second of loading costs conversions.

    Fix→Get mobile LCP under 2.5 s and pages under 2 MB: compress images, cut unused scripts and fonts, and lazy-load what’s below the fold.

    For your developer
    • LCP (mobile, lab): 4569.02 ms (target 2500)
    • page weight: 4.81 MB (target 2)

    web.dev: Core Web Vitals thresholds (LCP 2.5 s, INP 200 ms, CLS 0.1)

  • minor

    Conversions can be measured

    No analytics found, so conversions cannot be measured or improved. Without measurement you can’t tell which changes help, so improvements become guesswork.

    Fix→Install privacy-friendly analytics and track your key actions (button clicks, form submissions, bookings) as conversion events.

    For your developer
    • analytics hosts: 0

    Corey Haines (marketingskills): cro, signup, popups and offers skills

  • minor

    Forms ask only what they need

    contact form asks for 8 fields; 8 field(s) without the right keyboard type. Every extra form field lowers completion, and wrong field types make phones show the wrong keyboard.

    Fix→Ask only for what you need now (five fields or fewer for a lead form), mark optional fields, and use type="email"/"tel" with autocomplete.

    For your developer
    • #c32567 > div.tx-powermail > div.container-fluid > form.powermail_form · Ihre Angabe auswählen*, Vorname**, Nachname**, E-Mail-Adresse**, Ihre Nachricht, Mit d…
    • #powermail_field_receiver · type="select-one" for "Ihre Angabe auswählen"
    • #powermail_field_vorname · type="text" for "Vorname*"
    • #powermail_field_vornamename · type="text" for "Nachname*"

    Baymard Institute: Checkout usability research (guest checkout, form field count)

UX

Not checked yet 36% measured

UX needs some love. I'd start with "you always know where you are".

  • minor

    You always know where you are

    No consistent way back to the homepage. Without a “you are here” cue, visitors who arrive from search or a shared link can’t tell where they are or how to get back.

    Fix→Mark the current page in the menu (and add aria-current="page"), link the logo to the homepage on every page, and add breadcrumbs on pages three or more levels deep.

    For your developer
    • pages where nav marks the current page: 0 of 0
    • No home link in the header on some pages

    Jakob Nielsen, NN/g: 10 Usability Heuristics for User Interface Design

  • minor

    Visitors stay in control

    1 element(s) change on their own; whether visitors can pause them, and how overlays close, needs the judge stage. Content that moves on its own, or overlays that are hard to close, take control away from visitors. They read more slowly than carousels advance.

    Fix→Let visitors pause or stop anything that changes by itself, make overlays closable with a close button, Escape and a click outside, and keep the Back button working.

    For your developer
    • #swiper-container-137 > div.swiper-wrapper:nth-of-type(1) · 4 changes in 6 s without input

    Jakob Nielsen, NN/g: 10 Usability Heuristics for User Interface Design

  • minor

    Mobile is a first-class experience

    First action 0.1 screens down; 2 key button(s) under 44px tall. Most visits are on phones. Small tap targets and actions pushed far down make the mobile site feel second-class.

    Fix→Make primary buttons at least 44 px tall, bring the main action into the first screen on mobile, and check that nothing overflows sideways.

    For your developer
    • #header > div.header-inner:nth-of-type(2) > div.nav-col-mobile:nth-of-type(2) > button.navbar-toggler · First prominent action "" at 0.1 screens down, 20×22px
    • #header > div.header-inner:nth-of-type(2) > div.nav-col-mobile:nth-of-type(2) > button.navbar-toggler · 22px tall: ""
    • div.container > div.row > div.col-12:nth-of-type(1) > div.left-inner-wrap > a.btn-pill · 35px tall: "> Jetzt [brand] finden"

    NN/g: Mobile UX guidelines (touch targets, content priority)

Your 30-minute plan

0 of 11 done

Small fixes with a big pay-off. Tick them off as you go.

That's it from me. Make a few changes, run me again, and I'll tell you what moved.

Run your own audit