nicht angemeldet
neuer Forenbereich usability / WAI notwendig
Hallo,
neue Rechtsverordnungen zum barrierefreien webdesign erfordern einen speziellen Bereich usability, da hier ca. 50 000 webmaster betroffen sind.
selfhtml sollte um die WAI-Checkliste ergänzt werden. Noch besser wäre selfwai ;-)
Ich erstelle z.B. gerade eine Datenbak für Formulare nach WAI - steht dann auch für selfwai zur Verfügung.
Denn:
Die praktische Umsetzung von Standard-Codes und WAI-Richtlinien gestaltet sich als schwierig. Ausser Netscape 7.0 bzw. Mozilla 1.1 spielt hier kaum ein Browser mit.
Benötigt werden Programmiersprachen übergreifende Tools in PHP,Perl,Phyton, Java (Applets,Servlets,Beans) , JavaScript 1.2 bis 1.5 bzw. DOM nach W3C, Flash, Shockwave, XML (!), XHTML, HTML (Netscape 4.0), HTML 4.0x, SMIL sowie anderen Seitenbeschreibungssprachen und interaktive Codes zum Gestalten von Boards,Foren,Gästebüchern, Umfragen z.B. BBCode.
Am besten geeignet scheint mir aber ein Projekt zu sein, das einen XML-Code gestaltet, der von serverseitgen Scripts geparst und browserspezifisch ausgegeben wird.
Die magelhafte Ausstattung bei den Providern stellt hierbei ein grosses Problem dar, und begründet Lösungen in JavaScript /DHTML; die JavaScript/DHTML-Lösungen alleine sind schon ein Mammut-Projekt und fehlerfrei für alle Browser kaum machbar.
In diesem Sinne allen WAI-Freunden gutes Gelingen.
< http://www.michelm.de/erste_seite401b.html />
Michaeö
-
Sup!
Ja klar, WAI!
Was ist das denn? Ich will doch nicht dumm sterben...
Es gibt übrigens Links im Internet!Gruesse,
Bio
-
Hallo,
Ja klar, WAI!
Was ist das denn? Ich will doch nicht dumm sterben...
Das hätte ich von _Dir_ nicht erwartet. Du bist doch sonst immer so "emotional", wenn es um Mozilla und die Einhaltung von Standards geht. Du kanntest das wirklich nicht?
<cite who="w3c-pfarrer">
Der Standard behüte und beschütze Dich,
Der Standard erhebe sein Angesicht über Dich,
Der Standard lasse sein Angesicht leuchten über Dich
Und sei Dir gnädig.
EOF
</cite>Grüße,
Christian
-
Sup!
Tjö, aber was ist das denn für ein Stil, einen Bereich für etwas zu fordern, was "WAI" heisst, und von dem wahrscheinlich 90% der Leute nicht wissen, was es ist? Und dann ohne Erklärung, ohne Link, so nach dem Motto "alles wissen was gemeint ist".
Das geht doch nicht... ;-)
Und ausserdem brauchen wir so einen Bereich nicht, denn wenn man seine Seite im Selfforum hat zerlegen lassen, kriegt man mehr Hinweise für WAI, als im Standard stehen ;-)
Gruesse,
Bio
-
Hallo Bio,
Tjö, aber was ist das denn für ein Stil, einen Bereich für etwas zu fordern, was "WAI" heisst, und von dem wahrscheinlich 90% der Leute nicht wissen, was es ist? Und dann ohne Erklärung, ohne Link, so nach dem Motto "alles wissen was gemeint ist".
Das geht doch nicht... ;-)
Du warst der einzige, der gefragt hat, d.h. deine 90% lösen sich in Luft auf. *scnr* ;-)
(ok, wenn man es richtig analysiert, warst Du der einzige, der sich getraut hat ...)
(folgendes Zitat herumgedreht, weil die Antworten so besser passen - hoffe Du nimmst mir das nicht übel)
denn wenn man seine Seite im Selfforum hat zerlegen lassen, kriegt man mehr Hinweise für WAI, als im Standard stehen ;-)
Full ACK.
Und ausserdem brauchen wir so einen Bereich nicht,
Wieso nicht? Vielleicht will es ja jemand von vornerein richtig[tm] machen? Immerhin haben wir *schauder* ASP.
Grüße,
Christian
-
Sup!
Problem ist ja, daß WAI eher eine Meta-Technik bzw. eine Ergänzung zu den verschiedenen Möglichkeiten der Realisierung einer Website mit HTML/XML oder HTML/XML-generierenden Technologien ist.
Und darum reicht IMHO HTML/XML locker aus.
Allerdings fände ich es okay, ASP gegen WAI zu tauschen ;-)
Und überhaupt, sicher arbeitet Stefan läääängst an Self 9, und I18N und WAI sind sowieso schon drin, so wie Franz im Genion-Netz.Gruesse,
Bio
-
Hallo,
Allerdings fände ich es okay, ASP gegen WAI zu tauschen ;-)
[X] Vote - meine Stimme hast Du.
Und überhaupt, sicher arbeitet Stefan läääängst an Self 9, und I18N und WAI sind sowieso schon drin
Dann wünsche ich ihm mal viel Spaß bei der Arbeit.
Grüße,
Christian
-
hi
Allerdings fände ich es okay, ASP gegen WAI zu tauschen ;-)
<troll>klar, wieso nicht - wer nutzt schon diese Schergensprache?
</troll>
...davon abgesehen fält das eh unter CGI und sowas wie Codefusion hat ja auch keine eigene Rubrik.Grüße aus Bleckede
Kai
-
-
-
hi
Und ausserdem brauchen wir so einen Bereich nicht, denn wenn man seine Seite im Selfforum hat zerlegen lassen, kriegt man mehr Hinweise für WAI, als im Standard stehen ;-)
ich denke, wenn man ein gewisses allgemeines Verständnis für Accessibility verbreitet, dann würde sich diese Arbeit erübrigen. Derzeit scheint ja ein Irrglaube verbreitet, dass Accessibility das gleiche ist, wie eine Seite in einen TXT-Datei umzuwandeln!
Grüße aus Bleckede
Kai
-
Hallo, Kai,
Und ausserdem brauchen wir so einen Bereich nicht, denn wenn man seine Seite im Selfforum hat zerlegen lassen, kriegt man mehr Hinweise für WAI, als im Standard stehen ;-)
ich denke, wenn man ein gewisses allgemeines Verständnis für Accessibility verbreitet, dann würde sich diese Arbeit erübrigen. Derzeit scheint ja ein Irrglaube verbreitet, dass Accessibility das gleiche ist, wie eine Seite in einen TXT-Datei umzuwandeln!
Was glaubtest du denn, warum intelligente Webdesigner[tm] bei "zugänglichen Textversionen" auf jegliches strukturierendes Markup verzichten?!
Aber jetzt einmal </ironie>: Textversionen sind bei einer geschmeidig degradierenden Grafikversion völlig unnötig, sofern Kontraste etc. bei der Grafikversion keine Probleme machen - was sie nicht machen dürfen, denn Zugänglichkeit hat per se nichts mit als diskriminierend als behindert titulierten Menschen zu tun, sondern es betrifft jeden, denn es beinhaltet viele Benutzbarkeitsaspekte, deshalb ist es Unsinn, eine schmucke, unbenutzbare Version für die Majorität zu erstellen und eine "Textversion" als Alibi für die "Behinderten". Eine streng WCAG-konforme Seite ist immer eine technisch, semantisch, optisch und inhaltlich hochwertige Seite - deshalb heißt es Webauthoring *für* *alle*.
Wenn man eine Zugänglichkeit von der Grafikversion nicht erreichen kann, soll man laut WCAG eine zugängliche Alternativversion anbieten, das heißt aber nicht, dass diese ungestylt sein muss oder nur aus div- oder p-Elementen bestehen darf, denn nicht nur spezielle "Behindertenwerkzeuge" enthalten die Fähigkeit, von einer Überschrift zur nächsten zu springen oder über einen accesskey zur Navigation zu springen o.ä.
Fazit: Textversionen sind eine schwachsinnige Erfindung von Webdesignern[tm], welche keine wirkliche Ahnung von Benutzbarkeit und Zugänglichkeit haben, was sich meist damit paart, dass sie generell keine Ahnung von Verfassen und Gestalten von Webseiten haben, weshalb im Endeffekt weder die sogenannte Textversion noch die Grafikversion zugänglich werden.
Hugh, ich habe gesprochen. ;)
Mathias.
-
-
-
-
hi
Die praktische Umsetzung von Standard-Codes und WAI-Richtlinien gestaltet sich als schwierig. Ausser Netscape 7.0 bzw. Mozilla 1.1 spielt hier kaum ein Browser mit.
und selbst da redet man manchmal gegen Wände, wenn man WAI als Argument _für_ eine zusätzliche Pref will!
Grüße aus Bleckede
Kai
-
Sup!
Wo soll ich voten? ;-)
Gruesse,
Bio
-
-
Hallo, Michael,
neue Rechtsverordnungen zum barrierefreien webdesign erfordern einen speziellen Bereich usability, da hier ca. 50 000 webmaster betroffen sind.
Ja, ich freue mich schon, wie die ganzen Pixelschubser hier andackeln und endlich umdenken müssen!!!1 ;-)
selfhtml sollte um die WAI-Checkliste ergänzt werden. Noch besser wäre selfwai ;-)
Hmm, momentan enthält Selfhtml durchaus viele Ansätze, welche man grob unter Benutzbarkeit/Ergonomie fassen könnte. Hier im Forum wird wie gesagt oft auf die WCAG hingewiesen, wenn auch indirekt. Das Problembewusstsein besteht auf jeden Fall, hier ist nahezu jeder davon überzeugt, dass der Benutzer/Leser/Kunde das Maß aller Dinge ist.
Ich erstelle z.B. gerade eine Datenbak für Formulare nach WAI - steht dann auch für selfwai zur Verfügung.
Brav mit label, title und alt arbeiten, und immer schön Vorbelegungen in die Formularfelder! :)
Die praktische Umsetzung von Standard-Codes und WAI-Richtlinien gestaltet sich als schwierig.
Wie meinst du das? Sicherlich muss man sein Denken noch einmal um genau 180 Grad drehen, aber wenn man die wichtigen Regeln verinnerlicht hat, achtet man bei neuen Seiten automatisch darauf... Was meintest du speziell?
Ausser Netscape 7.0 bzw. Mozilla 1.1 spielt hier kaum ein Browser mit.
Ich bitte um Erklärung, welche Defizite meintest du? Opera hat in manchen Bereichen noch ausgeprägtere Usability-Features.
Generell zielen die WCAG nich auf ein spezielles Browserfeature ab, wobei Sachen wie longdesc etc. tatsächlich nicht unterstützt werden, aber dafür gibt es längst etablierte Workarounds.Natürlich gibt es Richtlinien, welche mit "Until User Agents..." beginnen, selbige würde ich aber auch beachten, wenn die meisten Browser diese Benutzbarkeitsverbesserungen schon implementieren.
Außerdem gibt es ja die User Agent Accessibility Guidelines (http://www.w3.org/WAI/UA/UAAG10/, Candidate Recommendation/Last Call), die hoffentlich bald von den UA-Herstellern berücksichtigt werden.
Benötigt werden Programmiersprachen übergreifende Tools in PHP,Perl,Phyton, Java (Applets,Servlets,Beans)
Hm, mit Zugänglichkeit haben diese Techniken bzw. Tools für selbige nur indirekt etwas zu tun, sie sind nur Mittel zum Zweck. Beispielsweise kann man Sitemaps, breadcrumb trails, Suchscripte nur damit effizient realisieren, genauso mehrfach verzweigte Navigationen.
JavaScript 1.2 bis 1.5 bzw. DOM nach W3C
In wieweit hat das Auswirkungen auf die Barrierefreiheit? Es macht das Programmieren von optionalen Spielereien einfacher, das stimmt.
Flash, Shockwave
Jaa, ganz wichtig! Da tut sich momentan einiges bei Macromedia. Wie ich gelesen habe, gibt es auch Zusatzsoftware, welche Flash-Objekte zugänglich macht, selbst wenn keine Alternative angegeben ist.
XML (!)
Dafür gibt's die XML Accessibility Guidelines (http://www.w3.org/TR/xag, Working Draft). :)
XHTML, HTML (Netscape 4.0), HTML 4.0x,
Zugänglichkeit für den NS 4.x? Im Nebenthread habe ich den Sinn von Textversionen geleugnet, aber da es partout nicht möglich ist, ein CSS-Layout für den NS 4.x zu realisieren und somit eine Trennung von Markup und Styling unmöglich ist, sollte ich meine Meinung vielleicht noch einmal überdenken. :)
SMIL
Ist AFAIK von vornherein problemlos degradierbar (?). SVG dürften sich auch sehr einfach zugänglich gestalten lassen, das ist ihr Vorteil gegenüber proprietären Vektorgrafikformaten/-plugins.
sowie anderen Seitenbeschreibungssprachen
<besserwisser>TeX und PostScript sind bspw. Seitenbeschreibungssprachen, alles was auf SGML oder XML aufbaut nicht.</besserwisser> (Oder täusche ich mich?)
und interaktive Codes zum Gestalten von Boards,Foren,Gästebüchern, Umfragen z.B. BBCode.
Oh, über die Benutzbarkeit und Zugänglichkeit von Foren könnte man sicher viel diskutieren. Zumindest dieses hier ist relativ intuitiv bedienbar, und wenn ich das recht überblicke sind die phpBB-Menschen durchaus gewillt, ihr Forum zugänglicher zu gestalten. Gästebücher hingegen braucht sowieso niemand... ;)) Auf die meisten im Web vorhandenen Diskussionsysteme, Formular und Interfaces dürften sich die WCAG nachträglich anwenden lassen, wobei du zurecht eingebaute Zugänglichkeit forderst. Glücklicherweise verkauft heutzutage kein Unternehmen mehr unzugänglichen CMSse/Webapplikationen. Es würde einen Wettbewerbsnachteil bedeuten, wenn sie die Barrierefreiheit und Benutzbarkeit missachten würden.
Die neue Version 2 der WCAG (http://www.w3.org/TR/WCAG20/, Working Draft), welche die erste Version ergänzt, gibt auch Hinweise für die Zugänglichkeit von Webinhalten jenseits von HTML, daran dürften sich alle Webworker orientieren können.
Am besten geeignet scheint mir aber ein Projekt zu sein, das einen XML-Code gestaltet, der von serverseitgen Scripts geparst und browserspezifisch ausgegeben wird.
Das ist ohne Frage das Nonplusultra in Sachen Interoperabilität und ein riesiger Vorteil von XML gegenüber Seiten mit nur einem Template.
Die magelhafte Ausstattung bei den Providern stellt hierbei ein grosses Problem dar, und begründet Lösungen in JavaScript /DHTML; die JavaScript/DHTML-Lösungen alleine sind schon ein Mammut-Projekt und fehlerfrei für alle Browser kaum machbar.
Nee, JavaScript hilft dabei IMO nur wenig. CGI-fähiger Webspace ist heutzutage nicht teuer, außerdem sind JavaScript-Browserweichen immer mit Problemen verbunden.
In diesem Sinne allen WAI-Freunden gutes Gelingen.
Möge die Anzahl der WAI-Freunde steigen....
Hat der Link etwas zu sagen? Ich finde dahinter eine Hier klicken-Seite, absolut un-WCAG-ig. ;)
Grüße,
Mathias-
Hallo, Michael,
Brav mit label, title und alt arbeiten, und immer schön Vorbelegungen in die Formularfelder! :)
Da fängt es ja schon an: Netscape 4 schmiert ohne ersichtlichen Grund bei Einsatz von Label ab.
<NOLAYER><LABEL></LABEL></MOLAYER> macht wiederum Schierigkeiten bei anderen Browsern.Die praktische Umsetzung von Standard-Codes und WAI-Richtlinien gestaltet sich als schwierig.
Wie meinst du das? Sicherlich muss man sein Denken noch einmal um genau 180 Grad drehen, aber wenn man die wichtigen Regeln verinnerlicht hat, achtet man bei neuen Seiten automatisch darauf... Was meintest du speziell?
Ausser Netscape 7.0 bzw. Mozilla 1.1 spielt hier kaum ein Browser mit.
Ich bitte um Erklärung, welche Defizite meintest du? Opera hat in manchen Bereichen noch ausgeprägtere Usability-Features.
Generell zielen die WCAG nich auf ein spezielles Browserfeature ab, wobei Sachen wie longdesc etc. tatsächlich nicht unterstützt werden, aber dafür gibt es längst etablierte Workarounds.Es ist z.B. nicht möglich beim allseits beliebten IE CSS-Definitionen wie Focus und Hover einzusetzen. Da muss man auf DHTML zurückgreifen.
Code für NS 7 alleine 40kB, zu IE 6.0 kompatible 80kB usw. input:focus ist halt kürzer als in jedem Tag onfocus und onblur einzusetzen, z.B. onfocus=change_color(this,1,'#336699','#CCCCCC')"
onblur =change_color(this,0,'#CCCCCC',#336699')"
Abgesehen davon, dass man für Netscape 4 und andere ältere non-standard-Browser eigene Seiten erstellen muss, bläht sich doch ein WAI-konformer Code für mehrere Browser unnötig auf, sodass die Ladezeit selbst bei Modem 56k noch zu hoch ist.
Hier kann serverside scripting mit Client-Erkennung helfen,der dann die browser-spezifischen Tags und CSS einsetzt, weshalb das nicht unter einen Forenbereich HTML oder PHP sondern unter WAI fallen sollte.Das ist nur ein kleiner Einblick in die Problematik - deswegen wollte ich hier einen neuen Forenbereich vorschlagen.
Danke auf jeden Fall für Deine Anregungen - das hilft mir sicherlich ;-)
beid er URL fehlt /test/ sorry ! test ist test und nichts entgültiges.
< http://www.michelm.de/test/erste_seite401b.html />
Michael
-
Hallo, Michael.
Da fängt es ja schon an: Netscape 4 schmiert ohne ersichtlichen Grund bei Einsatz von Label ab.
<NOLAYER><LABEL></LABEL></MOLAYER> macht wiederum Schierigkeiten bei anderen Browsern.Krass, das ist tatsächlich sehr problematisch, das ist mir erst jetzt aufgefallen, NS4 crasht tatsächlich. Da werde ich einmal entsprechende Hinweise auf meine Seiten stellen.
Die praktische Umsetzung von Standard-Codes und WAI-Richtlinien gestaltet sich als schwierig.
Es ist z.B. nicht möglich beim allseits beliebten IE CSS-Definitionen wie Focus und Hover einzusetzen. Da muss man auf DHTML zurückgreifen.
Was hat das denn mit Zugänglichkeit zu tun? Es ist vielleicht eine Hilfe, dass ein selektiertes Eingabefeld optisch hervorgehoben wird, jedoch würde ich es nicht als obligat bezeichnen. Oder habe ich eine WCAG-Richtlinie bzgl. dessen vergessen?
Abgesehen davon, dass man für Netscape 4 und andere ältere non-standard-Browser eigene Seiten erstellen muss, bläht sich doch ein WAI-konformer Code für mehrere Browser unnötig auf, sodass die Ladezeit selbst bei Modem 56k noch zu hoch ist.
Was bedeutet WAI-konformer Code? Die WCAG schreiben eine Trennung von Inhalt ([X]HTML) und Präsentation (CSS) vor, und NS4 und übrigen alten Browsern liefert man ganz simpel ein minimales Stylesheet, siehe http://pixels.pixelpark.com/~koch/hide_css_from_browsers/ und http://aktuell.de.selfhtml.org/tippstricks/css/browserweiche/index.htm.
Hier kann serverside scripting mit Client-Erkennung helfen,der dann die browser-spezifischen Tags und CSS einsetzt, weshalb das nicht unter einen Forenbereich HTML oder PHP sondern unter WAI fallen sollte.
Das stimmt, es ist eine technikübergreifende, ganzheitliche Problematik.
Das Hervorheben von Formularfeldern ist mir momentan nicht so wichtig, dass ich eine DHTML-Lösung für alle Browser implementiere, ich benutze :focus und warte, bis es alle Browser unterstützen. Ich habe keine Lust, mir für ein eher minderwichtiges Grafikfeature einen abzubrechen, um es interoperabel zu programmieren.Das ist nur ein kleiner Einblick in die Problematik - deswegen wollte ich hier einen neuen Forenbereich vorschlagen.
Bisher habe ich einfach als Interimlösung "(Zugänglichkeit)" oder "(Barrierefreiheit)" oder "(WCAG)" in dem Threadtitel angegeben.
Oh, super, darf ich meckern? :)
<script type="text/javascript" src="fun_fontsize.js"></script>
Was bezweckt das? Für Fließtext darfst du keine Schriftgröße angeben, für Strukturelemente nur relative, diese Schriftgrößenwähler sind Bullshit. Ich lese Function New Media, das sind die Leute von einfach-fuer-alle.de, bei denen sieht ein besuchter Link aus wie ein normaler, und eine Pixelgenaue und zudem kleine Schriftgröße geben sie auch an.
FONT: bold 0.8em/120% Verdana, Tahoma,Arial, Helvetica, sans-serif;
Dese Notation kenne ich gar nicht, was denn nun, 0.8em oder 120%? Du *darfst* *auf* *keinen* *Fall* die Schriftgröße für Fließtext herunterskalieren! Ich weiß was du vorhast, aber du suchst font-size-adjust weil Verdana vergleichsweise groß ist, aber die Browser unterstützen diese Eigenschaft nicht, deswegen ist es unklug, mit 0.8em nachzuhelfen.
<fieldset class="head"><legend>Navigationshilfe Kapitel</legend>
fieldset und legend dürften nur für ein *Formular* benutzt werden.
[<A tabindex=8 accesskey=8 href="#8" title="Die direkte Zugänglichkeit der in Internet-Angeboten eingebetteten Benutzerschnittstellen ist sicherzustellen.">8</a>]
Bitte schließe die Attributwerte in Anführungsstriche ein (attribut="wert" ). Zudem schreibe bitte *striktes* HTML (4.01 Strict oder XHTML 1.0 Strict). Außerdem musst du nicht jeden Link einklammern, du musst ihn nur durch nicht zu einem Link gehörende Zeichen von dem nächsten Link trennen (<a>murks</a> | <a>purks</a>).
<script type="text/javascript">
//<![CDATA[
...
//]]>
</script>In HTML 4.x ist der script-Elementinhalt per se ein CDATA-Bereich, so eine Syntax macht nur in XHTML Sinn. Über diesen seltsamen fun_fontSize-Quark habe ich schon etwas gesagt.
<td class="head" height="24" colspan="3">Checkliste für barrierefreies Webdesign</td>
Keine Tabellenzelle! Das gehört in ein caption-Element oder mit etwas mehr Erläuterungen auch in das summary-Attribut des table-Elements.
<td class="Zelle" colspan="3">Die Checkliste orientiert sich an der Anlage der Barrierefreie Informationstechnik-Verordnung. Kursiv dargestellte Anforderungen entsprechen der Priorität 2 der Verordnung und sollen für zentrale Navigations- und Einstiegsseiten, insbesondere Portale, beachtet werden.</td>
Das gehört auch nicht in eine Zelle, eher in die summary oder als Erklärung *vor* die Tabelle, aber keinesfalls in die Tabelle, denn es hat nichts mit den Tabellendaten zu tun.
<td class="Zelle" style="width: 40px;"><strong><br>
</strong></td>
<td class="Zelle"><br>
</td>
<td class="Zelle"><br>
</td>Pfui! Schon wieder ein grober Fehler. :) Abstände macht man *keinesfalls* mit leeren Tabellenzellen, das ist Markupmissbrauch und ganz und gar nicht WCAG-konform. Hier musst du mit padding arbeiten.
<td class="Zelle"><strong><br></strong></td>
<td class="Zelle"><strong>Anforderungen</strong></td>
<td class="Zelle"><strong>Praxistipps für HTML und DHTML</strong></td>Du musst Kopfzeilen einer Tabelle mit dem thead-Element kennzeichnen und *darfst* *nicht* td-Elemente benutzen, sondern musst th-Elemente benutzen. Außerdem gehört in die erste Spalte die Erklärung "Nummer der Richtlinie" oder so etwas.
fieldset und legend missbrauchst du scheinbar öfters.
tabindex=270 accesskey=0
Das benutzt du dutzende Male.
Die übrigen Tabellen haben ebenfalls die genannten Probleme.
Grüße,
Mathias
-
-