Is het gebruik van headings een sufficient technique voor 2.4.1 Blokken omzeilen?

[Veyfeyken]

Providing heading elements at the beginning of each section of content https://www.w3.org/WAI/WCAG21/Techniques/html/H69

[Aircl0wn]

Ik reken headings als voldoende. Landmarks en een enkele skip link naar de content als best practice toevoeging.

Je kunt zeggen dat je daarmee geen oplossing biedt voor keyboard users zonder screen reader, maar er zijn bijvoorbeeld wel plug-ins beschikbaar die dat toevoegen (wat in eenzelfde lijn ligt als het gebruik van andere hulpsoftware). Je biedt mensen een handvat om te gebruiken.

[rianrietveld]

Ik keur het af. Snelle navigatie is vooral fijn voor toetsenbord-gebruikers. Navigeren via headings kun je alleen met een screen reader. Nu sluit je de toetsenbord-gebruikers. uit of dwing je ze tot extra middelen.

[sophieschoice]

Ik volg Rian in haar redenering. Extensies en plugins die het mogelijk maken, zijn nog niet wijdverbreid genoeg bekend IMO.

Navigeren via koppen sluit ook slechtzienden uit.

[ShadowBB]

De techniek is "sufficient" maar dat betekent niet dat daarom een website goedgekeurd zou moeten worden tijdens een audit als er geen accessibility support voor is. Een plugin (hoewel gratis verkrijgbaar in de plugin store van de browser) telt niet als "widely distributed".

De technieken zijn meer dan 10 jaar geleden geschreven in de hoop dat user agents native functionaliteit zouden bieden rondom navigeren op basis van landmarks. Hoewel Opera dat ooit deed, doen ze dat nu niet meer.

Beide technieken ARIA11 en H69 wordt heftig over gediscussieerd om deze naar "advisory" te verplaatsen. De redenen waarom dit nog niet gebeurd is is (naar slechts mijn mening) voornamelijk vanwege backwards compatibility issues, onduidelijkheid in de discussie zelf en te weinig mensen die hier aan kunnen werken op het moment: https://github.com/w3c/wcag/issues/1712

Omdat ik lui ben heb ik hetzelfde antwoord getyped voor beide issues. ;)

Op dit moment keur ik het dus af.

[Aircl0wn]

Dat ik het niet afkeur heeft weinig te maken met of ik het goed of fout vindt. Ik zie ze het liefst allemaal toegepast en zal de ontbrekende altijd benoemen. Het probleem is dat het moeilijk te onderbouwen is vanuit de WCAG zelf zonder vast en duidelijk besluit/standpunt.

Die discussies die Brian noemt heb ik ook gelezen, maar ik vind niet dat je klanten daarmee kunt opzadelen.

Hier heb je de WCAG, dan heb je nog de UD en oh ja er lopen ook nog 3 discussies over of het eigenlijk wel ok is of dat het toch anders moet dus momenteel kan iemand dit totaal anders beoordelen.

Mijn ervaring is dat het meer effect op het eindresultaat heeft om vanuit een positieve insteek de verbeteringen te onderbouwen.

Een plugin (hoewel gratis verkrijgbaar in de plugin store van de browser) telt niet als "widely distributed".

@ShadowBB : Die is lastig want hier is geen definitie voor vastgesteld voor zover ik weet? In die context kan een plugin dus nooit(?) widely distributed zijn.. Of moeten we een minimum aantal installs gaan hanteren, kijken welke plugin voor meerdere UA's beschikbaar is, etc?

De discussie toont in ieder geval de waarde van dit platform aan en dat vind ik tof! Dit is precies waarom we hiermee begonnen zijn.

Ik kan er prima in meegaan als we hier gezamenlijk besluiten "wij keuren dit af en dit is onze onderbouwing". In die onderbouwing kan dan de mondiale onduidelijkheid hierover een plek krijgen met de conclusie dat we ervoor kiezen gezamenlijk hetzelfde standpunt in te nemen.

Ik heb het onderwerp intern ook nog eens ff een slinger gegeven naar aanleiding hiervan.

[gjccopinga]

Ik ben het met @rianrietveld en @ShadowBB eens dat zowel de techniek met headings als met landmarks (#23 ) nog niet voldoende standaard ondersteund wordt in User Agents en dat de plugins of extensies die je er voor nodig hebt nog niet heel bekend zijn en gebruikt worden. Om deze als 'accessibility supported' te zien is er dus nog wel meer nodig om dit SC op basis van deze technieken goed te keuren. In die zin is de 'skiplink' op de juiste manier geïmplementeerd nog steeds de enig goed werkende oplossing voor alle doelgroepen. En, deze oplossing is denk ik voor de meeste organisaties ook niet een groot probleem om te implementeren. Ik heb hier in ieder geval nog nooit klachten over gehoord vanuit klanten.

[Veyfeyken]

Ik heb correct gebruik van headings altijd goedgekeurd omdat ik nooit had stilgestaan bij de toevoeging achter de sufficient technique, namelijk: (Sufficient when used with an unwritten technique)

Dankzij de uitleg van @ShadowBB is het duidelijk dat het neerkomt of we plugins die gebruik maken van de headings als "widely distributed" zien of niet. Hard no volgens mij. Als dat de consensus gaat zijn, wil dat zeggen dat je enkel aan dit criterium kan voldoen door een skiplink toe te voegen. Dat is in mijn mening de correcte interpretatie van WCAG.

Maar ik ben het niet eens met WCAG. In mijn mening bestaat de ziende keyboard-only gebruiker niet. Mensen met motorische problemen beperken zich niet tot tab en enter. Het strikt lineair navigeren doorheen een website met enkel de tabtoets is een extreem edge case. Kent er hier iemand die zo een computer gebruikt? Ik denk dat we hier te ver van de realiteit aan het afdwalen zijn.

Dit criterium is vooral zinvol voor screenreadergebruikers. Daarom heb ik zowel headings als landmarks altijd goedgekeurd. Maar volgens de "logica" van WCAG mag je het niet goedkeuren.

[Aircl0wn]

Je laatste zin is ook altijd mijn overweging geweest. Voor iemand die een keyboard als voorkeur heeft, zoals ikzelf, is het een UX probleem, geen accessibility probleem.

Ik moet wel zeggen dat bijvoorbeeld een switch/puf gebruiker wel degelijk onder een ziende keyboard-only gebruiker valt. Maar in die situatie zijn er weer andere technieken van navigatie en zijn ze niet beperkt tot alleen maar een tab-volgorde. Ik ben nog niet 100% overtuigd dat dit zo strikt bekeken moet worden.

[julezrulez]

Ik keur het af als de skiplink ontbreekt in situaties waar meer dan 2 teugkerende focusbare elementen voor het contentdeel aanwezig is. Het kruimelpad tel ik daarbij niet mee als terugkerende focusbare element omdat die per pagina kan afwijken.

[ShadowBB]

Die discussies die Brian noemt heb ik ook gelezen, maar ik vind niet dat je klanten daarmee kunt opzadelen.

Eens. Zo een discussie bijhouden en verwerken is het werk van accessibility consultants die klanten informeren over welke technieken ze wel en niet zouden moeten toepassen.

Het is wel het werk van bouwers om te weten dat een techniek in de praktijk niet goed werkt voor toetsenbord gebruikers. Maar zowel mijn argument hier als of we klanten hier wel of niet mee kunnen opzadelen lijkt me (ondanks dat dat belangrijke onderwerpen zijn om te bespreken) geen invloed hebben op of we het af of goed zouden moeten keuren lijkt me.

Die is lastig want hier is geen definitie voor vastgesteld voor zover ik weet? In die context kan een plugin dus nooit(?) widely distributed zijn.. Of moeten we een minimum aantal installs gaan hanteren, kijken welke plugin voor meerdere UA's beschikbaar is, etc?

Ik zou een plugin persoonlijk inderdaad nooit als widely distributed bestempelen. Maar ja, ik zie niet eens alle moderne browsers als widely distributed (zie mijn issue over welke browsers ik zie als onderdeel van de accessibility support baseline).

De definitie van accessibility support is en blijft een heikel punt inderdaad en zonder goede definitie voor "de Nederlands sprekende gebruiker" of zo iets dergelijks kunnen we eigenlijk niet beslissen of zo een plugin wel of niet bij die baseline hoort.

Ik denk dat we vooral pragmatisch hierover moeten beslissen dat de meeste gebruikers die hier gebruik van zouden willen maken niet weten van dergelijke plugins en daarom niet kunnen genieten van de voordelen die het volgende van deze techniek voortbrengt.

De discussies op deze Github waardeer ik ook moet ik zeggen. Volgens mij helpt het ook erg tegen klanten dingen te kunnen zeggen zoals "de Nederlandstalige inspectie-instellingen hebben een consensus bereikt over de interpretatie van dit SC." of "Dit punt wordt op dit moment besproken door de Nederlandstalige inspectie-instellingen dus hoewel we dit op dit moment niet afkeuren raden we aan dit aan te passen zodat als de consensus op "failed" uitkomt je niet tegen de verrassing aanloopt dat het volgend jaar afgekeurd wordt.", dan konden we meestal sowieso wel zeggen bij wijd geaccepteerde dingen, maar nu hebben we een openbare plek waar we werkelijk naar kunnen verwijzen als bewijs en naslagwerk.

[Aircl0wn]

Eens. Zo een discussie bijhouden en verwerken is het werk van accessibility consultants die klanten informeren over welke technieken ze wel en niet zouden moeten toepassen.

Precies, daarom fijn dat hier nu te kunnen doen. :)

Je verwijzing naar het andere topic dacht ik ook aan inderdaad. Vooral omdat Gerard daarbij verschillende combinaties aan hulpsoftware betrok, iets wat zeker een stukje van de puzzel is. maar daar wordt het niet simpeler van.

Als dit onderwerp niet standaard werk in een browser (zonder plugin) maar wel met hulpsoftware, waar zit dan de switch in de keuze van niet naar wel supported?

[ShadowBB]

Maar ik ben het niet eens met WCAG. In mijn mening bestaat de ziende keyboard-only gebruiker niet. Mensen met motorische problemen beperken zich niet tot tab en enter. Het strikt lineair navigeren doorheen een website met enkel de tabtoets is een extreem edge case. Kent er hier iemand die zo een computer gebruikt? Ik denk dat we hier te ver van de realiteit aan het afdwalen zijn.

Dit criterium is vooral zinvol voor screenreadergebruikers. Daarom heb ik zowel headings als landmarks altijd goedgekeurd. Maar volgens de "logica" van WCAG mag je het niet goedkeuren.

Ik moet eerlijk zeggen dat ik nog onvoldoende hier vanaf weet om je tegen te spreken of gelijk te geven. Ik heb in het verleden wel eens een middag hier in gedoken en kwam toen wel voorbeelden tegen van gebruikers die (in theorie) eenmaal met hun ogen knipperde voor "tab" en tweemaal snel achter elkaar met hun ogen knipperen voor "enter" en zo websites konden bedienen. Maar ik heb hier nooit video's van gezien of zo iets dergelijks en in hoeverre dit niet ook een volledig theoretisch gebruiker is weet ik niet. Ik ben in ieder geval gestopt met deze theoretische gebruiker noemen als voorbeeld in mijn trainingen. (En dat zou inderdaad een relatief extreme edge case zijn.)

Verder ben ik van mening(!) dan rekening houden met theoretische extreme edge cases er voor zorgt dat je gebruikers in allerlei onvoorziene situaties en setups tegemoet komt. Dan zou het zo kunnen zijn dat dit te ver gaat, maar aangezien skiplinks ook ervaren worden als prettig door bijvoorbeeld onervaren screenreadergebruikers die nog niet goed met heading/landmark navigatie om kunnen gaan, of door screenreader gebruikers die meestal geen heading/landmark navigatie gebruiken omdat veel websites hun headings en landmarks slecht weergeven en er dus vanuit gaan dat het op alle websites slecht bruikbaar is, zie ik daar dan nog steeds een waarde in het "eisen" van skiplinks, zelfs als ziende keyboard-only gebruikers niet/nauwelijks bestaan.

Ik denk dat we dus in ieder geval voor WCAG een voorlopige consensus bereikt hebben van "failed" voor zowel heading als landmarks, dus die tags zal ik toevoegen.

[ShadowBB]

Als dit onderwerp niet standaard werk in een browser (zonder plugin) maar wel met hulpsoftware, waar zit dan de switch in de keuze van niet naar wel supported?

Dat is een goede vraag waar ik op dit moment nog geen goed antwoord op heb. Ik zou haast zeggen open er een issue over. XD Maar eerlijk gezegd geen idee waar die grens precies zou moeten liggen.

[rianrietveld]

Mee eens dat dit een fail is voor WCAG

[ShadowBB]

@Veyfeyken Het is gebruikelijk dat de persoon die de issue opent uiteindelijk ook de conclusie schrijft voor op de website. Heb jij hier tijd voor? Zo nee, dan kan ik die taak op mij nemen.

[ShadowBB]

Conclusie voor op de website:

Hoewel het wel wordt aangeraden om headings te gebruiken om navigatie en aangegeven structuur te bevorderen is het onvoldoende om hierop te leunen als enige mechanisme om herhalende content over te slaan. Dit aangezien niet alle gebruikers die baat hebben bij zo een mechanisme software gebruiken die gebruik kan maken van deze headings om te navigeren. Hierdoor wordt deze manier van voldoen aan dit succescriteria niet gezien als "door toegankelijkheid ondersteund" en wordt het op basis daarvan afgekeurd op SC 2.4.1 (ondanks dat dit beschreven is binnen een "sufficient technique" binnen WCAG: H69).

[rianrietveld]

Gepubliceerd: https://wcag-audit-discussions.github.io/NL-BE/sc/2.4.1/