Ersatz für onclick

[Martin Hölter]

Hallo Forum!

Ich versuche gerade, unsere Homepage barrierefreier zu gestalten und benutze dabei auch den Bobby. Der meckert allerdings auch bei dem Konstrukt
<a href="..." onclick="window.open(this.href,'bla','bla'); return false;"> rum und meint ich sollte das ganze durch einen eingabegerätunabhängigen Eventhandler austauchen, z.B. onkeypress. Das hab ich dann acuh gleich getan und beim durchtabben öffnet er mir jedes mal ein neues Fenster *grr*.
Gibt es eine Möglichkeit, nur das Ausführen des Verweises abzufangen?

Wäre für jede Hilfe (auch wahsagas Kommentare *g*, nicht bös' gemeint) dankbar!

Gruß

Martin

[FrankieB]

hi,

Ich versuche gerade, unsere Homepage barrierefreier zu gestalten und benutze dabei auch den Bobby.

Wer oder was ist Bobby?

Der meckert allerdings auch bei dem Konstrukt
<a href="..." onclick="window.open(this.href,'bla','bla'); return false;"> rum ....

onclick = Javascript und das hat mag/kann nicht jeder aktivieren.

Wäre für jede Hilfe (auch wahsagas Kommentare *g*, nicht bös' gemeint) dankbar!

$ich != "wahsaga"

Grüsse
Frankie

[Martin Hölter]

Hi!

Wer oder was ist Bobby?

Bobby ist ein Tool, um seine Seiten bzgl. Barrierefreiheit zu überprüfen: http://bobby.watchfire.com/

Der meckert allerdings auch bei dem Konstrukt
<a href="..." onclick="window.open(this.href,'bla','bla'); return false;"> rum ....

onclick = Javascript und das hat mag/kann nicht jeder aktivieren.

Deshalb biete ich ja auch das "normale" href an. Eben für die, die kein Javascript anhaben.

$ich != "wahsaga"

Ich weiß, aber die Regulars hier wissen, wie's gemeint ist.

Grüsse
Frankie

Danke und Gruß

md

[Ingo Turski]

Hi,

probier doch mal onfocus aus. Zumindest mit dem IE habe ich da keine Probleme.

freundliche Grüße
Ingo

[Martin Hölter]

Hallo Ingo!

bei <a href="..." onfocus="window.open(this.target,...);" wird das PopUp schon geöffnet, wenn man den Link mit dem Tab erreicht. Ich will aber erst beim drücken von Enter den Link aktiv werden lassen (so wie es üblich ist).

Gruß

Martin

[Ingo Turski]

Hi,

bei <a href="..." onfocus="window.open(this.target,...);" wird das PopUp schon geöffnet, wenn man den Link mit dem Tab erreicht.

...es sei denn, man benutzt den IE ;-)
Aber wie molily schon vorschlug würde ich in diesem Fall wahrscheinlich auf die Bobby-Validierung verzichten.

freundliche Grüße
Ingo

[Martin Hölter]

HI!

So werd ichs machen!

html und css sind valide, bobby meckert nur beim onclick und bei einem Link rum, der angeblich nur durch whitespaces vom nächsten getrennt ist, was auch nicht stimmt, also: bin zufrieden!

Jetzt heisst es nur noch Chef überzeugen, dass ich das so machen darf.

Aber ich glaube, ich brauche den Vergleich nicht scheuen:
http://www.sparkasse-iserlohn.de/ <- mit Programm gebastelt
http://www.sparkasse-iserlohn.de/test/ <- per Hand geschrieben
Gruß

Martin

P.S.: Danke, das hat geholfen!

[Ingo Turski]

Hi,

ist wirklich viel besser die neue Seite. Allerdings unter dem Aspekt der Barrierefreiheit noch nicht ok. Zum einen kommt es bei den Links oben zu Überlagerungen, wenn das Fenster zu schmal ist. Zum anderen sollte man m.E. den Schriftgrad auch über das Ansichtmenü im IE skalieren können.
Und mit der Trennung von Links hat Bobby bisher eigentlich immer zu Recht gemeckert.

freundliche Grüße
Ingo

[Martin Hölter]

Hi!

Ist auch noch nicht so ganz fertig. Ich werde wohl die Positionierungen so gut es geht durch float ersetzen. Schriftgrößen in em werden schwer umsetzbar sein, aber ich werds versuchen.
Aber die Trennung der Links kann ich überhaupt nicht nachvollzihen, wenn in dem angemeckerten Berich ein verlinktes Bild neben einem Textblock steht, in welchem dann nach einer gewissen Menge TExt wieder ein Link steht.

Oder vertut der ich auch mal in den Zeilennummern? Ich jann nämlcih so eine Barriere nicht erkennen...

Gruß

Martin

[Ingo Turski]

Hi,

Aber die Trennung der Links kann ich überhaupt nicht nachvollzihen, wenn in dem angemeckerten Berich ein verlinktes Bild neben einem Textblock steht, in welchem dann nach einer gewissen Menge TExt wieder ein Link steht.

Wenn das im Quelltext etwa so aussieht:
<p>eine gewisse Menge Text mit einem <a href="#">Link</a></p> <a href="#"><img /></a>
dann meckert er zu Recht. Wenn der Link jedoch mitten im Text steht, wäre das afaik kein Fehler.

freundliche Grüße
Ingo

[Martin Hölter]

Wenn das im Quelltext etwa so aussieht:
<p>eine gewisse Menge Text mit einem <a href="#">Link</a></p> <a href="#"><img /></a>

Nö. Folgender massen:

<div><a href="#"><img></a></div>
<div>Text, Text und nochmehr Text<img><a href="#">Linktext</a></div>

Und was gibts daran zu meckern?

Gruß

Martin

[Ingo Turski]

Hi,

<div><a href="#"><img></a></div>
<div>Text, Text und nochmehr Text<img><a href="#">Linktext</a></div>
Und was gibts daran zu meckern?

wenn direkt danach kein weiterer Link kommt, m.E. gar nichts.

freundliche Grüße
Ingo

[Martin Hölter]

wenn direkt danach kein weiterer Link kommt, m.E. gar nichts.

danach kommt ein <hr> und dann wieder

<div><a href="#"><img></a></div>
<div>Text, Text und nochmehr Text<img><a href="#">Linktext</a></div>

Seh ich kein Problem drin. Die Links sind auhc optisch weit auseinander...

Gruß

Martin

[Ingo Turski]

Hi,

danach kommt ein <hr> und dann wieder

das wird es aber sein. denn <hr> ist inhaltslos und lediglich ein designelement aus sicht einer braillezeile (denke ich mir mangels eigener erfahrung jedenfalls). genauso sieht bobby ja auch absatzbildende elemente nicht als echte trenner an, also z.b: <p><a href></a></p> <p><a href>... wird auch moniert.

freundliche Grüße
Ingo

[Martin Hölter]

Hi!

das wird es aber sein. denn <hr> ist inhaltslos und lediglich ein designelement aus sicht einer braillezeile (denke ich mir mangels eigener erfahrung jedenfalls).

Und was soll ich dann zur Trennung nehmen?

Gruß

Martin

[Ingo Turski]

Hi,

Und was soll ich dann zur Trennung nehmen?

kommt auf das ganze Konstrukt an. Z.B. trennt <li> Links voneinander, Falls sich also eine entsprechend formatierte Liste anbieten würde...
Oder schliesse den Link ein. Bobby sieht sowas: [<a href>link</a>] sehr gerne. Die [] könntest Du @media screen,projection,print auch ausblenden.

freundliche Grüße
Ingo

[Martin Hölter]

Hi!

Das ist doch mal ein guter Tipp!

Danke, das hat geholfen!

Gruß

Martin

[molily]

Hallo,

Und was soll ich dann zur Trennung nehmen?
kommt auf das ganze Konstrukt an. Z.B. trennt <li> Links voneinander, Falls sich also eine entsprechend formatierte Liste anbieten würde...
Oder schliesse den Link ein. Bobby sieht sowas: [<a href>link</a>] sehr gerne. Die [] könntest Du @media screen,projection,print auch ausblenden.

Das bringt letztlich nichts, außer eben, dass Bobby ruhig ist und WCAG 10.5 theoretisch erfüllt ist, da display:none bekanntlich auch von den Screenreadern und somit von Braillezeilen ignoriert wird. Ich kenne mich mit Braillezeilen nicht aus, aber wieso sollte Trennung mit li unproblematischer als Trennung mit p und div sein? Ich tippe eher auf einen weiteren Bobby-Fehler.

Mathias

[Ingo Turski]

Hi,

WCAG 10.5 theoretisch erfüllt ist, da display:none bekanntlich auch von den Screenreadern und somit von Braillezeilen ignoriert wird.

das sollte die Sache doch gerade bewirken: Anzeige der Klammern auf Braillezeilen.

Ich kenne mich mit Braillezeilen nicht aus, aber wieso sollte Trennung mit li unproblematischer als Trennung mit p und div sein?

Ich könnte mir vorstellen, daß hier der Listenpunkt ausgegeben wird und als Trenner fungiert.

freundliche Grüße
Ingo

[molily]

Hallo,

Das bringt letztlich nichts, außer eben, dass Bobby ruhig ist und WCAG 10.5 theoretisch erfüllt ist, da display:none bekanntlich auch von den Screenreadern und somit von Braillezeilen ignoriert wird.
das sollte die Sache doch gerade bewirken: Anzeige der Klammern auf Braillezeilen.

Verzeihung, da habe ich mich unverständlich ausgedrückt. Ich meinte: Die gängigen Screenreader geben das aus, was auf dem Bildschirm steht. Elemente, die mit display:none oder visibility:hidden formatiert sind, werden nicht ausgegeben. Ob die Ausgabe nun Sprachsynthese ist oder eine angeschlossene Braillezeile. Wenn am Bildschirm keine Klammern angezeigt werden, dann werden auch keine vorgelesen und es tauchen keine auf der Braillezeile auf. Nicht display:none wird ignoriert, sondern der damit formatierte Text wird als nicht existent angesehen, wollte ich sagen. Dadurch sind solche Textversteck-Aktionen, die Screenreader-Benutzern zu Gute kommen sollen, widersinnig, da sie höchstens Textbrowser-Benutzern nützen.

Mathias

[Ingo Turski]

Hi,

so gesehen hast Du ja Recht, daß es widersinnig ist. Trotzdem müßte doch afaik display:none für die Ausgabe auf Braillezeilen unberücksichtigt bleiben, oder? Damit wäre dann der Schwarze Peter an die Interpretationsprogramme weitergereicht und die Trennung der Links wäre zumindest formal erreicht.

freundliche Grüße
Ingo

[at]

Hallo.

so gesehen hast Du ja Recht, daß es widersinnig ist. Trotzdem müßte doch afaik display:none für die Ausgabe auf Braillezeilen unberücksichtigt bleiben, oder? Damit wäre dann der Schwarze Peter an die Interpretationsprogramme weitergereicht und die Trennung der Links wäre zumindest formal erreicht.

Formale Berrierefreiheit/-armut gibt es nicht.
MfG, at

[Ingo Turski]

Hi,

Formale Berrierefreiheit/-armut gibt es nicht.

nunja, Definitionssache. Aber Du hast schon Recht: wo etwas nach dem Standard barrierefrei wäre und es dann mangels Umsetzung nicht ist, ist es nicht barrierefrei.

Und da ist ich mir doch gerade eine Alternative zu display:hidden eingefallen:

<span style="font-size:0;">[</span>link<span style="font-size:0;">}</span>

Das sollte doch aber funktionieren, oder?

freundliche Grüße
Ingo

[at]

Hallo.

Und da ist ich mir doch gerade eine Alternative zu display:hidden eingefallen:

<span style="font-size:0;">[</span>link<span style="font-size:0;">}</span>

Das sollte doch aber funktionieren, oder?

Wahrschein, wie auch Kombinationen von minimaler Breite, großem Innenabstand und unterdrückten Bildlaufleisten. Je komplizierter die Lösung ist, desto unwahrscheinlicher ist es, dass Screenreader meinen, es besser wissen zu müssen. Und in deinem Fall mag es egal sein, aber auch Suchmaschinen nehmen FIR-ähnliche Techniken ja nur dann übel, wenn sie sie verstehen.
MfG, at

[Raik]

Hallo, Martin!

... und meint ich sollte das ganze durch einen eingabegerätunabhängigen Eventhandler austauchen, z.B. onkeypress. Das hab ich dann acuh gleich getan und beim durchtabben öffnet er mir jedes mal ein neues Fenster *grr*.
Gibt es eine Möglichkeit, nur das Ausführen des Verweises abzufangen?

ja, wenn du das öffnen des popups auf nur einen bstimmten key beschränkst, undzwar den, mit dem der link ausgeführt wird (enter?). finde den keycode für enter heraus und mach den zur bedingung für das öffnen.

freundl. Grüsse aus Berlin, Raik

[Martin Hölter]

Hallo Raik!

Entweder spinne ich oder der IE 6.0 kennt window.event.keyCode nicht mehr.
alert(typeof(window.event.keyCode)); gibt die Fehlermeldung window.event ist Null oder kein Objekt, während alert(typeof(window.event)); mir object entgegenwirft.

Sonst wüsste ich keine Möglichkeit, darauf zurückzugreifen.

Gruß

Martin

P.S.: Ich werde auch Mozilla-Syntax berücksichtigen.

[Raik]

Hallo, Martin Hölter!

Hallo Raik!

Entweder spinne ich oder der IE 6.0 kennt window.event.keyCode nicht mehr.
alert(typeof(window.event.keyCode)); gibt die Fehlermeldung window.event ist Null oder kein Objekt, während alert(typeof(window.event)); mir object entgegenwirft.

daran gedacht, das der keycode erst onkeyup ausgelesen werden kann?

<HTML><HEAD>
<SCRIPT event=onkeyup() for=document type=text/jscript>
  document.forms[0].elements[0].value=window.event.keyCode;
</SCRIPT>
</HEAD>
<BODY>
<form><input></form>
</BODY></HTML>

freundl. Grüsse aus Berlin, Raik

[molily]

Hallo,

vergiss Bobby. Bobby bezieht sich in dem Punkt auf die WCAG 6.4. Die Techniques dazu raten zwar zu doppelten Event-Handlern, ich sehe hier aber keinen Sinn darin. Du kannst wahrscheinlich nicht zuverlässig das Aktivieren des Links über einen der gewöhnlichen JavaScript-Events erkennen. Das sollte hier m.E. auch nicht notwendig sein, da der Link ja auch ohne das Popup funktioniert. Die Zielseite würde also ganz normal ohne Popup aufgerufen, was ich vertretbar finde, da ich keinen Grund sehe, den Benutzer unbedingt auch in diesem Falle mit einem Popup zu beglücken. Hauptsache ist, dass die Funktionalität des Links jederzeit erhalten bleibt. Insofern ist die Lösung m.E. auch ohne zusätzlichen Event-Handler WCAG-konform.

Im Übrigen feuert MSIE 6 den onlick-Event, wenn der Link per Tastatur angesprungen und mit Enter aktiviert wird. Von IE 5.x nehme ich dasselbe an. Opera ab 7.11 und Mozilla spätestens ab 1.0 zeigen dasselbe Verhalten. Das Popup-Fenster öffnet sich somit auch bei Tastaturaktivierung des Links, ein zusätzlicher Event-Handler ist somit auch aus dem Grunde unnötig.

Siehe auch http://www.barrierefreies-webdesign.de/knowhow/pop-up-fenster/index.php und </archiv/2003/1/36287/#m198339>.

Mathias