Het probleem met accesskeys
Michael heeft het op Nono over Accesskeys:
Door toetsencombinaties te voorzien kunnen deze gebruikers met hun toetsenbord snel de gewenste pagina bezoeken.
Accesskeys bestaan al lang maar worden maar weinig gebruikt. Ik zie twee oorzaken. Ten eerste is het niet evident om de aanwezigheid van accesskeys op een bepaalde website duidelijk te maken. Standaard is er in de meeste hedendaagse browsers geen aanduiding voorzien van de aanwezige accesskeys, dus is het aan de maker van de pagina om de mogelijkheid in de kijker te zetten. Dit zal bijgevolg verschillen van site tot site – als er überhaupt al een hint gegeven wordt.
De tweede reden zijn de mogelijke conflicten met de standaard browserfunctionaliteit. Michael zegt:
Windows gebruikers gebruiken nu ALT+Accesskey (gevolgd door Enter)
Klopt, al is dit niet het geval voor Opera (Shift+Esc, dan Accesskey) en voor Firefox sinds versie 2.0 (Shift+Alt+Acceskey) en dat heeft een goeie reden. Met een ALT+karakter kan je namelijk ook bepaalde items uit het menu van je browser aanroepen.
In Internet Explorer (waar wel met ALT+Accesskey wordt gewerkt) geven accesskeys die toevallig ook sneltoetsen van de browser zijn, aanleiding tot verwarrend gedrag:
- Als een letter enkel in een sneltoetscombinatie van de browser voorkomt, wordt het bijhorende menu-item geactiveerd (goed!)
- Als een letter enkel als accesskey op de webpagina gebruikt wordt, wordt deze link geactiveerd (goed!)
- Als de letter zowel door de brower (als sneltoetscombinatie) als door de webdesigner (als accesskey) gedefinieerd is, wordt voorrang gegeven aan de accesskey en zal het menu-item niet geselecteerd worden (niet goed!)
Afhankelijk van welke website een gebruiker bekijkt, werken bepaalde sneltoetsen dus wel of niet. Gebruikers die geen idee hebben van het bestaan van accesskeys, maar die wel met browser-shortcuts werken, zullen in sommige gevallen voor onverklaarbare problemen staan.
Om deze twee redenen vind ik de usability-voordelen van accesskeys – momenteel – niet opwegen tegen de nadelen. Wat denk jij hiervan?
Ik heb er nooit gebruik van gemaakt en nu ik er van weet, zal ik er ook geen gebruik van maken (niet als webdesigner en niet als internetgebruiker). In Firefox is het nog redelijk fijn te gebruiken, maar in IE dus niet. En Opera: ik vind Shift-Esc een nogal ongelukkige combinatie.
[...] Update: Michiel somt eventjes op welke toetsencombinaties op welke platformen en bij welke browsers voorzien zijn. [...]
Wat betreft die herkenbaarheid: Net als RSS in z’n beginjaren, zullen accesskeys door webdevelopers en webdesigners meer naar voren gebracht moeten worden, vrees ik (hier alvast een voorbeeld). Zomaar naast je neer leggen omdat ze eventueel in conflict zouden kunnen komen met sneltoetsen van de browser, lijkt me totaal verkeerd.
Indien je deze goed zichtbaar in het design zet, heb ik geen problemen met numerieke accesskeys. To hell with Opera>>accesskeys ;-)
Klopt Michael, willen accesskeys populair worden, zullen de webdesigners uit hun kot moeten komen. Maar het verschil met andere toekomstgerichte verbeteringen, zoals RSS en Microformats, is dat accesskeys blijkbaar in de weg staan van andere functionaliteit.
Een mogelijke oplossing is, zoals Benjamin zegt, enkel gebruik te maken van cijfers, die bij mijn weten niet gebruikt worden als browser-shortcuts. Dit komt trouwens ook terug in de aanbevelingen van de UK Government accesskeys standard.
Wat nog beter is Michiel, is om -zoals ook in de UK Government accesskeys standard genoemd- vaste accesskey’s te gebruiken voor diverse pagina’s. Voorbeelden als 1 voor de beginpagina.
Gebruikmakend van de juiste rel-attributen in de code, is met enkel toetsen navigeren in een site – met Opera – al zeer gemakkelijk. Met spatie volg je bv de link met rel=”next”. De navigatiebalk toont alle herkende links: index, help, copyright, sitemap, home, auteur, volgende, vorige, omhoog, enz. Dit komt redelijk overeen met die lijst van de UK Government accesskeys standard. Dus, met een paar beschrijvende attributen in de code kun je de browser al een stuk slimmer maken. Ik geef de voorkeur aan het rel-attribuut, dat meer betekenis geeft aan een link dan een accesskey doet.
Het nadeel van het gebruik van numerieke accesskeys in browsers is dat je de speciale tekens niet meer via je alt toets en het numerieke toetsenbord kan creeeren.
Voor de rest, leuk dat een artikel van mij aangehaald wordt op deze site, altijd leuk om te zien. Een vervolgartikel op het artikel dat hier aangehaald wordt staat hier: http://www.internetschoon.nl/viewSingleItem/348/
Nagenoeg met gelijkende strekking als dit artikel overigens.
Tja, niet akkoord eigenlijk, om dezelfde reden als die die Arjan aanhaalt. De firefox combinatie ALT+SHIFT in samenwerking met de UK Gov acceskeys specificatie lijkt me het meest optimaal. Eventueel kan dit aangevuld worden met een unificatie van bepaalde rel-verwijzingen :).
@Xavez: De Firefox-combinatie mag dan wel ok zijn, maar die van IE geeft problemen. Ik sta achter het concept van accesskeys, maar in de praktijk werken ze (nog) niet.
Rel-attributen hebben toch veel meer betekenis? Een accesskey vertelt op zichzelf niets, dus kan de browser er ook niets mee. De site zal aan de gebruiker duidelijk moeten maken dat ‘de accesskey-standaardisering’ van toepassing is. Het feit dat sites hun eigen standaard kunnen volgen, betekent verwarring voor de gebruiker (”alt-shift-0 was toch home?”). Met de rel’s heb je al goede afspraken daarover ( http://www.oasis-open.org/cover/maloneyQuinLinkRel.txt ). Accesskeys zijn niet semantisch, om even met een buzzword te spreken.
@Michiel: klopt, maar ik pleit net voor een standaardisering van de toetsencombinatie (Mac en PC kunnen dan wel verschillen, bijvoorbeeld).
@Vincent: dat klopt, maar wat doe je dan met links (anchors) in het document zelf? Vanuit webdesignstandpunt vind ik het overigens alles behalve optimaal om de next/previous links in de header te moeten steken. Een standaardisering van de rel-waarden in het document zelf (body) bijvoorbeeld zou dan weer wel een oplossing kunnen zijn.
En daarbij moeten we ook realistisch blijven. rel’s zullen de langetermijnoplossing ongetwijfeld zijn, maar op dit moment zie ik Microsoft of Mozilla niet meteen grote updates aan “de manier van browsen” doorvoeren. Standaardisering van de accesskeys is iets wat m.i. makkelijker door te voeren is dan een heel nieuwe browsercomponent :).
Links met rel-waarden mogen ook in de body (de specificaties verbieden dit toch niet?), hoewel Opera deze waardes dan niet inleest. Dat zou inderdaad gepromoot moeten worden, ik zal eens kijken wat er in de Opera-gemeenschap over is gezegd.
Wat betreft de overige links (externe links etc, niet de FAQ en home-pagina), daarvoor zijn accesskeys wel een goed idee. Rel’s voor standaardpagina’s, accesskeys voor de rest.
Oké, de grote browsers zullen niet snel dergelijke veranderingen krijgen, maar dat is met veel zaken zo. Dat belet ons niet om vooruitstrevend te zijn :) Als je nu niet begint met rel’s, dan zal er nooit iets veranderen aan de browsers.
Vincent
Ik hou het op een combinatie van accesskeys en rel’s ;).
Standaardisering van access keys lijkt ook niet de oplossing: de access keys moeten niet door de webontwikkelaar vastgelegd worden (weet hij veel hoe bezoekers hun computer willen gebruiken en met wat voor toetsenbord ze werken) maar door de gebruiker. John Foliot heeft heel overtuigend geprotesteerd tegen het behouden van access keys in XHTML 2 omdat ze in de huidige HTML 4 en XHTML 1.x implementaties zo’n ramp zijn. Zie hierover zijn artikel op http://www.wats.ca/show.php?contentid=47. Ook nu is het trouwens mogelijk om de access keys door de bezoeker te laten kiezen: zie de artikels van Gez Lemon over User-Defined Access Keys op http://juicystudio.com/article/user-defined-accesskeys.php en http://juicystudio.com/article/user-defined-access-keys-aspversion.php.
@Michiel, we hoeven niet eens over de grenzen te kijken: de website van de Coördinatiecel Vlaams eGovernment (CORVE) heeft ook sneltoetsen: http://www3.vlaanderen.be/e-government/accesskeys.html.