Het oplossen van de CSS-lay-out en de bronvolgorde

We willen graag uw feedback op een voorgestelde oplossing voor het probleem dat lay-outmethoden items rangschikken in een volgorde die losstaat van de bron van het document.

De CSS Working Group werkt aan een oplossing voor het probleem waarbij een lay-outmethode elementen in een volgorde plaatst die niet overeenkomt met de broncode en dus ook niet met de lees- en focusvolgorde van het document. Dit artikel legt het probleem en de voorgestelde oplossing uit. We stellen uw feedback zeer op prijs.

Het probleem

De leesvolgorde van een HTML-document volgt de volgorde van de broncode. Dit betekent dat een schermlezer het document leest zoals het in de broncode is opgemaakt, en dat iemand die met de tabtoets door het document navigeert, ook die volgorde volgt. Meestal is dit logisch, en een verstandige volgorde van de broncode is essentieel voor de weergave van content in leesmodus, schermlezers en apparaten met beperkte CSS-functionaliteit. CSS, en met name flexbox en grid, kunnen echter lay-outs creëren waarbij de lay-out een visuele leesvolgorde definieert die afwijkt van de onderliggende broncode.

Het gebruik van de eigenschap order op flex-items verandert bijvoorbeeld de volgorde in de lay-out, maar niet de volgorde in de broncode.

Klik op het voorbeeld en navigeer met de tabtoets om te zien hoe de tabvolgorde losgekoppeld is van de lay-outvolgorde, met behulp van de eigenschap `order`.

Bij gebruik van een rasterindeling is het mogelijk dat de gekozen indelingsmethode de tabvolgorde door elkaar gooit, bijvoorbeeld bij gebruik van grid-auto-flow: dense , wat een willekeurige indeling van items creëert.

Klik op het voorbeeld en navigeer met de tabtoets om te zien hoe de tabvolgorde losgekoppeld is van de lay-outvolgorde, ditmaal door de items in een raster in een andere volgorde te rangschikken.

Een ontwikkelaar kan deze discrepantie ook veroorzaken door items in een andere volgorde op het raster te plaatsen dan in de broncode is voorgeschreven.

Klik op het voorbeeld en navigeer met de tabtoets om te zien hoe de tabvolgorde losgekoppeld is van de lay-outvolgorde door gebruik te maken van rasterplaatsingseigenschappen.

Voorgestelde oplossing

De CSS Working Group stelt een oplossing voor dit probleem voor en zou graag feedback ontvangen van ontwikkelaars en de toegankelijkheidsgemeenschap over deze aanpak.

De volgende lay-outs worden willekeurig gegenereerd met reading-order: auto

In situaties die een willekeurige lay-outvolgorde creëren, zoals bij het gebruik van dense packing in een grid-layout, wilt u waarschijnlijk dat de browser de lay-out volgt in plaats van de volgorde van de broncode. Om dit te bewerkstelligen, moeten de flex- of grid-elementen een ` reading-order eigenschap hebben met de waarde ` auto .

De volgende CSS zorgt ervoor dat de leesvolgorde de plaatsing van items volgt die dicht op elkaar staan ​​als gevolg van grid-auto-flow: dense .

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

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

Na niet-gerandomiseerde lay-outs met reading-order-items

Bij sommige grid- en flex-layouts is de volgorde van de elementen eenvoudig te begrijpen. Bijvoorbeeld, bij een flex-layout die de eigenschap order gebruikt om elementen opnieuw te rangschikken, is er een duidelijke volgorde die wordt bepaald door de eigenschap order . Bij andere layouts is het minder duidelijk wat de ideale volgorde is; er kunnen meerdere mogelijke opties zijn. Daarom moet u bij niet-gerandomiseerde layouts de eigenschap grid-order-items toevoegen aan de container, met trefwoordwaarden die uw intentie voor de volgorde van de elementen verklaren.

Het volgende voorbeeld toont een flex-layout met row-reverse . De flex-items hebben reading-order: auto , en de flex-container heeft reading-order-items: flex flow om aan te geven dat we ook de leesvolgorde de flex-flow richting willen laten volgen, in plaats van een visuele volgorde (die we zouden kunnen aangeven met flex visual ).

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

.cards li {
  reading-order: auto;
}

In het volgende voorbeeld wordt een rasterindeling gemaakt met behulp van grid-template-areas en worden de items in een andere volgorde geplaatst dan in de bronindeling. De eigenschap reading-order-items wordt gebruikt om aan te geven dat we de lay-outvolgorde moeten volgen en elke rij moeten doorlopen voordat we naar de volgende gaan. ( grid column zou de tegenovergestelde richting aangeven).

.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;
}

Betekent dit dat de volgorde van de bronnen er niet toe doet?

Nee, de volgorde in de broncode is nog steeds belangrijk. Deze functionaliteit moet alleen worden gebruikt in specifieke situaties waarin de leesvolgorde kan afwijken van de broncode. Bijvoorbeeld bij het gebruik van lay-outmethoden die deze discrepantie kunnen veroorzaken, zoals een dicht raster, of wanneer een andere lay-outvolgorde zinvol is op een bepaald breakpoint.

Wanneer je deze eigenschappen gebruikt, maak dan een brondocument aan in een volgorde die logisch zou zijn als de pagina zonder CSS zou worden weergegeven. Voeg deze eigenschappen alleen toe op de plaatsen en bij de breakpoints waar ze nodig zijn.

Moeten auteurstools deze eigenschappen toepassen?

Ontwerptools waarmee gebruikers een rasterindeling kunnen maken door elementen te slepen en neer te zetten, zouden gebruikers nog steeds moeten aanmoedigen om een ​​logische broncode te creëren. Daarom is het in de meeste gevallen beter om de broncode te herschikken op basis van de lay-outvolgorde, in plaats van deze eigenschappen te gebruiken als een gemakkelijke manier om de discrepantie te verbergen.

Graag ontvang ik uw feedback op dit voorstel.

We willen graag feedback hierover ontvangen. In het bijzonder, als u een gebruikssituatie hebt die volgens u hiermee niet wordt opgelost, of als u zich zorgen maakt over de toegankelijkheid van deze aanpak, laat het de CSS-werkgroep dan weten.

Er is een lopende discussie met veel gebruiksscenario's en ideeën over de aanpak. Die discussie is een uitstekende plek om opmerkingen te plaatsen en mogelijke problemen met dit voorstel aan te kaarten. Houd er rekening mee dat het huidige voorstel heel anders is dan mijn oorspronkelijke voorstel waarmee de discussie begon. Geïnteresseerden zullen wellicht de hele discussie die tot dit punt heeft geleid interessant vinden, omdat het een goed voorbeeld is van hoe voorstellen binnen de CSS Working Group worden uitgewerkt om uiteindelijk in browsers te kunnen worden geïmplementeerd.

Miniatuurafbeelding door Patrick Tomasso . Met dank aan Chris Harrelson, Tab Atkins en Ian Kilpatrick voor hun feedback en beoordeling.