Archiv der Kategorie: CSS

Erinnerung: Kenne Deine Standards

Zugegeben, ich hatte es selber nicht mehr auf dem Schirm: wenn man einen font-stack angibt, werden von den später angegebenen Schriftarten nur solche Zeichen ersetzt, die in den zuerst genannten Fonts nicht vorhanden sind.

Heißt: wenn ich beispielsweise alle Ampersands eines Textes in einer eigenen Schriftart darstellen will, kann ich eine Schriftart erstellen, die nur dieses eine Zeichen enthält. Das wird dann genommen – für alle anderen Zeichen werden die folgenden Schrfiten verwendet.

Mich hat Heydon Pickering mit folgendem Beispiel dran erinnert:

body {
font-family: Ampersand, Georgia, serif;
}

According to the law of font stacks, all characters not supported by “Ampersand” will defer to Georgia.
Quelle: Heydon Pickering on „Font Hacking

 

Workshop: Barrierefreie Webseiten entwickeln in Köln

Schulungsangebot der besonderen Art

Bei der hier angebotenen Schulung handeln es sich um ein Format, das von 2 Dozenten geleitet wird. Einerseits bringen sich beide Dozenten mit Ihren Spezialisierungen ein, so dass alle Fragen mit exzellenter Kompetenz beantwortet werden können. Andererseits werden neben der Vermittlung der Theorie Beispiele für Barrieren und deren Auswirkungen auf Menschen mit Behinderungen live vorgeführt.

Alle Beispiel wird Domingos de Oliveira von seinem Screenreader ausgeben lassen, so dass deutlich wird, welche Probleme insbesondere für blinde Menschen bei der Bedienung von Webseiten bestehen.

Inhalte des Workshops

Sie erhalten eine Übersicht über geltende nationale (BITV) und internationale Standards (WCAG), die Ihnen die Anforderungen von Menschen mit Behinderungen an Webseiten erläutern und als Checkliste bei der Entwicklung dienen können.

Im Wechsel werden die Dozenten zu Ihren Fachgebieten referieren und Ihre Fragen beantworten, so dass es weder zu stundenlangen vortragen kommt, noch Ihre persönlichen Anliegen zu kurz kommen.

Am Ende sind Sie in der Lage, eine Vielzahl von Barrieren zu erkennen. Anhand der erworbenen Kenntnisse und des ausgehändigten Skripts sind Sie in der Lage, Lösungen für Probleme zu recherchieren und eigenständig zu arbeiten.

Eine Teilnahmebescheinigung wird ausgehändigt, so dass Sie die erworbenen Kenntnisse nachweisen können.

Die Dozenten

Marc Haunschild

schwarz-weiß-Portrait: 45jähriger Mann mit Vollbart und Brille
Dozent, Entwickler, Fachbuchautor

ist Entwickler, Fachbuchautor und Dozent für Barrierefreie Webanwendungen, er hält Vorträge und berät Agenturen. Zu seinen Arbeitgebern und Kunden zählen die Bundesanstalt für Landwirtschaft und Ernährung, TYPO3, das digital career institut, eduvision, web-vision u.v.a.m.

Er ist Mitglied in SelfHTML e.V.

Im Workshop wird er schwerpunktmäßig die Beispiele vorführen, sowie über die BITV und technische Aspekte der Barrierefreiheit berichten.

Domingos de Oliveira

Mann mit Anzug und Krawatte
Dozent, Trainer und Fachbuchautor

arbeitet seit 2010 als Berater und Dozent für digitale Barrierefreiheit. Er ist von Geburt an blind. Er hat bereits mehr als zahlreiche Personen zu diesen Themen geschult und viele Projekte beraten. Unter anderem hat er den BIENE-Wettbewerb für barrierefreie Webseiten fachlich begleitet. Zu seinen Kunden zählen die Aktion Mensch, die Deutsche Forschungsgemeinschaft und der Zoll.

Während der Schulungsmaßnahme wird er zu den internationalen Standards, den besonderen Anforderungen blinder Menschen und seinen Erfahrungen im Web referieren und Fragen beantworten. Außerdem wird er alle Beispiele im Screenreader vorführen.

Zielgruppen des Workshops

Der Workshop richtet sich in erster Linie an Entwickler. Kenntnisse in HTML und CSS sind sinnvoll.

Webagenturen und Unternehmen, die sich einen Wettbewerbsvorteil verschaffen möchten, erhalten hier Kenntnisse, die Ihnen Zugang zum Markt der etwa 8 Millionen Menschen mit anerkannter Schwerbehinderung verschaffen, aber auch zu den vielen Menschen denen aufgrund leichterer oder temporärer Einschränkungen die Bedienung konventioneller Webseiten schwer fällt.

Entwickler in Behörden, die barrierefreie Webseiten erstellen müssen, profitieren natürlich in besonderem Masse von den vermittelten Inhalten.

Laden Sie sich hier gerne eine Zusammenfassung des englischsprachigen Vortrags „economic aspects of accessibility“ herunter.

Termin und Adresse der Fortbildungsmaßnahme

Zeit

19.9.2018 von 10 bis 17 Uhr

Ort

TRAIN & EDUCATION Ltd.
Kölner Strasse 265
51149 Köln-Porz

Der Schulungsraum ist mit Computern ausgestattet, Sie müssen also keine eigene Hardware mitbringen.

Anmeldung und Kosten

Die Teilnahme am Workshop kostet 300,00 Euro zzgl. 19 % Umsatzsteuer. Bitte melden Sie sich spätestens zum 4.9.2018 verbindlich an. Mit Ihrer Anmeldung akzeptieren Sie die allgemeinen Teilnahme- und Geschäftsbedingungen. Diese finden Sie auf Seite 3 der Ausschreibung.

Sie können sich formlos per Mail an barrierefreiheit @ posteo.de anmelden. Teilen Sie uns bitte Ihren Namen und Ihre Kontaktdaten mit. Teilen Sie uns auch bitte aus organisatorischen Gründen mit, ob Sie eine Behinderung haben, die für Ihre Teilnahme am Workshop relevant ist.

Kontakt und Anmeldung

Kontaktieren Sie uns auch gerne, wenn Sie Fragen zum Workshop haben.
Domingos de Oliveira
– Freiberuflicher Accessibility-Consultant
Umsatzsteuer-ID: DE273231108
Karthäuserstr. 13
53129 Bonn
Telefon: 0176/32245129
Mail: barrierefreiheit ät posteo.de

Mögliche weiterführende Kurse

  • BITV – Webseiten konform zur Barrierefreien Informations-Technik-Verordnung erstellen
  • Redaktionelle Aspekte der Barrierefreiheit
    Texte für alle in einfacher Sprache, Texte korrekt auszeichnen und illustrieren

Das Web barrierefrei gestalten – Leitfaden für Entwickler

Mein Buch „Das Web barrierefrei gestalten – Leitfaden für Entwickler“ ist in der Trainer-Edition des „Herdt Verlag für Bildungsmedien“ erschienen.

Ziel war einen möglichst kompakten Einstieg für Entwickler in das Thema anzubieten. Obwohl das Buch und die mitgelieferten Beispiele auch Code enthalten, dienen diese in der Regel nur der Verdeutlichung der Prinzipien von barrierefreien Webseiten.

Mehr Besucher, bessere Webseiten, glückliche Nutzer – alle gewinnen!

Cover (Titelseite)
Das Web barrierefrei gestalten – Leitfaden für Entwickler (HERDT Verlag für Bildungsmedien – Trainer Edition 2017)

So wird beispielsweise gezeigt, wie Menschen mit Behinderungen und Entwickler von der bestimmungsgemäßen Verwendung von HTML profitieren. Barrierefreiheit ist nicht kompliziert, man muss nur wissen, wie es geht!

An zahlreichen Beispielen wird erläutert, warum sich Barrierefreiheit für Agenturen, deren Kunden und die Nutzer im Web lohnt – einschließlich nicht behinderter Anwender.

Statt langatmiger Erläuterungen bietet das kompakte Werk zahlreiche Verweise ins Web, so dass Entwickler Ihr Wissen gezielt zu bestimmten Themen vertiefen können. Auf Vorträge, Code-Beispiele und Tutorials von Heydon Pickering, Lea Verou, Leonie Watson, Kerstin Probiesch, Jan Eric Hellbusch und vielen anderen wird verwiesen und so ist dieser Leitfaden auch ein Wegweiser zu den Perlen der Zugänglichkeits-Experten im Netz.

Auf der Website des Verlages stehen das Inhaltsverzeichnis und eine Leseprobe bereit.

Ich würde mich freuen über Rückmeldung in Form von Verbesserungsvorschlägen, Kritik und Lob.

Zur Buchbeschreibung und Bestellung

Inclusive Design: Video von Leonie Watson über Flexbox (und Grid)-Layouts (und Tee)

Leonie Watson hat vor einer Weile einen Vortrag gehalten, der sich unter anderem mit der Zugänglichkeit von Webseiten beschäftigt, die mit Flexbox gestaltet werden.

Das meiste, was Sie hier gesagt hat, gilt auch für das neue CSS Grid. Deswegen: wer jetzt begeistert ist von den neuen Möglichkeiten des CSS-Grid, sollte sich das Video mal anschauen. So lassen sich (wie immer) Probleme mit der Zugänglichkeit von Anfang an vermeiden.

Übrigens: Der Grid-Pionier Microsoft passt seine Implementation an den aktuellen stand der Technik an!

Video (englisch): Leonie Watson: On CSS accessibility and drinking tea (CSS day 2016)

Link zum Video „On CSS accessibility and drinking tea (CSS day 2016)“ auf YouTube – YouTube erhebt Daten .

Tools und Links aus dem Vortrag:

Webseiten zum anhören: Tipps für die Sprachausgabe

Lesen lassen – nicht nur für Blinde eine Hilfe

Webseiten sind in den meisten Fällen mit viel Aufwand optisch ansprechend gestaltet. Sie lassen sich heute in der Regel sowohl an einem großen Bildschirm, als auch auf dem kleinen Smartphone-Display bequem betrachten und bedienen.

Aber habe Sie sich Ihre Webseite schon einmal vorlesen lassen? Zwar sind die Computerstimmen nicht so nett anzuhören, wie ein Mensch, aber es wurde eine Menge Aufwand in die einzelnen Systeme gesteckt, damit die Sprache weitgehend natürlich klingt. Na ja, das klappt nicht hundertprozentig, aber heutige Vorleseautomaten sind einwandfrei zu verstehen. Wenn man seine Hände frei haben möchte, ist das Hören einer Webseite – insbesondere bei einem längeren Text – eine nicht zu verachtende Alternative zum Selberlesen.

Safari im Lesemodus mit aktivierter Vorlesefunktion

Besonders gut ist das auf iOS-Geräten umgesetzt. In den Bedienungshilfen lässt sich aktivieren, dass eine Seite vorgelesen werden soll, wenn man mit zwei Fingern von oben nach unten streicht. Dann erscheint auch ein kleiner Player, mit dem man die Geschwindigkeit bestimmen und das Vorlesen pausieren kann. Der Browser Safari bietet darüber hinaus einen Lesemodus, der sich aktivieren lässt, indem man in der Adressleiste des Browsers auf ein Text-Symbol klickt, ähnlich dem Symbol für linksbündigen Text in einer Textverarbeitung wie Word.

Dann werden Navigation, Kopf- und Fußbereich und Werbung ausgeblendet und gezeigt wird nur noch der Hauptinhalt der geöffneten Seite. Sehr angenehm zu lesen (Einstellungen zu Schriftgröße, Darstellung usw lassen sich auf die persönlichen Wünsche abstimmen).

Diese Darstellung ist aber auch sehr gut geeignet, um vorgelesen zu werden.

Wenn Sie die Seite nicht nur lesen möchten, sondern auch mit ihr interagieren wollen, ist der Lesemodus natürlich nicht geeignet, denn ohne Links und Schlatflächen, keine Interaktion.

Mit einer freien Hand beim Essen oder Kaffetrinken, kann man sich per Tastatur durch die Webseite bewegen. Mit der Tabulator-Taste beispielsweise springt man von Link zu Link.

In vielen Situationen ist das eine echte Hilfe. Noch freier wird man in der Bedienung, wenn man nicht ständig auf den Bildschirm schauen muss. Dazu benötigt man eine Sprachausgabe. Auch diese ist in iOS bereits integriert (in Android auch, aber als Apple-User kann ich zur Bedienung wenig sagen – auch unter Windows und Windows für mobile Geräte wird es sicher so etwas geben).

Manche von uns sind sogar auf die Bedienbarkeit ohne Bildschirm angewiesen, weil sie nicht oder so schlecht sehen, dass die Seite auch ohne Bild funktionieren muss, um von ihnen bedient werden zu können.

Auf vielen modernen Webseiten gehrt das schon ganz gut, weil diese meistens einige wichtige Aspekte beachten. Sonst würden auch so Dinge wie der Lesemodus von Apple nicht funktionieren.

Um Blinde so zu unterstützen, dass eine Webseite nicht nur irgendwie vorgelesen wird, sondern auch noch ein komfortabel zu bedienen ist, braucht es dann noch ein bisschen mehr. Man kann exklusiv für die Nutzer von Screenreadern mit mehreren Methoden Hinweise geben, die das Layout der Seite für Sehende nicht „stören“, weil sie nicht angezeigt werden.

So ist es beispielsweise eine große Hilfe, wenn die einzelnen Bereiche einer Webseite mit Überschriften versehen sind. Haben Hauptnavigation, Inhaltsbereich, Seitenleiste und Fußbereich sinnvolle Überschriften, wissen Blinde, die von Überschrift zu Überschrift navigieren können, auf Anhieb, wo sie sich innerhalb einer Seite befinden.

Sinnvolle Überschriften wären beispielsweise

  • „Navigation“ für die Hauptnavigation,
  • die Artikelüberschrift für den Hauptbereich (möglichst identisch mit dem Titel der Seite und mit den Links, die auf diese Seite führen),
  • „Weiterführende Informationen“ für die Seitenleiste und
  • „Über diese Webseite“ für den Fußbereich, der in der Regel Copyright-Hinweis, Kontakt-Adresse des Betreibers u.ä. enthält

Anhand der Positionierung und des Layouts sollten alle diese Bereiche auf den ersten Blick für sehende Besucher erkennbar sein. Man ist gewohnt, die Navigation oben oder links zu finden und weiß, wie die ungefähr gestaltet ist (ein zusammengehöriger Block mit einer Liste von Links – oft fahren Unterpunkte bei Berührung mit der Maus oder Touch-Kontakt aus).

Also benötigen Sehende diese Informationen in der Regel nicht. Es gibt nämlich Ausnahmen – haben Sie sich mal eine komplexe Webseite ohne Layout angeschaut? – Sicher haben Sie so etwas schon mal gesehen, weil hin und wieder kommt es bei der einen oder anderen Seite zu so einem Fehler, weil ein Entwickler sich vertan hat, im Server etwas falsch konfiguriert ist oder bei der Übertragung etwas schief gelaufen ist. Die Formate (CSS) lassen sich aber auch vom Besucher gezielt ausschalten oder durch eigene Formatierungen ersetzen. In diesen Fällen ist nicht mehr sichergestellt,  dass die geannnten Bereiche auf Anhieb erkannt werden.

Darum ist es sinnvoll, die Überschriften der Seite nur dann auszublenden, wenn das Original-Autoren-Stylesheet des Seitenbetreibers verwendet wird.

Das geht recht einfach: die nicht anzuzeigenden Inhalte sollen vorgelesen werden, aber nicht zu sehen sein. Screenreadern (und Blinden) ist es egal, ob ein Text in ein Element hinein passt oder ob es sich außerhalb des sichtbaren Bereiches befindet. Wenn die entsprechende Stelle im Quelltext „an der Reihe ist“, vorgelesen zu werden, gibt das Vorleseprogramm den Text aus.

Also sorgen Sie dafür, dass solche Texte per CSS aus dem sichtbaren Bereich verschoben werden. Klingt einfacher, als es ist, damit es auch in allen Browsern und Screenreader-Kombinationen funktioniert (siehe auch Diskussion unter https://github.com/h5bp/html5-boilerplate/issues/194/). Ich benutze die Lösung von HTML5 Boilerplate (die diverse Vorläufer hat) seit Jahren ohne Probleme. Sie funktioniert wie folgt:

HTML

<h2 class="visuallyhidden">Navigation</h2>

CSS

.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

Auf diese Weise verstecken Sie Elemente vor Sehenden, sorgen aber dafür, dass diese zugänglich sind, wenn Ihre Webseite mit einem Screenreader besucht wird oder Ihre Styles vom Besucher nicht genutzt werden.

Bilder für blinde Hörer beschreiben

Wichtige Informationen zu Bildern, die Sie exklusiv für Nutzer von Screenreadern mitgeben wollen, schreiben Sie in das alt-Attribut des Bildes:

<figure>
  <img alt="Lachendes Mädchen schaut in einen blauen Sommerhimmel" src="Sommer.jpg">
  <figcaption>Auch das Wetter hat bei unserem Urlaub mitgespielt</figcaption>
</figure>

Beachten Sie, dass der Alternativ-Text keine Wiederholung der Bildbeschreibung ist. Der Alternativ-Text informiert zusätzlich über das Motiv und die Stimmung des Bildes.

Nerven Sie Blinde nicht, indem Sie eine Visitenkarte basteln, die mit Max Muster überschrieben ist, dann Vorname: Max, Name: Muster enthält, daneben ein Bild mit der Beschreibung (figcaption) Porträt von Max Muster und demselben Text nochmal im alt– und title-Attribut.

Zusätzlicher Nutzen: steht ein Bild mal nicht zur Verfügung, wird statt des Bildes der alternativ-Text angezeigt (darum heißt der auch so). Gründe für das Fehlen von Bildern sind zahlreich, z.B.:

  • ein Entwickler hat einen Fehler gemacht (z.B. falscher Dateipfad)
  • bei der Übertragung ist etwas schief gegangen
  • das Bild stammt liegt nicht auf dem Server, die das HTML-Dokument und obwohl das HTML-Dokument erreichbar ist, ist der Bilderserver nicht erreichbar
  • das Bild liegt in einer Datenbank, die gerade nicht funktioniert
  • der Besucher Ihrer Webseite ist eine Suchmaschine
  • der Besucher Ihrer Webseite ist im Ausland und kann oder will sich die hohen Kosten für den Download der Bilder nicht leisten oder
  • hat die Darstellung aus anderen Gründen abgeschaltet (beispielsweise um Werbebildchen zu entgehen und so das Laden von Webseiten zu beschleunigen)

Mehr Möglichkeiten mit WAI-ARIA

Wenn es mal nötig und unumgänglich ist, den Sehenden noch einmal denselben Text zu präsentieren, den Sie bereits im alt-Attribut verwendet haben, gibt es eine Wunderwaffe für Barrierefreiheit: WAI-ARIA.

Damit können Sie insbesondere Screenreader-Nutzer über zahlreiche Dinge informieren (z.B. ob ein Untermenü aufgeklappt ist oder nicht). Mit dem Attribut aria-hidden haben Sie aber auch die Möglichkeit, das Vorlesen eines bestimmten Textes zu verhindern:

<p aria-hidden="true">Dieser Text ist sichtbar, wird aber von Screenreadern nicht vorgelesen.</p>

Über WAI-ARIA werde ich sicher in Zukunft noch eine Artikel schreiben – ein weites Feld, das eine genauere Betrachtung verdient.

An dieser Stelle möchte ich noch auf den Artikel von Jan Eric Hellbusch zu alternativ-Texten für Bilder hinweisen, die für Screenreader-Nutzer nicht unbedingt identisch mit dem alt-Attribut sind.

Längere Beschreibungen können Sie einem Element zuweisen, indem Sie einen Text, den Sie schon geschrieben haben (z. B. ein Hinweis in einem aside-Element) in einen logischen Bezug mit dem zu beschreibenden Element setzen.

Diesen Bezug stellen Sie über eine ID her. Das heißt, Sie geben dem informativen Text eine ID und verknüpfen diesen Text, mit dem Element, das beschrieben werden soll mittels aria-describedby:

HTML

<figure>
 <img
    alt="Lachendes Mädchen schaut in einen blauen Sommerhimmel"
    src="Sommer.jpg"
    aria-describedby="bildbeschreibung">
 <figcaption>Auch das Wetter hat bei unserem Urlaub mitgespielt</figcaption>
</figure>
<aside id="bildbeschreibung">Länger Text Lorem ipsum....</aside>

Wo bin ich?  Orientierung geben mittels aria-current

Ein sehr wichtiger Hinweis für Menschen, ist die Angabe des aktuellen Ortes oder auch einer Zeit – beispielsweise „heute“ in einem Kalender. Mit dem Attribut ariacurrent können Sie genau diese Information Blinden mitgeben. Es dient dazu ein Element aus einer Liste von Elementen als „das Aktuelle“ zu markieren. Das kann zum Beispiel der Eintrag in der Hauptnavigation sein, der auf die aktuell geöffnete Seite verweist oder eben „heute“ in einem Kalender. Dazu sind entsprechende Werte erlaubt:

  • page (Aktuelle Seite)
  • step (z.B. In einem Bestellprozess)
  • location (z.B. der aktuelle Aufenthaltsort auf einer Reiseroute)
  • date (z.B. Heute im Kalender)
  • time (z.B. die aktuelle Uhrzeit in einem Veranstaltungsprogramm)
  • true (das Element ist tatsächlich das aktuelle Element)
  • false (Standard-Wert – das Element ist nicht das aktuelle Element einer Liste)

Jeder Wert ungleich „true“ oder „false“ wird von Screenreadern interpretiert und der Hörer bekommt einen sinnvollen Text angesagt – in der Sprache, die im HTML-Attribut lang angegeben ist.

Inclusives Design: Das „current page“-Problem

Was ist das „current page„-Problem?

Beim „current page„-Problem geht es darum, wie man Nutzer idealerweise darüber informiert, auf welcher Seite man sich in einem Webangebot befindet und wie die geöffnete Seite im Hauptmenü dargestellt und ausgezeichnet werden soll.

Im Fazit am Ende dieser Seite gebe ich zusammenfassende Empfehlungen. Bitte lesen Sie dennoch den gesamten Text, da er die Vor- und Nachteile der verschiedenen Methoden erläutert. Es gibt leider keine Methode, die immer optimal ist.
Inclusives Design: Das „current page“-Problem weiterlesen

Inclusives Design: Formulare mit HTML und CSS

Auf den meisten Ihrer Seiten bieten Sie vermutlich Informationen an, die „nur“ gelesen werden sollen. Vielleicht haben Sie für Ihre Texte schon viel getan, um diese zugänglich zu machen.

Auch  Formularen sollten Sie die gleiche Aufmerksamkeit widmen. Formulare sind schließlich eine Möglichkeit, mit Ihren Besuchern in Kontakt zu treten. Worauf Sie bei der Erstellung von inklusiven Formularen achten müssen, erfahren Sie in diesem Artikel.

Inclusives Design: Formulare mit HTML und CSS weiterlesen

w3c Logotype

Umsetzung zugänglicher Webseiten

20131120-162814.jpgMan sollte nicht den Eindruck erwecken, es sei wahnsinnig
zeitaufwändig, zugängliche Webseiten zu erstellen. Nötig ist
eigentlich vor allem ein einmaliger Lernaufwand, damit man weiß,
wie es geht. Beispielsweise semantisch korrekte Auszeichnung: die
Tags zur Auszeichnung einer Überschrift schreiben sich nicht
langsamer als die für das Element strong. Man muss nur wissen, dass
strong eben nicht für die Auszeichnung von Überschriften geeignet
ist und wie es besser geht. Dasselbe gilt für die Verwendung von
header, main, blockquote, usw statt div. Auch zusätzliche Angaben
sind in aller Regel schnell gemacht. So soll die Hervorhebung von
angetabbten Links mindestens so deutlich sein, wie die
Hervorhebungen für Mausnutzer (:hover). In der Praxis bedeutet es,
dass ich einen langen Selektor wie main #content article a:hover
markiere, kopiere und ein zweites mal einfüge, hover durch focus
ersetze und ein Komma einfüge. Ergebnis: main #content article
a:focus, main #content article a:hover Dauer etwa 5-10 Sekunden.
Das ist selbst bei aufwändig durchgestylten Webseiten, an denen man
mehrere Tage entwickelt, selten mehr als zehn Mal nötig.
Gesamtaufwand maximal also eineinhalb Minuten. Nutzt man Vorlagen
wie HTML5-Boilerplate, hat man gleich jene ganze Reihe von Klassen
inklusive, die auch die Entwicklung zugänglicherSeiten erleichtern,
wie zum Beispiel visuallyhidden, um Texte nur für
Screenreadernutzer bereit zu stellen (oder falls mal CSS nicht
funktioniert). Mit einem durchdachten Workflow, klug gewählten
Vorlagen und Werkzeugen und dem nötigen Wissen entsteht dafür kaum
ein nennenswerter Mehraufwand. So ist es mit vielen Dingen.
Berücksichtigt man gleich beim Design ausreichende Kontraste und
gibt man für das Layout nicht pixelgenaue Breiten statt fluider
Spalten vor (was in Zeiten des responsiven Designs ohnedies
schwachsinnig ist), wie viel länger dauert das dann, wenn
überhaupt? Zugegeben, der Testaufwand steigt. Aber in Zeiten
responsiver Layouts ist auch das anteilmäßig nicht mehr so der
große Brocken. Es ist deutlich aufwändiger in allen Browser- und
(mobilen) OS-Kombinationen zu testen, als einen Test auf
Zugänglichkeit zu machen (der sich größtenteils in die anderen
Tests integrieren lässt). Viele Dinge, die für zugängliche
Webseiten vorgeschrieben sind, sind ohnehin nach W3-Standard nötig,
wie valides HTML, Verzicht auch veraltete Elemente und Attribute,
alt-Texte, semantische Elemente statt div und so weiter. Aufwändig
und teuer (und relativ nutzlos) sind dagegen Zusammenfassungen in
Leichter Sprache und Deutscher Gebärdensprache. Entweder man
„übersetzt“ alle Inhalte (de facto wohl nicht zu leisten) oder man
steht auch dazu und lässt es gleich ganz. Für mich sind diese
Forderungen der BITV (die ohnehin nur für die wenigsten Sites,
nämlich Portale verlangt werden) reine Alibi-Forderungen, um sagen
zu können, dass man Gehörlose und Menschen mit kognitiven
Einschränkungen auch ernst nimmt. Von daher kann ich auch ein Stück
weit verstehen, dass die Vertreter der diversen Behindertenverbände
behaupten, die BITV berücksichtige vor allem die Interessen von
Fehlsichtigen und Blinden. Nichtsdestotrotz: viele wesentliche
Verbesserungen sind schnell gemacht. Der zusätzliche Aufwand sollte
(für die einmaligen technischen und gestalterischen Aspekte) 10%
kaum überschreiten, selbst wenn es schon richtig gut gemacht wird.
Wenn man dazu noch bedenkt, dass bei zwei bis fünf Jahren der
Laufzeit einer Website der Dauerbetrieb deutlich mehr Ressourcen
verbraucht, sieht man, wie gering der Zusatzaufwand während der
gesamten Lebensdauer solch eines Projektes ist. Was ich aber nicht
verschweigen möchte, Sind inhaltliche (nicht technische)
Gesichtspunkte. Redakteure müssen einige Angaben machen, die für
zugängliche Webseiten vorgeschrieben sind, die aber die Nutzbarkeit
für jeden Leser erhöhen verbessern. Das sind beispielsweise
saubere, tippfehlerfreie Texte, die nach den Regeln der
entsprechenden Textgattung verfasst und sprachlich an die
Zielgruppe angepasst sind: Zitate sollen als Zitate ausgezeichnet,
Abkürzungen aufgelöst, fremdsprachige Texte übersetzt sein – alles
für jeden Webseitenbesucher und -Betreiber ein Gewinn. Denn auf
solche Webseiten kommt man gerne wieder. Das gilt auch für Tante
Google, die man mit den Auflösungen von Abkürzungen oder
Übersetzungen natürlich ebenfalls füttert und die Texte so
bewertet, als wären sie gut geschrieben (wichtiges zuerst, später
die Details und am Ende ein Fazit). Google ist sicher der häufigste
wiederkehrende „blinde“ Besucher der meisten Websites. Darum hat
auch der Betreiber einer Seite etwas davon, wenn diese Kriterien
der Zugänglichkeit berücksichtigt. Ganz zu schweigen davon, dass
man potentiell mehr Besucher erreicht, wenn man Menschen mit
Behinderungen nicht durch unüberwindbare Hürden vom Besuch der
eigenen Site abhält. Und letztendlich macht es einen Auftraggeber
oder Webseitenbetreiber sympathisch, wenn er Seiten für alle
erstellt. So kann man soziale Kompetenz demonstrieren.

Linktipps Responsives Webdesign (RWD)

In aller Kürze ein paar nützliche Links zum Thema responsives Webdesign:

Online Tool zum  Testen:
https://quirktools.com/screenfly/

RWD muss schnell sein und ein (von mir nicht präferierter) Lösungsansatz:
http://tympanus.net/Tutorials/ResponsiveRetinaReadyMenu/

Die Bücher aus dem Galileo-Verlag haben mich immer wieder begeistert. Das unten verlinkte werde ich mir auf jeden Fall besorgen. Ihr solltet Euch mal die Videos ansehen. Vor allem im Video Lektion: 3.4 Mobile First, Content First [12:02] wird eine prima Lösung gezeigt, um (ältere) InternetExplorer zu unterstützen, die ja keine media queries verstehen (Stichwort response.js).

Da diese Lösung JS benötigt könnt Ihr natürlich alternativ (falls die Seite auch ohne JS laufen muss) meine an anderer Stelle vorgeschlagene Lösung verwenden (d.h. alle Angaben in media queries für den IE wiederholen. Entweder per HTML5-Boilerplate-Klasse oder in einer CSS-Datei extra für den IE (was ich aus Performanz-Gründen empfehlen würde)).

Hier der Link zum Buch, (Auszüge und einige Videos können Online betrachtet werden):
http://www.galileocomputing.de/katalog/buecher/titel/gp/titelID-3347

Alle hier genannten links habe ich auch der Seite über Responsoves Webdesign zugefügt.