Am 13. November 2026 um 22:00 Uhr MEZ hat das WebKit-Team den Beitrag „Safari on Apple HomeView“ veröffentlicht^[1]. WebKit ist die Browser-Engine, also der technische Unterbau, von Safari. Am selben Tag hat Apple den Verkauf von HomeView in ausgewählten Ländern gestartet, darunter die USA und Großbritannien^[2]. Vorgestellt hatte Apple das Gerät für zu Hause bereits am 13. Oktober^[3].

Wichtig für Deutschland: HomeView wird laut Apple in der EU nicht verkauft, weil Siri AI, die neue Version der Sprachassistentin Siri, in der EU derzeit nicht unter iOS verfügbar ist^[2]. Apple bemüht sich nach eigenen Angaben gemeinsam mit der EU um eine Lösung^[2].

Dieser Beitrag ist deshalb keine Geräte-News. Er fragt, was Apples Hinweise für jede Firmenwebsite bedeuten: kleine, quadratische oder quer gehaltene Bildschirme und Bedienung per Sprache und Touch (Stand: 14.11.2026).

HomeView hat einen quadratischen 7-Zoll-Bildschirm. Man spricht das Gerät quer durch den Raum an oder tippt aus der Nähe auf das Display^[1]. Was müssen Webentwickler dafür tun? WebKit antwortet selbst: „Most likely, you don’t need to do anything.“ Das Web sei dafür gemacht, auf jedem Bildschirm und mit jeder Eingabeart zu funktionieren^[1].

Die meisten Websites müssen also nicht für HomeView umgebaut werden. Interessant sind die Ausnahmen. Websites, die fest annehmen, was ein Gerät ist und wie Menschen es nutzen, können laut WebKit brechen, wenn ein neues Gerät erscheint^[1]. Vier solche Annahmen nennt der Beitrag:

Wer mit einer Seite spricht, zeigt nicht auf einen Button, sondern ruft ihn beim Namen, so beschreibt es WebKit^[1]. Dafür empfiehlt WebKit semantisches HTML, also Code, der sagt, was ein Element ist: echte Buttons, Links und Formularfelder sowie eine klare Beschriftung an jedem Bedienelement^[1]. Barrierefreie Inhalte, große Tippflächen und flexible Layouts helfen laut WebKit allen, ob sie sprechen, tippen oder beides^[1].

WebKit nennt dabei keine Norm, die Verbindung zu den WCAG ziehen wir. Beide Hinweise passen zu Erfolgskriterien der WCAG 2.2, der Richtlinien des W3C für barrierefreie Webinhalte^[4]:

• 2.5.3 Label in Name (Stufe A): Bei Bedienelementen mit Beschriftungen, die Text oder Bilder von Text enthalten, enthält der Name den Text, der sichtbar dargestellt wird^[4]. Gemeint ist der Name, den der Code für Hilfsmittel wie Sprachsteuerung bereitstellt. Als gute Praxis nennt das W3C, den sichtbaren Text an den Anfang des Namens zu stellen^[4].
• 2.5.8 Target Size (Minimum) (Stufe AA): Die Größe des Ziels für Zeigereingaben beträgt mindestens 24 × 24 CSS-Pixel^[4]. Ausnahmen gelten unter anderem bei ausreichendem Abstand zwischen kleineren Zielen, für Links im Fließtext und für unveränderte Browser-Elemente^[4].

Warum das für Sprache zählt, erklärt das W3C: Wer per Spracherkennung navigiert, spricht die sichtbare Beschriftung aus. Passt sie nicht zum Namen im Code, scheitert der Befehl^[5]. Steht auf dem Button etwa „Angebot anfordern“, im Code aber nur „Senden“, findet der Sprachbefehl nichts. Ausreichend große Ziele machen laut W3C zudem Touchscreens leichter bedienbar^[6].

Auf einem kurzen Bildschirm können Kopf- und Fußleisten, die beim Scrollen stehen bleiben, kaum noch Platz für den eigentlichen Inhalt lassen^[1]. Heikler sind Modals, also Fenster, die sich über die Seite legen, etwa für Newsletter-Anmeldungen. Sind sie höher als der Viewport, können Besucher sie womöglich gar nicht mehr schließen^[1].

Als schnelle Lösung für solche Fenster zeigt WebKit diesen CSS-Code^[1]:

.modal {
  max-height: 90svh;
  overflow-y: auto;
}

Die erste Zeile begrenzt das Fenster auf 90 Prozent der Viewport-Höhe; svh misst dabei so, als wären alle ein- und ausblendbaren Browserleisten eingeblendet^[7]. Die zweite Zeile macht überlangen Inhalt im Fenster scrollbar. „.modal“ steht für den Klassennamen des Fensters, der auf Ihrer Website anders heißen kann.

Ein eigenes Gerät brauchen Sie nicht. WebKit nennt zwei Testwege^[1], die Prüfpunkte danach ergänzen wir:

Der User-Agent ist die Kennung, die ein Browser bei jedem Seitenabruf mitschickt. Manche Websites schließen aus einer iOS-Kennung, dass ein iPhone anfragt, doch Safari auf HomeView meldet ebenfalls eine iOS-Kennung^[1]. WebKit rät deshalb von dieser Browser-Erkennung ab und empfiehlt Feature Detection: direkt prüfen, ob eine Funktion unterstützt wird^[1]. Laut der Entwicklerdokumentation MDN ist die Erkennung über den User-Agent sehr schwer zuverlässig umzusetzen und eine häufige Fehlerquelle^[10].

Für Rezeptseiten bietet Safari auf HomeView eine Kochansicht mit Schritt-für-Schritt-Anleitung. Grundlage sind Rezeptdaten im schema.org-Typ Recipe im Format JSON-LD^[1], also strukturierte Daten, eine maschinenlesbare Beschreibung im Quelltext. Google nutzt Recipe-Daten für hervorgehobene Suchergebnisse, verlangt dafür eigene Pflichtangaben wie name und image und garantiert keine Anzeige^[11].

Für Videos empfiehlt WebKit Untertitel als WebVTT-Dateien, also in einem Textformat für zeitgesteuerte Untertitel, eingebunden über track-Elemente im Video-Code^[1]. Auch WCAG 2.2 verlangt Untertitel: Kriterium 1.2.2 (Stufe A) fordert sie für voraufgezeichnete Audioinhalte in synchronisierten Medien, also etwa in Videos mit Ton^[4].

HomeView ist für Unternehmen in Deutschland derzeit kein Zielgerät. Nützlich sind die Hinweise trotzdem, weil sie Annahmen sichtbar machen, die auch auf dem Smartphone im Querformat stören. Unsere Empfehlung: ein kurzer Test, kein Umbau und erst recht keine eigene HomeView-Erkennung.