Wenn feste Elemente Schaltflächen verdecken, können Kunden die Seite sehen und trotzdem die nächste nötige Aktion nicht erreichen. Kopfbereich, untere Leiste und geöffnetes Widget passen einzeln in den Entwurf, besetzen gemeinsam aber den Aufgabenbereich. Prüfe eine konkrete Schaltfläche im tatsächlichen Ablauf statt nur den Anfangsbildschirm. Das betrifft Conversions auf Mobilgeräten, kann jedoch auch am Desktop nach Vergrößerung oder während der Tastaturnavigation auftreten und das Fortsetzen verhindern.
Wähle die nicht ausführbare Aktion
Beginne mit einer nötigen Aktion wie Weiter nach der Variantenauswahl statt einer Liste sämtlicher fester Elemente. Notiere Bildschirm, Aufgabenstand und Position der Schaltfläche im erforderlichen Moment. Kläre, ob Sehen, Auswählen oder Lesen der Beschriftung betroffen ist. Eine teilweise sichtbare Schaltfläche kann auf den Zeiger reagieren, doch Kunden sollten weder ihren Text erraten noch ein winziges freies Stück suchen müssen, um die Aufgabe erfolgreich fortsetzen zu können.
Beschreibt die Meldung „Es geht nicht weiter“, reproduziere den Weg und prüfe die Aktivierung der Aktion. Nicht jeder Fehlversuch ist eine Kollision; eine fehlende Auswahl oder ein Aufgabenfehler kann die Ursache sein. Notiere, ob das verdeckende Element immer oder erst nach Scrollen, Widgetöffnung oder Ausrichtungswechsel erscheint. Das begrenzt die Korrektur auf ein konkretes Layout, statt ohne bestätigte Ursache eine umfassende Änderung der gesamten Seite auszulösen und dabei andere funktionierende Wege zu verändern.
Kartiere dauerhaft belegte Bildschirmflächen
Erfasse Elemente mit fester Bildschirmposition oder haftendem Verhalten beim Scrollen. Notiere Kopfbereich, untere Aktionsleiste, schwebenden Kontaktknopf und geöffnetes Fenster im geprüften Zustand. Ordne jedem Rand, belegte Fläche und Erscheinungsmoment zu. Analysiere nicht ausschließlich Ebenennummern: Eine über das Fenster gehobene Schaltfläche kann sichtbar werden und dafür Informationen verdecken, die zur Entscheidung gebraucht werden, sodass das ursprüngliche Hindernis nur an eine andere Stelle der Aufgabe wandert.
Prüfe nach dem Laden und nach Aufgabenbeginn, weil Widget oder Leiste später hinzukommen können. Behalte relevante Zustände bei, statt vor dem Screenshot alle Fenster einzuklappen. Nutze für Kontaktzugang den Artikel über zugängliche Kontaktwege. Das Ziel ist gleichzeitig ausführbare Aufgabe und erreichbarer Kontakt, nicht die Freilegung eines Knopfs durch vollständige Entfernung eines benötigten Kommunikationswegs, den der Kunde gerade während der Bearbeitung zur Klärung einer Frage verwenden möchte.
Prüfe Breite, Vergrößerung und Zustand systematisch
Eine Matrix verändert gezielt die Bedingungen möglicher Kollisionen. Wähle einen unterstützten schmalen Bildschirm, typische Desktopansicht, passende Vergrößerung sowie geöffnetes und eingeklapptes Widget. Die Tabelle zeigt Versuche für eine Aktion ohne universelle Größen für jede Website. Notiere Ergebnis und Aufgabenstand je Versuch, damit die korrigierende Person den Zusammenstoß reproduzieren kann, ohne ihn auf einem zufälligen anderen Bildschirm zu suchen, der die entscheidenden Bedingungen gar nicht enthält.
Scrolle die Tabelle seitlich, um alle Spalten zu sehen.
| Bedingung | Mögliche Kollision | Versuch |
|---|---|---|
| Schmaler Bildschirm | Untere Leiste belegt den Schaltflächenbereich | Zum Abschnittsende scrollen und Zugriff prüfen |
| Vergrößerte Ansicht | Kopfbereich verdeckt oberen Inhalt | Nach Zoomänderung zur Schaltfläche gehen |
| Tastaturnavigation | Fokus landet unter einem festen Element | Den gesamten Tab-Weg zur Aktion beobachten |
| Offenes Widget | Fenster verdeckt randnahe Schaltfläche | Offenen und eingeklappten Zustand vergleichen |
Prüfe am Telefon die offene Bildschirmtastatur, wenn vor der Aktion eine Eingabe erfolgt. Der verfügbare Bereich kann sich mitten in der Aufgabe ändern, obwohl die Startansicht korrekt wirkte. Teste das Scrollen der Schaltfläche über die untere Leiste, statt weiteren Fingerbewegungen automatisch Erfolg zuzuschreiben. Fehlt dafür Seitenraum, beschreibe den konkreten fehlenden Scrollbereich und nicht nur „Mobil sieht schlecht aus“, damit die Korrektur ein nachvollziehbares Platzproblem statt einer subjektiven Gesamteinschätzung behandelt.
Erreiche das fokussierte Element per Tastatur
Die Tastaturprüfung folgt der natürlichen Reihenfolge zur Aktion und setzt keinen Zeiger auf eine schon sichtbare Schaltfläche. Beobachte die Sichtbarkeit bei Fokus und die Scrollposition der Seite. Ein fester Kopfbereich kann die gerade vom Browser erreichte Kontrolle verdecken. Auch wer den Namen kennt oder hört, braucht einen sichtbaren Arbeitsbereich; funktionierendes Enter allein löst daher die Kollision nicht und sagt wenig über die Orientierung während der weiteren Bearbeitung aus.
Notiere vollständige oder teilweise Verdeckung und deren Ursache. W3C F110 beschreibt die vollständige Verdeckung eines fokussierten Elements durch festen Kopf- oder Fußbereich; übertrage diese Bewertung nicht auf jeden überlappenden Pixel. Eine teilweise verdeckte Beschriftung oder Zielfläche kann trotzdem ein echtes Nutzbarkeitsproblem sein. Sowohl die Kriterienbewertung als auch der praktische Aufgabenfehler brauchen klaren Nachweis statt eines allgemeinen Eindrucks, der nur aus einem einzelnen Bildschirmfoto ohne den vorhergehenden Tastaturweg entstanden ist.
Die W3C-Technik F110 behandelt vollständig verdeckte fokussierte Elemente durch einen feststehenden Kopf- oder Fußbereich. Teilweise Kollisionen brauchen ebenfalls eine Nutzbarkeitsprüfung, sind aber nicht automatisch derselbe beschriebene Fehlerfall.
Verbinde Aufzeichnung und manuelle Wiederholung
Eine verfügbare Aufzeichnung kann den Moment zeigen, in dem Fenster und Leiste auf die Schaltfläche treffen. Markiere vorherige Handlung, Elementanzeige und weitere Versuche ohne Absichtszuschreibung allein aus Bewegungen. Ein Bild dieser Stelle hilft beim Lokalisieren, beweist aber nicht das Verhalten sämtlicher Bildschirmgrößen. Bestätige den Zustand kontrolliert mit passender Breite und aktiven Elementen, bevor du die Korrektur dem Oberflächenverantwortlichen zuweist und aus der Beobachtung eine technische Anforderung machst.
Nutze die Regeln der Analyse von Sitzungsaufzeichnungen mit ihrem Erfassungsumfang. Prüfe verfügbare Wege in der Meetlead-Analyse, Fokus und vollständige Verdeckung aber auch manuell. Eine Aufnahme ersetzt keine Tastaturprüfung. Beurteile nicht die gesamte Barrierefreiheit der Website anhand einer Person, wenn die Frage eine bestimmte Aktion unter einem definierten Layoutzustand betrifft, dessen Bedingungen für einen belastbaren Befund gezielt wiederholt werden müssen.
Wähle die Korrektur für die konkrete Kollision
Eine Korrektur kann schwebende Elemente verschieben, Platz unter einer Leiste reservieren oder Scrollen am Kopfbereich ausrichten. Entscheidend sind tatsächliches Layout und wichtiger Inhalt, nicht ein universeller Abstandswert. Beschreibe das Ergebnis: „Bei offenem Kontaktfenster bleibt Weiter sichtbar und per Tastatur erreichbar“. Stimme die Umsetzung mit dem Oberflächenverantwortlichen und vorhandenen Gestaltungsregeln ab, statt einen isolierten Sonderweg zu schaffen, dessen Folgen für andere Ansichten noch nicht geprüft wurden.
Korrigiere nicht einen Bildschirm durch zufällige Ebenenänderung ohne Prüfung anderer Kontrollen. Nach dem Verschieben muss das Fenster weiterhin schließbar und seine innere Aktion nutzbar sein. Nach zusätzlichem Platz prüfe Inhaltsende und unnötige Leerflächen in anderen Zuständen. Wiederhole die Matrix derselben Aktion, damit die Bewertung zur ursprünglichen Kollision gehört und nicht nur zu einem neuen bequemen Screenshot, auf dem der problematische Zustand zufällig nicht mehr aktiv ist.
Prüfe das Fortsetzen nach der Änderung
Der letzte Versuch bestätigt Ausführung der früher verdeckten Aktion und Erkennbarkeit ihres Ergebnisses. Sichtbare Beschriftung reicht nicht, wenn ein anderes Element Auswahl abfängt oder Fokus falsch landet. Gehe den Weg mit offenem sowie geschlossenem Fenster und auf schmalem Bildschirm durch. Notiere den Aufgabenabschluss, ohne eine freigelegte Schaltfläche als Geschäftskonversion zu behandeln, die noch gar nicht durch ein tatsächliches Ergebnis der ausführenden Anwendung bestätigt wurde.
Manche Kollisionen erscheinen auf selten besuchten Seiten, etwa nach einem defekten Link. Prüfe dabei den Rückweg zur Aufgabe von einer 404-Seite, deren weiterführender Link ebenfalls erreichbar bleiben muss. Wiederholte Bedingungen und abschließender Versuch genügen für diese begrenzte Korrektur. Bewahre die Beschreibung bei der Aufgabe, damit eine spätere Leistenänderung die entfernte Kollision nicht zurückbringt und das Team den schon bekannten Fall erneut von Grund auf untersuchen muss.
Fragen zu verdeckten Schaltflächen
Reicht ein kleineres Widget? Manchmal, aber erst nach Prüfung des tatsächlichen verdeckenden Elements. Die Ursache kann untere Leiste, Kopfbereich oder fehlender Scrollraum sein.
Verschieben oder Layoutänderung kann geeigneter als Verkleinern sein. Prüfe danach auch die Bedienbarkeit der Kontrollen im Widget.
Ist eine teilweise sichtbare Schaltfläche unproblematisch? Das darfst du nicht annehmen. Kunden müssen Beschriftung erkennen und Aktion auch per Tastatur ausführen.
Trenne die Bewertung vollständiger Verdeckung von anderen Nutzbarkeitsproblemen. Halte Beobachtung und erforderliches Ergebnis fest, statt die Prüfung mit dem sichtbaren Reststück zu beenden.
