WCAG 3.2.6: Konsistente Hilfe

WCAG 3.2.6 verlangt, dass, wenn eine Website menschlichen Kontakt, Selbsthilfe- oder automatisierte Unterstützungsmechanismen anbietet, diese Mechanismen auf allen Seiten in derselben relativen Reihenfolge erscheinen. Dies stellt sicher, dass Nutzerinnen und Nutzer mit kognitiven Beeinträchtigungen oder Gedächtnisstörungen Hilfe zuverlässig finden können, ohne die Benutzeroberfläche auf jeder Seite neu erlernen zu müssen.

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 3.2.6 Konsistente Hilfe (Level AA, eingeführt in WCAG 2.2) besagt: „Wenn eine Webseite einen der folgenden Hilfemechanismen enthält und diese Mechanismen auf mehreren Webseiten wiederholt werden, erscheinen sie in derselben relativen Reihenfolge zum übrigen Seiteninhalt, sofern die Änderung nicht vom Nutzer initiiert wurde.“ Die von diesem Kriterium abgedeckten Hilfemechanismen sind: menschliche Kontaktdaten (wie eine Telefonnummer, E-Mail-Adresse oder Öffnungszeiten), ein menschlicher Kontaktmechanismus (wie ein Live-Chat-Widget oder ein Kontaktformular), eine Selbsthilfe-Option (wie eine Seite mit häufig gestellten Fragen, ein Help Center oder eine Wissensdatenbank) und ein vollständig automatisierter Kontaktmechanismus (wie ein Chatbot oder virtueller Assistent).

Die zentrale Anforderung ist die Konsistenz der relativen Reihenfolge, nicht die identische Pixelposition. Wenn ein Live-Chat-Button in der unteren rechten Ecke der Startseite erscheint, muss er auf jeder anderen Seite, auf der er angezeigt wird, in derselben unteren rechten Position erscheinen. Wenn ein „Hilfe“-Link auf einer Seite das dritte Element in der oberen Navigationsleiste ist, muss er das dritte Element bleiben – oder zumindest dieselbe relative Beziehung zu den umgebenden Inhalten beibehalten – auf allen anderen Seiten, auf denen diese Navigationsleiste erscheint.

Eine Seite besteht dieses Kriterium, wenn: (a) auf der Website kein Hilfemechanismus existiert oder (b) ein Hilfemechanismus nur auf einer einzigen Seite existiert oder (c) überall dort, wo ein Hilfemechanismus auf mehreren Seiten wiederholt wird, er in derselben relativen Reihenfolge innerhalb des Seitenlayouts erscheint. Eine Seite verfehlt das Kriterium, wenn ein Hilfemechanismus, der auf mehreren Seiten vorhanden ist, seine Position in der Seitenreihenfolge von einer Seite zur anderen verschiebt, ohne dass der Nutzer diese Änderung initiiert hat – zum Beispiel ein Chat-Widget, das auf der Produktlistenseite unten rechts schwebt, aber auf der Checkout-Seite nach unten links verschoben wird.

Das Kriterium enthält eine ausdrückliche Ausnahme: Die Reihenfolge darf sich ändern, wenn der Nutzer die Änderung initiiert. Wenn ein Nutzer beispielsweise ein schwebendes Hilfe-Widget per Drag & Drop verschiebt oder wenn eine Nutzereinstellung das Hilfe-Panel von einer Seite auf die andere umschaltet, ist diese Neupositionierung nutzerinitiiert und stellt keinen Verstoß dar. Diese Ausnahme spiegelt dieselbe nutzerinitiierte Logik wider, die in SC 3.2.2 (Bei Eingabe) zu finden ist.

Wichtig ist, dass dieses Kriterium nicht verlangt, dass jede Seite einen Hilfemechanismus hat, und auch nicht, dass der Hilfemechanismus wirksam oder leicht zu bedienen ist. Es regelt ausschließlich die Positionskonsistenz, wenn der Mechanismus auf mehreren Seiten vorhanden ist.

Warum das wichtig ist

Eine konsistente Platzierung von Hilfe ist in erster Linie dazu gedacht, Nutzerinnen und Nutzern mit kognitiven Beeinträchtigungen zugutezukommen, darunter Menschen mit Gedächtnisbeeinträchtigungen, Aufmerksamkeitsstörungen, Lernbehinderungen wie Legasthenie und Erkrankungen wie ADHS oder Demenz im Frühstadium. Für diese Nutzer erfordert das Auffinden eines vertrauten Interface-Elements bewusste kognitive Anstrengung. Wenn ein Hilfe-Button oder Kontaktlink auf jeder Seite an einer anderen Stelle erscheint, müssen sie diese Anstrengung immer wieder aufbringen, was die kognitive Belastung und das Risiko von Frustration, Desorientierung oder dem Abbruch von Aufgaben erhöht.

Nutzerinnen und Nutzer, die neu im Web sind oder nur über eine begrenzte digitale Kompetenz verfügen – eine bedeutende Bevölkerungsgruppe in der Türkei und weltweit – sind ebenfalls stark auf eine vorhersehbare Platzierung angewiesen. Laut der Weltgesundheitsorganisation leben weltweit über 1,3 Milliarden Menschen mit irgendeiner Form von Behinderung, und kognitive und neurologische Beeinträchtigungen machen einen erheblichen Anteil dieser Bevölkerung aus. Für Positionskonsistenz zu gestalten, dient daher einem breiten Publikum weit über diejenigen hinaus, bei denen klinisch eine Behinderung diagnostiziert wurde.

Betrachten wir ein konkretes Szenario: Eine Nutzerin mit Alzheimer im Frühstadium versucht, eine Flugbuchung online abzuschließen. Sie erinnert sich, dass die Website der Fluggesellschaft eine Live-Chat-Option hat, die sie nutzen kann, wenn sie durcheinander gerät. Auf der Suchergebnisseite erscheint das Chat-Symbol in der unteren rechten Ecke. Wenn sie jedoch zur Sitzplatzauswahlseite wechselt, wurde das Chat-Widget in die obere rechte Ecke in eine ausklappbare Hilfeleiste verlegt. Sie kann es nicht finden, fühlt sich überfordert und bricht die Buchung vollständig ab. Dies ist ein direkter, vermeidbarer Verstoß gegen SC 3.2.6.

Für motorisch beeinträchtigte Nutzer, die mit Schaltersteuerung, Eye-Tracking-Software oder Kopfmaus navigieren, bedeutet die Neupositionierung eines Hilfemechanismus, einen neuen Bereich des Bildschirms erneut zu scannen und anzusteuern – ein anstrengender und zeitaufwändiger Prozess, den eine konsistente Platzierung überflüssig macht.

Screenreader-Nutzer, die sich die Tab-Reihenfolge oder die Überschriftenstruktur einer Website eingeprägt haben, um schnell zum Hilfebereich zu gelangen, sind gleichermaßen betroffen, wenn sich die DOM-Reihenfolge dieses Mechanismus von Seite zu Seite ändert, selbst wenn die visuelle Position ähnlich aussieht.

Über die Barrierefreiheit hinaus gibt es einen klaren Nutzen für Usability und Geschäft: Nutzer, die schnell Hilfe finden, brechen Transaktionen seltener ab, was Absprungraten und Supportkosten reduziert. Konsistente UI-Muster stärken zudem das Vertrauen in die Marke und vermitteln Professionalität.

Wie man testet

Hilfemechanismen inventarisieren: Erstellen Sie vor dem Testen einzelner Seiten eine Liste aller auf der Website vorhandenen Hilfemechanismen – Live-Chat-Widgets, Kontakttelefonnummern, E-Mail-Links, FAQ-Links, Chatbot-Launcher, Kontaktformulare und Help-Center-Links. Notieren Sie, auf welchen Seiten jeder Mechanismus erscheint. Wenn ein Mechanismus nur auf einer Seite erscheint, fällt er nicht in den Geltungsbereich dieses Kriteriums.
Automatischen Scan für Basis-Kontext durchführen: Verwenden Sie axe DevTools (Browser-Erweiterung) oder Lighthouse auf repräsentativen Seiten, um DOM-Order-Snapshots zu erfassen und die strukturelle Position von hilfebezogenen Elementen zu identifizieren. Zwar zielt keine axe-Regel direkt auf SC 3.2.6 ab, aber die von diesen Tools gemeldete DOM-Reihenfolge kann manuell über Seiten hinweg verglichen werden. Exportieren oder screenshotten Sie den Accessibility Tree für jede Seite, die einen Hilfemechanismus enthält.
Relative Positionen über Seiten hinweg vergleichen: Öffnen Sie zwei oder mehr Seiten, die denselben Hilfemechanismus gemeinsam haben, nebeneinander (oder nacheinander). Identifizieren Sie für jeden Mechanismus seine Position relativ zu den umgebenden Landmark-Bereichen (<header>, <main>, <footer>, <nav>). Protokollieren Sie, ob der Mechanismus in demselben Landmark-Bereich und in derselben relativen Reihenfolge (vor oder nach benachbarten Elementen) auf jeder Seite erscheint. Eine Positionsänderung stellt einen potenziellen Verstoß dar.
Mit Tastaturnavigation testen (alle Browser): Tabben Sie durch jede Seite, die einen Hilfemechanismus enthält. Zählen Sie die Anzahl der Tabstopps, die erforderlich sind, um vom Seitenanfang zum Hilfemechanismus zu gelangen. Vergleichen Sie diese Anzahl über die Seiten hinweg. Ein signifikanter Unterschied – etwa erreichbar in 5 Tabs auf der Startseite, aber 47 Tabs auf der Checkout-Seite – weist auf eine Änderung der DOM-Reihenfolge hin, selbst wenn die visuelle Position ähnlich erscheint.
Mit NVDA + Firefox testen: Öffnen Sie die NVDA-Elementliste (NVDA-Taste + F7) und wechseln Sie zur Ansicht Links oder Buttons. Suchen Sie den Hilfemechanismus in der Liste. Notieren Sie seine Position relativ zu anderen aufgelisteten Elementen. Wiederholen Sie dies auf jeder Seite, auf der der Mechanismus erscheint, und vergleichen Sie die Positionen.
Mit VoiceOver + Safari (macOS/iOS) testen: Verwenden Sie den VoiceOver-Rotor (VO + U), um die Liste der Links oder Formularelemente zu öffnen. Navigieren Sie zum Hilfemechanismus und notieren Sie seine Position in der Liste. Vergleichen Sie die Positionen über die Seiten hinweg.
Mit JAWS + Chrome testen: Verwenden Sie die JAWS-Linkliste (Einfügen + F7), um den Hilfemechanismus zu finden. Notieren Sie seine Ordnungsposition und benachbarte Elemente. Wiederholen Sie dies über die Seiten hinweg.
Nutzerinitiierte Ausnahmen prüfen: Wenn die Website es Nutzern erlaubt, Hilfemechanismen neu zu positionieren oder auszublenden (z. B. ein verschiebbares Chat-Widget), verifizieren Sie, dass die Neupositionierung durch eine explizite Nutzeraktion ausgelöst wird und dass die Präferenz logisch beibehalten wird. Dokumentieren Sie dies als gültige Ausnahme unter dem Kriterium.
Auf mobilen Viewports prüfen: Responsive Layouts ordnen DOM-Elemente manchmal bei unterschiedlichen Breakpoints neu. Testen Sie sowohl auf Desktop- als auch auf mobilen Viewports (mindestens 375px und 1440px Breite), um zu bestätigen, dass der Hilfemechanismus bei allen gängigen Bildschirmgrößen eine konsistente relative Platzierung beibehält.

Wie man es behebt

Schwebendes Chat-Widget – Falsch

<!-- Seite A (Startseite): Chat-Button unten rechts -->
<div class='chat-widget' style='position:fixed; bottom:20px; right:20px;'>
  <button>Chat with Us</button>
</div>

<!-- Seite B (Checkout): Chat-Button nach unten links verschoben -->
<div class='chat-widget' style='position:fixed; bottom:20px; left:20px;'>
  <button>Chat with Us</button>
</div>
<!-- FAIL: Das Widget ändert seine feste Position zwischen den Seiten
     und verletzt damit die konsistente Hilfeplatzierung. -->

Schwebendes Chat-Widget – Richtig

<!-- Sowohl Seite A als auch Seite B: Chat-Button konsistent unten rechts -->
<div class='chat-widget chat-widget--bottom-right'>
  <button type='button' aria-label='Open live chat support'>
    Chat with Us
  </button>
</div>
<!-- PASS: Das Widget erscheint auf jeder Seite in derselben Ecke.
     Verwenden Sie eine CSS-Klasse, die in einem gemeinsamen Stylesheet
     definiert ist, statt Inline-Styles, sodass die Position zentral
     gesteuert und konsistent über alle Templates angewendet wird. -->

Hilfelink in der Navigation – Falsch

<!-- Seite A: Help ist das 4. Navigationselement -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>

<!-- Seite B (Produktdetail): Help-Link aus der Navigation entfernt
     und stattdessen in einem Footer-Bereich platziert -->
<footer>
  <a href='/help'>Help Center</a>
</footer>
<!-- FAIL: Der Help-Link ist von der Hauptnavigation in den Footer
     verschoben worden und hat seine relative Reihenfolge deutlich geändert. -->

Hilfelink in der Navigation – Richtig

<!-- Sowohl Seite A als auch Seite B verwenden dasselbe Navigationstemplate -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/products'>Products</a></li>
    <li><a href='/about'>About</a></li>
    <li><a href='/pricing'>Pricing</a></li>
    <li><a href='/help'>Help</a></li>
  </ul>
</nav>
<!-- PASS: Der Help-Link ist das 4. Element in der Hauptnavigation
     auf jeder Seite, auf der die Navigation vorhanden ist. Die Verwendung
     einer gemeinsamen Navigationskomponente oder eines Server-Side-Includes
     stellt sicher, dass dies automatisch beibehalten wird. -->

Bedingte Hilfeanzeige – Falsch

<!-- Auf ausgeloggten Seiten: Telefonnummer im Header -->
<header>
  <p>Need help? Call <a href='tel:+908501234567'>0850 123 45 67</a></p>
</header>

<!-- Auf eingeloggten Seiten: Telefonnummer aus dem Header entfernt
     und nur tief in einem Konto-Dropdown-Menü verfügbar -->
<header>
  <nav aria-label='Account menu'>
    <details>
      <summary>My Account</summary>
      <ul>
        <li><a href='/orders'>Orders</a></li>
        <li><a href='/contact'>Contact: 0850 123 45 67</a></li>
      </ul>
    </details>
  </nav>
</header>
<!-- FAIL: Die Kontaktnummer ändert ihre relative Position drastisch
     in Abhängigkeit vom Authentifizierungsstatus und wird für
     wiederkehrende Nutzer unvorhersehbar. -->

Bedingte Hilfeanzeige – Richtig

<!-- Sowohl auf ausgeloggten als auch auf eingeloggten Seiten: Telefon an derselben Header-Position -->
<header>
  <div class='header-support'>
    <a href='tel:+908501234567' aria-label='Call support: 0850 123 45 67'>
      <svg aria-hidden='true' focusable='false'><!-- phone icon --></svg>
      0850 123 45 67
    </a>
  </div>
  <nav aria-label='Account menu'>
    <!-- account links here -->
  </nav>
</header>
<!-- PASS: Der Kontaktmechanismus befindet sich unabhängig vom
     Authentifizierungsstatus immer an derselben Position im Header.
     Zusätzliche kontospezifische Links können an anderer Stelle
     erscheinen, ohne den Hilfemechanismus zu verschieben. -->

Häufige Fehler

Platzierung des Chat-Widgets in unterschiedlichen Ecken auf verschiedenen Seitentemplates: Entwicklungsteams verwenden häufig eine feste Positionierung für Chat-Widgets pro Template statt über ein globales Stylesheet, wodurch das Widget auf Marketingseiten unten rechts und auf App-Seiten unten links erscheint. Verwenden Sie eine einzige global eingebundene Komponente mit einer fixierten Positionsklasse.
Entfernen des Hilfelinks aus der Navigation auf Checkout-Seiten, um Unordnung zu reduzieren: Einige UX-Muster reduzieren die Navigation auf Checkout-Seiten bewusst, um die Conversion zu optimieren. Wenn ein Hilfemechanismus Teil dieser Navigation ist, führt das Entfernen auf diesem Seitentemplate zu einem Bruch der Konsistenz. Behalten Sie stattdessen den Hilfelink in einem minimalen Header auch in reduzierten Checkout-Flows bei.
Einbindung von Hilfemechanismen über Drittanbieter-Skripte, die mit unvorhersehbaren DOM-Positionen laden: Viele Live-Chat-SDKs injizieren ihr Widget asynchron in den DOM, und ihr Einfügepunkt kann je nach Skriptlade-Reihenfolge variieren. Dies kann dazu führen, dass das Widget an einer anderen Position im Accessibility Tree über Seiten hinweg erscheint. Konfigurieren Sie Drittanbieter-Widgets so, dass sie immer an ein festes, bekanntes DOM-Ankerelement angehängt werden.
Verwendung von CSS-order oder Flexbox/Grid-Umsortierung, um das Hilfeelement visuell zu verschieben, ohne die DOM-Reihenfolge zu ändern, und dann diese CSS-Einstellungen pro Seite zu variieren: Auch wenn die visuelle Position konsistent erscheinen mag, ändern seitenweise CSS-Overrides, die die visuelle Reihenfolge eines Hilfemechanismus verändern, dennoch die vom Nutzer wahrgenommene Reihenfolge und können Screenreader-Nutzer verwirren, deren Lesereihenfolge der DOM-Struktur folgt.
Verlassen auf A/B-Testing-Tools, die die Position des Hilfeelements zwischen Testvarianten tauschen: Wenn Nutzer in Variante A den Hilfe-Button in der oberen Leiste sehen und Nutzer in Variante B ihn im Footer sehen, erleben diese Nutzer eine inkonsistente Hilfeplatzierung über Seiten innerhalb ihrer Sitzung, da das A/B-Framework auf verschiedenen Seiten unterschiedliche Varianten anwendet. Stellen Sie sicher, dass A/B-Tests, die die Platzierung von Hilfemechanismen betreffen, die Variante konsistent über alle Seiten einer Sitzung anwenden.
Behandlung von authentifizierten und nicht authentifizierten Zuständen als unterschiedliche „Websites“ mit unterschiedlichen Hilfe-Layouts: Nutzer, die sich mitten in einer Sitzung einloggen, finden den Hilfemechanismus plötzlich an einem neuen Ort. Die Änderung des Authentifizierungsstatus ist im Kontext der Hilfeplatzierung nicht nutzerinitiiert, daher verstößt dies weiterhin gegen SC 3.2.6. Wenden Sie ein konsistentes Hilfe-Layout über alle Authentifizierungszustände hinweg an.
Einbettung der Hilfe-Telefonnummer nur in dichtem Footer-Text auf einigen Seiten und in einer dedizierten Header-Leiste auf anderen: Selbst wenn die Telefonnummer technisch auf allen Seiten vorhanden ist, stellt eine erhebliche Änderung ihrer relativen Position (vom ersten interaktiven Element im Header zu einem im Footer vergrabenen Element nach Hunderten von Links) einen Verstoß gegen die konsistente Reihenfolge dar.
Die Annahme, dass das Kriterium erfüllt ist, nur weil ein Hilfe-Symbol immer visuell „in der Ecke“ ist: Das Kriterium misst die relative Reihenfolge im Seiteninhalt, nicht nur absolute Pixelkoordinaten. Ein Chat-Symbol, das visuell immer unten rechts ist, aber an einem völlig unterschiedlichen Punkt in der DOM-Reihenfolge auf verschiedenen Seiten erscheint (z. B. unmittelbar nach dem <body>-Tag auf einer Seite und direkt vor dem schließenden </body>-Tag auf einer anderen), kann für Tastatur- und Screenreader-Nutzer dennoch einen Verstoß darstellen.
Versäumnis, responsive Breakpoints zu prüfen: Ein Hilfemechanismus, der bei Desktop-Breiten konsistent ist, kann bei schmalen Viewports ausgeblendet oder in ein mobiles Hamburger-Menü verschoben werden, was zu einer anderen Position auf Mobilgeräten führt. Wenn mobile Nutzer eine andere relative Position als Desktop-Nutzer erleben, sollte dies im Hinblick auf das Kriterium bewertet werden – insbesondere, wenn Mobilgeräte die primäre Zugriffsmethode für die Zielgruppe sind.
Unterlassen der Dokumentation von Hilfe-Mechanismus-Positionen in Designsystemen: Ohne einen dokumentierten Standard dafür, wo Hilfemechanismen erscheinen müssen, werden einzelne Entwicklerinnen, Entwickler und Designer unabhängige Entscheidungen treffen, die im Laufe der Zeit zu Inkonsistenzen führen. Fügen Sie Regeln zur Platzierung von Hilfemechanismen explizit in die Dokumentation Ihres Designsystems oder Ihrer Komponentenbibliothek ein.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt mit der Nummer 32933 am 21. Juni 2025, etabliert einen umfassenden nationalen Rahmen für digitale Barrierefreiheit. Die Verfügung schreibt die Konformität mit WCAG 2.2 Level AA als grundlegenden Barrierefreiheitsstandard für eine breite Palette digitaler Dienste vor, die in der Türkei betrieben werden. WCAG 3.2.6 Konsistente Hilfe fällt als Level-AA-Kriterium, das in WCAG 2.2 eingeführt wurde, direkt in den Geltungsbereich dieser gesetzlichen Verpflichtung.

Die von der Präsidialverfügung 2025/10 erfassten Entitätstypen umfassen: öffentliche Institutionen und Behörden auf zentraler und lokaler Verwaltungsebene; Banken und Finanzdienstleister, die der Aufsicht der Bankenregulierungs- und Aufsichtsbehörde (BDDK) unterliegen; E-Commerce-Plattformen und Online-Marktplätze; Krankenhäuser und Gesundheitsdienstleister, die patientenorientierte digitale Dienste anbieten; Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten; Reisebüros mit Online-Buchungssystemen; private Transportunternehmen, die Linienverkehre betreiben; sowie Privatschulen und Bildungseinrichtungen, die vom Bildungsministerium (MoNE) autorisiert sind. Für all diese Einrichtungen ist der vollständige Kriterienkatalog von WCAG 2.2 Level AA – einschließlich SC 3.2.6 – der anzuwendende Standard.

Die Einhaltung von WCAG 3.2.6 ist auch eine Voraussetzung für den Erhalt des Erişilebilirlik Logosu (Barrierefreiheitslogo), das vom türkischen Ministerium für Familie und Soziale Dienste (Aile ve Sosyal Hizmetler Bakanlığı) vergeben wird. Dieses Logo dient als offizielles Zeichen der Barrierefreiheitskonformität und wird von türkischen Verbraucherinnen, Verbrauchern und Beschaffungsverantwortlichen zunehmend als Qualitätssignal wahrgenommen. Organisationen, die dieses Logo anstreben, müssen eine vollständige WCAG-2.2-Level-AA-Konformität über ihre digitalen Angebote hinweg nachweisen, was bedeutet, dass eine inkonsistente Hilfeplatzierung – selbst wenn sie scheinbar geringfügig ist – eine Bewerbung disqualifizieren kann.

Aus praktischer Compliance-Perspektive ist SC 3.2.6 insbesondere für türkische E-Commerce- und Finanzdienstleister relevant, deren Websites und mobile Web-Apps typischerweise Live-Chat-Widgets, WhatsApp-Kontaktlinks und FAQ-Bereiche als primäre Kanäle für den Kundensupport bieten. Sicherzustellen, dass diese Hilfemechanismen auf Produktlistenseiten, Warenkorbseiten, Checkout-Flows und Kontoverwaltungsbereichen an konsistenten Positionen erscheinen, ist sowohl eine gesetzliche Verpflichtung im Rahmen der Verfügung als auch eine sinnvolle UX-Praxis zur Bedienung der vielfältigen Internetnutzerbasis der Türkei – zu der eine große Zahl von Erstnutzerinnen und -nutzern sowie Personen mit geringer Literalität im digitalen Bereich gehört, die am meisten von vorhersehbaren Interface-Mustern profitieren.

Organisationen, die der Verfügung unterliegen und die Platzierung ihrer Hilfemechanismen noch nicht geprüft haben, sollten eine Seiten-übergreifende Konsistenzprüfung als Priorität in ihre WCAG-2.2-Compliance-Roadmap aufnehmen. Da dieses Kriterium manuelle Tests erfordert, sollte es sowohl in Erstkonformitätsaudits als auch in laufende Qualitätssicherungszyklen einbezogen werden, insbesondere nach größeren Redesigns oder Template-Änderungen, die die Position von Hilfeelementen unbeabsichtigt verschieben könnten.