Lesetip: The web accessibility basics

[Gunnar Bittersmann]

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

“Everyone who creates stuff on the web should read this article over and over again until everything in it is obvious.” —Vasilis van Gemert

LLAP 🖖

[pl]

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

“Everyone who creates stuff on the web should read this article over and over again until everything in it is obvious.” —Vasilis

Sieht aus wie eine Todesanzeige, liest sich aber gut. Schönen Sonntag!

[marctrix]

Hej pl,

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Sieht aus wie eine Todesanzeige, liest sich aber gut. Schönen Sonntag!

Das ist das "Problem" - auf den meisten Webseiten muss man barrierefreiheit und Corporate Design, Responsivität und aktuelle technische Trends irgendwie unter einen Hut bringen.

Ich habe nichts gegen ein fehlendes Design. Fefes Blog lese ich auch so gerne, wie es ist. Selbst der gute alte Lynx hat für mich einen auch optischen Charme. Aber da bin ich wohl die Ausnahme.

Marc

[Der Martin]

Hallo,

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Sieht aus wie eine Todesanzeige, liest sich aber gut. Schönen Sonntag!

Das ist das "Problem" - auf den meisten Webseiten muss man barrierefreiheit und Corporate Design, Responsivität und aktuelle technische Trends irgendwie unter einen Hut bringen.

ja, darin liegt wohl die Kunst. Und dazu soll es nach Möglichkeit auch noch gut aussehen.

Ich habe nichts gegen ein fehlendes Design.

Ich schon. Design heißt ja nicht nur, Bilder und bunte Farben. Design ist auch nicht nur Typographie. Design ist das Gesamtkunstwerk - dazu gehören unter anderem die genannten Merkmale, aber auch Layout, Gliederung und Struktur, Bedienbarkeit und Funktionalität.

Aber vermutlich war Design nur ein ungünstig gewählter Begriff.

So long,
 Martin

[marctrix]

Hej Der Martin,

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Sieht aus wie eine Todesanzeige, liest sich aber gut. Schönen Sonntag!

Ich habe nichts gegen ein fehlendes Design.

Aber vermutlich war Design nur ein ungünstig gewählter Begriff.

Es war ein provkant gewählter Begriff. ;->

Selbst fefes Blog hat ja durchaus ein (bewusst minimalistisches) Design.

Marc

[Gunnar Bittersmann]

@@Der Martin

Design ist das Gesamtkunstwerk

Nei-en!! Design ist nicht Kunst.

dazu gehören unter anderem die genannten Merkmale, aber auch Layout, Gliederung und Struktur, Bedienbarkeit und Funktionalität.

Eben.

“Most people make the mistake of thinking design is what it looks like. People think it’s this veneer—that the designers are handed this box and told, ‘Make it look good!’ That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.”
—Steve Jobs

LLAP 🖖

[marctrix]

Hej Gunnar,

dazu gehören unter anderem die genannten Merkmale, aber auch Layout, Gliederung und Struktur, Bedienbarkeit und Funktionalität.

Eben.

“Most people make the mistake of thinking design is what it looks like. [...]

Leider haben offenbar viele Menschen, die für das Aussehen von (virtuellen) Dingen verantwortlich sind, an dieser Stelle aufgehört zu lesen...

Marc

[Der Martin]

Hallo,

Design ist das Gesamtkunstwerk

Nei-en!! Design ist nicht Kunst.

ach was? Einen Absatz weiter unten bestätigst du es wieder.

dazu gehören unter anderem die genannten Merkmale, aber auch Layout, Gliederung und Struktur, Bedienbarkeit und Funktionalität.

Eben.

Eben. Also doch Kunst. Oder gehören diese Aspekte für dich nicht zu Kunst? Für mich schon.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

dazu gehören unter anderem die genannten Merkmale, aber auch Layout, Gliederung und Struktur, Bedienbarkeit und Funktionalität.

Oder gehören diese Aspekte für dich nicht zu Kunst?

Nein. Bei Kunst geht es nicht um Bedienbarkeit und Funktionalität.

Ein Künstler will sich ausdrücken und seine Person in sein Werk einfließen lassen.
Ein Designer wird sich zurücknehmen und das Produkt für den Nutzer gestalten.

LLAP 🖖

[Der Martin]

Hi,

dazu gehören unter anderem die genannten Merkmale, aber auch Layout, Gliederung und Struktur, Bedienbarkeit und Funktionalität.

Oder gehören diese Aspekte für dich nicht zu Kunst?

Nein. Bei Kunst geht es nicht um Bedienbarkeit und Funktionalität.

dann haben wir unterschiedliche Auffassungen von Kunst.

Kunst ist für mich das Ausüben einer kreativen Tätigkeit, die eine gewisse Fertigkeit erfordert - das Wort Kunst leitet sich IMO von Können ab. Ob bei dieser Tätigkeit eher Ästhetik oder Zweckmäßigkeit im Vordergrund steht, ist für mein Verständnis von Kunst Nebensache. Auch so manches Handwerk betrachte ich als Kunst.

Ein Künstler will sich ausdrücken und seine Person in sein Werk einfließen lassen.

Ein Künstler will seine besonderen Fertigkeiten demonstrieren und damit etwas schaffen, was anderen gefällt oder nützt.

Ein Designer wird sich zurücknehmen und das Produkt für den Nutzer gestalten.

Sag das mal Modedesignern.

Ciao,
 Martin

[Tabellenkalk]

Hallo,

Sag das mal Modedesignern.

Die machen ja auch keine Designs sondern Dessins...

Gruß
Kalk

[Auge]

Hallo

… das Wort Kunst leitet sich IMO von Können ab.

Logisch, sonst hieße es ja „Wunst“. *scnr*

Tschö, Auge

[Gunnar Bittersmann]

@@Der Martin

Kunst ist für mich das Ausüben einer kreativen Tätigkeit

Oder deren Ergebnis.

die eine gewisse Fertigkeit erfordert

Das sicher. Wer nicht singen kann, wird mit seiner Gesangskunst kaum jemanden erfreuen. Und wird vom Schmied an den Baum gefesselt.

Ob bei dieser Tätigkeit eher Ästhetik oder Zweckmäßigkeit im Vordergrund steht, ist für mein Verständnis von Kunst Nebensache.

Was hat Kunst mit Zweckmäßigkeit zu tun?

Was nicht heißen soll, dass Kunst nicht nützlich sein kann. Der Nutzen ist aber eher ideeller Natur.

Auch so manches Handwerk betrachte ich als Kunst.

Dann ist Programmieren für dich Kunst? Programmieren ist ja durchaus das Ausüben einer kreativen Tätigkeit, die eine gewisse Fertigkeit erfordert. Ist für mich aber keine Kunst.

Ein Designer wird sich zurücknehmen und das Produkt für den Nutzer gestalten.

Sag das mal Modedesignern.

Die wissen das. Auf jeden Fall, wenn sie Mode für Leute machen und nicht für den Laufsteg.

LLAP 🖖

[Der Martin]

Hallo,

Kunst ist für mich das Ausüben einer kreativen Tätigkeit

Oder deren Ergebnis.

das geht jetzt in Richtung Wortklauberei, aber ... nein, deren Ergebnis ist das Kunstwerk, während Kunst an sich für mich der Vorgang des Schaffens ist.

Auch so manches Handwerk betrachte ich als Kunst.

Dann ist Programmieren für dich Kunst?

Selbstverständlich (aber nicht das bloße Umsetzen eines bereits vorhandenen Konzepts in Code). Oder ein Möbelstück schreinern - vom Entwurf bis zum fertigen Produkt. Oder sich ein leckeres Essen ausdenken und zubereiten.

Programmieren ist ja durchaus das Ausüben einer kreativen Tätigkeit, die eine gewisse Fertigkeit erfordert. Ist für mich aber keine Kunst.

Ich sagte ja schon: Wir haben wohl unterschiedliche Auffassungen des Kunstbegriffs.

Ein Designer wird sich zurücknehmen und das Produkt für den Nutzer gestalten.

Sag das mal Modedesignern.

Die wissen das. Auf jeden Fall, wenn sie Mode für Leute machen und nicht für den Laufsteg.

Wobei letztere aber in der Regel die bekannteren sind.

Ciao,
 Martin

[marctrix]

Hej Der Martin,

Programmieren ist ja durchaus das Ausüben einer kreativen Tätigkeit, die eine gewisse Fertigkeit erfordert. Ist für mich aber keine Kunst.

Ich sagte ja schon: Wir haben wohl unterschiedliche Auffassungen des Kunstbegriffs.

Ich wollte mich eigentlich nicht einmischen, aber Popcorn ist alle. Was ich an anderer Stelle mal @Gunnar Bittersmann gesagt habe, sage ich dir jetzt: wenn man eine eigene Auffassung davon hat, was ein Wort bedeutet, hört man auf, verstanden zu werden.

Gunnar hat recht. ;-)

Marc

[Der Martin]

Hallo,

Ich sagte ja schon: Wir haben wohl unterschiedliche Auffassungen des Kunstbegriffs.

Ich wollte mich eigentlich nicht einmischen, aber Popcorn ist alle.

*g*

Was ich an anderer Stelle mal @Gunnar Bittersmann gesagt habe, sage ich dir jetzt: wenn man eine eigene Auffassung davon hat, was ein Wort bedeutet, hört man auf, verstanden zu werden.

Ja. Das passiert aber leider oft im Alltag.

Gunnar hat recht. ;-)

Aber nicht als einziger. Im Gegensatz zur Fachsprache gibt es in der Alltagssprache oft kein eindeutiges "Richtig" oder "Falsch". Deswegen missverstehen die Leute einander ja so häufig.

Ciao,
 Martin

[marctrix]

Hej Der Martin,

Was ich an anderer Stelle mal @Gunnar Bittersmann gesagt habe, sage ich dir jetzt: wenn man eine eigene Auffassung davon hat, was ein Wort bedeutet, hört man auf, verstanden zu werden.

Ja. Das passiert aber leider oft im Alltag.

In Chats oder Forenbeiträgen ist es zugegebenermaßen zusätzlich schwierig. Ist ja auch kein Angriff, jedenfalls war es nicht als solcher gemeint...

Gunnar hat recht. ;-)

Aber nicht als einziger. Im Gegensatz zur Fachsprache gibt es in der Alltagssprache oft kein eindeutiges "Richtig" oder "Falsch". Deswegen missverstehen die Leute einander ja so häufig.

Auch wieder wahr!

Marc

[Gunnar Bittersmann]

@@marctrix

Das ist das "Problem" - auf den meisten Webseiten muss man barrierefreiheit und Corporate Design, Responsivität und aktuelle technische Trends irgendwie unter einen Hut bringen.

Ich sehe nicht, wie sich da irgendwas davon in die Quere kommen sollte.

Ich habe nichts gegen ein fehlendes Design.

Gibt es sowas wie „fehlendes Design“? Ebenso wie „man nicht nicht kommunizieren kann“ (Paul Watzlawick), würde ich sagen, dass man nicht nicht designen kann.

LLAP 🖖

[pl]

Ich habe nichts gegen ein fehlendes Design. Fefes Blog lese ich auch so gerne, wie es ist. Selbst der gute alte Lynx hat für mich einen auch optischen Charme. Aber da bin ich wohl die Ausnahme.

Ne, biste nich. Gegen die große Masse an mobil gemachten Seiten, die bei einem einzigen Aufruf 250 Requests in die schöne bunte Welt des Internettes hecken ist der Lynx tatsächlich eine gute Alternative.

Ich bin grad dabei, mir einen Reader (Link rein => Text raus) zu bauen, weil mir der Zuschnitt von gezielter Werbun langsam zu persönlich wird.

[pl]

Link rein, Text raus

[Matthias Apsel]

Hallo pl,

Link rein, Text raus

Ebenso wie Struktur, Semantik und Komfort. Dein Ziel lässt sich bestimmt besser, schneller und einfacher umsetzen, indem man an den Browsereinstellungen spielt:

JavaScript ausschalten, nur zwei Farben, keine Grafiken und noch einige Stellschrauben mehr lassen sich nach Bedarf kombinieren. In neueren Browsern gibt es zudem eine Leseansicht, die das sehr viel besser macht als dein „Tool“. (sinnvolles HTML vorausgesetzt)

Bis demnächst
Matthias

[pl]

Hallo pl,

Link rein, Text raus

Ebenso wie Struktur, Semantik und Komfort. Dein Ziel lässt sich bestimmt besser, schneller und einfacher umsetzen, indem man an den Browsereinstellungen spielt:

Nein eben nicht für meine Zwecke, hab lang drüber nachgedacht, bestimmt länger als Du. Einzig mit den eingesetzten Modulen muss ich noch ein bischen spielen, die sind neu für mich.

JavaScript ausschalten, nur zwei Farben, keine Grafiken und noch einige Stellschrauben mehr lassen sich nach Bedarf kombinieren. In neueren Browsern gibt es zudem eine Leseansicht, die das sehr viel besser macht als dein „Tool“. (sinnvolles HTML vorausgesetzt)

Die Leseansicht verhindert nicht, dass eine Seite 250 Requests feuert.

[Christian Kruse]

Hallo pl,

JavaScript ausschalten, nur zwei Farben, keine Grafiken und noch einige Stellschrauben mehr lassen sich nach Bedarf kombinieren. In neueren Browsern gibt es zudem eine Leseansicht, die das sehr viel besser macht als dein „Tool“. (sinnvolles HTML vorausgesetzt)

Die Leseansicht verhindert nicht, dass eine Seite 250 Requests feuert.

Das ist möglich. Das ausschalten von JavaScript und das deaktivieren von Grafiken dagegen schon.

LG,
CK

[JürgenB]

Hallo,

Link rein, Text raus

und was passiert dann, bzw. wo kommt der Text raus?

Gruß
Jürgen

[pl]

Hallo,

Link rein, Text raus

und was passiert dann, bzw. wo kommt der Text raus?

bei http://berkemeier.eu wurde $path nicht erkannt.

Jetzt hab ich $path ||= "/"; gesetzt und unterhalb des Forms kommt nun auch das erwartete Ergebnis.

[Gunnar Bittersmann]

@@pl

Link rein, Text raus

Und was soll das?

Wenn du den Text von jeglichem Markup befreist und in HTML ausgibst, hat er bei der Anzeige im Browser überhaupt keine Struktur mehr und ist ziemlich schlecht zu erfassen.

Du möchtest wenigstens white-space: pre-wrap für das Ausgabefeld setzen.

LLAP 🖖

[pl]

@@pl

Link rein, Text raus

Und was soll das?

Wenn du den Text von jeglichem Markup befreist und in HTML ausgibst, hat er bei der Anzeige im Browser überhaupt keine Struktur mehr und ist ziemlich schlecht zu erfassen.

Du möchtest wenigstens white-space: pre-wrap für das Ausgabefeld setzen.

Nein. Es gibt einen Grund gerade das NICHT zu machen (überlege selbst warum) und außerdem hab ich eine andere Lösung zur Verbesserung der Lesbarkeit.

[Gunnar Bittersmann]

@@pl

Du möchtest wenigstens white-space: pre-wrap für das Ausgabefeld setzen.

Nein. Es gibt einen Grund gerade das NICHT zu machen (überlege selbst warum)

Da mir schon der Gedanke, sämtliches Markup zu entfernen (also alles, was zur sinnvollen Ausgabe des Textes verwendet werden kann – womit nicht nur Bildschirmausgabe gemeint ist), dermaßen unverständlich ist, wird sich mir deine Intention, alles hintereinanderzuquetschen, auch nicht erschließen.

LLAP 🖖

[pl]

Idealerweise wird für sowas ein Proxy aufgesetzt der ICAP kann: Internet Content Adaption Protocol.

Des Weiteren eine Konfigurationsdatei nach dem WPAD Standard (.pac) und eine Policy welche die Verwendung des Proxies vorab regelt.

Alles Andere ist eh nur Spielerei ;)

[Gunnar Bittersmann]

@@pl

Link rein, Text raus

Wo du deine Seite hier zum Code-Review freigibst:

    <meta charset="UTf-8">

Viel Eifer hast du wohl nicht in diese Codezeile gesteckt. Groß-/Kleinschreibung per Zufallsprinzip?

Auch hätte der Eifer eher kommen sollen. Die Angabe der Zeichencodierung muss in den ersten 1024 Bytes des Dokuments stehen. Das tut sie bei dir noch. Wenn aber noch Angaben dazukommen, kann sie da schnell rausfallen. Deshalb: Angabe der Zeichencodierung am besten als allererstes im head.

    <meta name="author" content="Rolf Rost" />

So wichtig bist du aber auch nicht als dass diese Angabe gleich doppelt vorhanden sein müsste.

<div class="desk navcontainer_desk">
    <nav>
      <ul class='navlist_desk'>
        
            <li  title="Modern Perl-Framework Next Generation"> <a href="/" >Startseite</a> </li>
         
            <li  title="Schreiben Sie mir, ich freue mich über jede Rückmeldung"> <a href="/mail.html" >Mail</a> </li>
         
            <li  title="Volltextsuche über den Index und Inhalte dieser Website"> <a href="/find" >Suche</a> </li>
         
            <li  title="Ausgewählte Artikel und Anwendungen welche zu meinen Hobbies passen."> <a href="/hobby.html" >Hobby</a> </li>
         
            <li  title="Eigentlich sollte das mein Blog werden. Aber soviel habe ich nun auch wieder nicht zu sagen."> <a href="/blog" >Blog</a> </li>
         
            <li  title="Als Perlprogrammierer entwickelte ich in den Jahren 1997 bis heute ungezählte Webanwendungen und Perl-Scripts."> <a href="/web" >Web</a> </li>
        
      </ul>
    </nav>
</div>

Auch dieser Block mit identischem Inhalt ist doppelt vorhanden. Was soll das?

<address>
Anbieter: nmq​rstx-18­@yahoo.de, 
die Seite verwendet funktionsbedingt einen Session-Cookie und ist Bestandteil meines nach modernen Aspekten in Perl entwickelten Frameworks.
</address>

Vom Wahrheitsgehalt des Satzes abgesehen: er hat nichts in einem address-Element zu suchen.

<div class="desk">
    <ul id="footer_urls">
    
        <li style="display:inline; padding:0.1em"> <a href="/framework.html" title="Post-Modern Framework für Perl5, multidomain- und multiuserfähig">Framework</a> </li>
     
        <li style="display:inline; padding:0.1em"> <a href="/web" title="Als Perlprogrammierer entwickelte ich in den Jahren 1997 bis heute ungezählte Webanwendungen und Perl-Scripts.">Web</a> </li>
     
        <li style="display:inline; padding:0.1em"> <a href="/demo" title="Testen Sie hier einige von mir programmierte Webanwendungen">Demo's</a> </li>
     
        <li style="display:inline; padding:0.1em"> <a href="/geosun.html" title="Die Anwendung ermittelt Ihren geografischen Standort und zeigt Sonnenaufgang/Sonnenuntergang">Sunrise</a> </li>
     
        <li style="display:inline; padding:0.1em"> <a href="/jobs.heise.de" title="Über jobs.heise.de RSS Feed publizierte IT-Stellenangebote">Jobs</a> </li>
     
        <li style="display:inline; padding:0.1em"> <a href="/blog" title="Eigentlich sollte das mein Blog werden. Aber soviel habe ich nun auch wieder nicht zu sagen.">Blog</a> </li>
     
        <li style="display:inline; padding:0.1em"> <a href="/wetter.de" title="Feed: Ein Service von www.wetter.com">Wetter</a> </li>
     
        <li style="display:inline; padding:0.1em"> <a href="/eu.html" title="Wer die Gegenwart verstehen will, sollte die richtigen Schlüsse aus der Geschichte ziehen">Euro</a> </li>
     
        <li style="display:inline; padding:0.1em"> <a href="/irc.html" title="Chat über Websocket, die innovative Technik!">Chat</a> </li>
    
    </ul>
</div>

Auch diesen Inhalt gibt es in identischer Form doppelt.

Und warum Inline-Styles?

LLAP 🖖

[Matthias Apsel]

Hallo Gunnar Bittersmann,

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Gibts das auch auf deutsch?

die Grundregeln zugänglicher Webseiten

Bis demnächst
Matthias

[Orlok]

Hallo Gunnar

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Kannte den Artikel zwar schon, aber ich habe die Gelegenheit genutzt, ihn mir nochmals durchzulesen, und ich kann mich deiner Einschätzung nur anschließen, dass der Artikel sehr lesenswert und darum zu empfehlen ist. Allerdings ist mir beim Lesen etwas aufgefallen, was man in diesem Zusammenhang fast immer liest, und zu dem ich aus eben diesem Grund noch etwas anmerken möchte.

If, on the other hand, an image is purely decorative, its alternative text consists of an empty string “”. That is simply alt=””, two consecutive quotes.

Wenn man das Attribut alt auf den leeren String setzen will, dann ist es nicht zwingend erforderlich dies ausdrücklich zu tun, wie in dem Zitat und so ziemlich jeder anderen Quelle, die ich zu dem Thema bislang gelesen habe.

<body>
  <img id="picture" src="decorative.jpg" alt>
  <script>

    const image = document.images.picture;
    console.log(image.hasAttribute('alt')); // true

    const value = image.alt;
    console.log(typeof value === 'string' && value.length === 0); // true

  </script>
</body>

Wird nämlich nur der Attributname notiert, dann wird der Wert automatisch auf den leeren String gesetzt, eine explizite Angabe dieses Wertes ist also überflüssig, was dem Standardverhalten für diese Variante der Notierung von Attributen entspricht und wohl auch von allen Browsern so umgesetzt wird.

Das ist natürlich nur eine unwesentliche Kleinigkeit, aber ich wollte es mal erwähnt haben. ;-)

Viele Grüße,

Orlok

[Matthias Apsel]

Hallo Orlok,

Wenn man das Attribut alt auf den leeren String setzen will, dann ist es nicht zwingend erforderlich dies ausdrücklich zu tun, wie in dem Zitat und so ziemlich jeder anderen Quelle, die ich zu dem Thema bislang gelesen habe.

Solange man nicht xhtml schreibt, scheint das tatsächlich möglich zu sein. Und das sieht auch der Validator so.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Orlok

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Kannte den Artikel zwar schon

Ach ja, ich hatte den ja auch selbst schon mal verlinkt.

Kann man aber auch nicht oft genug machen. Wie Ian Devlin so treffend sagte: „The 11 in a11y stands 
for the number of times 
you have to tell developers 
that accessibility is important.“

Wird nämlich nur der Attributname notiert, dann wird der Wert automatisch auf den leeren String gesetzt, eine explizite Angabe dieses Wertes ist also überflüssig

Ich sehe immer noch Vorteile darin, polyglottes HTML (also XML-Syntax) zu schreiben. Also Attribute (auch boolesche) immer mit Wert. Und auf Groß-/Kleinschreibung achten: <!DOCTYPE html>

LLAP 🖖

[marctrix]

Hej zusammen,

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Leider ist es damit aber nicht getan. Ich mag Marco sehr gerne, habe ihn auch hierher eingeladen, weil ich ihn sehr schätze und er ist ja nicht ohne Grund ständig in Sachen Barrierefreiheit unterwegs.

Aber der Artikel von Marco, gibt doch einen recht speziellen Blickwinkel wieder. Was er beschreibt sind die Basics für blinde Menschen.

Er hat keine Probleme mit zu kleinen Schaltflächen, weil er - selbst wenn er einen Tremor hätte (starkes Zittern) - Funktionen mit Tasten auslöst und nicht mit einem Mausklick.

Ihn muss auch roter Text auf grünem Grund nicht stören, denn er wird ihm immer klar und deutlich vorgelesen, während Menschen mit einer Rot-Grün-Schwäche daran verzweifeln. Menüs, die sich nervös ein und ausblenden, wenn man die Maus nicht ruhig genug bewegt? Für Marco ebenfalls kein Problem! Schriftvergößerung, Seitenzoom, angemessene Sprache? Marco ist überdurchschnittlich intelligent und wird niemals zoomen - alles keine Barrieren für ihn, für andere aber durchaus.

Fehlende Audiodeskription? Marco arbeitet ausschließlich über sein Gehör, für ihn muss Audio nicht transskribiert werden...

Darum: solche Listen sind IMMER mit Vorsicht zu genießen und sie reichen niemals, um eine Seite barrierefrei zu bekommen. Nicht einmal die Basics sind für Gehörlose oder Menschen mit motorischen Einschränkungen erfüllt, wenn man alles beachtet, was dieser Artikel beschreibt. Für Blinde wird eine Seite grundsätzlich bedienbar, wenn man sich an das hält, was Marco schreibt. Aber Blinde sind eben auch besonders leicht zu unterstützen. Man kommt nicht in Konflikt mit Designvorgaben (Styleguides, Corporate Design usw) oder vielen anderen Vorgaben aus dem echten Leben.

Provokant gesagt: Blinde brauchen lienearisierbare Texte und für alle Bilder und Videos eine textliche Entsprechung. Darüber hinaus noch eine vernünftige Struktur (Überschriften, Tabellen, Semantik) - also eigentlich nur sauberes, möglichst valides HTML, das bestimmungsgemäß eingesetzt wird und sonst gar nichts!

Für Menschen mit Lese-Rechtschreibschwäche, Konzentrationsschwierigkeiten, photosensitiver Epilepsie (die Liste lässt sich fast beliebig fortsetzen) hätte man mit den im Artikel von Marco beschriebenen Maßnahmen nichts oder nicht viel getan. Außer: sauberes HTML ist immer eine gute Grundlage für die eigentliche Arbeit, die danach aber erst beginnt.

Die WCAG sind nicht umsonst so umfangreich. Es führt halt kein Weg um sie herum. Alles andere kann bestenfalls einen ersten Einstieg erleichtern - womit solche Artikel ihre Daseinsberechtigung haben, denn die WCAG sind schon aufgrund ihres Umfanges für viele Menschen abschreckend. Wenn man Barrierefreiheit aber erst einmal beherrscht und von Beginn an in einem Projekt berücksichtigt, ist der Aufwand in der Umsetzung durchaus überschaubar. Für die meisten Seiten reicht einem erfahrenen, ohnehin sauber codendem Entwickler ein zusätzlicher Aufwand von etwa 10%.

Übrigens hat Marco in seinem Blog nicht viele Anpassungen gemacht. Standard-Wordpress mit Standard-Theme. Das ist schon ein Großteil der Miete!

Marc

[marctrix]

Post Scriptum:

Ja, Marco geht am Rande auf Farbenblindheit ein, auch auf Kontraste und Leseschwäche. Ich habe das gelesen, aber für die müsste es jeweils eine ähnlich lange Liste geben, wie dieser insbesondere für Blinde relevante Artikel. Aber der Hinweis auf das Buch von Jan und Kerstin ist natürlich alleine schon Gold wert! - Das sollte man wirklich kennen!

[kerstin]

Hallo,

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Leider ist es damit aber nicht getan.

Das sagt er aber ja auch nicht. :-)

Er hat keine Probleme mit zu kleinen Schaltflächen, weil er - selbst wenn er einen Tremor hätte (starkes Zittern) - Funktionen mit Tasten auslöst und nicht mit einem Mausklick.

Kann man allerdings auch schwer reliabel festlegen. Wie klein ist "zu klein"? Das kann für jeden was anderes bedeuten.

Darum: solche Listen sind IMMER mit Vorsicht zu genießen und sie reichen niemals, um eine Seite barrierefrei zu bekommen. Nicht einmal die Basics sind für Gehörlose oder Menschen mit motorischen Einschränkungen erfüllt, wenn man alles beachtet, was dieser Artikel beschreibt. Für Blinde wird eine Seite grundsätzlich bedienbar, wenn man sich an das hält, was Marco schreibt. Aber Blinde sind eben auch besonders leicht zu unterstützen. Man kommt nicht in Konflikt mit Designvorgaben (Styleguides, Corporate Design usw) oder vielen anderen Vorgaben aus dem echten Leben.

Natürlich muss man solche Listen immer vorsichtig betrachten. Ich denke aber, dass das außer Frage steht. Und mal ehrlich: Wenn sich alle daran halten würden, dann wäre ja schon sehr viel gewonnen.

Die WCAG sind nicht umsonst so umfangreich. Es führt halt kein Weg um sie herum. Alles andere kann bestenfalls einen ersten Einstieg erleichtern - womit solche Artikel ihre Daseinsberechtigung haben, denn die WCAG sind schon aufgrund ihres Umfanges für viele Menschen abschreckend.

Leider wird aber regelmäßig nicht so ganz richtig kolportiert, was die WCAG eigentlich sind. Die WCAG selber sind nur die normativen Texte. Ich hab die Recommendation nie gedruckt, dürfte aber 30 Seiten nicht übersteigen. Die Techniken und die Understanding-Dokumente sind nur Supporting Documents.

[marctrix]

Hej kerstin,

Er hat keine Probleme mit zu kleinen Schaltflächen, weil er - selbst wenn er einen Tremor hätte (starkes Zittern) - Funktionen mit Tasten auslöst und nicht mit einem Mausklick.

Kann man allerdings auch schwer reliabel festlegen. Wie klein ist "zu klein"? Das kann für jeden was anderes bedeuten.

Hier geht es ja nicht um Testmethoden ;-)

Natürlich muss man solche Listen immer vorsichtig betrachten. Ich denke aber, dass das außer Frage steht. Und mal ehrlich: Wenn sich alle daran halten würden, dann wäre ja schon sehr viel gewonnen.

Das schon - dagegen habe ich wiederum nichts gesagt. ;-)

Marco hat mit allem recht, was er da geschrieben hat. Ich habe nur darauf hingewiesen, dass die Liste stark die Bedürfnisse von Blinden Menschen in den Fokus rückt und andere Behinderungen weitgehend außen vor lässt.

Die WCAG sind nicht umsonst so umfangreich. Es führt halt kein Weg um sie herum. Alles andere kann bestenfalls einen ersten Einstieg erleichtern - womit solche Artikel ihre Daseinsberechtigung haben, denn die WCAG sind schon aufgrund ihres Umfanges für viele Menschen abschreckend.

Leider wird aber regelmäßig nicht so ganz richtig kolportiert, was die WCAG eigentlich sind. Die WCAG selber sind nur die normativen Texte. Ich hab die Recommendation nie gedruckt, dürfte aber 30 Seiten nicht übersteigen. Die Techniken und die Understanding-Dokumente sind nur Supporting Documents.

Jetzt sag ich mal das böse Wort: so wie die BITV ;-)

Es ist ja einer der zu Recht immer wieder (auch von mir) vorgebrachten Kritikpunkte an der BITV, dass die deutsche Verordnung zu viel Ermessensspielraum zum Beispiel bei der Gestaltung von Tests wie dem von BIK zulässt, WEIL ihr die erläuternden Dokumente fehlen.

Die Macher vom BIK-Test können sich in ihrer Argumentation ja immer auf den Standpunkt stellen, dass Argumente gegen den Test nciht aus der BITV abgeleitet werden können. Ich habe diese Diskussionen ja miterlebt...

Man muss die WCAG ja nicht komplett als Anfänger auf einmal lesen. Du hast das nicht zitiert, aber ich habe ja schon gesagt, dass solche Artikel wie der von Marco (gibt ja viele ähnliche) ihre Daseinsberechtigung haben, weil sie einen ersten einfachen Einstieg in die Welt der BF ermöglichen.

Hoffen wir, dass er viele sensibilisiert für die Bedürfnisse von Menschen mit Behinderungen. Und im Übrigen ist er ja auch ein Plädoyer für semantisch sauberes, korrekt strukturiertes HTML!

Marc

[kerstin]

Er hat keine Probleme mit zu kleinen Schaltflächen, weil er - selbst wenn er einen Tremor hätte (starkes Zittern) - Funktionen mit Tasten auslöst und nicht mit einem Mausklick.

Kann man allerdings auch schwer reliabel festlegen. Wie klein ist "zu klein"? Das kann für jeden was anderes bedeuten.

Hier geht es ja nicht um Testmethoden ;-)

Spielt aber auch bei Umsetzung eine Rolle.

Die WCAG sind nicht umsonst so umfangreich. Es führt halt kein Weg um sie herum. Alles andere kann bestenfalls einen ersten Einstieg erleichtern - womit solche Artikel ihre Daseinsberechtigung haben, denn die WCAG sind schon aufgrund ihres Umfanges für viele Menschen abschreckend.

Leider wird aber regelmäßig nicht so ganz richtig kolportiert, was die WCAG eigentlich sind. Die WCAG selber sind nur die normativen Texte. Ich hab die Recommendation nie gedruckt, dürfte aber 30 Seiten nicht übersteigen. Die Techniken und die Understanding-Dokumente sind nur Supporting Documents.

Jetzt sag ich mal das böse Wort: so wie die BITV ;-)

Jehova?! ;-) Da wollte ich gar nicht von anfangen.

Generell ist diese ganze Sache mit dem angeblichen Umfang der WCAG ein ziemliches Missverständnis.

Mit dem Umfang von 30 gedruckten Seiten lag ich übrigens gar nicht so falsch - gerade mal geschaut. Es sind 28 Seiten und das schon inkl. Einleitung und Anhang B.

Du hast das nicht zitiert, aber ich habe ja schon gesagt, dass solche Artikel wie der von Marco (gibt ja viele ähnliche) ihre Daseinsberechtigung haben, weil sie einen ersten einfachen Einstieg in die Welt der BF ermöglichen.

Dann sind wir uns aber einig.

[marctrix]

Hej kerstin,

Er hat keine Probleme mit zu kleinen Schaltflächen, weil er - selbst wenn er einen Tremor hätte (starkes Zittern) - Funktionen mit Tasten auslöst und nicht mit einem Mausklick.

Kann man allerdings auch schwer reliabel festlegen. Wie klein ist "zu klein"? Das kann für jeden was anderes bedeuten.

Hier geht es ja nicht um Testmethoden ;-)

Spielt aber auch bei Umsetzung eine Rolle.

In einem Artikel mit dem Grundtenor "Hey Leute, wodrauf ihr mal achten solltet" wäre ein Hinweis auf große Buttons aber möglich gewesen, ohne gleich auf ergonomische Studien und nachmessbare Verfahren einzugehen... ;-)

Die WCAG sind nicht umsonst so umfangreich. Es führt halt kein Weg um sie herum. Alles andere kann bestenfalls einen ersten Einstieg erleichtern - womit solche Artikel ihre Daseinsberechtigung haben, denn die WCAG sind schon aufgrund ihres Umfanges für viele Menschen abschreckend.

Leider wird aber regelmäßig nicht so ganz richtig kolportiert, was die WCAG eigentlich sind. Die WCAG selber sind nur die normativen Texte. Ich hab die Recommendation nie gedruckt, dürfte aber 30 Seiten nicht übersteigen. Die Techniken und die Understanding-Dokumente sind nur Supporting Documents.

Jetzt sag ich mal das böse Wort: so wie die BITV ;-)

Jehova?! ;-) Da wollte ich gar nicht von anfangen.

Ging mir nur um den Umfang...

Generell ist diese ganze Sache mit dem angeblichen Umfang der WCAG ein ziemliches Missverständnis.

Mit dem Umfang von 30 gedruckten Seiten lag ich übrigens gar nicht so falsch - gerade mal geschaut. Es sind 28 Seiten und das schon inkl. Einleitung und Anhang B.

Macht auf jeden Fall mal Sinn darauf hinzuweisen, dass das eigentliche Dokument nicht mehrere hundert Seiten umfasst. Aber ehrlich gesagt, obwohl ich bereits seit der WCAG 1 dabei bin: ohne die erläuternden Dokumente hätte ich manches in der WCAG 2.0 nicht begriffen. Allein zu Wissen, was assistive Technologien sind, gelingt wohl kaum, wenn man von BF noch nichts gehört hat und sich nur die WCAG 2.0 durchliest...

Gruß,

Marc

[marctrix]

Hej kerstin,

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Leider ist es damit aber nicht getan.

Das sagt er aber ja auch nicht. :-)

Die Gefahr ist aber, dass jemand das denken könnte. Menschen lieben einfache Handlungsanweisungen. Du wirst sicher auch ständig nach einer Checkliste für BF gefragt. Gibt es aber nicht. Insofern sind solche "Basics" immer gefährlich, weil sie dazu verleiten können, zu denken, man habe jetzt eine grundlegend barriefreie Webseite. Das gilt im vorliegenden Fall aber tatsächlich nur für Blinde und Bf ist eben mehr.

Man kann alles machen, was Marco geschrieben hat und trotzdem eine komplett unzugängliche und unbenutzbare Webseite für Sehende bauen...

Ich fände es schön, wenn Marcos Artikel neugierig macht auf BF und die Leute dann das Buch von Frau Probiesch und Herrn Hellbusch kaufen. Dann hat sich der Artikel IMHO gelohnt!

Du sagst ja selber immer (zu Recht!): es geht nicht darum irgendwelche Listen abzuarbeiten. Man muss die Bedürfnisse von Menschen mit Behinderungen verstehen, wenn man Webseiten für alle bauen möchte!

Marc

[kerstin]

Marco Zehe hat Grundlegendes zusammengeschrieben: The web accessibility basics

Leider ist es damit aber nicht getan.

Das sagt er aber ja auch nicht. :-)

Die Gefahr ist aber, dass jemand das denken könnte. Menschen lieben einfache Handlungsanweisungen. Du wirst sicher auch ständig nach einer Checkliste für BF gefragt. Gibt es aber nicht. Insofern sind solche "Basics" immer gefährlich, weil sie dazu verleiten können, zu denken, man habe jetzt eine grundlegend barriefreie Webseite. Das gilt im vorliegenden Fall aber tatsächlich nur für Blinde und Bf ist eben mehr.

Es sind schon nicht nur Aspekte der Barrierefreiheit für Blinde dabei. Ich finde aber auch, dass wenn es um Ergänzungen geht hier nicht der richtige Ort ist, sondern im Kommentarbereich des Blogposts selber. Da ja auch dort am Ende steht: "and if there is something I missed that you think should belong in this collection, feel free to also let me know, and I’ll add it!"

[marctrix]

Hej kerstin,

Es sind schon nicht nur Aspekte der Barrierefreiheit für Blinde dabei.

Ich bin auch auf einige eingegangen. Ich bleibe aber dabei, dass in dem Blogpost die Belange von blinden Menschen schwerpunktmäßig behandelt werden (was ja auch ok ist, es sollte nur klar gemacht werden).

Ich finde aber auch, dass wenn es um Ergänzungen geht hier nicht der richtige Ort ist, sondern im Kommentarbereich des Blogposts selber.

Es geht mir gar nicht darum zu ergänzen, sondern nur darum auf den obigen Punkt hinzuweisen...

Da ja auch dort am Ende steht: "and if there is something I missed that you think should belong in this collection, feel free to also let me know, and I’ll add it!"

Habe ich auch überlegt. Aber wenn man den Text weiter ergänzt (er ist mit den verlinkten Inhalten und den Kommentaren vermutlich schon fast so lang wie die WCAG), ist die Intention die wichtigsten Aspekte der BF kurz zusammenzufassen auch futsch.

Marc

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Und ansehen, wie Léonie Watson auch für Blinde benutzbare toggle tips und tab panels baut: Developer's guide to accessibility mechanics.

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

Und ansehen, wie Léonie Watson auch für Blinde benutzbare toggle tips und tab panels baut: Developer's guide to accessibility mechanics.

aha, und für Links (lies "Hyperlinks") verwendet sie dann kein <a href="#">link</a>, sondern <span id="link" data-link="http://tink.uk">Tink UK</span>, welches sie dann mit JavaScript und allerlei Attributen anreichert. Warum nimmt sie nicht das, was in HTML bereits dafür vorgesehen ist? Warum baut sie das aufwendig nach?

Da will ich dann von ihr überhaupt nicht mehr wissen, wie sie Tabs realisiert. Egal, ob die besonders zugänglich sind, oder nicht.

Und darauf hast Du nun verlinkt. Findest Du das gut? Ausgerechnet Du, der Du doch (mit Recht!) auf semantisches HTML pochst und <button> als "von Natur aus interaktiv" bezeichnest?

Liebe Grüße,

Felix Riesterer.

[Gunnar Bittersmann]

@@Felix Riesterer

aha, und für Links (lies "Hyperlinks") verwendet sie dann kein <a href="#">link</a>, sondern <span id="link" data-link="http://tink.uk">Tink UK</span>, welches sie dann mit JavaScript und allerlei Attributen anreichert. Warum nimmt sie nicht das, was in HTML bereits dafür vorgesehen ist? Warum baut sie das aufwendig nach?

Um eben zu zeigen, wie aufwendig das wäre. Um zu sagen, dass man genau das nicht machen sollte, sondern das native a-Element verwenden.

Dazu bedarf es wohl keiner Extra-Folie während des Vortrags.

Ja, ich hatte (unschwer zu erkennen) Vortragsfolien verlinkt. Das sollte man im Kopf haben; die Aufarbeitung des Inhalts für andere Präsentationsformen sähe gewiss anders aus.

Da will ich dann von ihr überhaupt nicht mehr wissen, wie sie Tabs realisiert. Egal, ob die besonders zugänglich sind, oder nicht.

Klar, mit Ignoranz kommt man am besten durchs Leben.

LLAP 🖖

[Felix Riesterer]

Lieber Gunnar,

Klar, mit Ignoranz kommt man am besten durchs Leben.

schon vergessen? (Erinnerung)

Liebe Grüße,

Felix Riesterer.