Eine Website ohne ein einziges For­mu­lar

Für wen gebaut wird

Wer hier auf die Website kommt, ist meistens über 60, hat oft ein älteres Gerät, und kleinere Schrift ist ein Problem. Eine Stadtteilapotheke, keine Kette; im Viertel ein hoher Anteil an Menschen mit Migrationsgeschichte.

Der Umsatz einer Apotheke hängt weit überwiegend an verschreibungspflichtigen Arzneimitteln, und die entstehen beim Arzt — daran ändert eine Website nichts, weil über den Weg des Rezepts die Entfernung entscheidet. Die Seite ist deshalb nicht als Neukundenmaschine angelegt, sondern auf Bindung: Vorbestellung, Botendienst, Auffindbarkeit.

Daraus folgen kleine Dinge mit großer Wirkung. Die Telefonnummer steht im Kopf als Wählverknüpfung, auch auf dem Handy sichtbar und nicht im Menü versteckt: Anrufen ist bei einer Apotheke keine Nebenaktion. Die acht Beratungssprachen des Teams stehen auf der Seite, formuliert ohne Verfügbarkeitszusage, weil nicht jederzeit jede Sprache besetzt ist — im Viertel ein stärkeres Vertrauenssignal als jedes Foto. Und die Sprache bleibt konkret: „Rezept vorbestellen“, nicht „digitale Arzneimittelversorgung“.

Keine Ge­sund­heits­da­ten

Im öffentlichen Bereich der Website gibt es kein einziges Formular. Rezepte, Vorbestellungen und E-Rezepte laufen ausschließlich über die Plattform des Partners.

Ein eigener Rezept-Upload hätte Gesundheitsdaten nach Art. 9 DSGVO auf den Server der Apotheke gebracht: Verschlüsselung bei Übertragung und Speicherung, Zugriffs- und Löschkonzept, Eintrag im Verarbeitungsverzeichnis, Auftragsverarbeitungsvertrag, wahrscheinlich eine Datenschutz-Folgenabschätzung. Dazu die apothekerliche Schweigepflicht nach § 203 StGB, die den Hoster zur mitwirkenden Person macht.

Ausschlaggebend war aber die Wartungsperspektive. Die Apotheke pflegt die Seite selbst, mit minimaler Betreuung. Ein System, das Rezeptfotos vorhält, braucht dauerhafte Aufmerksamkeit: Aktualisierungen, Überwachung, im Ernstfall eine Meldung an die Aufsichtsbehörde binnen 72 Stunden.

Eine unbetreute Website mit Gesundheitsdaten ist die Kombination, die irgendwann teuer wird.

Aus derselben Überlegung gibt es kein Kontaktformular. Es hätte Menschen dazu verleitet, Beschwerden hineinzuschreiben — dieselben Daten auf demselben Server, nur durch die Hintertür. Bei der E-Mail-Adresse steht stattdessen der Hinweis auf den richtigen Weg: Portal oder Telefon.

Bar­rie­re­frei­heit als Ziel­set­zung

Barrierefreiheit war hier nicht durch die Auftragslage erzwungen. Sie wurde als Zielsetzung gesetzt, weil die Nutzerschaft sie braucht. Was daraus wurde, ist messbar:

• Fließtext mindestens 18 Pixel, Zeilenhöhe 1,6
• Kontrast im Fließtext mindestens 7:1 — der Wert, den die WCAG für die höchste ihrer drei Stufen nennt, nicht das übliche Mindestmaß
• Klickflächen mindestens 48 Pixel
• vollständig per Tastatur bedienbar, Fokus jederzeit sichtbar
• reduzierte Bewegung wird respektiert
• semantisches HTML, genau eine Hauptüberschrift je Seite
• geprüft bei 320, 360 und 375 Pixeln Breite sowie bei 200 Prozent Zoom

Auch die Schriftwahl ist funktional: Für den Fließtext läuft Atkinson Hyperlegible, eine Schrift, die für Menschen mit eingeschränktem Sehvermögen gezeichnet wurde.

Ein Detail zeigt, wie weit das reicht. Deutsche Komposita wie „Kompressionsstrümpfe“ passen auf schmalen Bildschirmen in keine Zeile, und der Browser brach sie ohne Trennstrich um. Die Regel lautet jetzt: Ein Wort, das nicht passt, bricht mit Trennstrich, nie ohne. Dafür muss die Sprachauszeichnung stimmen, sonst trennt der Browser nach englischen Regeln an den falschen Stellen.

Der 360-Grad-Rundgang ist nach denselben Maßstäben gebaut. Der Szenenwechsel läuft über beschriftete Schaltflächen statt über schwebende Pfeile in der Kugel — für einen 75-Jährigen ist ein benannter Knopf auffindbar, ein Symbol nicht. Der Betrachter ist keine Tastaturfalle. Die verwendete Bibliothek schaltet den Fokusring auf ihrem eigenen Element ab; er wurde zurückgeholt, sonst säße man unsichtbar darin.

Keine Anfrage an Dritte

Beim Aufruf der Seite geht keine einzige Anfrage an einen Dritten hinaus. Das ist eine Anforderung, die durchgehend eingehalten und automatisiert überwacht wird.

• Schriften selbst gehostet. Das dynamische Einbinden von Google Fonts ist in Deutschland abgemahnt worden.
• Keine eingebettete Karte, sondern ein Foto und ein Verweis auf den Routenplaner. Ein Link überträgt beim Seitenaufruf nichts.
• Der 360-Grad-Rundgang läuft auf eigenem Server, aus eigenen Panoramen, mit einer selbst gehosteten Bibliothek von rund 21 Kilobyte.
• Keine Reichweitenmessung, keine eingebundenen Dienste.
• Für Besucher wird nichts auf dem Endgerät gespeichert: keine Cookies, kein localStorage, sessionStorage, IndexedDB, CacheStorage, kein Service Worker.

Die Begründung ist bewusst präzise gefasst, denn die verbreitete Kurzform „keine Cookies, also kein Banner“ ist falsch: § 25 TDDDG knüpft nicht an Cookies an, sondern an das Speichern von Informationen auf dem Endgerät und den Zugriff darauf. Geprüft werden deshalb alle Speichermechanismen. Ausgehende Verweise sind einzeln dokumentiert; ein automatisierter Test vergleicht die tatsächlich vorhandenen Ziele mit dieser Liste und schlägt an, sobald ein weiteres auftaucht.

Den Rundgang gäbe es auch bei einem großen Kartendienst. Eingebettet hätte er beim Seitenaufruf von dort geladen — damit wäre eine Einwilligung nötig gewesen und für diese Zielgruppe ein Dialogfeld vor dem Inhalt. Stattdessen ist er selbst gebaut: Auflösung auf 4096 Pixel begrenzt, weil ältere Mobilgeräte darüber nicht zuverlässig darstellen; geladen wird erst auf Klick; ohne JavaScript oder 3D-Unterstützung bleibt ein Standbild stehen statt eines kaputten Knopfes. Die Startansicht ist mit diesem Standbild deckungsgleich — Blickrichtung und Bildwinkel wurden überlagert geprüft. Die Bibliothek fügt selbst einen Herkunftsverweis nach außen ein; er wird entfernt, weil er die dokumentierte Liste der ausgehenden Ziele verfälscht hätte.

Bei den Bildern galt Rechtelage vor Ästhetik. Aufnahmen aus fremden Quellen wurden nicht verwendet, solange sie nicht dokumentiert war — auch dann nicht, als sie greifbar gewesen wären. Keine Stockfotos, keine erzeugten Bilder. Keine erkennbaren Kundinnen und Kunden: Drei von acht Panoramen sind deshalb ausgeschieden. Beim Hochladen werden Metadaten entfernt, denn Produktfotos aus der Offizin tragen sonst Standortdaten mit sich.

Pflicht­an­ga­ben, die die Maske erzwingt

Die Apotheke pflegt Angebote, Stellenanzeigen und Leistungen selbst, und nach dem Livegang liest niemand gegen. Also muss die Eingabemaske verhindern, was schiefgehen kann — nicht die Schulung.

• Der Grundpreis wird aus Preis, Füllmenge und Einheit berechnet und immer als Euro je Kilogramm oder Liter ausgegeben; die frühere Ausnahme für kleine Packungen ist 2022 entfallen. Er steht unmittelbar beim Preis, nicht in einer Fußnote.
• Bei Preisermäßigungen verlangt § 11 PAngV den niedrigsten Preis der letzten 30 Tage. Das Eingabefeld heißt deshalb wörtlich „Niedrigster eigener Preis der letzten 30 Tage“ und nicht „bisheriger Preis“ — steht im Feld, was die Vorschrift verlangt, wird mit höherer Wahrscheinlichkeit der richtige Wert eingetragen.
• Die Angebotsverwaltung lässt keine Arzneimittel zu, weil die Pflichtangaben nach § 4 HWG in einer selbst gepflegten Maske nicht zuverlässig darstellbar sind. Die Kategorieliste hat bewusst keine Auffangkategorie, durch die doch eines hineinrutschen könnte.
• Der Zusatz „(m/w/d)“ wird nicht geprüft, sondern erzeugt: Eingegeben wird die reine Berufsbezeichnung, die Ausgabe ergänzt den Zusatz. Was man vergessen kann, wird irgendwann vergessen.
• Abgelaufene Angebote und Stellenanzeigen verschwinden von selbst. Abgelaufene Stellen antworten mit Statuscode 410 und tragen kein aktives Stellenmarkup mehr.
• Angebote haben bewusst keine eigene Adresse; Direktaufrufe werden umgeleitet. Damit entfällt die ganze Fehlerklasse, statt behandelt zu werden.

Dieselbe Logik trägt die Wortwahl. Die Apotheke hat keine Versanderlaubnis nach § 11a ApoG, deshalb vermeidet die Website durchgehend Shop-, Kauf- und Versandbegriffe und spricht von Vorbestellen, Reservieren, Abholen und Botendienst. Beim Botendienst wäre „liefern“ zulässig — § 17 Abs. 2 ApBetrO erlaubt die Zustellung ausdrücklich —, doch die Trennung wird sprachlich durchgehalten, damit kein Eindruck eines Versandhändlers entsteht. Ein automatisierter Test prüft die Wortliste auf jeder Seite.

Im Impressum steht die Firmierung wörtlich aus dem Handelsregisterauszug statt aus Name und Rechtsformzusatz zusammengesetzt, die Angaben richten sich nach dem DDG und nicht mehr nach dem TMG, und ein Verweis auf die 2025 eingestellte EU-Streitschlichtungsplattform fehlt bewusst. Die Berufshaftpflicht steht mit Versicherer, Anschrift und räumlichem Geltungsbereich nach DL-InfoV — die Versicherungsscheinnummer nicht, weil sie nicht verlangt ist.

Angaben, die von außen kommen, werden gegen die Quelle geprüft. Die im Impressum genannte Aufsichtsbehörde war nicht mehr die zuständige; Zuständigkeiten wechseln. Sie wurde gegen die aktuelle Zuständigkeit geprüft und korrigiert.

Öff­nungs­zei­ten

Falsche Öffnungszeiten bedeuten Kunden vor verschlossener Tür. Entsprechend ist dieser Teil gebaut:

• Feiertage werden berechnet, nicht eingetragen — ausdrücklich die hessischen, mit Fronleichnam, ohne Reformationstag und Allerheiligen. Müsste sie jemand pflegen, wäre der erste vergessene Karfreitag eine Frage der Zeit.
• Die Zeitzone ist explizit gesetzt und nicht von der Serverkonfiguration übernommen.
• Der Status wird im Browser berechnet, nicht auf dem Server. Sonst friert er in einem Zwischenspeicher ein und zeigt sonntags den Freitagstext.
• Acht Statusfälle sind einzeln geprüft, darunter der schwierigste: „Geöffnet bis 13:00, dann wieder ab 14:30“. Ein bloßes „geöffnet bis 13:00“ wäre wahr und würde trotzdem jemanden um 13:30 vor die Tür führen.
• Die Wochentage sind feste Felder statt einer freien Liste, damit kein Tag doppelt vorkommt und keiner fehlt.

Ohne JavaScript erscheint die Wochentabelle, aber kein Status.

Keine Aussage ist besser als eine falsche.

Übergabe

Die Apotheke pflegt die Seite selbst, ein- bis zweimal im Monat, überwiegend am Handy. Also gehört zur Lieferung mehr als Code.

Eine Anleitung in Alltagssprache ist aus dem Redaktionsbereich heraus erreichbar — dort, wo sie gebraucht wird, nicht in einem Repository. Ein Notfallzettel passt gedruckt auf eine A4-Seite und enthält keine Zugangsdaten; erster Punkt darin ist der häufigste Notfall: Eine falsche Angabe steht online, und statt auf den Entwickler zu warten, zieht man den Inhalt im Redaktionsbereich zurück.

Für alles technisch Messbare gibt es Prüfungen. Für die Voraussetzungen, auf denen das Ganze ruht — Behördenzuständigkeit, Versanderlaubnis, Fundstellen der Rechtsvorschriften — gibt es keine. Sie stehen deshalb in einer Liste der Annahmen, jede mit Prüfdatum, Zuständigkeit und einer jährlichen Durchsicht im Januar. Was ein Prüflauf überwacht und was ein Mensch bestätigen muss, wird getrennt geführt.

Was bewusst nicht gebaut wurde

• Kein NewsletterEr existiert bereits über die Partnerplattform. Ein zweiter Kanal, der nach drei Ausgaben einschläft, schadet mehr, als er nutzt — und er hätte das erste Formular auf den Server gebracht.
• Keine eingebettete KarteAuf einer Apothekenseite erkundet niemand eine Karte, man will eine Route.
• Kein Erkennungsskript für die Partner-AppDas übliche Verfahren mit Wartezeit und Rückfall ist unzuverlässig und erzeugt leere Tabs.
• Keine Einbettung der PartnerplattformDer Wechsel zu einem externen, transaktionalen Angebot soll sichtbar bleiben. Das ist der Kern der Entscheidung, keine Gesundheitsdaten zu verarbeiten.
• Keine Detailseiten für AngeboteSie hätten Adressen erzeugt, über die ein abgelaufenes Angebot erreichbar bliebe.