Anforderungen

Bei der Entwicklung von Web-Anwendungen auf wien.gv.at sind ein paar Prinzipien grundlegend.

Die Content Strategie für wien.gv.at folgt dem Content-First-Prinzip. Es sieht vor, dass aus Sicht der Wiener*innen möglichst nützliche Inhalte angeboten werden und so aufbereitet sind, dass sie rasch gefunden werden - unabhängig vom gerade verwendeten Kanal (Websites, Apps, Google und so weiter).

Alle bekommen noch schneller und einfacher die Information, die sie brauchen. Auf dem Kanal ihrer Wahl.

Um Content-First erfolgreich anwenden zu können, müssen Entwickler*innen eng mit Redakteur*innen und Designer*innen zusammenarbeiten. Unsere Patterns sind so konzipiert worden, dass der Content möglichst einfach und verständlich aufbereitet ist. Es ist wichtig zu verstehen: Besucher*innen auf wien.gv.at kommen nicht aufgrund des Designs, sondern wegen der nützlichen Inhalte. Das responsive Design der Patterns unterstützt den Content auf allen Geräten und rundet eine zufriedenstellende User-Journey für Nutzer*innen ab.

Für die Erstellung von Inhalten für wien.gv.at gilt, dass auch die Workflows nach dem Content-First-Prinzip ausgerichtet sind. Das bedeutet, dass zuerst analysiert wird, welche Inhalte nachgefragt werden und wie diese aufbereitet werden müssen, damit Nutzer*innen sie bestmöglich finden und lesenkönnen. Dann können weitere Schritte in Konzeption, Entwicklung und Design gesetzt werden. Kurz: "Form follows Content".

Alle Anwendungen auf wien.gv.at müssen nach dem Mobile-First-Prinzip konzipiert, entwickelt und gestaltet werden. Konkret besagt das Prinzip, dass User-Interfaces in erster Linie für die Nutzung auf Smartphones erstellt werden. Das betrifft die Gestaltung und Positionierung von Texten und Bedien-Elementen sowie die Entwicklung in HTML, CSS und JavaScript.

In CSS bedeutet das beispielsweise, dass Stil-Definitionen zuerst für kleinere Bildschirme geschrieben und dann Breakpoints für größere Bildschirme gesetzt werden und nicht umgekehrt.

Bevorzugter Mobile-First Ansatz

.block { padding: 1rem; } @media(min-width: 600px) { .block { padding: 2rem; } }

Alternativer Desktop-First Ansatz

.block { padding: 2rem; } @media(max-width: 599px) { .block { padding: 1rem; } }

In der Programmierung besagt die "Rule of Least Power", dass stets die einfachste und schwächste Programmiersprache für einen Anwendungszweck verwendet werden soll. Für Web-Anwendungen und -Komponenten bedeutet das in der Regel HTML. Das heißt nicht, dass zusätzliche Sprachen wie CSS und JavaScript gar nicht verwendet werden sollen, wenn sich eine Aufgabe mit HTML allein lösen lässt, sondern, dass der Funktionsumfang Schicht für Schicht erweitert werden soll (siehe Progressive Enhancement).

Progressive Enhancement beschreibt die Umsetzung der Rule of Least Power mit zusätzlicher, progressiver Erweiterung der Funktionalität. Dabei werden Features schichtweise so hinzugefügt, dass untere Schichten immer noch funktionieren, selbst wenn obere Schichten wegfallen. Man beginnt mit einem gut strukturierten und semantisch korrekten HTML-Dokument. Dieses wird optisch und funktional mit CSS angereichert, um die Bedienbarkeit zu verbessern. Kann CSS nicht geladen werden, ist das Dokument aufgrund seiner starken Basis, immer noch zugänglich. Wenn es für die Besucher*innen zusätzlichen Nutzen bringt, kann die Funktionalität mit JavaScript nochmals erweitert werden.

Anwendungen auf wien.gv.at müssen die folgenden Browser in der jeweils aktuellen Version unterstützen (bei Safari zusätzlich auch die vorhergehende Hauptversion von macOS beziehungsweise iOS).

Unterstützte Browser für Anwendungen auf wien.gv.at

Legende

1: Volle Unterstützung
Weitgehend gleiche Darstellung, Bedienung und gleiches Verhalten der Anwendung auf allen Browsern dieser Kategorie. Geringe Unterschiede sind möglich.

2: Bedingte Unterstützung
Alle Inhalte der Anwendung sind zugänglich, wobei Darstellung, Bedienung und Verhalten der Anwendung gegenüber anderen Browsern abweichen können.

Performance-Anforderungen

Die serverseitige Reaktionszeit ("Time to First Byte") einer beliebigen Website in Österreich soll bei circa 200 Millisekunden liegen, niemals über 400 Millisekunden. Die Website muss im "Google Page Speed Insights"-Test sowohl bei Desktop als auch mobil ein grünes Rating aufweisen.

Barrierefreiheit

Für Inhalte auf wien.gv.at ist die Einhaltung der Richtlinien für ein barrierefreies Web-Design nach WCAG 2.2 Level AA Pflicht.

Die Zugänglichkeit von Web-Anwendungen muss ausreichend getestet werden. Das bedeutet, dass die Bedienbarkeit zumindest mit folgenden Eingabe-Modalitäten und Programmen gewährleistet sein muss:

• Tastatur oder ähnliche Eingabegeräte
• Gängige Screenreader Software: NVDA und Jaws auf Windows, VoiceOver auf macOS und iOs, Talkback auf Android.
• Geräte- und browserunabhängig ohne JavaScript

Ein Score von 100 in Lighthouse oder 0 Fehler in anderen automatisierten Testprogrammen wie axe oder WAVE sind erwünscht, sagen allein aber nichts über die Barrierefreiheit einer Website aus. Es muss jedenfalls auch manuell getestet werden.

Suchmaschinenoptimierung (SEO)

Etwa die Hälfte der Nutzer*innen auf wien.gv.at kommt über Google. Damit die Wiener*innen dort unsere offiziellen Infos finden, braucht es eine zeitgemäße Search Engine Optimization (SEO).

Redakteur*innen können mit passendem Meta-Titel und Meta-Beschreibung, Keywords, Alt-Texten, et cetera ihren Beitrag leisten.

Das allein ist aber nicht mehr ausreichend. Suchmaschinen interessieren sich immer stärker für den Kontext von Inhalten. Und: Die Gestaltung der Inhalte muss die zunehmende Verwendung von gesprochenen Suchanfragen und Sprachassistenten (vor allem bei Mobilgeräten) berücksichtigen. Texte in leicht verständlicher Sprache erhöhen somit nicht nur die Barrierefreiheit, sondern unterstützen auch ein gutes SEO-Ranking. Ebenso besteht mit gut strukturierten Text-Elementen die Möglichkeit, ein "Featured Snippet" zu erzielen.

Optimierung für Mobile Endgeräte

Unsere Web-Anwendungen müssen für mobile Endgeräte optimiert sein. Sie sollen den aktuell gültigen Mobile Best Practices entsprechen und eine einfache Bedienbarkeit für die Nutzer*innen ermöglichen.

Als Kriterium gilt: Unsere Web-Anwendungen müssen beim "Google Mobile Friendly Test" ein grünes Rating haben. Die Vorschau-Funktion des Tests muss die Website so zeigen, wie User*innen sie erwarten würden.

Web-Performance Optimierung

Wenn die Performance einer Website unter den gängigen Standard fällt, wird die Seite von Suchmaschinen-Anbietern (allen voran Google) im Suchergebnis (PageRank) nach hinten gereiht. Web-Anwendungen müssen daher den gängigen Performance-Standards hinsichtlich Antwortzeit, First-Byte, Ladezeiten und dergleichen entsprechen.

Als Kriterium gilt: Die serverseitige Reaktionszeit ("Time to First Byte") eines Aufrufs aus Österreich einer beliebigen Webpage der Applikation soll bei zirka 200 Millisekunden liegen, niemals über 400 Millisekunden. Die Applikation muss im "Google Page Speed Insights"-Test sowohl bei Desktop als auch mobil ein grünes Rating aufweisen.

Sitemap.xml Verteilungslogik

Web-Anwendungen müssen Seiten, die in Google oder anderen Suchmaschinen gefunden werden sollen, mittels sitemap.xml Logik an die Suchmaschinen kommunizieren. Über die sitemap.xml können Änderungen an der Struktur schneller und effizienter an Suchmaschinen kommuniziert werden. Dies erhöht speziell in Folge von Änderungen das Such-Ranking der einzelnen Seiten und vermindert die Fehler-Rate.

HTML-Seiten, die gefunden werden sollen (nicht aber HTML-Seiten, die nicht gefunden werden sollen) werden in einer anwendungsspezifischen sitemap.xml gelistet. Je nach Anzahl der HTML-Seiten kann es sein, dass mehrere Unterversionen der sitemap.xml benötigt werden. Diese werden dann in einer applikationsspezifischen Sitemap-Index.xml gelistet. Die finale Sitemap.xml oder Sitemap-Index.xml wird in der /robots.txt der ausliefernden Domain gelistet.

Vermeidung Extensiver URL-Kombinationen

Dynamisch erzeugte URL-Variationen (die zum Beispiel bei Web-Anwendungen mit Suchfunktionalität vorkommen können), führen zu einer unüberschaubaren und nicht verwaltbaren Anzahl von für Suchmaschinen-Crawler als relevant eingestuften URLs. Dadurch steigt die Durchlaufzeit für einen kompletten Crawl der Domain, was negative Auswirkungen auf die Aktualität der Suchergebnisse haben kann.

Systematische Verlinkungen wie Navigation, Paginierung (Aufteilung der Inhaltsanzeige auf mehrere Seiten) sowie damit verbundene Parametrisierung wie etwa Suchergebnisse dürfen nicht dazu führen, dass eine große oder unbekannt wachsende Anzahl von verschiedenen URL-Kombinationen (zum Beispiel mit unzähligen Parameter-Variationen) erzeugt wird.

Jede URL-Kombination, die im Markup einer Website (verlinkt oder im onpage JavaScript) aufscheint, wird von Google gecrawlt. Werden große Mengen oder eine unbekannt wachsende Anzahl dieser URLs systematisch aufgrund der Navigationslogik (Navigation, Paginierung und dergleichen) erzeugt, werden diese von Suchmaschinen automatisch gecrawlt, anstatt aktualisierte Pages zeitgerecht abzuholen.

Korrekte Darstellung bei Deaktiviertem JavaScript

Web-Anwendungen müssen den textlichen und bildlichen Content sowohl auf der Startseite als auch auf Unterseiten bei deaktiviertem JavaScript im Browser anzeigen. Die Darstellung der Seite kann aufgrund der deaktivierten JavaScript-Funktionen verändert sein. Die Deaktivierung von durch JavaScript gesteuerten Elementen oder Funktionalitäten hat keine negative Auswirkung auf die Suchmaschinen-Optimierung, solange die Information der Seite ohne JavaScript zugänglich ist.

Darstellung der Seite durch Googlebot

Web-Anwendungen mit öffentlich zugänglichen Seiten müssen die Informationen auch bei der Abfrage als Googlebot (Fetch as Googlebot) vollständig darstellen.

Als Kriterium gilt: Mithilfe des "Abruf wie durch Google"-Tests in der Google Search Console (Dashboard > Crawling > Abruf wie durch Google) muss eine Auswahl an Seiten der Web-Anwendung getestet werden. Im "Render"-Modus muss der Content der Seite sichtbar und das Design der Seite wie erwartet dargestellt werden. Im Fehler-Report unterhalb der Screenshots dürfen weder "-" noch "Mittel" oder "Hoch"-Fehler angezeigt werden.

Unabhängige Bearbeitung von Meta-Daten

Die Elemente "Meta-Title", "Meta-Description", "URL" und "Überschrift" von redaktionell verwalteten Seiten müssen im CMS so implementiert werden, dass es möglich ist, sie getrennt voneinander zu bearbeiten. Vor allem muss es möglich sein, dass ein Element verändert wird, ohne dass eines der anderen genannten Elemente dadurch "automatisch" mitgeändert wird. Auch darf die Änderung nicht zur Erzeugung einer neuen HTML-Seite (auch nicht mit nur geänderten URL-Parametern) führen.

Eine "Standard-Logik", die zum Beispiel die Überschrift einer Seite als Meta-Title setzt oder einen Text-Bestandteil als Meta-Description, ist möglich, solange es die Möglichkeit gibt, die so eingetragenen Inhalte der Tags nachträglich und unabhängig voneinander zu bearbeiten.

Strukturierung von Content im CMS-Editor

Bei der Eingabe von Content in einem CMS muss es möglich sein, die aktuell gültigen Regeln zur Content-Strukturierung einzuhalten.

Das CMS muss die Eingabe von Inhalten in Form von HTML-Tabellen, nummerierten oder ungeordneten Listen, Definitions-Listen, Zwischenüberschriften und Fließtext-Eingaben ermöglichen und diese auch am Frontend im richtigen semantischen Markup (tables, ul-li-lists, ol-li-lists, dt-dl-lists, h2, h3, ..., p) wiedergeben.

Kanonische Verlinkung (Meta-Tag Canonical)

Interne Verlinkungen sollen immer auf die kanonische (also die Haupt-)URL der verlinkten Ressource zeigen. Das bedeutet: Interne Links zeigen nicht auf Redirects oder auf URLs, die unnötige Parameter beinhalten. Siehe dazu auch Kanonische URL-Logik.

Kanonische URL-Logik

Jede Seite einer Web-Anwendung setzt im HTML-Header die jeweils gültige, korrekte kanonische URL. Die kanonische URL muss im CMS editierbar sein und darf sich beispielsweise nicht vom Seitentitel ableiten.

Die kanonische URL ist im einfachsten Fall die URL der Seite ohne für die Content Darstellung nicht nötige Parameter.

<link rel="canonical" href="%%canonical URL%%" />

Noindex Meta Direktive

Es muss möglich sein, HTML-Seiten von der Indizierung durch Suchmaschinen-Crawler explizit mittels HTML-Tag im Header auszunehmen.
Im CMS ist es möglich einzelne HTML-Seiten auf

<meta name="robots" content="noindex">

als auch

<meta name="googlebot" content="noindex">

zu setzen.

Einfache URLs

In den redaktionell angelegten URLs sind nur Zeichen von [0 bis 9], [a bis z] und [-] erlaubt. Das beinhaltet, dass alle Bestandteile von URLs immer kleingeschrieben sind. Die Verwendung des Zeichens [-] am Anfang oder am Ende eines redaktionell gesetzten URL-Teils ist nicht erlaubt, auch können nie mehrere [-] hintereinander vorkommen. Wichtig: "underscores" [_] sind in redaktionell gestalteten URL-Teilen nie erlaubt.

URL-Schema für Anwendungen

• Dynamische Anwendungen können in kurzer Zeit Millionen von URLs erzeugen, was aus SEO-Perspektive ausgesprochen negative Folgen für das Portal hat.
• Die URLs neuer außenwirksamer Anwendungen müssen daher mit der wien.gv.at Redaktion abgestimmt werden. Das gilt auch für Änderungen der Domain/URL bestehender wien.gv.at-Anwendungen.
• Kleinere Formulare und Anwendungen werden unter der Subdomain https://anwendungen.wien.gv.at/namederanwendung/ veröffentlicht.
• Für Anwendungen mit umfangreichen Funktionen oder Inhalten, zum Beispiel Kataloge, oder aus anderen technischen Gründen kann eine eigene Subdomain nach dem Schema applikationsname.wien.gv.at angefordert werden.
• Für die Kommunikation kann ein "First Level Redirect" verwendet werden.

Benutzerfreundlichkeit

Für eine erfolgreich umgesetzte Content Strategie ist eine kontinuierliche Zusammenarbeit der Redaktion, User Experience-Verantwortlichen, Designer*innen und Entwickler*innen notwendig. Gute User Experience bedeutet: Übersichtliche, gut strukturierte CMS-Elemente (Patterns ), die von der wien.gv.at Redaktion mit leicht verständlichen Texten, aussagekräftigen Bildern und Videos gefüllt werden.

Da Web-Inhalte von den Nutzer*innen oft nur "gescannt" werden, ist das entscheidend, damit die wichtigsten Inhalte rasch gefunden werden und die Wiener*innen ein positives Erlebnis mit wien.gv.at haben.

Ob und wie gut das gelingt, wird laufend mit Analyse-Tools, zum Beispiel Siteimprove oder Google Tools, und unserer Test-Community überprüft.