Navi: Desktop + Mobil + barrierefrei bzw. -arm

faglork · 22. Juli 2015 11:21

Moinsen!

Bitte mal eure Meinung ...

Ich habe für eine Kommune eine Navi benötigt, die sowohl mobiltauglich als auch weitgehend barrierefrei ist.

Das Problem: Eine Mobil-Navi setzt voraus, dass der gesamte Baum zur Verfügung steht - bei umfangreichen Seiten wäre es extrem nervend, immer nur ebenenweise navigieren zu können.

Das aber hat zur Folge, dass

- die Bedienbarkeit mit der Tastatur fast unmöglich wird (250 Seiten mit TAB durchsteppen sind auch kein Vergnügen)

- ein Screenreader erstmal ne Stunde lang Links vorliest bis er mal zum Inhalt kommt.

Ich habe folgende Lösung gefunden die ich gerne mit euch diskutieren möchte:
http://tinyurl.com/ozbdrzz

Key features:

- Komplette Dropdown-Flyout Navi für Desktop und Tablets am Seitenanfang. Dabei wird die OBERSTE EBENE mit Tabindex und Accesskey versehen, alle anderen bekommen einen negativen Tabindex, keinen Accesskey sowie ein aria-hidden=true (wird alles im navi-template gemacht, accesskeys und tabindexe kommen vom Seiteneditor.). Dadurch ist für Tastaturnavigation und Screenreader nur die oberste Ebene erreichbar. Accesskeys sind auf einer Hilfeseite aufgelistet.

- ab dem 5. Menüeintrag klappen die Untermenüs nach links aus, um zu verhindern dass einzelne Menüs offscreen sind

- Bei Unterschreiten einer gewissen Bildschirmbreite wandelt sich die Desktop-Navi in eine Mobil-Navi. Sowohl Desktopversion als auch mobilversion sind mit touch bedienbar

- ergänzende Binnennavi auf der rechten Seite, für Desktops und Tablets (wird beim umschalten in den Mobilmodus ausgeblendet, für smartphones gar nicht erst ausgeliefert). Kann ganz normal mit TAB durchsteppt werden, keine Accesskeys. Zudem erleichtert diese zusätzliche Navi die Bedienung der Ebenen ungemein, weil man ja alles im Blick hat. Die Flyout-Navi oben ermöglicht das schnelle Wechseln in entfernte Bereiche.

- Zusätzliche Accesskeys für
- HauptNavigation : n
- Unternavigation : u
- Inhalt : i
- Suche: s

Acceskeys sind auf Hilfeseite erläutert.

Die Links erhalten ein a:focus um bei Keyboard-Navigation den grade aktiven Focus optisch anzuzeigen

Die Lösung ist sicher nicht perfekt, aber m.E. brauchbar ... wie gesagt, es geht um eher große Websites.

Eure Meinung bitte. Fehler im Ansatz? Irgendwas falsch? Probleme?

Servus,
Alex

Beitrag geändert von faglork (22. Juli 2015 12:16)

faglork · 15. September 2015 19:59

Na, das Interesse an Barrierearmut ist ja gering ... sad

Ich habe das inzwischen noch etwas verbessert, hauptsächlich bei den aria-xxx Sachen.

Ich bräuchte aber wirklich ein bisschen Feedback, denn IMO passt das so, aber auch ich habe nur einen begrenzten Horizont smile

Wenn das alles komplett fertig ist, stelle ich Navi-Template und CSS zur Verfügung.

Servus,
Alex

Andynium · 20. September 2015 18:30

Hab den leisen Verdacht, dass uns tendenziell die Experten dafür ausgehen roll ...

Klenkes · 21. September 2015 09:55

Ich hatte früher viele Seiten gemacht die auch für Blinde funktionierten, weil ich damals Beziehungen zu einer Blindenschule hatte. Wenn ich dort Eines gelernt habe, dann, dass nichts so ist, wie man glaubt.
Ich schaute den Leuten beim Browsen zu, und stand wie ein Idiot staunend mit offenem Mund da. Danach baute ich nie wieder versteckte Sprunglinks zur Navigation ein.

Blinde drehen die Vorlesegeschwindigkeit dermaßen hoch, dass "ich" nur noch ein Zwitschern des Screenreaders hörte, sie aber alles verstanden. Niemand benutzte meine Sprunglinks!
Auf meine Frage warum, kam die Antwort, dass sie ständig das Gefühl hätten, damit was Wichtiges übersprungen zu haben. Also speeden sie lieber über alles drüber.

Für die Anfänger unter den Sreenreadernutzer sind die Links aber sichr nützlich.

Wichtiger als eine zugängliche Navigation war den Leuten, dass Texte eine erkennbare Zusammenfassung haben, und aussagekäftige Überschriften, die als solche erkennbar sind. Damals waren Tabellenlayouts noch üblich. Das war für Screenreader natürlich furchtbar.

Anmerkung zum Menü:
Bei einer Auflösung von 1024px, also z.B. Netbook oder iPad, klappt die Vierte Ebene nach links auf dem Viewport raus. Siehe Tourismus und Freizeit -> Freizeitmöglichkeiten -> Fahrradparadies...

Die Checkboxen sind für Screenreader eher hinderlich, da sie mit vorgelesen werden.

Eine Tab-Navigation ist für motorisch eingeschränkte Menschen wichtig, und funktioniert hier auch gut, bis auf die Untermenüs rechts. Die erreiche ich praktisch nicht.
Hilfetexte zur Bedienung werden meist nicht gelesen.(Nach meiner Erfahrung)

Ansonsten finde ich, dass es gut funktioniert.

Andynium · 21. September 2015 10:50

Klenkes schrieb:

Blinde drehen die Vorlesegeschwindigkeit dermaßen hoch, dass "ich" nur noch ein Zwitschern des Screenreaders hörte, sie aber alles verstanden.

Das erinnert mich doch schon sehr stark an meine Funker-Ausbildung während meiner Armeezeit vor 26 Jahren big_smile .

Wurden damals so gedrillt, so dass man aus einem (anfänglichen) Gepiepse sehr schnell ein "Daah-Dit-Daah-Daah" heraushören konnte (musste!).

faglork · 21. September 2015 11:32

Danke dass Du Dir die Zeit genommen hast!

Klenkes schrieb:

Ich hatte früher viele Seiten gemacht die auch für Blinde funktionierten, weil ich damals Beziehungen zu einer Blindenschule hatte. Wenn ich dort Eines gelernt habe, dann, dass nichts so ist, wie man glaubt.
Ich schaute den Leuten beim Browsen zu, und stand wie ein Idiot staunend mit offenem Mund da. Danach baute ich nie wieder versteckte Sprunglinks zur Navigation ein.
Blinde drehen die Vorlesegeschwindigkeit dermaßen hoch, dass "ich" nur noch ein Zwitschern des Screenreaders hörte, sie aber alles verstanden. Niemand benutzte meine Sprunglinks!
Auf meine Frage warum, kam die Antwort, dass sie ständig das Gefühl hätten, damit was Wichtiges übersprungen zu haben. Also speeden sie lieber über alles drüber.
Für die Anfänger unter den Sreenreadernutzer sind die Links aber sichr nützlich.

Naja, dann lieber drinlassen.

Klenkes schrieb:

Wichtiger als eine zugängliche Navigation war den Leuten, dass Texte eine erkennbare Zusammenfassung haben, und aussagekäftige Überschriften, die als solche erkennbar sind.

DAS liegt halt ausserhalb meines Einflussbereichs. Ich kann da auch nur ne Schulung anbieten, aber das wird selten nachgefragt. Das Verständnis für Texte (sinnvolle Semantik etc.) ist leider sehr gering ausgeprägt.

Klenkes schrieb:

Anmerkung zum Menü:
Bei einer Auflösung von 1024px, also z.B. Netbook oder iPad, klappt die Vierte Ebene nach links auf dem Viewport raus. Siehe Tourismus und Freizeit -> Freizeitmöglichkeiten -> Fahrradparadies...

Zum einen lässt sich das über einen Parameter steuern (derzeit fix codiert, könnte aber auch evtl. übergeben werden.). Zum anderen muss man da halt auch sehen, wie man seine Baumstrukturen aufbaut. Prinzipiell ist das natütlich ein Problem bei sehr großen Ausklappmenüs. Aber bei *sehr* großen Menüs gibts noch ganz andere Probleme, da würde ich auch eher zu Sub-Sites raten.

Klenkes schrieb:

Die Checkboxen sind für Screenreader eher hinderlich, da sie mit vorgelesen werden.

Aaah ... da muss noch ein aria-hidden=true rein

Klenkes schrieb:

Eine Tab-Navigation ist für motorisch eingeschränkte Menschen wichtig, und funktioniert hier auch gut, bis auf die Untermenüs rechts. Die erreiche ich praktisch nicht.

Hmm. Warum? Auch nicht über den Shortcut?

Klenkes schrieb:

Hilfetexte zur Bedienung werden meist nicht gelesen.(Nach meiner Erfahrung)

Hast du einen alternativen Vorschlag?

Klenkes schrieb:

Ansonsten finde ich, dass es gut funktioniert.

Danke!

An dieser Stelle muss ich noch etwas nachtragen was ich im Eingangspost vergessen hatte. Das Klappmenü basiert auf
http://www.cssplay.co.uk/menus/cssplay- … three.html

Es ist Donationware, in diesem Fall IMO mehr als gerechtfertigt.

Das Problem mit den meisten Ausklappmenüs auf REINER CSS BASIS ist ja, dass sie entweder für große Sites unbrauchbar sind oder sich nicht mit der Logik der cmsms-Menütemplates abbilden lassen. Dieses hier funzt. Es war dennoch nicht ganz einfach, aber es funkioniert gut.

Wichtig war mir vor allem, dass die Navi per Screenreader / Tastatur bedienbar sein soll. Die üblichen Ausklapp-Navis sorgen ja meist dafür, dass erstmal 200 Seiten-links vorgelesen werden bzw. duchtastet werden müssen.

Servus,
Alex

Andynium · 21. September 2015 11:52

faglork schrieb:

Klenkes schrieb:
Wichtiger als eine zugängliche Navigation war den Leuten, dass Texte eine erkennbare Zusammenfassung haben, und aussagekäftige Überschriften, die als solche erkennbar sind.
DAS liegt halt ausserhalb meines Einflussbereichs. Ich kann da auch nur ne Schulung anbieten, aber das wird selten nachgefragt. Das Verständnis für Texte (sinnvolle Semantik etc.) ist leider sehr gering ausgeprägt.

Naja, an dieser Stelle könnte man es dergestalt forcieren, dass die Zusammenfassung der Standard-Content-Block ist (der ja immer gefüllt werden muss) und der "normale" Text in einer zusätzlichen Box eingegeben wird roll ...

Klenkes · 21. September 2015 12:51

faglork schrieb:

DAS liegt halt ausserhalb meines Einflussbereichs. Ich kann da auch nur ne Schulung anbieten, aber das wird selten nachgefragt. Das Verständnis für Texte (sinnvolle Semantik etc.) ist leider sehr gering ausgeprägt.

Ich glaube dies kennen wir alle nur zu gut sad

Solch ein Menge an Menüpunkten übersichtlich darzustellen, ist natürlich sehr schwer, und Aufklappmenüs sind für Desktop prima, aber für Tastatursteuerung nur schwer umzusetzen.

Wenn ich meine Erfahrungen mit der Blindenschule zusammenfassen müsste, würde ich es so machen:

1. Semantik, Semantik und Semantik.
HTML Elemente richtig verwenden. User machen ja gerne Absätze fett und groß, und glauben dann, es wäre eine Überschrift. Das bringt Screenreader-User extrem durcheinander, genauso wie eine falsche Dokumentenstruktur. Gemeint sind Sprünge zwischen den Headings.
Blinde erstellen sich im Kopf eine Art Landkarte des Inhalts.

2. Korrekte Alttexte
Speziell für Schmuckbilder ohne echte Aussage sind Alttexte oder longdesc wichtig.

3. Keine Modalwindow für wichtige Sachen.
Vielleicht kommen Screenreader heute damit klar. Früher aber nicht.

4. Aussagekräftige Buttonbeschriftungen
Ein SVG mit einem Icon bringt einem Blinden nichts.
Auch ein einfaches mehr... hat damals schon viele in Zorn versetzt. Besser wäre immer: "Ganzer Artikel zu XXX" oder "Hier gehts zum ganzen Artikel"
Solche Sachen eben.

Ich kann nur jedem empfehlen, das mal selbst auszuprobieren.

faglork · 21. September 2015 16:45

Klenkes schrieb:

2. Korrekte Alttexte
Speziell für Schmuckbilder ohne echte Aussage sind Alttexte oder longdesc wichtig.

Ja wie? Grade bei reinen Schmuckbildern sollte doch KEIN alt rein. Der Erkenntnisgewinn liegt ja schon bei den Sehenden bei NULL.

Und longdesc ... ich kenne niemanden der schon mal ne longdesc eingebaut hat. Der Aufwand ist einfach zu hoch. Wenn es im "Bild einfügen"-Dialog ein Feld gäbe um die longdesc einzugeben, und das würde dann gleich gespeichert und automatisch verlinkt ... dann vielleicht, obwohl ich nicht eine Bildbeschreibung lesen möchte, die ein Verwaltungsmitarbeiter (dem man noch "nebenbei" die Pflege der Homepage aufgedrückt hat) unter Zeitdruck zusammengstöpselt hat.

Das sind alles so Vorstellungen die in der Praxis meist nicht umsetzbar sind. IMO.

Servus,
Alex

Klenkes · 21. September 2015 19:09

Das ist natürlich vollkommen richtig.
Ich war im Kopf wieder zurück versetzt, als ich das alles ohne CMS noch selbst geschreiben hatte. Lang ist's her...

faglork · 22. September 2015 22:05

Klenkes schrieb:

Das ist natürlich vollkommen richtig.
Ich war im Kopf wieder zurück versetzt, als ich das alles ohne CMS noch selbst geschreiben hatte. Lang ist's her...

Ja, die guten alten Zeiten smile

Da war das alles Raketenwissenschaft, und das höchste der Gefühle waren server side includes ... damit hab ich riesige webs gebaut.

Insofern sind die CMSse ein kleiner Rückschritt. Ein "made simple" (nicht dass das bei anderen Systemen besser wäre!) bedeutet halt eben auch "weniger komplexität" und Barrierefreiheit ist halt nu mal ne ganze Ebene komplexer.

Versuch mal ne Tabelle barrierearm aufzubauen ... das geht, selbst mit den Bordmitteln des TinyMCE, aber vermittel das mal ner Sekretärin oder nem Sachbearbeiter. Die werden schlicht und einfach nicht dafür bezahlt. Und solange da kein Umdenken auf "höherer Ebene" da ist, solange können wir uns hier nen Wolf programmieren - es wird wenig nützen.

Ich finde, das ist man mit ner barrierearmen Navi schon ziemlich weit. So traurig es ist.

Aber da gehts ja schon los: Wenn die Reihenfolge oder Anzahl der Menüpunkte in der obersten Navi-Ebene geändert wird, müssen auch die Access-Keys geändert werden. Das weiss in einem halben Jahr kein Schwein mehr. Eigentlich muss ich das so programmieren, dass die Access keys für die erste Ebene automatisch vergeben werden. Also zurück ans Reissbrett ... und Nav-Templates zusammenbasteln ist was ekelhaftes ...

Servus,
Alex

Beitrag geändert von faglork (22. September 2015 23:29)

Janl · 22. September 2015 10:54

Meine Hochachtung!

Es ist schön zu sehen dass es Menschen gibt die sich kümmern um Sehbehinderten.

MfG
Jan

Andynium · 22. September 2015 11:16

Klenkes schrieb:

Auch ein einfaches mehr... hat damals schon viele in Zorn versetzt. Besser wäre immer: "Ganzer Artikel zu XXX" oder "Hier gehts zum ganzen Artikel"

Genau das unterstützt diese Aussage

http://www.cmsmadesimple.de/forum/viewtopic.php?id=4466

faglork schrieb:

Und longdesc ... ich kenne niemanden der schon mal ne longdesc eingebaut hat.

Hat ja auch seinen Grund hmm

http://www.w3schools.com/tags/att_img_longdesc.asp schrieb:

The longdesc attribute is so poorly supported that it should not be used.

Browser-Support = 0

faglork · 22. September 2015 11:49

Janl schrieb:

Es ist schön zu sehen dass es Menschen gibt die sich kümmern um Sehbehinderten.

Nunja, das ist ja nicht nur das soziale Bewusstsein, das hat auch was mit Business zu tun. Die meisten meiner Mitbewerber haben keine blasse Ahnung um was es da eigentlich geht, und das hat auch gewisse Vorteile ... :-)

Wenn man dann auch noch demonstrieren kann wie das alles funktioniert - perfekt.

Das Hauptproblem ist IMO dass es halt schon aufwendig ist. Man könnte jetzt ja sagen: Hey, mach doch einfach keine Dropdown-Menüs. Dann hast du einige Probleme gar nicht.

Aber das stimmt nur bei kleinen Websites. Ein funktionierendes Dropdown-Menü bietet bei großen Seiten echte Vorteile, weil es halt einen besseren Überblick verschafft und es den Benutzern ermöglicht, sehr einfach in ganz andere Bereich zu springen. Ansonsten müsste man sich durchhangeln, was bei umfangreichen Sites recht mühselig ist.

Zudem hat man für die mobile Darstellung/kleine Viewports das komplette Menü ja genau da wo es sein soll. Den Rest erledigen media queries.

Langer Rede kurzer Sinn: Was mir vorschwebt ist so eine kleine Sammlung an Tipps & Tricks speziell für CMSMS. So wie dieses Menü hier - einbauen, konfigurieren, stylen. Fertich.

Was mir derzeit schwer am Herzen liegt sind barierrearme UND mobiltaugliche Tabellen. Das wird noch ne harte Nuss, das muss ja mit dem TinyMCE machbar/bearbeitbar sein.

Und dann stellen sich noch ein paar Fragen:

- Galerien? Responsive, kein Problem, aber barrierearm? Oder lieber gleich daraif hinweisen dass die
- Audio? Responsive, kein Problem, aber barrierearm?
- Videos? Responsive, kein Problem, aber barrierearm?
- GoogleMaps? Responsive, kein Problem, aber barrierearm?

Und: Es wird oft so getan als ob barrierefrei sich nur auf Sehbehinderte bezöge. Es gibt aber auch Leute mit Parkinson, für die die Buttons und Links auch mit zittrigen Händen bedienbar sein sollten. Es gibt kognitiv Behinderte, für die eine einfache Sprache notwendig ist. usw. usf.

Was mir vorschwebt wäre so ne Sammlung an Tipps a la "Wie erzeuge ich mobiltaugliche barrierearme Tabellen?" etc.
Man muss ja nicht jedesmal das Rad neu erfinden.

Servus,
Alex

Andynium · 22. September 2015 12:16

faglork schrieb:

Man muss ja nicht jedesmal das Rad neu erfinden.

Inwieweit ist in diesem Thema da noch eine Dynamik drin?

Oder anders gefragt - bringt es da noch etwas, sich ältere Literatur wie z.Bsp.

http://www.amazon.de/gp/product/3898645 … 3898645207

zuzulegen?

5 Jahre sind fürs Internet ja schon 'ne Ewigkeit ...

Klenkes · 22. September 2015 13:14

faglork schrieb:

Und: Es wird oft so getan als ob barrierefrei sich nur auf Sehbehinderte bezöge. Es gibt aber auch Leute mit Parkinson, für die die Buttons und Links auch mit zittrigen Händen bedienbar sein sollten. Es gibt kognitiv Behinderte, für die eine einfache Sprache notwendig ist. usw. usf.

Richtig! Und noch viel naheliegender ist der Userkreis der, naja, Senioren.
Mein Vater ist 80 Jahre alt, ist zwar nicht zittrig, sieht aber mächtig schlecht. Ich betreue nebenher eine Frau, die ist über 85 und verkauft ihre Stricksachen online. Die hat oft ein reines Verständnisproblem der Websites(Ebaykleinanzeigen) und ist motorisch nicht mehr so zielsicher. Kleine Links trifft sie nicht.

Früher hatte ich einen Firmenkunden, wo ich das Intranet mausfrei machen musste. Klar, mit manuell erstelltem HTML war alles möglich. Wenn ich das heute mit einem CMS machen müsste... kein Plan.

faglork · 22. September 2015 13:21

cyberman schrieb:

5 Jahre sind fürs Internet ja schon 'ne Ewigkeit ...

Der aktuelle Stand der WCAG ist aber auch schon älter, diese Übersetzung ist von 2011:
https://www.einfach-fuer-alle.de/wcag2.0/

Ich denke das Buch ist eher was für Einsteiger, die noch nie was davon gehört haben. Letztlich auch nur ne Beschreibung was die WCAG eigentlich will und wie man es umsetzt.

Mir wären ja (cmsms-)praxis-bezogene Geschichten lieber. Natürlich weiss ich dass zb. zu einem Video ein beschreibender Text evtl. sinnvoll wäre. Wie sieht sowas konkret aus? Wie fügt man das ein? So dass das auch für einen "normalen" Editor machbar (und verwaltbar!) ist?

Meist scheitert es doch daran dass man *prinzipiell* zwar weiss was zu tun ist, aber wenn man das für einen Kunden so umsetzt dass er das bedienen kann dann wirds eventuell teuer. Und das ist eigentlich auch nicht einzusehen, dass die Kunden noch extra bezahlen sollen für die Möglichkeit, barrierearme Seiten zu erstellen. Da geht die Motivation doch gleich gegen null.

Wenn wir so ein paar Bausteine hätten, die einfach nur noch gestylt werden müssten, oder ein paar HOW-TOs dann würde sich IMO da etwas mehr bewegen.

Aber ich kann mich auch täuschen und es interessiert wirklich kein Schwein ...

Servus,
Alex

faglork · 22. September 2015 13:23

Klenkes schrieb:

Klar, mit manuell erstelltem HTML war alles möglich. Wenn ich das heute mit einem CMS machen müsste... kein Plan.

Genau das meine ich.

Servus,
Alex

Janl · 22. September 2015 13:45

Zur Information, ich bettele bei Kunden um zu erlauben das ich mich an WAI Richtlinien halte, so dass es lesbar ist.

Meine Mutter ist 95 und kann immer schlechter sehen, schimpft auf Skype weil sie die Texte nicht lesen kann, der standard Schriftgrösse ist auf 200% eingestellt, was dann alles nicht mehr gut funktioniert ist erschreckend.

Aber auch selber, Webseiten mit dunkelgraue Text auf hellgraue Hintergrund, unlesbar.
Man soll die jenigen die eine Webseite besuchen doch so viel Respekt zeigen das Text wenigstens lesbar ist.

MfG
Jan

faglork · 22. September 2015 14:05

Janl schrieb:

Zur Information, ich bettele bei Kunden um zu erlauben das ich mich an WAI Richtlinien halte, so dass es lesbar ist.
Meine Mutter ist 95 und kann immer schlechter sehen, schimpft auf Skype weil sie die Texte nicht lesen kann, der standard Schriftgrösse ist auf 200% eingestellt, was dann alles nicht mehr gut funktioniert ist erschreckend.
Aber auch selber, Webseiten mit dunkelgraue Text auf hellgraue Hintergrund, unlesbar.
Man soll die jenigen die eine Webseite besuchen doch so viel Respekt zeigen das Text wenigstens lesbar ist.
MfG
Jan

Styleswitcher, anyone?

Auch da gibt es viele Möglichkeiten, ein cmsmadesimple.de-"approved" Vorschlag wäre da eventuell sinnvoll.

Denn wenn man nur
- ein plugin in die template einbauen
- ein css bereitstellen
muss dann ist das sicher attraktiver.

Servus,
Alex

Beitrag geändert von faglork (22. September 2015 14:08)

Andynium · 22. September 2015 14:08

faglork schrieb:

ein cmsmadesimple.de-"approved" Vorschlag wäre da eventuell sinnvoll.

Ähmm, was genau meinst du damit?

Ich kämpf hier gerade mit ('nem) Panther wink ...

faglork · 22. September 2015 14:14

cyberman schrieb:

faglork schrieb:
ein cmsmadesimple.de-"approved" Vorschlag wäre da eventuell sinnvoll.
Ähmm, was genau meinst du damit?

Naja, wir haben hier doch eine Handvoll Leute die solche Lösungen beurteilen können.
Ich stell mir das in etwa so vor:

- einer stellt ne Lösung vor
- wir diskutieren ob das so sinnvoll ist
- ändern das bis es "passt"

Falls die Lösung brauchbar ist, kommt sie in eine "Best Practise"-Liste: runterladen, installieren, stylen, fertig.
Kann aber auch nur eine "einfache" Anleitung sein.

Dann müsste man nicht mehr unbedingt -zig Lösungen durchtesten, sondern könnte sich erstmal auf bewährte Lösungen verlassen. Wenn man dann doch was spezielles braucht, kann man das immer noch ändern. Aber man hat erstmal was funktionierendes.

Servus,
Alex

Beitrag geändert von faglork (22. September 2015 14:15)

Andynium · 22. September 2015 16:16

Ok, klingt grundsätzlich gut.

Ein eigenes "Prüfsiegel" halte ich jedoch gegenwärtig eher für nicht realisierbar wink . Zumindest für meinen Teil hab ich gegenwärtig noch zu viel andere Themen auf der ToDo-Liste.

Cherry · 22. September 2015 19:06

faglork schrieb:

Styleswitcher, anyone?

Da hat Rolf auf seinem Blog mal was zu geschrieben:
http://www1.cmscanbesimple.org/blog/web … e-switcher

Janl schrieb:

Aber auch selber, Webseiten mit dunkelgraue Text auf hellgraue Hintergrund, unlesbar.

Spricht mir aus der Seele ....

Forum für CMS/made simple

#1 22. Juli 2015 11:21

Navi: Desktop + Mobil + barrierefrei bzw. -arm

#2 15. September 2015 19:59

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#3 20. September 2015 18:30

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#4 21. September 2015 09:55

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#5 21. September 2015 10:50

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#6 21. September 2015 11:32

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#7 21. September 2015 11:52

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#8 21. September 2015 12:51

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#9 21. September 2015 16:45

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#10 21. September 2015 19:09

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#11 22. September 2015 22:05

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#12 22. September 2015 10:54

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#13 22. September 2015 11:16

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#14 22. September 2015 11:49

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#15 22. September 2015 12:16

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#16 22. September 2015 13:14

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#17 22. September 2015 13:21

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#18 22. September 2015 13:23

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#19 22. September 2015 13:45

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#20 22. September 2015 14:05

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#21 22. September 2015 14:08

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#22 22. September 2015 14:14

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#23 22. September 2015 16:16

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

#24 22. September 2015 19:06

Re: Navi: Desktop + Mobil + barrierefrei bzw. -arm

Fußzeile des Forums