sok fecsegés az idő körül <details> és a <summary> elemek mostanában! láttam Lea Verou a közelmúltban egy megfigyelést tett közzé a Twitteren az elemről display viselkedése, és ez a fajta több megfigyelésre és használati megjegyzésre oszlott, többek között a felélénkült a vita arról, hogy <summary> tartalmaznia kell interaktív elemeket, vagy sem.
Nagyon sok pontot kell összekötni, és mindent megteszek, hogy pontosan ezt tegyem.
Meg tudjuk-e változtatni a beágyazott elemek megjelenítését <details> elem?
Szuper furcsa! Ha feltörjük a DevTools megnyitását, a felhasználói ügynök stíluslapja megmondja nekünk <details> blokk elemként jelenik meg.
Vegye figyelembe a szükséges <summary> elem és a két további <div>s bent van. Felülírhatjuk a display, jobb?
Amit várhatunk, az az <details> most kifejezett magassága van 40vh és három sor, ahol a harmadik sor az első kettőből megmaradt helyet foglalja el. Mint ez:
Jaj, de a harmadik sor nem… ezt teszi.
Nyilvánvalóan egy rácstárolóval van dolgunk, amely nem képes rács-viselkedést alkalmazni rácselemeire. De a HTML specifikáció a következőket mondja:
A
detailselem az várhatóan a blokk doboz. Az elem várhatóan belsővel is rendelkezik árnyékfa kettővel nyílások.(Kiemelés az enyém)
És kicsit később:
A
detailselem második rés várhatóan megleszstyleattribútum beállítása "display: block; content-visibility: hidden;" amikor azdetailselem nem rendelkezikopentulajdonság. Amikor megvan aopenattribútum, astyleattribútum várhatóan el lesz távolítva a másodikból rés.(Kiemelés az enyémről, ismét)
Tehát a specifikáció szerint a második slot – a két további <div>s a példából — csak akkor kényszerítik blokkelemekké, ha <details> zárva. Amikor nyitva van - <details open> — meg kell felelniük a rács-megjelenítésnek, amely felülírja a felhasználói ügynök stílusát… igaz?
Ez a vita. értem slots beállítva display: contents alapértelmezés szerint, de a beágyazott elemek beszorítása a nyílásokba és a stílusuk megszüntetése nem tűnik jónak. Specifikációs probléma, hogy a tartalom slotok, vagy olyan böngésző probléma, amelyet nem tudunk felülbírálni display annak ellenére, hogy a dobozban vannak? Okosabb emberek felvilágosíthatnak, de ez helytelen megvalósításnak tűnik.
Is <details> konténer vagy interaktív elem?
Sokan vannak segítségével <details> a menük váltásához nyitott és zárt. Ez egy gyakorlat népszerűsítette a GitHub.
Ésszerűnek tűnik. A specifikáció biztosan megengedi:
A
detailselem jelentése egy közzétételi widget, amelyből a felhasználó további információkat szerezhet vagy vezérlők.(Kiemelés az enyém)
Rendben, erre számíthatunk <details> a tartály (van benne hallgatólagos role=group) És <summary> egy interaktív elem, amely beállítja a tárolót open állapot. Azóta van értelme <summary> van egy implicit button szerep bizonyos összefüggésekben (de nincs megfelelő WAI-ARIA szerepkör).
De Melanie Sumner ásott egy kicsit ami nemcsak ellentmondani látszik ennek, hanem arra a következtetésre vezet, hogy a használata <details> menüként valószínűleg nem a legjobb dolog. Nézze meg, mi történik mikor <details> nélkül jelenik meg <summary> elem:
Pontosan azt teszi, amit a specifikáció sugall, ha hiányzik a <summary> — megcsinálja a magáét:
Az első
summaryelem az elem gyermeke, ha van ilyen, jelentése a részletek összefoglalása vagy jelmagyarázata. Ha nincs gyereksummaryelemet, a felhasználói ügynöknek meg kell adnia a saját jelmagyarázatát (pl. „Részletek”).(Kiemelés az enyém)
Melanie ezt egy HTML-ellenőrzőn keresztül futtatta, és – meglepetés! - érvénytelen:
Szóval, <details> megköveteli a <summary>. És mikor <summary> hiányzik, <details> létrehozza a sajátját, bár érvénytelen jelölésként továbbítja. Ez mind huncut, és akkor érvényes <summary> van:
Mindez egy új kérdéshez vezet: miért van <summary> adott egy implicit button szerepet mikor <details> az, ami interaktív elemnek tűnik? Talán ez egy másik eset, amikor a böngésző megvalósítása nem megfelelő? Aztán a specifikáció mindkettőt a következő kategóriába sorolja interaktív elemek. Láthatod, mennyire zavarba ejtő ez az egész.
Akárhogy is, Melanie végső következtetése, amelyet kerülnünk kell <details> A menük esetében a segédtechnika olvasásának és bemondásának módja alapján történik <details> amelyek interaktív elemeket tartalmaznak. Az elemet bejelentik, de ezen túlmenően nincs szó interaktív vezérlőkről, amíg Ön, ööö, kölcsönhatásba val vel <details>. Csak ezután kerül sor olyasmire, mint a linkek listája.
Különben is, a tartalom belsejében összeomlott <details> ki van zárva az oldalakon belüli keresésből (kivéve a Chromium böngészőket, amelyek hozzáférnek az összecsukott tartalomhoz az írás idején), ami még nehezebbé teszi a keresést.
Kellene <summary> engedélyezi az interaktív elemeket?
Ez a feltett kérdés ez a nyitott szál. Az ötlet az, hogy valami ilyesmi érvénytelen lenne:
<details>
<summary><a href="...">Link element</a></summary>
</details>
<!-- or -->
<details>
<summary><input></summary>
</details>Scott O'Hara szépen összefoglalja miért probléma ez:
A link egyáltalán nem fedezhető fel a JAWS felé, amikor a virtuális kurzorral navigál. Ha a Tab billentyűvel navigál az összefoglaló elemhez, a JAWS az elem neveként és szerepeként „példaszöveg, gomb”-t hirdet. Ha ismét megnyomja a Tab billentyűt, a JAWS ismét bejelenti: „példaszöveg, gomb”, bár a billentyűzet fókusza a hivatkozáson van.
[...]
Többet is folytathatnék azokkal a különféle problémákkal, amelyeket az AT-nek a tartalmi modellel kapcsolatban összefoglalva tapasztalhat… de ez csak kiterjesztené ezt a megjegyzést a szükségesnél. tldr; az összefoglaló tartalommodell nagyon inkonzisztens és néha csak lapos hibás élményeket hoz létre az AT-t használó emberek számára.
Scott jegyeket nyitott, hogy kijavítsa ezt a viselkedést Króm és a WebKit. Köszönöm Scott!
Mégis, ez érvényes HTML:
Scott tovább megy a külön blogbejegyzés. Például elmagyarázza, milyen pofon role=button on <summary> ésszerű megoldásnak tűnhet annak biztosítására, hogy a kisegítő technológia következetesen bejelentse. Ez a vitát is eldöntené, hogy vajon <summary> engedélyeznie kell az interaktív elemeket, mert a gombok nem tartalmazhatnak interaktív elemeket. Az egyetlen probléma az, hogy a Safari kezeli <summary> szabványos gombként, ami elveszti a hatását expanded és a collapsed Államok. Tehát a megfelelő szerepet bejelentik, de az állapotát most nem. 🙃
Hova megyünk most?
Félsz használni <details>/<summary> mindezekkel a problémákkal és következetlenségekkel? Biztos vagyok benne, de csak annyiban, hogy megbizonyosodjunk arról, hogy ami benne van, az megfelelő élményt és elvárásokat nyújt a felhasználók számára.
Örülök, hogy ezek a beszélgetések zajlanak, és hogy nyíltan zajlanak. Emiatt kommentálhatja Scott három javasolt megoldását a tartalommodellhez <summary> meg van határozva, szavazzon pozitívan a jegyeire, és közben jelentse a saját problémáit és használati eseteit. Remélhetőleg minél jobban megértjük az elemek felhasználási módját és azt, hogy mit várunk el tőlük, annál jobban megvalósítják őket.
