HTML Barrierefrei völlig ohne Maus - triggern von Objekten

[cumulonimbus8]

Hallo!

Auf einer Seite seien mehrere Objekte (Auswahlen) gegeben die ich über eine Kugelschreiberfunktion nach Belieben schalten kann. Final soll diese erlangte Information ›abgeschickt‹ werden.

Das geht mit OnMouseDown usw. usf. einfach, JS wird ausgelöst das Grafiken ersetzt, das alles ist schon da.

Wie navigiere ich aber, mit TAB sicherlich, Cursor wäre m.E. nach besser (aber potenziell nicht «Barrierefrei») allein per Tastatur zu meinen Objekten, schalte diese um (Enter, Leer - siehe weiter unten), gehe zum Auslöser und schalte den (wiederum Enter und/oder Leer)?
Problematisch ist, dass das anvisierte Ziel auch optisch hervorgehoben werden muss; das Rähmchen das mir FF zeigt taugt nicht(s). Hier stelle ich mir vor mag CSS helfen.

Ideen, Grafiken einfach zu INPUT zu befördern (damit kann ich sie wenigstens schon mal mit Tab erreichen), scheitern in meinem Falle daran, dass die Absendefunktion alles was Enter oder Leertaste ist für sich veranschlagt. Also ist ein einzelnes Umschalten schon mal schwierig.
JS das wie BASICs INKEY einfach mal Tastendrücke verwertet gibts ja nicht… Also bin ich eigentlich auf TAB (Shift+Tab) und Enter/Leer als Trigger angewiesen - oder? Vergessen wir bitte gleich diese Shortcut-Hilfstools; die passen auf meinen Fall nicht.

Was außer der Tastaturmaus (ich ich wohl faktisch nicht ›anbringen‹ kann) wäre realistisch? Google liefert Vorschriften, besagtes Hotkey-Tool und ein Hüpfen von Link zu Link… Irgendetwas saht ich Tabellenzellen zu beeeinflussen, aber das hat nicht richtig funktioniert. Eine Zelle (Tab-verkettet) so zu bedienen würde als optisches Element hinreichen.

CN8


PS: Das ist nicht ›meine‹ Page, ich bekomme maschninennutzbaren Code von derselben vorgebacken und kann diverse Regeln nicht umgehen. Das Reservieren von Enter/Leer scheint eine davon zu sein…

 

[Daaron]

Barrierefrei heißt: KEINERLEI JavaScript für Kernfunktionen. Barrierefrei ist nur eines: Ein vollkommen sauberer DOM, der vollkommen ohne zusätzliche Scripte auskommt und korrekt mit Labels, Titeln und Alt-Tags versehen ist.

Nein, Grafiken sind NIE barrierefrei, wenn du sie als Ja/Nein-Eingabefelder verwendest, dafür gibt es Checkboxen und NUR Checkboxen.

 

[cumulonimbus8]

Dann werde ich denen die das von mir wollen mal beibringen müssen was wirkliches Barrierefrei ist.

Das Problem mit dem Abschicken habe ich unter Kontrolle bekommen - üble Vorlagen aus der Retorte…

CN8

 

[Daaron]

Auch wenn der Award nicht mehr ausgelobt wird und mit HTML5 ein paar neue Tricks dazu gekommen sind, schau mal in den Quelltext von http://www.biene-award.de/
So sieht barrierefreies Web aus (vor allem hinsichtlich des "role"-Attributs), alles andere ist nur halbgewalkter Mist.

 

[cumulonimbus8]

Nachtrag: die Biene hatte ich auch gefunden - das Dumme ist: mit der Mechanik die mir aufbgebrummt wird gibt das insgesamt nix, da muss ich tiefer schürfen und alles neu erfinden.

CN8

 

[Daaron]

Du brauchst da gar nicht schürfen: Wenn deine Struktur nur bei aktivem JavaScript ansatzweise funktioniert, dann ist sie nicht barrierefrei. Da hilft nur: Neu schreiben in semantisch korrektem HTML5.

 

[cumulonimbus8]

«Meine» Struktur ist interaktiv, also keine pure Lese-Seite. Mit JS als logischer (und für die zentrale Funktion rein logischer) Instanz (›wurde eine Zahl größer 10 in das Eingabfeld eingegeben?‹). Mehrwert für »»normale«« Nutzer nicht ausgeschlossen.

Ich sehe im Sinne von Barrierefrei nicht recht ein warum man diesen Eingaben und Denklogik vorenthalten sollte? Das wäre eine sehr mächtige Kastration genau diese Leute denen man das Internet zur Verfügung stellen will.

CN8


PS: der Hersteller der SW die mir das vorgibt meint fröhlich, dass der Auslöse-Knopf der Seite barrierefrei und mit TAB erreichbar wäre. Stimmt auch. Nützt mir aber nichts.

 

[Daaron]

Ich sehe im Sinne von Barrierefrei nicht recht ein warum man diesen Eingaben und Denklogik vorenthalten sollte?

Weil es TECHNISCH nicht geht.
Die Accessibility - Werkzeuge wie Screenreader oder Braille-Terminals haben alle keine JavaScript-Engine, weil sie so einen Kram einfach nicht brauchen. Die haben auch keine CSS-Parser.

Wenn du wissen willst, ob und wie "zugänglich" deine Seite ist, dann verwende Lynx oder einen anderen Textbrowser. Alles, was du mit Lynx sieht und bedienen kannst, kann ein Benutzer eines Braille-Terminals auch. Alles was in Lynx nicht geht, ist nicht barrierefrei.


Der grundlegende Fehler deiner Software ist: Es wurde als ERSTES mit JavaScript im Hinterkopf gearbeitet. JS wurde für Sachen jenseits purer Optik verwendet. Statt dessen hätte die gesamte Software von 0 an erst einmal in purem, nacktem HTML geschrieben werden sollen. Kein CSS für "hübsch", kein JS für "noch hübscher" und erst recht kein JS für "jetzt mit Logik". Erst wenn die pure HTML-Semantik perfekt ist, kommt CSS3 für "verdammt hübsch" drüber, noch etwas JS für "da wackelt was" und, um den Workflow zu optimieren, OPTIONALE JS-basierte Logik.
Wenn es die Anforderungen zulassen, dann darf JS nie für nicht-optionale Logik her halten.