WBCE CMS Forum

grindmobil

Gast

Barrierefreiheit

Seit 2016 gilt in Österreich das „Behindertengleichstellungsgesetz“ - und das gilt auch für gewerbliche Websites, noch mehr für alles was irgendwie „staatlich“ ist; Schulen, Ämter, geförderte Einrichtungen.
Größeren Abstrafungen wurde vom Gesetz ein Riegel vorgeschoben, deswegen wird es (noch) nicht so heiß gegessen wie gekocht, aber: bei neuen Websites wird Barrierefreiheit verlangt.
Wie ist das eigentlich in Deutschland? - Wohl ähnlich.

Barrierefreiheit ist ein sehr komplexes Thema, über das sich auch super streiten lässt. Und – das will natürlich keiner hören: Meistens ist es Sache des Kunden: Verständliche Menütitel, einfache Sprache, sinnvolle Bilder (ordentlich beschriftet), …. dazu dies verboten, das nicht erlaubt.

Die technische Seite:
Da steht WBCE nicht sonderlich gut da, aber auch nicht gerade schlimm. Durchschnittlich eben.

Ich verwende den WAVE Test, der ist ziemlich nervig, weil er auch Javascript interpretiert, und insgesamt recht pingelig ist:
http://wave.webaim.org/report#/wbce.org

Gibt es andere automatische Checks, die von „Barrierefreiheits-Freaks“ verwendet werden? Also solche, durch die man „durch“ muss, wenn man halbwegs auf der sicheren Seite sein will?

Ich habe vor:
Ich möchte die Top30 Templates – soweit möglich – auf barrierefrei bringen, zumindest formal (das grenzt manchmal an einen VW-Abgastest ;-)
bei webezeeeh hab ich gar nix tun müssen, das ist recht ordentlich gemacht (den z-index – bug hab ich im Download behoben).
Allerdings funktioniert es nicht, wenn Javascript deaktiviert ist oder durch Fehler gestört. Is das heute noch ein Kriterium?

Dann noch aeromsting und  fyorxlight
http://wbce.at/tpls/template-fyorxlight.html
http://wbce.at/tpls/template-aeromsting.html

Diese 2 funktionieren auch ohne JS – wenn auch nicht schön…

Vielleicht schaut noch wer rein, ob ich bei diesen was übersehen habe. Ich habe bei allen Templates die gleichen Fehler gemacht, das Abarbeiten der Fehler-Liste geht relativ schnell, wenn sie denn vollständig ist.

Bei Topics werden die vielen redundanten Links und Alt-Attribute angemeckert. Das kann zwar an sich jeder selbst beheben, aber es sollte natürlich Out of the Box laufen. Zumindest mit einem Preset.

Die rFG barrierebrei machen ist so, wie ein Taxi mit schwarzen Scheiben für blinde Fahrer zu machen. Immerhin: Die Bedienung mit Tastatur funktioniert in der Standard-Gallery super.

Itemz ist das, was man draus macht, ich werde bei den Presets man nachsehen.

GlobalComments ist aus dem Schneider, weil für Bots NUR die bisherigen Kommentare sichtbar sind, nicht die Kommentarbox selbst. Auch der WAVE-Test sieht sie nicht.

Andere Module:
WYSIWYG: Verhindert Barrierefreiheit nicht, kommt aber eben drauf an, was man damit macht.

Jo - Meinungen, Vorschläge?

MIr wäre recht gedient, wenn mal jemand die og 2 Templates ansieht, damit ich die Vorschläge gleich berücksichtigen kann.

Beitrag geändert von grindmobil (20.11.2016 19:51:53)

evaki

Gast

Re: Barrierefreiheit

Hatt diesbezgl. Angebote gemacht und Tips gegeben. ??????????
Ich gucke mir die beiden mal an.
Der bestandene Wave-Test ist quasi die Voraussetzung für alles folgende. Einfach: Setzt man ein xhtml-(strict)-Template zusammen und besteht diese Prüfung, kann man sich auf die Barrierefreiheit der Inhalte konzentrieren. Da werden meist die schwereren Fehler eingebaut.
So, nun hole ich mal den Arbeitsrechner.
MfG. Evaki

Die Ergebnisse packe ich hier als Anlage (grindmobil_01.zip) rein.
Bei html gibts nur 'nen Hinweis (html_01.txt)

Ach ja, erhebe keinen Anspruch auf Vollständigkeit, ein paar Sachen finde ich auf dem Rechner nicht mehr (-weiß aber: Die waren da!).

Beitrag geändert von evaki (20.11.2016 21:10:24)

florian

Administrator

Re: Barrierefreiheit

Es gab schon mal den Versuch, das hier im Forum zu diskutieren.
Das war dann aber aus dem Ruder gelaufen. Vielleicht klappt es diesmal besser, wenn wir wirklich beim Thema bleiben. Wen das Thema nervt oder nicht betrifft, braucht sich nicht zu beteiligen. (Keine Spitze, sondern einfach nur ein Hinweis).
Das, was ich hier geschrieben hatte, ist mMn weiterhin gültig. Oder, etwas allgemeiner ausgedrückt: So lange wir noch nicht vom Code von gefühlt 1995 mit ineinander verschachtelten Tabellen im Core oder auch bei den Frontend-Login-/Frontend-Profilformularen usw. losgekommen sind, ist es noch ein langer Weg zur Barrierefreiheit im Backend.
Fürs Frontend gibt es sicherlich noch weitere barrierearme/barrierefreie Templates, ich denke mal, je geringer die Komplexität, desto höher die Chance, dass sie bereits barrierefrei sind bzw. mit geringem Aufwand dazu werden können. Ich denke da z.B. an das Template Simple Responsive oder auch Bluespace/Darkspace.

Beitrag geändert von florian (20.11.2016 20:52:37)

evaki

Gast

Re: Barrierefreiheit

>>Es gab schon mal den Versuch, das hier im Forum zu diskutieren.
Naja, da gings ums BE, und auch erst NACH v1.2!

Im FE hängt vieles nur am "sauberen" bzw vollständigen html.
Auch die fast vergessenen semantischen Regeln zählen dazu.

Wer aus dem Gestaltungsbereich kommt, denkt und handelt einfach anders. Der kreative Prozess gestaltet sich völlig anders, da können Normen kreatives Denken auch behindern. Deshalb freier Lauf, aber danach technisch überprüfen, es gibt nur ganz wenige Fälle, wo das zusammen nur schwierig zu vereinbaren ist.
MfG. Evaki

Beitrag geändert von evaki (20.11.2016 21:05:11)

evaki

Gast

Re: Barrierefreiheit

Die Reports nochmal als Anhang (grindmobil_02.zip), diesmal als *.mht
Als *.html war das wohl nix 
MfG. Evaki

Beitrag geändert von evaki (20.11.2016 22:12:08)

grindbatzn

Gast

Re: Barrierefreiheit

Man sollte sich die Latte nicht gleich unerreichbar hoch legen, es geht auch um Verhältnismäßigkeit.

Es geht um: Was kann man - konkret!! - machen.

Wir haben das  Jahr 2016 - und HTML 5.
NIemand wird verlangen, dass man eine zeitgemäße Seite durch einen 10 Jahre alten Standard bringen muss, der xhtml strict als das Modernste ansieht.
Da muss man vernünftig bleiben.

Tabellen: Es gilt: Wenn eine Tabelle keine <th> und sonstige - für Behinderte - nützlichen Attribute hat, gilt sie als Layouttabelle und muss lediglich linearisierbar sein. Nirgends wird gesagt, dass Layouttabellen verboten sind. Sie sind nicht empfohlen (aus anderen Gründen), aber auch nicht verboten. Screenreader oder dgl stören sich nicht daran.

Abgesehen davon geht es zunächst ohnehin nur ums Frontend. Das was - behinderte - Besucher sehen.

Ich habe auch keinen EInfluss darauf, was Nutzer da so aufführen, aber ich habe EInfluss darauf, ob bei ordentlicher Nutzung auch (halbwegs) barrierefreie Seiten rauskommen können.

Mein Bruder arbeitet schon länger bei einem großen Invalidenverband als "Beauftragter für Barrierefreiheit". Mit ihm rede ich natürlich oft über dieses Thema. Auch er sagt, dass das eine sehr komplexe Sache ist, und dass es in Wahrheit gar keine Barrierefreiheit "für alle" geben kann; die Bedürfnisse widersprechen sich auch zum Teil. Man muss die Gruppe definieren, und für diese optimieren.
Im wesentlichen gilt: Man soll sich bemühen.

Zu Evakis Testergebnissen (Danke!)
Im wesentlichen wird beanstandet:

Javascript wird genutzt (ohne noscript)
Ich denke: Javascript sollte nicht unbedingt nötig sein für das Funktionieren einer Seite, schon deswegen, weil es einfach mal ausfallen kann. (Modul-Konflikte oder dgl)
Einen noscript tag halte ich nicht für nötig, weil der keinen zusätzlichen Nutzen bietet. Und dort wo man ihn braucht, ist er nach xhtml nicht erlaubt (in html 5 schon, da darf er im Body sein)

Leere Alt-Attribute, fehlende Longdesc
Hier gilt das gleiche wie bei Tabellen: Wenn es keine speziellen Maßnahmen zur Barrierefreiheit gibt, gilt ein Bild als dekoratives Element.
Ich würde also genau das Falsche tun, wenn ich bei einem Sliderbild ein alt oder gar longdesc angebe. Das alt muss vorhanden sein, aber es soll leer sein.

Die Sache mit dem Label
Man kann machen: <label for="hierdieID">Dings</label><input id="hierdieID".....>
oder (in HTML 5): <label>Dings<input (ohne id).....></label>
Der Grund, warum ich im Suchfeld die 2. Variante nehme: Beim Laden der Seite oder beim Aufruf des Handy-Menüs wird uU per JS das Menü und das Suchfeld dupliziert, fürs Handy-Menü.
Ich kann dann keine ids verwenden, weil ja auch diese dupliziert werden, was nicht erlaubt ist und Fehler verursachen kann.
(Sehe gerade, dass ich bei aeromsting das Suchfeld vergessen habe)

Kontraste:
Ja, man sollte auf ein Minimum achten. Aber hier spucken die Tools oft Fehler aus, wo keine sind.

Inhalte/Struktur:
Ja wenn evaki keine <h1> angibt, wird es wohl keine geben ;-)
Im Template selbst soll man headings vermeiden, weil man dadurch ein Bemühen des Autors untergräbt.

Hab ich was übersehen?

Nachtrag/Notiz:
Hmm - den noscript-Tag könnte man nutzen, um die Header-Bilder auszublenden.
Und in den Inputs (Suche) einen Placeholder angeben und stattdessen das JS da drin entfernen.

Beitrag geändert von grindbatzn (21.11.2016 11:08:53)

evaki

Gast

Re: Barrierefreiheit

Tja, mit den Tools ist das wie mit Testsuiten, Editoren, IDE usw. Auch da gibts gute, schlechte und schlicht unzulängliche. Bei einigen Arbeitsschritten ist es u.U. sogar sinnvoll "zu Fuß" zu arbeiten. Alles in allem also eigentlich nichts neues oder besonderes.
>>10 Jahre alten Standard bringen muss, der xhtml strict als das Modernste ansieht.
Abgesehen davon, daß xhtml auch als xhtml5-Variante existiert und bei der Vielfalt an Geräten auf Server-, wie auch Benutzerseite Sicherheit und Stabilität bietet, gibt es den allgemeinen Hinweis von Designern barrierearmer Webseiten, die Seiten (bzw. Template) zuerst in xhtml fertigzustellen und dann schlicht danach die Doctype zu ändern. Die letzten möglichen Kollisionen kann man dann immer noch beseitigen.

Ob nun h1, inline-Formatierungen oder sonstwat, semantische Regeln gibts bei jedem html.
(Persönlich habe ich den Eindruck, daß die bei html5 noch weniger als früher -beim Kaiser und so...- beachtet werden.)

Bei Kontrasten gibts schon mal "unsinnige" Ergebnise, weshalb auch hier separate Tools sinnvoll sind.

Zusammengenommen -mit Verlaub- gibt es nicht wirklich neues, aber es gibt möglicherweise ein Mißverständnis: Ich selbst empfinde die technisch notwenigen Prüfungen und Arbeiten überwiegend als nervtötend bis zum Platzen des Kragens; so wie "Wer kocht spült vielleicht nicht gern"; manche Sachen muß man halt wie das Pulen von Krabben oder Erbsenschoten angehen.

MfG. Evaki

Edit: Einfach mal 'nen Textbrowser installieren,  vielleicht mal mit und ohne Screenreader (Audio), dann kommt man der Angelegenheit schon etwas näher.

Edit 2: Wenn man Google mal mit 'css' und 'braille' füttert, kommt man auch zu http://www.w3.org/WAI/PF/braillecss.html Vielleicht hilft das ein wenig beim Verstehen.

Beitrag geändert von evaki (21.11.2016 12:16:53)

grindbatzn

Gast

Re: Barrierefreiheit

Ich denke: Soweit muss es im Moment nicht treiben.

Ich werde mal ein paar Templates so herrichten, dass sie bei den automatisierten Tests (WAVE usw) ohne (tolerierbare) Fehler durchkommen.
Vielleicht kann man ja auch mal eines machen, das so richtig hardcore-barrierefrei ist. Dem man es auf den ersten Blick schon ansieht, so hässlich ;-)
Vielleicht auch mal eine Anleitung: "So machst du dein Template barrierefrei". Es sind ja eh immer die gleichen Sachen, die angemeckert werden.

An sich mag ich den Begriff "barrierefrei" auch nicht, es sollte "barrierearm" heißen. Aber letzteren Begriff will keiner. Klingt so "arm", da ist "frei" schon viel besser. ;-)

evaki

Gast

Re: Barrierefreiheit

>>Dem man es auf den ersten Blick schon ansieht, so hässlich ;-)
Ansatz: schwarz/weiß, ohne js/css, gucken und prüfen, danach wie z.B. bei "ZenGarden" hübsch machen. Dann is nix mit häßlich 
MfG. Evaki

Beitrag geändert von evaki (21.11.2016 15:23:23)

grindbatzn

Gast

Re: Barrierefreiheit

Naja - das fängt schon früher an:

Eine Forderung ist: Aussagekräftige Menütitel. Damit fällt ein horizontales Menü aus, weil man da keine langen Titel reinbringt.
Nächste Forderung: Kein Dropdown-Menü, wenn möglich ein klassisches Aufklappmenü: Untermenüpunkte erst nach Klick auf den übergeordneten. So wie früher eben.
Sowas eben: http://wbce.at/tpls/template-lypsresp.html
Aber mit Suchfunktion.

evaki

Gast

Re: Barrierefreiheit

>>Damit fällt ein horizontales Menü aus, weil man da keine langen Titel reinbringt.
Andersrum kann 'ne Liste auch ganz schön lang werden (z.B. mobil)
Für all das existieren aber Lösungen, sogar responsiv.

Soweit ich das erinnere, wir hatten vor Jahren mal sowas wie 'ne Arbeitsgruppe zum Thema, haben wir darauf geschaut, wie das 'ne Suchmaschine sieht, dann kam der Textbrowser dran, für den zu allererst die Accesskeys definiert wurden. Mit zusätzlichen Shortcuts können die "Könner" auch sauschnell navigieren.

Was im Design nicht gebraucht wird, macht man halt unsichtbar bzw. versteckt es. Soweit meine Erinnerung.

MfG. Evaki

Edit: Wer sich bis zum "AccessKey-Pad" durchgewühlt hat, ist damit beim bekannten WB-Aktivisten Ralf Hertsch (†29.09.2014) gelandet.

Edit 2: Es gilt (WCAG 2.0) für alle erreichbaren Inhalte „Sorgen Sie dafür, dass alle Funktionalitäten per Tastatur zugänglich sind.“

Beitrag geändert von evaki (21.11.2016 18:36:54)

grindbatzn

Gast

Re: Barrierefreiheit

>>Damit fällt ein horizontales Menü aus, weil man da keine langen Titel reinbringt.
Andersrum kann 'ne Liste auch ganz schön lang werden (z.B. mobil)
Für all das existieren aber Lösungen, sogar responsiv.

Ja klar gibt es Lösungen zu allerhand. Du wirst mir aber keine sagen können, wo du 10 x was wie "Informationen über unsere Produkte" in der ersten Reihe horizontal unterbringst
Stabil geht das nur mit vertikalem Menu, auch mehrzeilige Menüpunkte.

Dass man am Handy kein horizontales Menü hat, ist ja eh klar, wo soll denn das hinpassen. Das hat aber mit barrierefrei nix zu tun.

Beitrag geändert von grindbatzn (21.11.2016 19:08:32)

evaki

Gast

Re: Barrierefreiheit

>>10 x was wie "Informationen über unsere Produkte" in der ersten Reihe
Ha, hast mich erwischt, bis zu welcher maximalen Breite das mit Braille geht, weiß ich übrigens garnicht. Tolle Wurst.

Aaaaber, das "Problem" gibts ja auch auf'm Desktop, weshalb man ja in WBce bei der Anzeige zwischen (kurzen) Menutiteln und abweichenden Dateinamen wählen kann. Also machts erstmal keinen Unterschied. Im Textbrowser sehe ich die Menus überwiegend als Liste, horizontal übrigens sehr oft mit dem Fehler, daß Leerzeichen beim Menu fehlen bzw keine Abstände zwischen den Links existieren, was die Lesbarkeit einschränkt. Es sind meist nur Kleinigkeiten, die eingeschränkten Benutzern oft große Probleme bereiten.

MfG. Evaki

Edit: >>Nächste Forderung: Kein Dropdown-Menü, wenn möglich ein klassisches Aufklappmenü:
Das sollte nicht stören, da es nur eines von mehreren Menus ist und dieses halt für den barrierefreien Zugang geeignet ist. Die anderen, wenn welche erforderlich, werden eben erst durch css /js und Konsorten sichtbar/unterdrückt/positioniert und gestaltet. Es geht eigentlich nur um die grundsätzliche Anforderungen an Struktur und Gliederung des Inhalts eines html-Dokuments. Alles andere ist Gestaltung und Bereitstellung von Funktionen.

Beitrag geändert von evaki (21.11.2016 21:16:46)

grindmobil

Gast

Re: Barrierefreiheit

Mehrere Menüs erzeugen redundante Links -> nicht so gut. Es sollte nur 1 Hauptmenü geben.

Jepp, war in Schreiblaune, eher allgemein:
http://wbce.at/de/topics/barrierefrei-wbce.php

evaki

Gast

Re: Barrierefreiheit

Ja, das war jetzt nicht so ne dolle Leistung von mir.
Gemeint war ein Menu, das per js/css gestaltet wird, in Abhängigkeit vom jeweiligen Gerät.
Boah, hoffe daß es jetzt richtig beschrieben ist. -ist wohl nicht mehr mein Abend 
MfG. Evaki

Beitrag geändert von evaki (21.11.2016 21:56:51)

evaki

Gast

Re: Barrierefreiheit

Das Produkt Deiner Schreiblaune habe ich aber doch noch gelesen.
Alte Geräte (Braillezeilen, Brailleprinter), die Standard sind und keinen oder nur geringen Besserungsbedarf über die Zeit auslösen, können mit alten Standards leben. Wie soll in einer Modernität, die meist nur die Neuheit/Aktualität meint, der Nutzen aussehen?
MfG. Evaki

Edit: Und neeee, Braillegeräte sind nüch umständlich und mühsam. Für uns schon, aber die Nutzer sind schneller als wir uns das normalerweise vorstellen können. Man muß es nur einmal gesehen haben. Das einzige was die aufhält sind besch... Webseiten.

So, nun is Feierabend, ich habe fertig. Nix geht mehr....

Beitrag geändert von evaki (21.11.2016 22:20:00)

grindmobil

Gast

Re: Barrierefreiheit

Was ich weiss, werden diese Geräte nur mehr fuer schulungszwecke eingesetzt. Privat nutzt niemand eine Braille Zeile. Zu teuer. Als blinder schwimmt man ja nicht so im Geld.

evaki

Gast

Re: Barrierefreiheit

Hier gibts die Dinger von den Krankenkassen -bezuschußt/voll-(*1), vergleichbar mit Zahnersatz, soweit mir bekannt. Sehr verkürzt:" Hast Du keinen öffentlichen Verkehr, brauchst Du auch keine Zähne."

Sinnvoll könnte also sein, einen preiswerten Ersatz für die teuren Dinger zu schaffen (Crowdfunding). Die "spezialisierten Firmen" dürften sich mittlerweile gesundgestoßen haben.
MfG. Evaki

*1) "Für die Leistungspflicht der gesetzlichen Krankenkassen kommt es darauf an, ob sie für die Befriedigung eines Grundbedürfnisses erforderlich sind."

Beitrag geändert von evaki (22.11.2016 10:29:21)

grindbatzn

Gast

Re: Barrierefreiheit

Wie gesagt: Es gibt sehr viele verschiedene Arten von Einschränkungen.
Motorische Störungen, kognitive Beeinträchtigungen (wohl mit Abstand die größte Gruppe), Epileptiker, sogar Nutzer von IE5/6 gibt es noch.
Da jetzt noch zwischen Blinden mit Braille-Zeile und solchen mit Software-Screenreader zu unterscheiden ist kontraproduktiv.

Mit theoretischem Geplauder kommen wir nicht weiter, es braucht praktische Lösungen.

evaki

Gast

Re: Barrierefreiheit

WAI un jut is -nämlich drin.
MfG. Evaki

grindbatzn

Gast

Re: Barrierefreiheit

WAI un jut is -nämlich drin.
MfG. Evaki

Sagt der Theoretiker.

Für praktische Ergebnisse braucht man aber praktische Lösungen. Wenn du dazu nichts zu sagen hast, solltest du vielleicht weniger Senf dazu beisteuern. Momentan geht der Teller schon mit Senf über, aber die Wurst fehlt immer noch ;-)

evaki

Gast

Re: Barrierefreiheit

Ich bin mit diesem Thema jedenfalls ab sofort hier durch.
Immerhin funktioniert das bei unseren Anwendern seit Jahren unter xhtml. Das ist Praxis. Da red' ich mir doch hier nicht einen Wolf. Viel Spaß noch mit dem Aufzählen von dem was alles nicht geht.
MfG. Evaki

florian

Administrator

Re: Barrierefreiheit

:-/

Um mal ein Meme zu bemühen:

grindbatzn

Gast

Re: Barrierefreiheit

Ne, das braucht nicht eskalieren.
Aber was man nicht braucht, ist jemand, der eigentlich nur von irgendwas redet, was angeblich vielleicht sogar.
Back to xhtml ist keine Option mehr. Wir haben html 5. Das ändern wir nicht.
Wenn man konkret was machen will, muss man konkret was sagen, und nicht herumschwurbeln. Das hält nur auf.

Zunächsts gehts ja mal um die Templates und eine Handvoll Module.

Die Sache mit den role-dingsern muss ich mir mal näher ansehen, das ist - in diesem eingegrenzten Bereich - nicht so ein theater, da braucht man nur 5 oder 6, und dann ist da schon mal viel erreicht.

Hat jemand Erfahrung mi WAI-ARIA ?
Dos and Dont's?

Beitrag geändert von grindbatzn (22.11.2016 15:40:03)

grindbatzn

Gast

Re: Barrierefreiheit

Was hamma denn so:

Access  Keys: Da kann man eigentlich nicht viel vorgeben, weil man ja nicht weiß, wie eine Site gestrickt wird. Ist also User-Sache.
Interessant dazu:  http://www.barrierefreies-webdesign.de/ … y/pad.html
Andere Meinungen?

ARIA Landmarks
Da gibt es hier eine gute Übersicht - und mehr als die paar braucht man in einem Template auch nicht:
https://accessibility.oit.ncsu.edu/deve … landmarks/

DIe neuen html 5 tags (<section> usw..) können, aber müssen nicht sein. Die werden sowieso zu oft falsch verwendet, also verlässt sich da niemand drauf.

Beitrag geändert von grindbatzn (22.11.2016 16:00:22)