Mye skravling rundt ol’ <details> og <summary> elementer i det siste! jeg så Lea Verou tvitret nylig en observasjon om elementets display oppførsel og det splittet seg opp i flere observasjoner og bruksnotater fra folk, inkludert en gjenopplivet diskusjon om hvorvidt <summary> bør få lov til å inneholde interaktive elementer eller ikke.
Det er mange prikker å koble til, og jeg skal gjøre mitt beste her for å gjøre akkurat det.
Kan vi endre visningen av elementer nestet i <details> element?
Super rart! Hvis vi åpner DevTools, forteller brukeragentstilarket oss <details> vises som et blokkelement.
Legg merke til det nødvendige <summary> element og de to ekstra <div>er der inne. Vi kan overstyre display, Ikke sant?
Det vi kan forvente er det <details> har nå en eksplisitt høyde på 40vh og tre rader der den tredje raden tar opp den resterende plassen fra de to første. Som dette:
Uff, men den tredje raden gjør ikke... det.
Det vi har å gjøre med er tilsynelatende en rutenettbeholder som ikke er i stand til å bruke rutenettadferd på rutenettelementene sine. Men HTML-spesifikasjonen forteller oss:
De
detailselementet er forventet å gjengi som en blokkboks. Elementet forventes også å ha en intern skyggetre med to spilleautomater.(Vekt min)
Og litt senere:
De
detailselementets andre slot forventes å ha sinstyleattributt satt til "display: block; content-visibility: hidden;" nårdetailselement har ikke enopenattributt. Når den haropenattributt, denstyleattributtet forventes å bli fjernet fra den andre slot.(Uthev min, igjen)
Så spesifikasjonen sier det andre sporet - de to ekstra <div>s fra eksemplet — blir bare tvunget til å være blokkelementer når <details> er stengt. Når den er åpen - <details open> — de bør samsvare med rutenettvisningen som overstyrer brukeragentens styling … ikke sant?
Det er debatten. Jeg skjønner det slots er satt til display: contents som standard, men å blokkere nestede elementer i spor og fjerne muligheten til å style dem virker av. Er det et spesifikasjonsproblem at innholdet er spor, eller et nettleserproblem som vi ikke kan overstyre display selv om de er i bokstreet? Smartere mennesker kan opplyse meg, men det virker som en feil implementering.
Is <details> en beholder eller et interaktivt element?
Mange folk er det ved hjelp av <details> for å veksle mellom menyer åpen og lukket. Det er en praksis popularisert av GitHub.
Virker fornuftig. Spesifikasjonen tillater det:
De
detailselement representerer en avsløringswidget som brukeren kan få tilleggsinformasjon fra eller kontroller.(Vekt min)
Ok, så vi kan forvente det <details> er beholderen (den har en implisitt role=group) Og <summary> er et interaktivt element som setter beholderens open stat. Gir mening siden <summary> har en implisitt button rolle i noen sammenhenger (men ingen tilsvarende WAI-ARIA-rolle).
Men Melanie Sumner gravde litt som ikke bare ser ut til å motsi det, men fører til konklusjonen at bruk <details> som en meny sannsynligvis ikke er det beste. Se hva som skjer når <details> er gjengitt uten <summary> element:
Den gjør akkurat det spesifikasjonen antyder når den mangler en <summary> — den lager sin egen:
Den første
summaryelement barn av elementet, hvis noen, representerer sammendraget eller forklaringen av detaljene. Hvis det ikke er noe barnsummaryelement, skal brukeragenten oppgi sin egen forklaring (f.eks. "Detaljer").(Vekt min)
Melanie kjørte det gjennom en HTML-validator og – overraskelse! – den er ugyldig:
Så, <details> krever <summary>. Og når <summary> mangler, <details> oppretter sin egen, selv om den videresendes som ugyldig markering. Det hele er rart og gyldig når <summary> er det:
Alt dette fører til et nytt spørsmål: hvorfor er <summary> gitt en implisitt button rolle når <details> er det som ser ut til å være det interaktive elementet? Kanskje dette er et annet tilfelle der nettleserimplementeringen er feil? Så igjen, spesifikasjonen kategoriserer begge som interaktive elementer. Du kan se hvor forvirrende alt dette blir.
Uansett, Melanies endelige konklusjon som vi burde unngå å bruke <details> for menyer er basert på hvordan hjelpeteknologi leser og kunngjør <details> som inneholder interaktive elementer. Elementet er annonsert, men det er ingen omtale av interaktive kontroller utover det før du, ehm, samhandle med <details>. Først da vil noe som en liste over lenker bli annonsert.
Dessuten innhold inne i en kollapset <details> er ekskludert fra søk på siden (unntatt i Chromium-nettlesere, som kan få tilgang til det kollapsede innholdet i skrivende stund), noe som gjør ting enda vanskeligere å finne.
Skulle <summary> tillate interaktive elementer?
Det er spørsmålet som stilles denne åpne tråden. Tanken er at noe slikt ville være ugyldig:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara oppsummerer fint hvorfor dette er et problem:
Linken er ikke synlig i det hele tatt til JAWS når du navigerer med den virtuelle markøren. Hvis du navigerer til sammendragselementet via Tab-tasten, kunngjør JAWS "eksempeltekst, knapp" som navnet og rollen til elementet. Hvis du trykker Tab-tasten igjen, kunngjør JAWS igjen "eksempeltekst, knapp" selv om tastaturfokus er på lenken.
[...]
Det er mer jeg kunne fortsette med de forskjellige problemene forskjellige AT har med innholdsmodellen for oppsummering ... men det ville bare utvide denne kommentaren utover det som er nødvendig. tldr; oppsummeringsinnholdsmodellen produserer svært inkonsekvente og noen ganger bare flate ødelagte opplevelser for folk som bruker AT.
Scott åpnet billetter for å korrigere denne oppførselen Chromium og WebKit. Takk, Scott!
Likevel er det gyldig HTML:
Scott går videre i en eget blogginnlegg. For eksempel forklarer han hvordan slapping role=button on <summary> kan virke som en rimelig løsning for å sikre at den konsekvent annonseres av hjelpeteknologi. Det vil også avgjøre debatten om hvorvidt <summary> bør tillate interaktive elementer fordi knapper kan ikke inneholde interaktive elementer. Det eneste problemet er at Safari da behandler <summary> som en standardknapp, som mister sin expanded og collapsed stater. Så den riktige rollen er annonsert, men nå er det ikke dens tilstand. 🙃
Hvor går vi nå?
Er du redd for å bruke <details>/<summary> med alle disse problemene og inkonsekvensene? Det er jeg sikkert, men bare i den grad å sørge for at det som er i det gir den riktige typen opplevelse og forventninger til brukerne.
Jeg er bare glad for at disse samtalene skjer og at de finner sted i det fri. På grunn av det kan du kommentere Scotts tre foreslåtte løsninger for hvordan innholdsmodellen for <summary> er definert, stem opp billettene hans, og rapporter dine egne problemer og brukssaker mens du holder på. Forhåpentligvis, jo bedre vi forstår hvordan elementene brukes og hva vi forventer at de skal gjøre, jo bedre blir de implementert.
