Summary/Details componenten

[joshuaboele]

Hi all,

Ik kom geregeld details en summary tegen, met name bij accordeon elementen. Op dit moment keur ik dit goed, zo lang het summary element een open attribute (dynamisch) krijgt bij het openen van zo'n accordeon element.

Mijn vraag gaat echter iets verder, wat vinden wij er van als er elementen/componenten niet volledig gesupport wordt door spraaksoftware? Summary kan dus niet bestuurt worden met "Dragon Naturally Speaking" op chrome en de VoiceControl van macOS wordt ook niet ondersteund. Is er hier een soort 'threshold' voor?

Volledige ondersteuning kan hier worden bekeken: https://a11ysupport.io/tech/html/summary_element#support-table-0

[ShadowBB]

Dit is een "Accessibility support" vraag. Specifiek voor spraaksoftware zoals Dragon Naturally Speaking hebben we op deze GitHub nog geen consensus (en ik verwacht dat die bereiken ook heel moeilijk is).

Ik keur details en summary goed op dit moment ondanks dat Dragon Naturally Speaking dit niet ondersteund. Deze elementen zijn al heel lang zo beschreven in de specs. Ik vind dit eerder een gemist van Dragon. Maar afgezien van een gevoel heb ik hier geen sluitende onderbouwing voor.

Overigens kun je ze wel openen en sluiten met Dragon (bijvoorbeeld via het mousegrid) maar niet gebaseerd op de naam en rol, wat inderdaad zeer slechte support is voor dergelijke elementen... maar in theorie kun je wel uiteindelijk bij de informatie komen.

[ShadowBB]

Also: Welkom hier Joshua! Meestal voegen we een SC toe aan het scenario waarover we twijfelen. In dit geval verwacht ik dat je 4.1.2 bedoelt?

[joshuaboele]

Thanks Brian en ja 4.1.2!

[julezrulez]

Ik houd in enige mate wel al rekening met spraaksoftware. Maar kijk ook nog niet naar de mate van ondersteuning van spraaksoftware. Ik vind in dit geval eigenlijk dat het probleem bij de software gelegd moet worden. Ik kom het probleem overigens nog niet hier tegen: https://github.com/dictation-toolbox/dragonfly/issues

[rianrietveld]

Samenvatting van de discussie naar aanleiding van de mail van @gjccopinga 23 maart 2023

Gerard Coppinga (Cardan)

Ik begrijp dat er wat verschil in inzicht is bij het beoordelen van succescriterium 4.1.2 en het gebruik van de HTML 5 elementen details en summary om een accordeon mee te maken. Hoe beoordelen jullie dit als jullie dit tegenkomen op een website?

Ik begrijp dat een aantal inspectie-instellingen/onderzoekers dit afkeuren als er geen aria-expanded attribuut gebruikt wordt bij het summary element, omdat de ondersteuning bij oudere browsers niet goed is. Klopt dit? Of wordt het wel goedgekeurd en alleen als tip mee gegeven dat het beter is om aria-expanded attribuut nog te gebruiken om oudere browsers te ondersteunen?

Als ik kijk op pagina https://caniuse.com/details dan lijkt het ook in Firefox inmiddels al een aantal jaar goed ondersteund te worden. Vanaf ergens half september gaat ook het aangeven van de toggle goed bij de combinatie NVDA en Firefox. Dus hoe ver zou je dan terug moeten gaan om toch te 'eisen' dat een aria-expanded attribuut wordt gebruikt (als het echt afgekeurd wordt bij het ontbreken). Browsers van de afgelopen 4 jaar ondersteunen het in ieder geval goed lijkt het.

Mijn voorstel is om het gebruik van details en summary goed te keuren en eventueel een tip te geven om een aria-expanded attribuut toe te voegen voor betere ondersteuning van oudere browsers. Maar het dus niet af te keuren.

Ik hoor het graag als er andere meningen zijn (met goede argumenten), want ik denk dat het het belangrijkste is dat we het allemaal consistent op dezelfde manier beoordelen.

Reactie @hidde

Ik keur details/summary zonder aria-expanded zeker goed; als dit een probleem is dan is het een bug in screenreaders, niet in websites.

Een speciaal geval dat ik me kan indenken is als er een heading gebruikt wordt in het summary element: dan vervallen de heading semantics en dat kan een probleem zijn, maar ook dan neig ik naar goedkeuren (beetje afhankelijk van hoe belangrijk de headings zijn).

Reactie @jeroenhulscher (Logius)

Ik ben het eens met de lijn van Hidde; we moeten de lijn van WCAG volgen, niet die van wat wel/niet werkt in browsers of hulpsoftware. De standaard moet in die zin dicteren hoe browsers en hulpsoftware zouden moeten functioneren, niet andersom.

Reactie @RenateRoke (Swink)

Wij keuren dat ook goed 😊 alhoewel het ontbreken van headers nog wel een vraagpuntje is inderdaad, in een FAQ is dat bijvoorbeeld toch wel erg prettig om wél te hebben.

Reactie @ShadowBB (Stichting Accessibility)

Ook wij keuren dit goed onder SC 4.1.2. Oude screenreaders die de specs niet goed volgen lijken me geen goed argument. Er kan uiteraard wel geadviseerd worden om een fallback te hebben. Wat betreft headers en SC 1.3.1. Er is visueel een relatie tussen de summary en details maar die relatie is vanuit dat element zelf ook beschikbaar voor hulpsoftware. Dus we eisen hier geen header. Wederom een header toevoegen zit (mits goed geïmplementeerd) niet in de weg en kan geadviseerd worden als fallback.

Raectie Léon Bouterse (Bubblefish)

Wij keuren Detail Summaries ook goed.

Zelf zou ik mij ook aansluiten met Hidde en Jeroen. Het detail summary element voldoet vanuit zichzelf aan de richtlijnen en heeft geen extra toevoegingen nodig. Als hulpsoftware dit niet ziet, dan is dat een fout van hulpsoftware.

Maar, aangezien die fout aanwezig kan zijn, zou ik zelf ook aanraden wat Gerard aangeeft, namelijk het toevoegen van een aria-expanded, geheel omdat het kan, maar blijft het alsnog geen reden om het af te keuren als leveranciers dit niet doen.

[rianrietveld]

Wat betreft VoiceControl in Safari: Details wordt (nog) niet beschouwd als focusable elelement en is dus niet aanklikbaar via naam of nummer. Maar het kan wel geopend worden via het htonen van een grit en en het dan selecteren van het nummer dat op de details naam staat. Show grit emuleert muisgedrag. Fijn is anders maar het kan wel.

En dan is er het nieuwe gedrag in Chromium and WebKit browsers, lees Exclusive accordions exclude van Eric Eggert.

A new proposal now wants to make the existing <details> element to an accordion by grouping them when adding a name attribute to it. Such element’s open state would then automatically be false (hiding the content) when another element’s open state is set to true, if those two <details> have the same name attribute value.

Staat jullie mening van een jaar geleden nog steeds?

[rvantonisse]

Helaas merk ik op dat de ondersteuning voor toegankelijkheid nog niet ok is.

codepen standaard details en "accessibleish" details: https://codepen.io/rvantonisse/pen/zYjGRdp Ik probeer het met een role=button en css generated content iets draaglijker te maken, maar helaas ik denk dat een aria-expanded op zijn plaats is om aan 4.1.2 te kunnen voldoen...

Het gaat met name om IOS en VoiceOver, maar ook MacOs en VoiceOver is niet ok. Ik heb het idee dat er nog flink gesleuteld wordt binnen webkit EN de 2 VoiceOvers. Ik kan mij herinneren dat een jaar geleden de ondersteuning een stuk beter lag...

Dit is een goed verdiepend artikel over Details<>Summary door Scott 'O Hara: https://www.scottohara.me/blog/2022/09/12/details-summary.html

👎 details<>summary is onvoldoende door ontbreken toegankelijke ondersteuning IOS / MacOs.

👍 Als IOS / MacOs buiten scope ligt is de details <> summary voldoende.

[gjccopinga]

Het komt dus neer op een "Accessibility Supported" issue. Als er kennelijk nog onvoldoende ondersteuning is op iOS en MacOS wat betreft VoiceOver in combinatie met een webkit browser, dan is inderdaad de vraag of we deze techniek wel moeten goedkeuren. Het is geen 'exotische' combinatie of exotisch platform waar het niet goed op ondersteund wordt, dus dan is er wel iets voor te zeggen om het niet goed te keuren, maar te adviseren om een ARIA-oplossing te gebruiken. Zoals op pagina https://www.w3.org/WAI/ARIA/apg/patterns/accordion/ wordt omschreven.