Aufheben der Verknüpfung des CSS-Layouts und der Quellenreihenfolge

Ihr Feedback ist zu einer vorgeschlagenen Lösung für das Problem gefragt, dass Layoutmethoden Elemente in einer Reihenfolge anordnen, die nicht mit der Quelle des Dokuments übereinstimmt.

Rachel Andrew Technical Writer

Die CSS Working Group arbeitet an einer Lösung für die Situation, in der eine Layoutmethode Elemente in einer Reihenfolge anordnen kann, die nicht mit der Quelle und daher nicht mit der Lese- und Fokusreihenfolge des Dokuments übereinstimmt. In diesem Artikel werden das Problem und die vorgeschlagene Lösung erläutert. Wir freuen uns über Ihr Feedback.

Das Problem

Die Lesereihenfolge eines HTML-Dokuments entspricht der Quellreihenfolge. Das bedeutet, dass ein Screenreader das Dokument so vorliest, wie es in der Quelle angeordnet ist. Auch Personen, die mit der Tastatur durch das Dokument navigieren, folgen dieser Reihenfolge. Normalerweise ist das sinnvoll und eine sinnvolle Quellreihenfolge für das Dokument ist für die Darstellung von Inhalten im Lesemodus, für Screenreader und für Geräte mit eingeschränktem CSS unerlässlich. Mit CSS, insbesondere mit Flexbox und Grid, können jedoch Layouts erstellt werden, bei denen die visuelle Lesereihenfolge von der zugrunde liegenden Quelle abweicht.

Wenn Sie beispielsweise die Property order für Flex-Elemente verwenden, ändert sich die Layoutreihenfolge, aber nicht die Reihenfolge in der Quelle.

Bei einem Rasterlayout kann es vorkommen, dass die gewählte Layoutmethode die Tabulatorreihenfolge durcheinanderbringt, z. B. wenn grid-auto-flow: dense verwendet wird, wodurch eine zufällige Layoutreihenfolge der Elemente erstellt wird.

Ein Entwickler kann diese Trennung auch verursachen, indem er Elemente in einer anderen Reihenfolge im Raster platziert als in der Quelle angegeben.

Vorgeschlagene Lösung

Die CSS Working Group schlägt eine Lösung für dieses Problem vor und würde sich über Feedback von Entwicklern und der Accessibility-Community zu diesem Ansatz freuen.

Zufällige Layouts mit reading-order: auto

In Situationen, in denen eine zufällige Layoutreihenfolge erstellt wird, z. B. bei der Verwendung von dichter Packung im Rasterlayout, möchten Sie wahrscheinlich, dass der Browser dem Layout und nicht der Quellreihenfolge folgt. Dazu müssen die Flex- oder Grid-Elemente eine reading-order-Eigenschaft mit dem Wert auto haben.

Mit dem folgenden CSS wird die Leserichtung an die Platzierung von Elementen angepasst, die aufgrund von grid-auto-flow: dense dicht gepackt wurden.

.cards {
  display: grid;
  grid-auto-flow: dense;
}

.cards li {
  grid-column: auto / span 2;
  reading-order: auto;
}

Folgende nicht randomisierte Layouts mit reading-order-items

Bei einigen Raster- und Flex-Layouts ist die Layoutreihenfolge leicht nachzuvollziehen. In einem Flex-Layout, in dem die Elemente mit dem Attribut order neu angeordnet werden, gibt es beispielsweise eine offensichtliche Layoutreihenfolge, die durch das Attribut order vorgegeben wird. Bei anderen Layouts ist weniger klar, was die ideale Reihenfolge ist. Es kann mehr als eine mögliche Auswahl geben. Wenn Sie also nicht randomisierte Layouts verwenden, müssen Sie dem Container das Attribut grid-order-items mit Keyword-Werten hinzufügen, die Ihre Absicht für die Layoutreihenfolge erklären.

Das folgende Beispiel zeigt ein flexibles Layout mit row-reverse. Die Flex-Elemente haben reading-order: auto und der Flex-Container reading-order-items: flex flow, um anzugeben, dass die Leserichtung auch der flex-flow-Richtung folgen soll, anstatt einer visuellen Reihenfolge (die wir mit flex visual angeben könnten).

.cards {
  display: flex;
  flex-flow: row-reverse;
  reading-order-items: flex flow;
}

.cards li {
  reading-order: auto;
}

Im nächsten Beispiel wird ein Rasterlayout mit grid-template-areas erstellt und die Elemente werden in einer anderen Layoutreihenfolge als der Quellreihenfolge platziert. Mit dem Attribut reading-order-items wird angegeben, dass die Layoutreihenfolge eingehalten werden soll. Dabei wird jede Zeile durchlaufen, bevor zur nächsten übergegangen wird. (grid column würde die entgegengesetzte Richtung angeben).

.wrapper {
  display: grid;
  grid-template-columns: repeat(6, minmax(0, 1fr));
  grid-template-areas:
    "a a b b b b"
    "c c d d e e"
    "f f g g h h";
  reading-order-items: grid rows;
}

.a {
  grid-area: a;
  reading-order: auto;
}

Bedeutet das, dass die Reihenfolge der Quellen keine Rolle spielt?

Nein, die Reihenfolge der Quellen ist weiterhin wichtig. Diese Funktion sollte nur in bestimmten Situationen verwendet werden, in denen die Lesereihenfolge von der Quelle abweichen kann. Beispielsweise, wenn Sie Layoutmethoden verwenden, die diese Diskrepanz verursachen können, wie z. B. dichte Rasterpackung, oder wenn eine andere Layoutreihenfolge bei einem bestimmten Haltepunkt sinnvoll ist.

Wenn Sie diese Eigenschaften verwenden, erstellen Sie ein Quelldokument mit einer Reihenfolge, die sinnvoll wäre, wenn die Seite ohne CSS gerendert würde. Fügen Sie diese Properties nur an den Stellen und bei den Haltepunkten hinzu, an denen sie erforderlich sind.

Sollten diese Eigenschaften in Authoring-Tools angewendet werden?

Autorentools, mit denen Nutzer ein Rasterlayout per Drag-and-drop erstellen können, sollten Nutzer dennoch dazu anregen, ein sinnvolles Quelldokument zu erstellen. Daher ist es in den meisten Fällen besser, die Quelle basierend auf der Layoutreihenfolge neu anzuordnen, anstatt diese Eigenschaften als einfache Lösung für die Diskrepanz zu verwenden.

Bitte gib uns dein Feedback zu diesem Vorschlag

Wir freuen uns auf Ihr Feedback. Wenn Sie einen Anwendungsfall haben, für den diese Lösung nicht geeignet ist, oder Bedenken hinsichtlich der Barrierefreiheit haben, teilen Sie dies bitte der CSS Working Group mit.

Es gibt einen laufenden Thread mit vielen Anwendungsfällen und Überlegungen zum Ansatz. In diesem Thread können Sie Kommentare hinzufügen und auf potenzielle Probleme mit diesem Vorschlag hinweisen. Das aktuelle Angebot unterscheidet sich stark von meinem ursprünglichen Vorschlag, mit dem der Thread begonnen hat. Interessierte können sich die gesamte Unterhaltung ansehen, die zu dem geführt hat, was wir heute haben. Sie ist ein gutes Beispiel dafür, wie Vorschläge in der CSS Working Group bearbeitet werden, damit sie in Browsern implementiert werden können.

Miniaturansicht von Patrick Tomasso. Vielen Dank an Chris Harrelson, Tab Atkins und Ian Kilpatrick für Feedback und Überprüfung.