Wir möchten Ihr Feedback zu einem Lösungsvorschlag für das Problem, dass Layoutmethoden Elemente in einer Reihenfolge anordnen, die nicht mit der Quelle des Dokuments zusammenhängt.
Die CSS Working Group arbeitet an einer Lösung für den Fall, dass Elemente durch eine Layoutmethode in einer Reihenfolge angeordnet werden, die nicht mit der Quelle und damit auch 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 folgt 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. 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 und insbesondere mit Flexbox und Grid lassen sich jedoch Layouts erstellen, bei denen das Layout eine visuelle Leserichtung definiert, die sich von der zugrunde liegenden Quelle unterscheidet.
Wenn Sie beispielsweise die order-Property für Flex-Elemente verwenden, ändert sich die Layoutreihenfolge, aber nicht die Reihenfolge in der Quelle.
Bei der Verwendung des Rasterlayouts kann es vorkommen, dass die Tab-Reihenfolge durch die ausgewählte Layoutmethode durcheinandergebracht wird, z. B. bei Verwendung von grid-auto-flow: dense, wodurch eine zufällige Layoutreihenfolge von Elementen erstellt wird.
Ein Entwickler kann diese Trennung auch verursachen, indem er Elemente im Raster in einer anderen Reihenfolge als in der Quelle angibt.
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 Barrierefreiheits-Community zu diesem Ansatz freuen.
Randomisierte Layouts mit reading-order: auto
In Situationen, in denen eine zufällige Layoutreihenfolge entsteht, z. B. bei der Verwendung von „dense packing“ im Rasterlayout, soll der Browser wahrscheinlich dem Layout und nicht der Quellreihenfolge folgen. Dazu müssen die Flex- oder Grid-Elemente eine reading-order-Eigenschaft mit dem Wert auto haben.
Mit dem folgenden CSS wird die Lesereihenfolge durch die Platzierung von Elementen bestimmt, 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;
}
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 Reihenfolge von Elementen mit der order-Eigenschaft geändert wird, gibt es beispielsweise eine offensichtliche Layoutreihenfolge, die durch die order-Eigenschaft vorgegeben wird. Bei anderen Layouts ist es 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 die Property grid-order-items hinzufügen. Mit Keyword-Werten können Sie Ihre Absicht für die Layoutreihenfolge erläutern.
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 und nicht 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 mit grid-template-areas ein Rasterlayout erstellt. Die Elemente werden in einer anderen Layoutreihenfolge als in der Quellreihenfolge platziert. Mit dem Attribut reading-order-items wird angegeben, dass wir der Layoutreihenfolge folgen und jede Zeile durchlaufen sollen, bevor wir zur nächsten übergehen. 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 spielt weiterhin eine Rolle. Diese Funktion sollte nur in bestimmten Situationen verwendet werden, in denen die Leserichtung von der Quelle abweichen kann. Das kann beispielsweise bei Layoutmethoden der Fall sein, die zu einer solchen Trennung führen können, z. B. bei der dichten Rasteranordnung, oder wenn bei einem bestimmten Breakpoint eine andere Layoutreihenfolge 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 Breakpoints hinzu, an denen sie erforderlich sind.
Sollten diese Eigenschaften in Authoring-Tools angewendet werden?
Autorentools, mit denen Nutzer ein Rasterlayout durch Ziehen und Ablegen von Elementen erstellen können, sollten Nutzer weiterhin 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 geben Sie uns 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. Beachten Sie, dass sich der aktuelle Vorschlag stark von meinem ursprünglichen Vorschlag unterscheidet, mit dem der Thread begonnen wurde. Interessierte können sich die gesamte Diskussion 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.