WBCE CMS Forum

WBCE CMS – Way Better Content Editing.

You are not logged in.

#1 Archiv - Hilfe & Support Core & Backend » Barrierefreiheit » 20.11.2016 20:46:28

grindmobil
Replies: 29

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.

#2 Re: Archiv - Hilfe & Support Core & Backend » Barrierefreiheit » 21.11.2016 11:46:35

grindbatzn

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.

#3 Re: Archiv - Fragen zu Templates » [Erledigt] ShowMenu2 - Hilfe erbeten » 06.06.2017 13:15:55

florian

Ich glaube, die linke Navigation im Template Aeromsting entspricht Deinen Vorstellungen, versuch mal, die als Vorbild zu nehmen:

show_menu2(1, SM2_ROOT+1, SM2_CURR+5, SM2_TRIM,  '<li ><a class="[class] lev[level]" href="[url]" class="[class] men">[menu_title]</a>', '</li>', '<ul>', '</ul>');

#4 Re: Neue Module / Add-Ons » Kundenregistrierung / Manual user activiation tool » 13.07.2018 11:54:45

dedra

Hatte probeweise anderes Template aktiviert und die Seite lief ohne murren (also Eingaben mit Umlauten) auch unter Firefox .
Verwendetes Template mit den Problemen ist aeromsting - woran es "hängt" weiß ich nicht, warte auf colinax - er möchte sich das näher ansehen.

#5 Hilfe & Support Core & Backend » .htaccess einbinden » 27.10.2021 14:39:06

flugelche
Replies: 2

Habe die Seite Serverseitig auf https umgestellt.
Als nächstes habe ich eine .htaccess erstellt mit dem Inhalt
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.medfusspflege-pankow.de$
RewriteRule ^(.*)$ https://www.medfusspflege-pankow.de/$1 [R=301,L]
Diese leigt im Hauptverzeichnis

egal was eingegeben wird soll sie auf https://www.medfusspflege-pankow.de umgeleitet werden

Es funktioniert gut, habe aber das Problem, wenn ich mich einlogge sagt er Passwort falsch.
lösche ich die .htaccess, geht der login wieder mit dem Passwort.
Habe noch eine andere Seite aber mit anderer Template Aeromsting
https://www.nagelstudio-wilhelmsruh.de/

Dort geht es mit dem Login nach der Umleitung

Beide aktuell auf 1.5.1.

habt ihr eine idee woran es liegen kann?

Board footer

up