Das leidige Thema Input[type=file]

[Camping_RIDER]

Aloha ;)

• verständlicher Aufbau der ganzen Site und einzelner Seiten, Navigation
• Texte und Daten gut strukturieren
• sninvolle Reihenfolge, Tastatur Bedienung
• Alternative Texte für Grafiken

Das alles ist nacktes HTML.

NEIN. Wie ich die Navigation aufbaue, wie ich Texte schreibe damit sie verständlich sind, welche Inhalte ich auswähle usw. ist Design Konzept und Content Produktion. Es wird erst am Ende im HTML umgesetzt. Das hab ich bereits geschrieben.

Jein. Ich denke ihr habt beide Recht. Natürlich ist das Design Konzept und Content Production, das erst nachher in HTML umgesetzt wird. Wenn man aber voraussetzt, dass HTML genutzt wird, wie es genutzt werden soll (was Gunnar imho annimmt), dann besteht auch "nacktes" HTML aus denselben Elementen des Design Konzept und Content Production. Immerhin ist HTML immer noch eine Markup Language, also ist nacktes HTML ein Term, den auch ich nur dann anwenden würde, wenn das Markup auch korrekt ist - und dazu gehört Design Konzept und Content Production. Alles, was diesen Ansprüchen nicht genügt, ist nicht nacktes HTML, sondern falsches Markup, also falsches HTML. Ich schätze aber, Nico, dass du genau das meintest, da du ja nicht nacktes HTML sondern nacktes, unbedarftes HTML schriebst.

Gunnar hat dich falsch verstanden, da er nur von nacktem, aber korrektem (in jeglichem Sinne, Korrektheit ≠ Syntax) HTML gesprochen hat, während du von nacktem, unbedarftem (also unkorrektem) HTML gesprochen hattest, und du hast Gunnar falsch verstanden, da du ihm nun widersprichst, obwohl Gunnar die ganze Zeit lang nur von nacktem, korrektem HTML gesprochen hast, du aber von nacktem, unkorrektem HTML ausgiengst.

Wenn man vernünftiges HTML schreibt, am besten ohne die Präsentation im Hinterkopf zu haben, Inhalte mit den entsprechenden HTML-Elementen auszeichnet, dann hat man schon sehr viel für Barrierefreiheit getan.

Ja, ca. 3 - 5 Prozent von dem was nötig ist um eine wirklich barrierefreie Site zu erstellen.

Ich gebe zu bedenken: Barrierefreiheit ist zumindest in meinen Augen immer nur relativ zu verstehen. Eine Seite oder eine konkrete Implementation ist barrierefreier als eine Andere. Absolute Barrierefreiheit ist erstens nie zu erreichen (denn jeder hat eine andere Form der "Barriere". Stell dir vor, jemand packt seinen Uraltrechner aus und möchte mit rein textbasiertem HTML 1.0 - Browser zugreifen. Diese Barriere wird niemand auflösen können) und zweitens nicht absolut messbar. Eine Aussage darüber, welchen Anteil an Barrierefreiheit dem Markup zukommt ist somit hinfällig und weckt in meinen Augen nur falsche Assoziationen (Neuling: "Ach, 3-5 Prozent, kann man ja vernachlässigen... Mach ich lieber die restlichen 95-97 Prozent..."). Jede mögliche erreichbare Barrierefreiheit ist damit wertvoll und erstrebenswert. Insbesondere ist es uncool, die Wichtigkeit von barrierefreiem Markup zu unterminieren, indem zu Hohe Maßstäbe angelegt werden (was ist schon "wirklich barrierefrei"...).

Ich würde dir da sogar wiedersprechen und behaupten, barrierefreies Markup ist das Wichtigste an der gesamten Barrierefreiheit. Denn das Markup bekommt tatsächlich jeder Nutzer, um es dann entsprechend seiner Notwendigkeiten zu verarbeiten. CSS, Javascript, Sprachausgabe... das alles sind Zusatzinhalte, die auf dem Markup aufbauen. Ein verhunztes Markup retten, können sie aber nicht. Dass es über das Markup hinaus vielleicht Dinge gibt, die die Barrierefreiheit eventuell noch viel stärker fördern, ist irrelevant. Denn barrierefreies Markup muss für alle diese Systeme die Basis sein, ist also in diesem Sinne notwendig, um barrierefrei zu entwickeln. Bitte an alle: Hört doch einfach auf, Dinge aufzuwiegen und zu bewerten ;) Jeder Beitrag hilft.

Grüße,

RIDER