Strohhalm

Sprung zu Navigation. Sprung zu Privat. Sprung zu Linktipps. Sprung zu StyleSwitcher. Sprung zum Inhalt.

 

Sprung zu Navigation. Sprung zu Privat. Sprung zu Linktipps. Sprung zu StyleSwitcher. Sprung zum Inhalt.

Privat

 

Anmelde-Formular



Als Strohhalm-Mitglied registrieren.

 

Sprung zu Navigation. Sprung zu Privat. Sprung zu Linktipps. Sprung zu StyleSwitcher. Sprung zum Inhalt.

Linktipps

 

passende Links in der aktuellen Rubrik

keine Links vorhanden

Insgesamt sind 130 Links in den Link-Listen

 

Sprung zu Navigation. Sprung zu Privat. Sprung zu Linktipps. Sprung zu StyleSwitcher. Sprung zum Inhalt.

Sprung zu Navigation. Sprung zu Privat. Sprung zu Linktipps. Sprung zu StyleSwitcher. Sprung zum Inhalt.

Forum

 

strohhalm.org / Forum / Forenübersicht / Barrierefreiheit / Nachricht 1316 lesen

alternative Seiten und Barrierefreiheit

  1. alternative Seiten und Barrierefreiheit

    wurstbrot.+0 -0.12. Juni 2006, 18:26

    Hallo,

    ich plane gerade ein etwas umfangreicheres Projekt und will dieses nach Möglichkeit barrierefrei gestalten. Allerdings will ich für die normalen Benutzer auch nicht auf AJAX verzichten, weil es die Performance doch stark verbessern kann. Deshalb hab ich gedacht: Bietet man auf der Seite einen Link an, der AJAX deaktiviert.

    Nun steht aber z.B. in den externer LinkBiene-Kriterien:

    Verzicht auf seitenübergreifende Alternativ-Versionen Prüfen Sie, ob auf einen parallelen seitenübergreifender Alternativ-Auftritt
    verzichtet wird. Das Vorhandensein eines seitenübergreifenden Alternativ-Auftritts führt zum Ausschluss vom Wettbewerb.

    Dann stellt sich doch die Frage: handelt es sich bei einer solchen Funktion um einen alternativen Zugang? Streng genommen ja, aber ohne diese Alternative würde ich ja Einschränkungen für normale User in Kauf nehmen.

    Wie seht ihr das?

    Wurstbrot

    Antworten [/forum/index.php?topic=1316&strukturid=1316&action=newEntry]

  2. Re: alternative Seiten und Barrierefreiheit

    wahsaga.+3 -0.12. Juni 2006, 18:32

    Unter einer "seitenübergreifenden Alternativ-Version" würde ich eher verstehen, dass du lediglich Links auf unformatierte Seiten/Textversionen bereitstellst - und dir dann zufrieden einbildest, du hättest der "Barrierefreiheit" damit Genüge getan. Gibt ja genug Leute, die solch ein Verständnis davon haben …

    Wenn du aber AJAX optional abschaltbar machst, sehe ich darin kein Problem hinsichtlich der Barrierefreiheit - wer es aufgrund irgendwelcher Einschränkungen nicht sinnvoll nutzen kann, schaltet es ab, und gut.

    Schön wäre, wenn du diese Einstellung in einem Cookie abspeicherst (oder alternativ bei Seiten, die einen geschlossenen Benutzerkreis haben, der sich einloggt, im Profil) - so dass ich die Entscheidung nicht bei jeder neuen Surf-Session erneut treffen muss.

    Bleibt noch die Frage: Weiß der Benutzer, den es betreffen würde, was AJAX ist, und warum er u.U. besser daran täte, es abzuschalten?
    Hier wäre denkbar, kein opt-out, sondern opt-in zu verwenden - beim ersten Aufruf einer Funktionalität wird der Benutzer gefragt, ob er AJAX benutzen möchte - wenn er damit nichts anzufangen weiß, dann soll er halt "nein" wählen, und bleibt künftig davon verschont.

    Antworten [/forum/index.php?topic=1316&strukturid=1316&action=newEntry]

  3. Re: alternative Seiten und Barrierefreiheit

    MuT.+0 -0.13. Juni 2006, 10:43

    Bleibt noch die Frage: Weiß der Benutzer, den es betreffen würde, was AJAX ist, und warum er u.U. besser daran täte, es abzuschalten?
    Hier wäre denkbar, kein opt-out, sondern opt-in zu verwenden - beim ersten Aufruf einer Funktionalität wird der Benutzer gefragt, ob er AJAX benutzen möchte - wenn er damit nichts anzufangen weiß, dann soll er halt "nein" wählen, und bleibt künftig davon verschont.

    Naja, bei "Non-Nerd-Seiten" (im weitesten Sinne!) stellt man damit aber locker mehr als 90% der Besucher vor unlösbare Aufgaben…. "AJAX? Will ich hier die Küche säubern - oder Fußball gucken??"
    Der Schalter sollte also keineswegs "AJAX-Abschalten" oder so heißen - sondern sich auf die Funktionen beziehen…

    Gruß,
    Daniel

    PS: Ich würde es ziemlich bescheuert finden, wenn ich eine Website funktionell beschränkte, nur um irgendwelche Standards 110%ig erfüllen zu wollen!

    Antworten [/forum/index.php?topic=1316&strukturid=1316&action=newEntry]

  4. Re: alternative Seiten und Barrierefreiheit

    Pedrito.+1 -0.13. Juni 2006, 11:55

    Man sollte AYAX eh nur für nützliche/hilfreiche, aber nicht für unbedingt benötigte Grund-Funktionen einsetzen, die sich auch per HTML abbilden lassen. Ich glaube nicht, dass es da viele überschneidende Features gibt, die unbedingt auch zugänglich sein müssen.

    AYAX hängt eh von aktiviertem JS und einem ansprechbaren XMLHTTP-Objekt ab und Screenreader gehören da wohl nicht zur Zielgrupppe.

    Ob JS aktiviert ist oder nicht, ist klar abgrenzbar und handelbar und Fallbacks sind meist gar kein Problem, Stichwort Unobtrusive. Z.B.: Per JS einfach einen normalen Link deaktivieren und durch eine AYAX-Funktion ersetzen, oder auch Interfaces komplett erst per DOM erstellen.

    Auf einer normalen Seite mit durchschnittlichem Zielpublikum ist es ein NoGo, JavaScript oder AYAX namentlich zu erwähnen oder gar vorauszusetzen, dass einer daraus eine Entscheidung ziehen kann. Entweder funktioniert die Infrastruktur oder halt nicht.

    mfG
    Pedrito

    Antworten [/forum/index.php?topic=1316&strukturid=1316&action=newEntry]

  5. Re: alternative Seiten und Barrierefreiheit

    wurstbrot.+0 -0.13. Juni 2006, 12:03

    [Pedrito:]
    Ob JS aktiviert ist oder nicht, ist klar abgrenzbar und handelbar und Fallbacks sind meist gar kein Problem, Stichwort Unobtrusive. Z.B.: Per JS einfach einen normalen Link deaktivieren und durch eine AYAX-Funktion ersetzen, oder auch Interfaces komplett erst per DOM erstellen.

    Ja, das ist leider nicht ganz korrekt. Sicher werden alle Funktionen doppelt angeboten. Aber Screenreader (von JAWS weiß ich es sicher) unterstützen JavaScript. Somit kann ich damit nicht herausfinden, ob ich AJAX verwenden soll oder nicht. Das Problem ist schlicht, dass die Screenreader AJAX unterstützen, aber die Änderung dem Benutzer nicht mitteilen (das ist ja gerade das eigentliche Problem). Ich habe deswegen JAWS mal angeschrieben, ob die für Entwickler nicht eine entsprechende Funktion anbieten könnten, mit der man sagen kann, was nochmals vorgelesen werden soll. Bisher aber keine Antwort.

    Wurstbrot

    PS.: AJAX = Asynchronous JavaScript And XML (also kein Y)

    Antworten [/forum/index.php?topic=1316&strukturid=1316&action=newEntry]

  6. Re: alternative Seiten und Barrierefreiheit

    wahsaga.+1 -0.13. Juni 2006, 12:37

    [Pedrito:]
    Auf einer normalen Seite mit durchschnittlichem Zielpublikum ist es ein NoGo, JavaScript oder AYAX namentlich zu erwähnen oder gar vorauszusetzen, dass einer daraus eine Entscheidung ziehen kann.

    Es müssen ja keine solchen Fachbegriffe verwendet werden (oder nicht ausschließlich).

    Es reicht ja die Erklärung, dass optional Techniken verwendet werden, die zum Beispiel für die Benutzer von Screenreadern problematisch sein könnten - und das solche sie deshalb lieber abschalten (opt-out) oder nicht aktivieren (opt-in) sollten.
    Für technisch interessiertere/bewandertere Nutzer kann man ja eventuell zusätzlich eine etwas ausführlichere Erklärung anbringen, um welche Art von Techniken es sich dabei handelt.

    Antworten [/forum/index.php?topic=1316&strukturid=1316&action=newEntry]

  7. Re: alternative Seiten und Barrierefreiheit

    Pedrito.+0 -0.13. Juni 2006, 12:55

    @wahsaga,
    gibt eigentlich ein Screenreader einen User Agent zurück? Dann wäre das Problem gegessen.

    mfG
    Pedrito

    Antworten [/forum/index.php?topic=1316&strukturid=1316&action=newEntry]

  8. Re: alternative Seiten und Barrierefreiheit

    DukeXP.+0 -0.13. Juni 2006, 14:35

    […] gibt eigentlich ein Screenreader einen User Agent zurück?

    Viele Screenreader setzen auf den IE auf und lassen sich daher nicht erkennen.

    Antworten [/forum/index.php?topic=1316&strukturid=1316&action=newEntry]

 
Nach oben springen

.(c) 2002 - 2018 strohhalm.org Community.Server powered by Manitu.Software powered by Mathias Bank
.Impressum + Team.Datenschutz