In februari 2025 kregen we flexibele secties in SharePoint. De reactie was vrijwel unaniem enthousiast. Eindelijk konden redacteuren webparts neerzetten waar ze wilden, ze schalen, ze over elkaar heen leggen. Geen vaste kolommen meer.
Anderhalf jaar later is de praktijk genuanceerder. Veel redacteuren hebben het één keer geprobeerd en zijn teruggegaan naar de vertrouwde drie kolommen. Niet omdat de functie niet werkt, maar omdat vrijheid zonder houvast lastig is. Je bouwt iets op een breed scherm, het ziet er goed uit, en op een telefoon of in een e-mail valt de compositie uit elkaar.
Deze maand rolt Microsoft verbeteringen uit die dat aanpakken. Ze zijn in de aankondiging beschreven als een gebruiksverbetering. In de praktijk raken ze iets breders: wie in jouw organisatie bepaalt hoe een pagina eruitziet, en wie controleert of hij nog leesbaar is voor iedereen.
Waar we vandaan komen
Een flexibele sectie laat de kolomstructuur los. In plaats van één, twee of drie kolommen krijg je een raster waarin je webparts vrij plaatst. Je kunt ze schalen, over elkaar heen leggen en groeperen zodat ze samen bewegen.
Twee beperkingen die vanaf het begin gelden en die vaak vergeten worden:
Niet elk webpart schaalt vrij. Tekst, Afbeelding en Bestand en media kun je op vrijwel elke breedte zetten. Kaartgebaseerde webparts zoals Snelkoppelingen, Personen en Hero hebben vier vaste breedtes: volledig, tweederde, de helft en een derde van het canvas. Aangepaste SPFx-webparts krijgen standaard diezelfde vier opties.
Op mobiel en in e-mail wordt het altijd één kolom. Overlappende webparts bestaan daar niet. Ze worden onder elkaar gestapeld. In de sectie-eigenschappen kies je in welke volgorde dat gebeurt: van boven naar beneden, of van links naar rechts.
Die tweede beperking is precies waar de meeste teleurstelling zat. Je ontwerpt in twee dimensies, maar de helft van je lezers krijgt één dimensie te zien.
Wat er nu verandert
De aankondiging staat in het Message Center onder MC1446804 en op de roadmap onder ID 567889. De uitrol is wereldwijd, begon medio augustus 2026 en zou eind augustus afgerond moeten zijn. Er is geen actie van beheerders nodig. De functies verschijnen vanzelf.
Drie dingen veranderen.
1. Hulplijnen voor de indeling
In het sectievenster, onder het tabblad Indeling, kies je nu een hulplijnindeling. De opties heten precies zoals de kolomindelingen die je al kent: Geen, Eén kolom, Twee kolommen, Drie kolommen, 1/3 links, 1/3 rechts. Nieuwe webparts lijnen standaard uit op de breedte van die hulplijn. Je kunt daarna nog steeds alles verplaatsen en schalen.
Dat klinkt als een uitlijnhulp. Dat is het niet helemaal. De toelichting in de interface zegt dat de hulplijnen bepalen hoe inhoud wordt verplaatst wanneer de grootte van de sectie verandert. Ze sturen dus het herschikgedrag aan, niet alleen de plaatsing tijdens het bewerken. Samen met de bestaande instelling voor mobiel en e-mail bepaal je daarmee vooraf hoe je ontwerp zich gedraagt op een scherm dat je niet hebt getest.
Dat is het echte verschil met de situatie van anderhalf jaar geleden. Toen was responsief gedrag iets wat je achteraf controleerde in de preview. Nu is het iets wat je vooraf instelt.
2. Raster permanent zichtbaar
Er komt een schakelaar in de opdrachtbalk waarmee je raster en hulplijnen zichtbaar houdt tijdens het bewerken. Daarnaast is er een instelling op paginaniveau voor hetzelfde.
Tot nu toe verschenen de hulplijnen pas op het moment dat je een webpart begon te slepen. Je moest dus iets verplaatsen om te zien of het al goed stond. Klein ongemak, maar het verklaart waarom veel redacteuren het gevoel hadden dat ze aan het gokken waren.
3. Een bestaande sectie omzetten
Dit is de meest onderschatte van de drie. Je kunt een bestaande standaardsectie omzetten naar een flexibele sectie vanuit het eigenschappenvenster van die sectie. De kolomindeling en de plaatsing van de webparts blijven daarbij behouden.
Waarom dat telt: tot nu toe was experimenteren met flexibele secties gelijk aan opnieuw beginnen. Je bestaande nieuwspagina of afdelingspagina moest je van voren af aan opbouwen. Dat is precies de reden waarom veel redacteuren het na één poging lieten zitten. Die drempel verdwijnt.
Eén kanttekening. De documentatie van Microsoft stelde tot nu toe expliciet dat wisselen tussen flexibele en andere sectietypen niet wordt ondersteund. De aankondiging beschrijft alleen de richting standaard naar flexibel. Over de weg terug staat niets. Ga er voorlopig van uit dat conversie eenrichtingsverkeer is en test het op een kopie voordat je het op een gepubliceerde pagina doet.
Het punt dat in geen enkele aankondiging staat
Hier wordt het interessant voor wie verantwoordelijk is voor digitale toegankelijkheid.
In een flexibele sectie volgen de leesvolgorde en de tabvolgorde niet de positie op het canvas. Ze volgen de volgorde waarin de webparts zijn toegevoegd. Dat is meerdere keren gemeld door mensen die het hebben getest, ook in de reacties onder Microsofts eigen aankondiging van de functie.
Wat dat betekent in de praktijk: je kunt een pagina bouwen die er visueel logisch uitziet en die voor een schermlezer of iemand die met het toetsenbord navigeert in een willekeurige volgorde wordt voorgelezen. De blokken staan visueel netjes van links naar rechts, maar worden voorgelezen in de volgorde waarin de redacteur ze toevallig heeft neergezet.
Voor overheden en zorginstellingen raakt dat direct aan verplichtingen. WCAG 1.3.2 gaat over betekenisvolle volgorde, 2.4.3 over focusvolgorde. Beide zijn niveau A. Dit is geen theoretisch risico.
De conversiefunctie maakt dit relevanter dan het was. Een omgezette sectie erft de volgorde van de oorspronkelijke kolommen, en die was waarschijnlijk correct. Maar zodra een redacteur daarna dingen gaat verslepen, kunnen kijkvolgorde en leesvolgorde uit elkaar lopen zonder dat iemand het merkt. Precies de handeling die deze update makkelijker maakt.
Dit is geen reden om flexibele secties te vermijden. Het is wel een reden om de test in je werkwijze op te nemen. Doorloop de pagina één keer met de Tab-toets voordat je publiceert. Als de focus van links onder naar rechts boven springt, klopt de volgorde niet.
Wat dit betekent voor je afspraken
De hulplijnen zijn een instelling per sectie. Niet per pagina, niet per site. Dat betekent dat consistentie tussen pagina’s niet vanzelf ontstaat.
Grofweg zijn er twee routes, met verschillende kosten.
Vooraf vastleggen. Je bepaalt welke hulplijnindelingen passen bij welk paginatype, legt dat vast in paginatemplates en sectietemplates, en informeert je redacteuren voordat ze de nieuwe knoppen zien verschijnen. Kost tijd en overleg. Levert eenheid op en een pagina die er over twee jaar nog steeds uitziet zoals bedoeld.
Achteraf bijsturen. Je laat het gebeuren, kijkt wat redacteuren ermee doen en corrigeert waar het misgaat. Kost minder voorbereiding. Levert meer variatie op, en de kans dat je pas bij een toegankelijkheidsaudit ontdekt wat er is ontstaan.
Welke route past, hangt af van hoeveel redacteuren je hebt, hoe lang je pagina’s blijven staan en of je onder de toegankelijkheidsverplichting valt. Bij tien redacteuren en een handvol pagina’s is bijsturen prima werkbaar. Bij tachtig redacteuren verspreid over veertig afdelingssites is dat een ander verhaal.
Wat in beide routes helpt: een paginatemplate is een sterker sturingsmiddel dan een richtlijn in een document. Redacteuren lezen zelden documentatie. Ze pakken wat er klaarstaat.
Wat je deze maand zou kunnen doen
Een paar concrete stappen, in volgorde van moeite.
Controleer of de functies in je tenant staan. Open een testpagina, klik op een sectie en kijk of je onder Indeling de hulplijnopties ziet.
Test de conversie op een kopie van een bestaande pagina. Kijk wat er met de plaatsing gebeurt, en controleer daarna de mobiele en e-mailweergave via de preview.
Loop één bestaande flexibele sectie door met de Tab-toets. Als je er al hebt, weet je binnen een minuut of je een probleem hebt.
Informeer je redacteuren. Er is geen adminactie nodig, dus zij zien dit vanzelf verschijnen. Een korte uitleg vooraf voorkomt tickets en experimenten op gepubliceerde pagina’s.
Kijk je huidige richtlijnen na. Als daar staat welke kolomindelingen zijn toegestaan, klopt dat document niet meer.
Tot slot
Microsoft heeft hier iets gedaan wat vaker zou mogen. Niet een nieuwe functie toevoegen, maar een bestaande functie voorspelbaarder maken. Flexibele secties waren krachtig en onhandelbaar. Ze worden nu krachtig en stuurbaar.
De vraag die overblijft is niet technisch. Meer ontwerpvrijheid betekent meer manieren waarop pagina’s van elkaar gaan verschillen. Of dat een probleem is, hangt af van wat je intranet moet zijn. Een verzameling afdelingspagina’s die elk hun eigen karakter mogen hebben, of één herkenbare omgeving waarin een medewerker altijd weet waar hij kijkt.
Dat is een keuze die je maakt voordat de knoppen verschijnen, of eentje die je achteraf terugdraait.
Bronnen
- Message Center MC1446804, SharePoint Pages: Flexible Section Authoring Improvements, 4 augustus 2026
- Microsoft 365 roadmap ID 567889
- Microsoft 365 roadmap ID 395213 (introductie flexibele secties, uitrol afgerond april 2025)
- Microsoft Support: Secties en kolommen toevoegen aan een moderne SharePoint-pagina
- Microsoft Tech Community: Introducing flexible sections in SharePoint Pages and News, inclusief reacties over tab- en focusvolgorde
