2015-10-22 6 views
6

Ich habe ein Problem beim Testen unserer Webapp für die Barrierefreiheit. Obwohl ich scheinbar sehr einfach bin, konnte ich keine klare Antwort auf Google finden.Was bestimmt, wenn eine Verbindung besucht wird?

Das Problem ist, dass der Bildschirmleser (speziell Voice Over in iOS und OSX Safari) jeden internen Link in der App als "Visited Link" liest, noch bevor der Benutzer auf einen von ihnen geklickt hat. Die Links haben alle die gleiche Basis (etwas wie http://domain.com/path/index.html#what-the-link-does), also mein erster Instinkt ist, dass, da diese Links alle auf verschiedene Hashes in derselben Datei verweisen, die Links Ansichten sind, wie sie besucht wurden, weil diese Datei besucht wurde.

Das ist jedoch nicht das gewünschte Verhalten. Wir möchten, dass alle Links nur als "Link" bezeichnet werden. Also hier sind meine Fragen:

  1. Was bestimmt, ob die Verbindung als besucht gilt? Wird nur der Besuch der Domain es verursachen? Wird der Besuch einer bestimmten Datei es verursachen? Oder sollten verschiedene Hashes derselben Datei unterschiedliche Status haben?

  2. Gibt es eine Möglichkeit, dieses Verhalten zu steuern und die Links davor als besucht lesen zu verhindern? Irgendein Aria Parameter vielleicht?

+0

wenn Sie alle von ihnen als unvisited markieren müssen es möglich ist, unter Verwendung von 'a: visited' Wählern, aber man kann nicht wissen, welche Verbindung er besuchte und was er nicht tat, es sei denn, du hast js code in deiner site, die den link zu cookies oder datenbank kopiert, bevor er dorthin weitergeleitet wird (wie facebook und google es jetzt tun), aber wenn der benutzer den link von außerhalb deiner seite besucht, würdest du t wissen – robert

+0

und durch die Art und Weise speichern, welche Links der Benutzer auf Ihrer Website besucht vielleicht betrachten "Verletzung der Privatsphäre", so wenn Sie dies tun, sollten Sie die Benutzer dieser – robert

+0

Benachrichtigen Wenn der Benutzer ging zu http://example.com /path/index.html als alle Links zu diesem werden besucht. Der Hash bedeutet nichts anderes als einen Ort auf der Seite. – epascarello

Antwort

1

Vielleicht habe ich die Frage falsch verstanden, aber wenn Sie Ihre Links sind auf index.html in Ihrem Beispiel können Sie nicht

http://domain.com/path/index.html#what-the-link-does 

mit einfach ersetzen

#what-the-link-does 

Die besuchte Logik wahrscheinlich nur betrachten der URI ohne Abfragezeichenfolge/Anchor-Tags wird berücksichtigt

+0

Ich denke, Sie haben mich in die richtige Richtung gezeigt. Nachdem ich einen weiteren Blick darauf geworfen hatte, bemerkte ich, dass einige der Links nur auf "#" mit Klickverhalten zeigten, das vollständig von JS gesteuert wurde. Ich vermute, dass, wenn ich die Links zu "# a-unique-value" ändere, sie weniger wahrscheinlich als besucht gelten. – Kris

0

Es ist abhängig von der Implementierung. Nach the spec,

Es ist möglich, Stylesheet-Autoren zu missbrauchen: link und: visited Pseudo-Klassen, um zu bestimmen, welche Websites ein Nutzer ohne die Zustimmung des Benutzer besucht hat.

UAs können daher alle Links als nicht besuchte Links behandeln oder andere Maßnahmen implementieren, um die Privatsphäre des Benutzers zu schützen, während besuchte und nicht besuchte Links anders dargestellt werden.

Die Spezifikation erfordert nur :link und :visited sich gegenseitig ausschließen, aber nicht angeben, wie.

+1

Das Problem hier ist, dass _unvisited_ Links als besuchte Links behandelt werden, nicht umgekehrt. –

+0

Ja, das ist das Problem. Es gibt kein Styling für ': visited', also sieht alles gut aus. Ich möchte nur, dass der Bildschirmleser aufhört, jeden Link zu lesen, als ob er besucht würde. – Kris

0

Ich denke, das Problem, das Sie haben, ist eine falsche Anwendung des Anchor-Tags in Bezug s zur Zugänglichkeit. Ich gehe davon aus, dass Sie eine einzelne Seitenanwendung codieren, und jeder Link zu einer anderen Ansicht ist ein Anker. Sie sollen einen Taste Tag statt mit einigen CSS ninjitsu werden.Es ist ein fantastischer Artikel über diese hier genaue Sache:

http://www.karlgroves.com/2013/05/14/links-are-not-buttons-neither-are-divs-and-spans/

Verwandte Themen