nicht angemeldet
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