Eine Website kann mehrere Sprachen anzeigen und trotzdem eine gültige Adresse ablehnen. Mehrsprachigkeit endet nicht bei der Übersetzung des sichtbaren Textes. Sie muss auch dort funktionieren, wo Menschen ein Konto anlegen oder eine Nachricht erhalten wollen.
10. Oktober 2026 · Lesezeit: ca. 5 Minuten
Der aktuelle Anlass
UNESCO und ICANN haben am 9. Oktober 2026 einen Aufruf für Veranstaltungen zum Universal Acceptance Day 2027 veröffentlicht. Vorschläge können bis zum 20. November 2026 eingereicht werden; die geplanten Aktivitäten sollen zwischen dem 25. März und 30. Mai 2027 stattfinden. Der Aufruf richtet sich unter anderem an technische Fachleute, Unternehmen und Sprachgemeinschaften.
Universal Acceptance bezeichnet nach ICANN das Prinzip, alle gültigen Domainnamen und E-Mail-Adressen korrekt anzunehmen, zu prüfen, zu speichern, zu verarbeiten und darzustellen. Das umfasst neue Domainendungen und internationalisierte Adressen in unterschiedlichen Schriften. ICANN hat dazu im September 2026 zusätzliche Leitlinien veröffentlicht.
Bestätigt sind damit der neue Aufruf und die beschriebenen technischen Ziele. Daraus folgt nicht, dass sämtliche Dienste bereits entsprechend funktionieren. Auch eine internationale Veranstaltung verbessert die Nutzung nicht von selbst. Ihr praktischer Wert entsteht erst, wenn konkrete Systeme geprüft und angepasst werden.
Die Sprache steckt auch in der Adresse
Eine Übersetzung verändert den Inhalt einer Seite. Eine internationalisierte Adresse betrifft dagegen den Weg zu einer Seite oder zu einem Postfach. Diese beiden Aufgaben können zusammenhängen, sind technisch aber nicht identisch. Ein übersetzter Anmeldedialog kann weiterhin auf eine veraltete Eingabeprüfung zurückgreifen.
Ein hypothetisches Formular verdeutlicht das. Eine Person gibt ihre gültige Mailadresse ein, doch die Website akzeptiert nur ein eng begrenztes Zeichenmuster. Das System erklärt dann möglicherweise, die Adresse sei falsch. Tatsächlich könnte die Beschränkung des Formulars das Problem sein. Das Beispiel ist keine Diagnose einer bestimmten Website.
Für internationalisierte E-Mail-Adressen beschreibt der IETF-Standard RFC 6531 die Erweiterung SMTPUTF8. Er regelt Unterstützung beim Transport solcher Nachrichten. Eine passende Eingabeprüfung allein genügt daher nicht für die gesamte Mailkette. Ebenso beweist die Existenz des Standards nicht, dass jeder einzelne Anbieter ihn vollständig unterstützt.
MIYAN-Einordnung: Ein Ausschluss kann unsichtbar bleiben
Die folgenden Überlegungen sind redaktionelle Einordnung. Technische Barrieren fallen oft erst auf, wenn jemand einen Weg nutzt, der in den bisherigen Tests nicht vorkam. Ein Dienst kann für viele Menschen problemlos funktionieren und für eine andere Gruppe bereits am ersten Formular scheitern. Die allgemeine Erfolgsquote würde diesen Unterschied möglicherweise verdecken.
Wer abgewiesen wird, sieht häufig nur eine Fehlermeldung. Sie erklärt selten, welche Annahme im System zu eng gefasst ist. Dadurch wird ein technisches Problem als Fehler der Nutzerin oder des Nutzers dargestellt. Eine verständliche Fehlermeldung sollte deshalb zwischen einer tatsächlich ungültigen Eingabe und einer fehlenden Unterstützung unterscheiden können.
Aus unserer Sicht betrifft das auch die Würde des Zugangs. Menschen sollten ihre sprachliche Identität nicht ändern müssen, nur weil ein Dienst unnötig enge technische Erwartungen hat. Ob eine konkrete Adresse sicher und gültig ist, muss weiterhin geprüft werden. Ihre Schrift allein ist jedoch kein ausreichender Grund für eine pauschale Ablehnung.
Die ganze Verarbeitungskette zählt
Eine Adresse kann am Anfang angenommen und später beschädigt werden. Deshalb muss die Prüfung über das sichtbare Formular hinausgehen. Werden Zeichen korrekt gespeichert? Bleibt die Adresse beim Export unverändert? Kann die Bestätigungsmail zugestellt werden? Erscheint sie in Verwaltungsoberflächen richtig?
Ein gedankliches Beispiel: Eine Anmeldung funktioniert, doch ein nachgelagertes System ersetzt bestimmte Zeichen. Die Bestätigung erreicht das Postfach dann nicht. Die Nutzerin sieht nur, dass keine Nachricht ankommt. Ein Test, der beim erfolgreichen Absenden des Formulars endet, würde den Fehler übersehen.
Für eine Organisation bedeutet das, Zuständigkeiten entlang der Kette zu klären. Website, Datenbank, Maildienst und Kundenverwaltung können von unterschiedlichen Teams betreut werden. Universal Acceptance ist deshalb eine gemeinsame Qualitätsaufgabe. Sie sollte nicht bei der Person hängenbleiben, die zuletzt eine Fehlermeldung beantwortet.
Sicherheit bleibt eine eigene Aufgabe
Ein möglicher Einwand lautet, dass unterschiedliche Schriften die Erkennung ähnlich aussehender Zeichen erschweren können. Diese Sicherheitsfrage ist ernst zu nehmen. Aus ihr folgt aber nicht, dass alle internationalisierten Adressen ausgeschlossen werden sollten. Unterstützte Nutzung und Schutz vor Täuschung müssen gemeinsam gestaltet werden.
Ein Dienst muss weiterhin prüfen, ob eine Adresse zu einem erwarteten Vorgang gehört und ob sensible Entscheidungen angemessen abgesichert sind. Die bloße Annahme eines Zeichenformats bestätigt keine Identität. Diese Unterscheidung gilt auch für Adressen, die ausschließlich vertraute lateinische Zeichen verwenden.
MIYAN sieht darin einen wichtigen Maßstab: Sprachliche Offenheit sollte nicht mit geringerer Sorgfalt erkauft werden, Sicherheit aber auch nicht als pauschales Argument gegen Vielfalt dienen. Die passende technische Lösung berücksichtigt beide Ziele und erklärt ihre Grenzen. Ein einfaches Verbot wäre zwar leicht umzusetzen, würde die eigentliche Entwicklungsaufgabe aber umgehen.
Praktische Tests sind aussagekräftiger als ein Bekenntnis
Eine Organisation kann Mehrsprachigkeit unterstützen wollen und dennoch ungeprüfte Standardkomponenten einsetzen. Deshalb sollte ein Anspruch durch realistische Tests ergänzt werden. Unterschiedliche zulässige Domainendungen, Schreibsysteme und vollständige Abläufe gehören in die Prüfung. Ein einzelner erfolgreicher Beispieldatensatz wäre kein umfassender Nachweis.
Die Auswahl der Tests sollte aus den tatsächlichen Nutzungssituationen entstehen. Welche Sprachgemeinschaften werden erreicht? Welche Dienste sind verbunden? Wo wurden Eingaben bislang abgewiesen? Diese Fragen helfen, die Prüfung sinnvoll zu gestalten. Sie verlangen keine Erhebung unnötiger persönlicher Angaben.
Auch Fehlerberichte können nützlich sein, wenn sie systematisch ausgewertet werden. Eine wiederholte Ablehnung derselben Adressart deutet auf einen überprüfbaren Bereich hin. Der Support sollte solche Beobachtungen an die technischen Verantwortlichen weitergeben können. Gute Zugänglichkeit entsteht hier aus der Verbindung von Nutzungsfeedback und verlässlicher Bearbeitung.
Der Nutzen des neuen Aufrufs
Der kommende Universal Acceptance Day bietet einen Anlass, technische und sprachliche Perspektiven zusammenzubringen. Seine Wirkung sollte aus unserer Sicht daran gemessen werden, welche Prüfungen und Verbesserungen daraus entstehen. Eine Veranstaltung mit vielen Teilnehmenden kann Aufmerksamkeit schaffen; ein dauerhaft funktionierender Vorgang schafft Zugang.
Für Menschen, die Persisch oder andere nicht lateinische Schriften nutzen, ist die Frage konkret, ohne das Internet auf eine einzige Sprachgemeinschaft zu verengen. Dasselbe Prinzip betrifft unterschiedliche Schriften und auch neue Domainendungen. Ein offenes Netz muss diese Vielfalt in seinen alltäglichen Abläufen berücksichtigen.
Die entscheidende Verbesserung ist deshalb unspektakulär: Eine gültige Adresse wird akzeptiert, bleibt unverändert und erreicht ihr Ziel. Wenn das gelingt, verschwindet eine Grenze, die viele Nutzerinnen und Nutzer zuvor nur als unerklärliche Fehlermeldung kannten.
Quellen und Transparenz
UNESCO/ICANN: Aufruf zum Universal Acceptance Day 2027, 9.10.2026
ICANN: Definition und Überblick zu Universal Acceptance
ICANN: Neue Leitlinien, 9.9.2026
IETF/RFC Editor: RFC 6531, SMTPUTF8, Februar 2012
Quellenstand: 10. Oktober 2026. Bestätigte Angaben, Aussagen der Quellen und MIYANs eigene Einordnung sind im Text getrennt. Hypothetische Beispiele beschreiben keine realen Einzelfälle.
