HTML-lijsten zijn saai. Dat doen ze niet do veel, dus we denken er niet echt over na, ondanks hoe vaak ze worden gebruikt. En we kunnen nog steeds dezelfde dingen doen die we altijd hebben gedaan om ze aan te passen, zoals het verwijderen van markeringen, het omkeren van de volgorde en het maken van aangepaste tellers.
Er zijn echter een paar "nieuwere" dingen - inclusief gevaren - die u moet weten bij het gebruik van lijsten. De gevaren zijn meestal klein, maar komen veel vaker voor dan je zou denken. Daar komen we op terug, plus enkele nieuwe dingen die we met lijsten kunnen doen, en zelfs nieuwe manieren om oude oplossingen te benaderen.
Ter verduidelijking, dit zijn de HTML-elementen waar we het over hebben:
- Bestelde lijsten
- Ongeordende lijsten
- Beschrijving lijsten
- Interactieve lijsten
Geordende lijsten, ongeordende lijsten en interactieve lijsten bevatten lijstitems (
) die worden weergegeven volgens het soort lijst waar we mee te maken hebben. Een geordende lijst (
) geeft getallen weer naast lijstitems. Ongeordende lijsten (
) en menu-elementen (
) toont opsommingstekens naast lijstitems. We noemen deze "lijstmarkeringen" en ze kunnen zelfs worden gestyled met de ::markeerstift pseudo-element. Beschrijvingslijsten gebruiken beschrijvingstermen (
) en beschrijvingsdetails (
) in plaats van
en geen lijstmarkeringen hebben. Ze zouden moeten worden gebruikt om metadata en woordenlijsten weer te geven, maar ik kan niet zeggen dat ik ze ooit in het wild heb gezien.
Laten we beginnen met de eenvoudige dingen: hoe u lijststijlen (althans naar mijn mening) correct kunt resetten. Daarna zullen we een aantal toegankelijkheidsproblemen bekijken voordat we een licht schijnen op het ongrijpbare
element, waarvan je misschien verrast zult zijn te horen ... is eigenlijk ook een soort lijst!
Lijststijlen resetten
Browsers passen automatisch hun eigen User Agent-stijlen toe om direct te helpen met de visuele structuur van lijsten. Dat kan geweldig zijn! Maar als we met een schone lei willen beginnen zonder stylingadviezen, dan moeten we eerst die stijlen resetten.
We kunnen bijvoorbeeld de markeringen naast lijstitems vrij eenvoudig verwijderen. Niets nieuws hier:
/* Zap all list markers! */
ol, ul, menu {
list-style: none;
}Maar moderne CSS heeft nieuwe manieren om ons te helpen specifieke lijstinstanties te targeten. Laten we zeggen dat we markeringen uit alle lijsten willen wissen, behalve als die lijsten voorkomen in inhoud in lange vorm, zoals een artikel. Als we de krachten van nieuwere CSS-pseudoklassefuncties combineren :where() en :not(), kunnen we die instanties isoleren en de markeringen in die gevallen toestaan:
/* Where there are lists that are not articles where there are lists... */
:where(ol, ul, menu):not(article :where(ol, ul, menu)) {
list-style: none;
}Waarom gebruik maken van :where() in plaats van :is()? De specificiteit van :where() is altijd nul, terwijl :is() neemt de specificiteit van het meest specifieke element in zijn lijst met selectors. Dus gebruiken :where() is een minder krachtige manier om dingen te negeren en kan zelf gemakkelijk worden opgeheven.
UA-stijlen passen ook opvulling toe om de inhoud van een lijstitem uit de markering te plaatsen. Nogmaals, dat is in sommige gevallen een behoorlijk mooie beloning, maar als we de lijstmarkeringen al verwijderen zoals hierboven, dan kunnen we die opvulling net zo goed wegvagen. Dit is een ander geval voor :where():
:where(ol, ul, menu) {
padding-left: 0; /* or padding-inline-start */
}OK, dat voorkomt dat lijstitems zonder markeringen in de ruimte lijken te zweven. Maar we hebben het kind min of meer met het badwater weggegooid en de opvulling in alle gevallen verwijderd, ook degene die we eerder hebben geïsoleerd in een
. Dus nu hangen die lijsten met markeringen min of meer aan de rand van het inhoudsvak.
Merk op dat UA-stijlen een extra toepassen 40px aan de
element.
Dus wat we willen doen, is voorkomen dat de lijstmarkeringen buiten de container "hangen". Dat kunnen we oplossen met de list-style-position eigendom:
Of niet… komt het misschien neer op stilistische voorkeur?
Nieuwere toegankelijkheidsproblemen met lijsten
Helaas zijn er een aantal toegankelijkheidsproblemen als het om lijsten gaat, zelfs in deze modernere tijden. Een zorg is een gevolg van het solliciteren list-style: none; zoals we deden bij het resetten van UA-stijlen.
Kortom Safari niet lees geordende en ongeordende lijsten gestileerd met list-style: none als daadwerkelijke lijsten, zoals bij het navigeren door inhoud met een schermlezer. Met andere woorden, het verwijderen van de markeringen verwijdert ook de semantische betekenis van de lijst. De oplossing voor deze oplossing het om een toe te passen ARIA list rol op de lijst en a listitem rol toe aan de lijstitems zodat schermlezers ze oppikken:
- ...
- ...
- ...
- ...
- ...
- ...
Vreemd, Safari beschouwt dit als een functie in plaats van een bug. In feite zouden gebruikers melden dat schermlezers te veel lijsten aankondigden (omdat ontwikkelaars de neiging hebben ze te veel te gebruiken), dus nu kunnen alleen degenen met role="list" worden aangekondigd door schermlezers, wat eigenlijk helemaal niet zo vreemd is. Scott O'Hara een gedetailleerd overzicht van hoe het allemaal is gegaan.
Een tweede toegankelijkheidsprobleem hebben we niet zelf gemaakt (hoera!). Dus je weet hoe je zou moeten voeg een aria-label naar
elementen zonder kopjes? Welnu, het is soms logisch om hetzelfde te doen met een lijst die geen kopelement bevat dat helpt bij het beschrijven van de lijst.
Grocery list
U absoluut niet beide methoden moeten gebruiken. Het gebruik van een kop of een ARIA-label is slechts een toegevoegde context, geen vereiste. Zorg ervoor dat u uw websites test met schermlezers en doe wat de beste gebruikerservaring biedt voor de situatie.
In enigszins gerelateerd nieuws schreef Eric Bailey een uitstekend stuk over waarom en hoe hij denkt aria-label een codegeur zijn.
Wacht,
is er ook een lijst?
OK, dus je vraagt je waarschijnlijk af over alle
elementen die ik in de codevoorbeelden heb gestopt. Het is eigenlijk super simpel; menu's zijn ongeordende lijsten, behalve dat ze bedoeld zijn voor interactieve items. Ze worden zelfs als ongeordende lijsten aan de toegankelijkheidsboom getoond.
In de begindagen van het semantische web geloofde ik ten onrechte dat menu's zo waren
s voordat ze dachten dat ze voor contextmenu's waren (of "werkbalken" zoals de specificatie zegt:) omdat dat is wat vroege versies van de HTML-specificatie zeiden. (MDN heeft een interessant artikel op alle verouderde dingen die verband houden met
als je überhaupt geïnteresseerd bent.)
Tegenwoordig is dit echter de semantische manier om menu's te gebruiken:
Persoonlijk denk ik dat er een aantal goede use-cases voor zijn
. Dat laatste voorbeeld toont een lijst met knoppen voor sociaal delen verpakt in een gelabeld
element, waarbij het opvallende aspect is dat het label "Artikel delen" een aanzienlijke hoeveelheid context toevoegt die helpt beschrijven wat de knoppen doen.
Zijn menu's absoluut noodzakelijk? Nee. Zijn ze dat? HTML-oriëntatiepunten? Zeker niet. Maar ze zijn er als je minder geniet
s en je hebt het gevoel dat het onderdeel een aria-label voor extra context.
Nog iets anders?
Ja, er is ook het bovengenoemde
(beschrijving lijst) element, echter, MDN lijkt ze niet als lijsten te beschouwen op dezelfde manier - het is een lijst met groepen die termen bevatten - en ik kan niet zeggen dat ik ze echt in gebruik heb gezien. Volgens MDN zouden ze moeten worden gebruikt voor metadata, woordenlijsten en andere soorten sleutel-waardeparen. Ik zou ze gewoon vermijden omdat alle schermlezers ze anders aankondigen.
Maar laten we niet eindigen met een negatieve noot. Hier is een lijst met supercoole dingen die je met lijsten kunt doen:
