2.4.3 Focus springt niet naar carrousel slide nadat specifieke slide gekozen is

[ShadowBB]

Stel je hebt een carrousel met daaronder een interface om verschillende slides te kiezen. De DOM volgorde gaat eerst langs deze volledige interface en dan langs de actieve slide. Als de gebruiker 1 van deze slides kiest (niet de laatste) blijft de focus op de knop staan om die slide te kiezen. Aangezien er eerst nog andere knoppen voor andere slides staan na deze knop is de nu zoujuist actief geworden slide ook niet het eerst volgende element dat focus ontvangt. Keuren we dit af onder SC 2.4.3 focus volgorde?

[ShadowBB]

Ikzelf heb 2.4.3 altijd geïnterpreteerd als zijnde dat als er dynamische content tevoorschijn komt dat je of met javascript hier de focus op moet plaatsen of dat het het eerst volgende stuk content moet zijn in de DOM volgorde zodat het als eerst volgende element focus ontvangt. Dit heb ik echter tot nu toe gebaseerd op technieken: SCR 26 F85

Als ik naar de normatieve tekst van het SC zelf kijk dan kom ik uiteindelijk ook tot die conclusie met wat aannames over definities:

"focusable components receive focus in an order that preserves meaning and operability."

Ik zou stellen dat als een gebruiker eerst langs andere knoppen moet navigeren om bij diens gekozen content uit te komen dat de relatie tussen de knop en de content dan ontbreekt in de DOM volgorde en de volgorde dus niet de "meaning" behoud.

Dus ik zou dit afkeuren.

[gjccopinga]

Ik zou dit ook afkeuren. Ik vergelijk dit met een interface met tabbladen. Als je een bepaalde 'tab' kiest en de content die bij die tab hoort verschijnt wil je ook direct de inhoud van dat tabblad kunnen lezen en er direct naar toe kunnen navigeren. De enige optie die ik dan zie is dat je voor het wisselen tussen de 'tabs' de pijltjestoetsen gebruikt en dan dus de Tab-toets overhoud om direct naar de interactieve content van het tabblad te gaan. Dus bij een carrousel zou je dan ook met de Tab-toets naar de interface moeten kunnen springen. Dan met de pijltjestoetsen een keuze kunnen maken. En dan met de Tab-toets weer naar de inhoud van de actieve slide in de carrousel. Zoiets als hier staat beschreven: https://www.w3.org/TR/wai-aria-practices-1.2/examples/carousel/carousel-2-tablist.html

[FerJo]

En zelfs als je de focus in @ShadowBB's voorbeeld naar de slide brengt, dan zit je, volgens mij, weer met een ander focus order probleem: shift-tab. Met shift-tab zou ik verwachten dat ik weer terug ga naar het trigger-element dat mij op de slide heeft gebracht. Maar dat gebeurt niet, ik ga dan eerst langs andere knoppen ...

[ShadowBB]

@FerJo Je hebt gelijk dat dat irritant is. De beste oplossing is uiteraard een "om en om" DOM volgorde (Knop, slide, knop, slide, knop, slide) en dat is ook wat ik aanraad. Ik zou met javascript de focus verplaatsen echter niet afkeuren ondanks dat ik het probleem wat je omschrijft herken, ik zie (nog?) geen goede onderbouwing vanuit de SC om het af te keuren.

[ShadowBB]

We hebben nu al 3 partijen die dit afkeuren. Dit ik zet dit op failed. Maar deze issue is nog maar net nieuw dus ik denk dat het eerlijk is om het nog even langer open te laten staan dan de 10 dagen voordat we het op de website zetten.

[FerJo]

Dan ben ik nog wel even benieuwd naar onze mening over deze carousel, een variant van de carousel die @gjccopinga noemt: https://www.w3.org/TR/wai-aria-practices-1.2/examples/carousel/carousel-1-prev-next.html?moreaccessible=false

Met pijltjes (volgende slide/vorige slide) kun je de slide laten bewegen. Als ik met het 'vorige slide'-pijltje een slide heb gekozen en ik wil daarnaartoe, dan moet ik eerst langs het 'volgende slide'-pijltje. Is dat dan ook een SC 2.4.3 FAIL?

[julezrulez]

Waar ik altijd mee zit is dat je om meerdere redenen door een slider heen gaat.

1. Je wilt alle slides bekijken (wenselijk om focus op bladerknop te houden)
2. Je zoekt een specifieke slide waar je meer wilt doen (route naar slide en terug naar bladerknoppen moet dan duidelijk zijn)
3. Je wilt elke slide bekijken en de link volgen... (focus naar de zichtbare slide is dan wenselijk) Ik vind het lastig om een slider met tabbladen te vergelijken. De content wijkt vaak af; waar in tabbladen vaak veel tekst aanwezig is, zijn sliders vaak kort en bondig of bevatten enkel een afbeelding. Ik denk dat ik per situatie zou bekijken en geen van de door mij onder 1, 2 en 3 genoemde voorbeelden de volgorde zou afkeuren.

[Veyfeyken]

Sorry voor de late reactie. Dit is volgens mij geen failure op focus volgorde. Het niet sturen van de focus bij activatie van de controls is een bewuste keuze, zie ook voorbeeld design pattern carousel. Dat de focus op de control blijft zorgt er niet voor dat "meaning en operability" in het gedrang komt. Er is logica in de focusvolgorde binnen het geheel van de component. Dit is verwacht en aanbevolen gedrag voor een carousel.

[Veyfeyken]

In het carousel patroon gaat het wel over "volgende" en "vorige" buttons ipv een "slide 1", "slide 2", etc. Het zou helpen als we een concreet voorbeeld hebben om naar te kijken?