Fronteers — vakvereniging voor front-end developers

WCAG 2.0: Voorspelbaar gedrag en overlays

Richtlijn 3.2 Voorspelbaar: Maak het uiterlijk en de bediening van webpagina's voorspelbaar.

3.2. Bij focus: Als een component de focus krijgt, dan veroorzaakt dat geen contextwijziging. (Niveau A)

Het gebruik van page overlays zoals Lightbox is erg populair: niet alleen voor een uitvergrote foto of een korte melding, maar ook voor ingewikkelde formulieren en andere content zoals video's.

Belangrijk voor de toegankelijkheid is dat deze pop-ups niet op focus worden geopend maar na het activeren van een link, waarbij een waarschuwing is gegeven dat de content in een overlay wordt geopend. Ook is het zaak dat de content in de overlay toetsenbordtoegankelijk is.

Maar ben je er dan? Zijn er nog meer problemen met overlays en zo ja, hoe pak je die aan?

Reacties

1 Luc De Brouwer op 11-05-2011 om 09:35 uur:
Die melding geven dat de content in een lightbox geopend wordt vind ik een beetje overdreven. Eleganter is het om dan middels CSS een icoontje mee te geven aan links met rel=lightbox die dit illustreert.

Keyboard accessibility is iets wat nog niet in iedere lightbox zit en wat qua verwacht gedrag toch wel al ingeburgerd is. ( En voorspelbaar / verwacht gedrag dus ).

Bij een groot project waar ik onlangs aan gewerkt heb moesten we ook een lightbox scenario hebben waar de gebruiker een keuze moest maken en de lightbox niet op een andere wijze kon weg klikken. Met name dit laatste leverde een usability issue op omdat mensen over het algemeen een klik op de overlay als een dismissal van de lightbox beschouwen.
2 Patrick Kraaij op 11-05-2011 om 10:01 uur:
Voor een site waar ik meebezig ben gebruiken we ook een Lightbox.

De moeilijkheid hierin zit hem in het navigeren met de keyboard in de Lightbox. De focus zit, na het openen van de Lightbox, niet op de Lightbox maar op de site 'eronder', maw als men op tab drukt dan tabt men door de site en niet door de Lightbox.

Hierovoor moet ik nog een oplossing zien te vinden.
3 Bojhan Somers op 11-05-2011 om 10:17 uur:
We hebben veel moelijkheden gehad met dit in Drupal core. Het moeilijkste is dat dat het openen van een overlay duidelijk word gemaakt tot de gebruiker. Zover ik weet is hier nog geen goede oplossing voor gevonden.

http://zufelt.ca/blog/can-modal-dialog-be-made-work-properly-screen-reader-users-web
4 Mallory op 11-05-2011 om 10:39 uur:
>> Eleganter is het om dan middels CSS een icoontje mee te geven aan links met rel=lightbox die dit illustreert.

Ik laat dat niet afhankelijk aan CSS... wel oké als een extra. Bvb wij zijn gestopt met PDF filesizes en aantal pagina's in de title in te zetten, maar nu zit dat informatie altijd "buiten", in gewone tekst. Mensen lezen toch nooit op internet, maar nu hebben ze geen excuus.

Onze lightboxes werken alleen met "klik", en moeten met toetsenboorden werken... maar ja, lightboxes zijn in het Engels geschreven dus N en P toetsen doen volgende en vorige... dat werkt gewoon niet in het Nederlands :) dus wij blijven met de pijltjes. X sluit altijd uit.

Wij hebben wel vaak popups die komen met "focus" (lezen alleen) maar ze zijn al in de HTML content zelf, zijn niet verborgen op mobiel/kleine schermen, en werken net zoals gewone anchors. Dus hulptekst moet ook tonen met toetsenbord... .ook in IE6, dus altijd met een anchor.
5 Sander Aarts op 11-05-2011 om 14:05 uur:
@Mallory: Pijltjes zijn ook veel logischer dan welke letter dan ook.
Voor sluiten lijkt me overigens de ESC logischer, of evt. beiden.
6 Dirk-Jan de Groot op 31-05-2011 om 15:07 uur:
Op deze url: http://www.w3.org/TR/wai-aria-practices/#dialog_modal

staan best practices m.b.t. (modal) dialogs;

Keyboard navigation within a modal dialog includes these aspects:

Enter If the purpose of the dialog is to gather information, the dialog should have a mechanism to submit the data gathered usually via a keyboard accessible button. The Enter key should serve as the default submit action.
Esc There should be a method to close the dialog without taking any action. This could be implemented via a cancel button which is keyboard accessible. It is recommended that a dialog also be cancelled by pressing the escape key with focus on any item.
Tab Focus must be held within the dialog until it is cancelled or submitted. As the user presses tab to move within items in the dialog, pressing tab with focus on the last focusable item in the dialog will move focus back to the first focusable item in the dialog.
Shift+Tab Likewise, if the user is shift-tabbing through elements in the dialog, pressing shift-tab with focus on the first focusable item in the dialog will move focus to the last item in the dialog.

****

Weet iemand toevallig welke "lightbox" plugin hier "out-of-the-box" goed mee omgaat (keyboard navigation)?

Is er toevallig iemand die ervaring heeft met Fancybox in deze context?

@Janita, heb je een voorbeeld implementatie ergens van wat je beschrijft? Ben nieuwsgierig hoe je dit (cross-browser) maakt ....
7 Janita Top op 31-05-2011 om 22:13 uur:
Bij Fancybox gaat het niet automatisch goed met de focus, die blijft op de onderliggende pagina.

Nu gebruik ik in een project de jQuery UI dialog voor overlays en dat gaat beter.
8 Mallory op 07-06-2011 om 11:51 uur:
Wij gebruiken Lightbox2 op jeansselling.nl, en daar gaat het raar: je kunt wel meteen de toetsenbord gebruiken op de plaatjes (pijltjes en ja @Sander, ESC werkt zo goed als "x" om te sluiten) maar verder TABben blijft op de pagina daaronder. Volgens model-dialogue-regels mag dat niet, maar ik vind het zelfs mooi want ik kan naar de volgende thumbnail afbeelding met de TAB en als ik ENTER druk dan komt dat afbeelding in plaats van de oude (of, pijltjes).

Maar voor screenreaders is dat een probleem, dus mss is het best om met de hand de focus() te plaatsen op de modalbox totdat de gebruiker heeft de model gesloten (en daarna terug waar ze waren zoals nu).
9 Mallory op 16-06-2011 om 13:55 uur:
Nieuw van Bruce:
http://www.brucelawson.co.uk/2011/modal-dialogues-in-html5/
Plaats een reactie