Fronteers — vakvereniging voor front-end developers

Webrichtlijn 54: Sneltoetskoppelingen

Ontzie het accesskey attribuut. Als toch besloten wordt dit attribuut toe te passen, gebruik het alleen op links die door de hele site onveranderd blijven (bijvoorbeeld hoofdnavigatie) en beperk de sneltoetscombinaties tot nummers. (R-pd.8.11)

Discussiëren maar :) Wie gebruikt dit attribuut?

Reacties

1 Kor Dwarshuis op 01-10-2008 om 11:28 uur:
Mijn initiële reactie is dat ik het leven al ingewikkeld genoeg vind zónder het accesskey attribuut en dat ik daarom dit attribuut graag ontzie.
2 Willem Bogaerts op 01-10-2008 om 12:06 uur:
Dit reactieform is een mooi voorbeeld waar accesskeys op hun plaats zouden zijn. Access keys zijn er niet voor navigatie-links, maar om de muis te ontzien bij invulvelden. Het is niet erg kies om de gebruiker te dwingen op een bepaalde manier te werken die voor hem wellicht helemaal niet handig en soms zelfs pijnlijk is!
Uiteraard moeten accesskeys gewoon worden aangegeven net zoals in elke goed geschreven programma. Voor dit form zou dus de N onderstreept kunnen worden van het Naam veld.
Voor accesskeys nummers gebruiken is wel het minst logische en gebruiksvriendelijke wat je kunt doen (al is daar een engelse overheidsstandaard voor).
3 Krijn Hoetmer op 01-10-2008 om 12:17 uur:
Willem: Alleen bij dit reactieformulier, of bij alle formulieren op de site?

De Engelse overheidsstandaard voor accesskeys trouwens. En meer artikelen: http://www.smackthemouse.com/20031231 en http://www.cs.tut.fi/~jkorpela/forms/accesskey.html
4 Sander v L op 01-10-2008 om 12:38 uur:
Een van de voornaamste redenen om accesskeys te ontzien is "Sneltoetscodes botsen met de gangbare sneltoetscodes in de webbrowser en het besturingssysteem."
Dit is een probleem van browsers, niet van accesskeys. Een browser zou altijd de voorkeur moeten geven aan de shortcut key van zichzelf boven die van een website.

Gelukkig komt het probleem in Gecko browsers niet meer voor: Daar moet je tegenwoordig shift-alt gebruiken om een accesskey te triggeren, wat gelijk alle conflicten heeft opgeheven. (En mocht je net als ik shift-alt een rot-combinatie vinden, dan kan je door de ui.key.contentAccess pref aan te passen er iets anders van maken. (Bij mij staat ie op 6, wat ctrl-alt is.))

Het punt van "Er is geen standaard voor te gebruiken sneltoetscodes op websites." is naar mijn mening een stuk minder sterk. Hier is helemaal geen standaard voor nodig. Accesskeys zijn uberhaupt alleen interessant voor veel terugkerende gebruikers, en als deze keyboard gebruikers zijn (i.p.v. mensen die de voorkeur geven om de muis overal voor te gebruiken), dan is de winst die accesskeys bieden dusdanig groot dat ze bereid zijn om site-specifieke shortcut keys te leren. (Intensieve data entry is hier altijd het beste voorbeeld van.) Deze gebruikers vertellen dat accesskeys beschikbaar zijn is heel makkelijk: gooi een text-decoration: underline op de betreffende letter, en het is duidelijk (voor mensen die weten dat accesskeys uberhaupt bestaan; voor mensen die dat niet doen doet het allemaal niet ter zake, want ze zullen er ook nooit last van hebben).
Een goed voorbeeld hiervan kan ik vinden in mijn eigen foto-gallerij, waar ik accesskeys "n" en "p" heb voor doorspringen naar de next en previous foto. Mensen die een hele rits foto's willen bekijken (en liever het keyboard gebruiken dan de muis) hebben zo door dat dat bestaat.

Natuurlijk is het goed om consistent te zijn met andere websites indien er een conventie gevormd is - maar dat is aan de websites zelf. Ik denk bijvoorbeeld aan hoe alle grote message boards accesskey="s" op de submit button hebben. vBulletin was daar volgens mij de eerste mee, en alle andere forum software heeft dit gekopieerd, omdat het een goed idee is (als je net een heel stuk getypt hebt is het een stuk makkelijker om (shift-)alt-s te doen dan om weer helemaal naar die muis te reiken), en de logische keus is.
Ook bestaan er een groot aantal websites waar alt-s het zoek formulier focused. Maar deze staan bijna volledig orthogonaal op de message board websites, en de verwarring die dit zal opleveren is minimaal.

Ik ben het ook niet eens met het advies van accesskeys op hoofdnavigatie. Dit wordt in een normale website zo weinig gebruikt (bij normaal gebruik elke link maximaal één keer per bezoek) dat een accesskey er helemaal geen voordeel biedt. Het is juist veelvuldig gebruik van een link of form element waarbij een accesskey nuttig is, en dit komt vaak maar voor op slechts een paar pagina's binnen de site.
Zolang die accesskeys maar geen verwarring scheppen (je moet niet "s" gebruiken voor focus op het "subject" veld in het ene scherm, en voor de "submit" knop in het andere scherm).
5 Krijn Hoetmer op 01-10-2008 om 12:48 uur:
Opera lost het trouwens ook leuk op, door via Shift + Esc een overzicht van de accesskeys te geven. Maar of je daarmee sneller door een site navigeert, vraag ik me af..
6 Koen Willems op 06-10-2008 om 01:02 uur:
Ik denk dat de Webrichtlijnen hier eigenlijk een kans gemist hebben.
Zoals we hier lezen ontbreekt een standaard voor sneltoetskoppelingen: http://www.webrichtlijnen.nl/handleiding/ontwikkeling/productie/links-navigatie/sneltoets-koppelingen/#r-pd-8-11.

Achteraf gezien hadden de Webrichtlijnen beter zelf een standaard (zie het Britse voorbeeld) kunnen stellen.

Overigens, veel bezoekers van websites zijn niet op de hoogte van sneltoetskoppelingen. Tegen die achtergrond verdient het aanbeveling een mogelijkheid te bieden de sneltoetskoppelingen bij bijvoorbeeld diverse navigatieknoppen te tonen.

Op http://www.regels-stadskanaal.nl/voorkeuren (tweede blok) kun je zien hoe dat kan.
7 Sander A op 06-10-2008 om 02:13 uur:
@Koen:
Ik lees op http://www.regels-stadskanaal.nl/voorkeuren het volgende: "Druk op Alt (PC) of Ctrl (Mac) samen met de cijfers of letters die u hieronder invult om naar de verschillende site-onderdelen te gaan." Zoals Krijn al aangaf hanteert Opera een iets andere manier om met sneltoetsen om te gaan (Shift + Esc om de access-key mode te activeren en vervolgens de bewuste key voor de gewenste link). Ook Firefox hanteert een andere toetsencombinatie: i.p.v. Alt + 'accesskey' zul je in Firefox Shift + Alt + 'accesskey' moeten gebruiken (tenzij je zelf eerst in de config gaat zitten rotzooien).

offtopic
hoe heet eigenlijk het kanaal dat door stadskanaal loopt? ;P
/offtopic

@Sander:
De standaardweergave van accesskeys, d.m.v. het onderstrepen van de bewuste letter, werkt natuurlijk alleen als de link niet al onderstreept is ;-) Anders zul je terug moeten vallen op iets als wat Koen doet (key tussen haakje achter de link vermelden) maar ik vraag me eerlijk gezegd af of dat dat direct duidelijk is. Bij de stadskanaal-site moet de gebruiker het zelf eerst aanzetten, dus dan zal het ook wel duidelijk zijn. Maar anders...?

Is het title attribuut een goede plaats om de accesskey te vermelden?
8 Kor Dwarshuis op 06-10-2008 om 09:20 uur:
@Sander A: als geboren Groninger zeg ik: er loopt helemaal geen kanaal door Stadskanaal (zelfs geen fronteers IRC kanaal volgens mij), het is volksverlakkerij. Dit antwoord heb ik voor Koen zijn neus weggekaapt, maar die toegangssleutelvraag staat nog open :-)
9 Sander v L op 06-10-2008 om 13:55 uur:
@Sander A: Dat klopt natuurlijk. Gelukkig vindt het grootste gedeelte van (mijn) accesskey gebruik niet op links plaats, maar op form elementen, waar je dat probleem niet hebt.
Ik kan me eerlijk gezegd geen enkel project herinneren waar ik aan heb gewerkt waar de underline van de aanduiding van een accesskey conflicteerde met de underline van een link. De links waarop een accesskey nuttig is zijn vaak niet "gewone" links binnen een lopende tekst, maar 'belangrijkere' links die n.a.v. hun functies al gestyled zijn als buttons of tabs of wat dan ook. (Bovendien houden veel designers niet meer van underlines op links.) :)

Mocht het desondanks toch voorkomen dat je een gewone onderlijnde link met accesskey wil hebben, dan zou ik me kunnen voorstellen dat ik daar een mou aan zou passen door heel vuil gebruik te maken van border-bottom als tweede "underline", of eventueel de letter in kwestie vet zou maken en een andere kleur zou geven. (Dat is een stuk minder duidelijk, maar als het consistent door de hele site heen wordt gedaan, dan is dat waarschijnlijk goed genoeg.)
10 Koen Willems op 06-10-2008 om 23:17 uur:
@Sander A: ik ga de tekst van de week even aanpassen.
'Shame on me!'
:-)
11 Herko op 09-10-2008 om 10:47 uur:
@sander v l:

"Dit is een probleem van browsers, niet van accesskeys. Een browser zou altijd de voorkeur moeten geven aan de shortcut key van zichzelf boven die van een website."

Als het een probleem van de browsers is, zou het doel dan niet moeten zijn dat ze er allemaal op dezelfde manier mee om gaan (net als met alle andere attributen en tags)? Als de accesskey nu conflicteert met de browser shortcut, wint de browser.

"De links waarop een accesskey nuttig is zijn vaak niet "gewone" links binnen een lopende tekst, maar 'belangrijkere' links die n.a.v. hun functies al gestyled zijn als buttons of tabs of wat dan ook. (Bovendien houden veel designers niet meer van underlines op links.) :)"

wat als je de pagina stijlloos bekijkt (css uit)? Dan zijn alle links (ook die belangrijke navigatielinks) blauw, onderstreept. Dan is het onderscheid moeilijk te maken.

Accesskeys zijn juist als attribuut toegevoegd als alternatief voor de normale rendering van de opgemaakte code. Het argument 'voor mijn sites is geen alternatief nodig' gaat dus niet op.

Wat raden jullie aan? Een standaard voor gebruik opnemen (standpunt Koen) of helemaal weglaten (huidige richtlijn)?
12 Sander v L op 16-10-2008 om 14:08 uur:
@Herko: Browsers gaan qua behaviour niet allemaal hetzelfde om met content, en dit zal ook nooit geëist worden. In de HTML5 specificatie wordt bijvoorbeeld expliciet niet verteld hoe een browser een date of email input veld moet behandelen, maar er wordt gesuggereerd dat hier een kalender-control of een combinatie met adresboek gebruikt kan worden om de user-experience beter te maken. Verder is dit expliciet ongedefinieerd gelaten, en kunnen browsers hierop concurreren.
HTML is wat dat betreft een heel ander beest dan CSS of de DOM, waar wel precies verteld wordt wat een browser moet doen. Zie bijvoorbeeld ook het link element (met rel= up, prev, next etc), en experimenten van browsers om daar iets mee te doen, zoals bijvoorbeeld de oude site navigation toolbar van de Mozilla Suite / SeaMonkey.

Nou moet ik wel toegeven dat accesskey een erg lastig attribuut is, dat ergens helemaal niet in HTML thuis hoort (XBL zou bijvoorbeeld een veel betere keus zijn geweest voor die functionaliteit), maar ja, die keuzes zijn in het verleden gemaakt, en accesskey "werkt" nu op een min-of-meer consistente manier, dus als je er gebruik van kan maken om het leven van je bezoekers makkelijker te maken, dan moet je dat ook zeker doen.


Je punt dat accesskeys niet te ontdekken zijn als je ze via styling aangeeft, en een gebruiker styling uitzet, klopt zeker. Maar uiteindelijk gaat er geen core functionaliteit verloren als accesskeys niet bij de gebruiker bekend zijn. Behaviour is optioneel, net als CSS. Je doet gewoon aan progressive enhancement door ze wel beschikbaar en bekend te maken.


Ik snap eerlijk gezegd niet wat je bedoelt met "Accesskeys zijn juist als attribuut toegevoegd als alternatief voor de normale rendering van de opgemaakte code."

Zou in ieder geval geen strikte standaard vanuit de webrichtlijnen voor gebruik van accesskeys opnemen. Als de webrichtlijnen er uberhaupt al iets over moeten zeggen, dan zou ik er zelf iets van maken als "Als een bezoeker veelvuldig gebruik maakt van individuele links of form-elementen kan een accesskey dit gebruik makkelijker maken. Omdat de meeste browsers het bestaan van accesskeys niet aan de gebruiker duidelijk maken is dit een taak voor de website. Pas ook op met conflicten met browser-gedefinieerde shortcut keys in oudere browsers."
Plaats een reactie