View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000176 | Main CAcert Website | website content | public | 2006-03-27 05:39 | 2006-08-16 04:18 |
Reporter | Sourcerer | Assigned To | Sourcerer | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | needs work | Resolution | open | ||
Summary | 0000176: Accessability | ||||
Description | Es gibt vom W3C die Richtlinien für Zugänglichkeit. Sind in den USA und auch in Deutschland für alle Webangebote, in denen öffentliche Gelder stecken auch verbindlich. Siehe "Barrierefreie Informationstechnik-Verordnung (BITV)" http://217.160.60.235/BGBL/bgbl1f/bgbl102s2654.pdf. Die CAcaert-Seiten verstossen gegen einen ordentlichen Schwung davon. Das geht los, dass jemand in die CSS Schriftgrößen von 92% hart reinkodiert. Sowas macht nicht nur Behinderten sondern auch vielen Erwachsenen Probleme. Beobachte mal in einer großen Firma, welche Bildschirmauflösungen viele Anwender fahren. Ich selber arbeite mit einem Macintosh bei 1600x1200 auf einem 20" Display, also nichts außergewöhnliches. Die im CSS-Style kodierte Schrift ist ohnehin sehr dünn und dann noch verkleinert. Selbst mit einer normalen Sehschärfe ist das anstrengend zu lesen. Macs haben andere Schriften und eine andere Font-Engine als Windows-Rechner. Die Bilder sich nicht mit ALT-Tags versehen, das Menü ist für Screenreader quasi unsichtbar. Zudem ist eine Anordnung auf der rechten Seite eher unüblich, normalerweise sind Navigationsleisten links. Die Überschriften sind keine Überschriften sondern Unterschriften. Die Client-Zertifikate-Seite z.B. bringt die Erklärung erst unter der Tabelle. D.h. jemand mit einem Screenreader darf sich die ganze Tabelle antuen, ohne daß er weiß, worum es geht. Es wird sie hinterher gleich noch mal hören müssen, wenn er denn dort hin wollte. Das Hervorheben von Pflichtfeldern mit (dazu noch recht blassen) Farben ist für Farbenblinde nicht zu gebrauchen. Ich habe einen Azubi in der Firma, der eine monochrome Invers-Darstellung mit 640*480 Punkten, vergrößerten Schriften auf einem 20" Display nutzt. Ob das Assurance-Formular überhaupt in einer Tabelle sinnvoll ist, ist fraglich. Aber das halt damit alles nichts zu tuen ! Jede normale GUI, egal ob Web oder nicht, sollte vermutliche Fehleingaben mit einer Sicherheitsabfrage abfangen. Jeder C-Compiler meckert if (a==1) an, da es in 99% der Fälle nicht das ist, was der Entwickler wollte. Da das Formular die anderen Daten wie Ort, Datum, ... etc aus dem letzten Formular übernimmt, aber das Punkte-Feld nicht, verstösst das Formular zusätzlich gegen die Erwartungshaltung der Anwender. Entweder übernimmt man gar keine Felder, oder man übernimmt alle. Der Butten "Gehe zur Startseite" geht tatsächlich zur Startseite, nur leider verschwindet das Menü dabei. Stattdessen wird einem wieder "Normales Login" angeboten, man hat also den Eindruck, daß man sich ausgeloggt hat. Stimmt aber nicht, ein "Zurück" im Browser zeigt, daß die Sitzung noch offen ist. Schwerer Fehler in der Benutzerführung ! Könnte (müsste man mal untersuchen, ist ein weit verbreiteter Fehler) auch ein schweres Sicherheitsproblem sein; der User macht den Browser zu, da er ja glaubt, sich abgemeldet zu haben, aber die Sitzung ist noch offen. | ||||
Tags | No tags attached. | ||||
Reviewed by | |||||
Test Instructions | |||||