„Erfolgsrezept TYPO3“: Deutscher Apotheker Verlag setzt auf das Open-Source-CMS
![Die Startseite von apotheken.de rückt die umfangreiche Suche und den redaktionellen Content in den Mittelpunkt. Die Startseite von apotheken.de rückt die umfangreiche Suche und den redaktionellen Content in den Mittelpunkt.](https://images.t3n.de/magazin/wp-content/uploads/2009/09/dms_579ab129fe7bc27cd07928439a9719e2.jpg?class=content)
Die Startseite von apotheken.de rückt die umfangreiche Suche und den redaktionellen Content in den Mittelpunkt.
Die Website umfasst alle wichtigen Informationen von rund 21.500 Apotheken und mehr als 6.000 Fachartikel. Die komplexen Suchabfragen nutzen dabei eine Geokodierung, um den Nutzern zielgenaue Daten liefern zu können. Mit dem Relaunch im Juni 2009 wurde das Portal nicht nur auf TYPO3 umgestellt, sondern auch mit redaktionellen Inhalten aus einem zweiten Internetportal erweitert. Hierfür hat die umsetzende Münchner Internetagentur Cross Content Media komplexe XML-Parser entwickelt, die die externen Seiteninhalte samt Querverlinkungen und Spezialformaten in die tt_news-Architektur überspielen.
Zielsetzung
Bereits das alte Portal hatte einen enormen Umfang an kleinen versteckten Features, die auch im neuen Portal untergebracht werden sollten. Als Problem erwiesen sich die gewachsene Struktur und dadurch eine für die Nutzer nicht optimale Usability. Der technische Projektleiter Jörn Steinhauer (9zwanzig Consulting) nannte daher „einen Mehrwert für den Nutzer durch eine verbesserte Usability“ als erklärtes Ziel in der ersten Vorbesprechung. Der Nutzer sollte schnell und mit wenigen Klicks zu seinem Ziel gelangen.
Gleichzeitig entschloss man sich, den Magazin-Bereich, in dem aktuelle Themen rund um das Thema „Gesundheit“ präsentiert werden, weiter auszubauen und in den Mittelpunkt zu stellen. Da auch die Architektur durch den Einbau komplexer neuer Features angepasst werden musste, entschied man sich für einen Komplettrelaunch.
Nutzerzentrierter Designansatz
Das komplett überarbeitete Design präsentiert das Wichtigste an erster Stelle. Der Besucher kommt mit dem Ziel, Apotheken zu finden, also findet er diese auch an erster Stelle: Direkt unter dem Header oben im Menü und zentral links oben in der Seitenleiste sind Schnellsuchen und Links zu den Detailsuchen platziert. Dazu noch eine Volltextsuche über alle medizinischen Fachartikel samt sämtlicher in Deutschland existierenden rund 21.500 Apotheken.
Als Portal muss apotheken.de natürlich Traffic generieren. Aus diesem Grund sind die aktuellen News, um die sich ein fünfköpfiges Redaktionsteam täglich kümmert, ebenfalls zentral auf der Startseite platziert. Um möglichst viele bebilderte News platzsparend unterzubringen, wurde für „tt_news“ eine Akkordeon-Ansicht entwickelt, bei der zwei News komplett zu sehen sind und die restlichen erst bei einem Klick auf die Überschrift sichtbar werden.
Echter Mehrwert durch sinnvolle Funktionen
Notdienst, Serviceapotheken und Arzneimittelbestellung: Wenn ein Besucher wissen will, welche Apotheke in seiner Nähe zuständig ist, hilft ihm der Suchbereich auf der Startseite. Ein kleines JavaScript tauscht bei einem Mouseover die Beschreibung gegen ein Suchformular aus, in das man Postleitzahl oder Ort eingeben kann. Dieses Quicksearchwidget bietet alle Suchmöglichkeiten mit Standardeinstellungen direkt auf der Startseite an, alle Detailsuchen sind über einen Klick in der Hauptnavigation erreichbar.
Nutzt man eine Suche auf der Startseite, blendet sich ein Fenster über den Inhaltsbereich ein, das die Suchergebnisse übersichtlich darstellt. Die Auflistung bietet nicht nur Adressinformationen, sondern auch weitere Serviceinformationen der Apotheke, etwa eine Karte, die den Standort der Apotheke zeigt, Infos zu Serviceleistungen wie Diabetes- oder Homöopathie-Beratung und Links zu Formularen für den Arzneibringdienst und die Arzneimittelvorbestellung. Ist ein Rezept nicht eindeutig lesbar, hilft die Medikamentensuche bei der Suche nach dem richtigen Namen.
Eine Umkreis-Dropdown-Liste grenzt den Suchradius ein, zudem kann man die Suchtreffer als PDF herunterladen. Diese Funktion ist bei Apothekern sehr beliebt und wird häufig genutzt, um einen Notdienstplan für den eigenen Umkreis auszudrucken.
Ebenfalls auf der Startseite untergebracht: der Diagnosefinder. Mit diesem Tool können Patienten typische Symptome noch vor dem Gang zum Arzt per Selbstdiagnose recherchieren. Anhand von Angaben wie Geschlecht, betroffener Körperregion und Symptom liefert der Diagnosefinder mögliche Diagnosen und gibt Tipps zum weiteren Vorgehen. Das Tool ersetzt hierbei natürlich keinen Arzt, kann aber erste Anhaltspunkte liefern.
![Die Suche liefert nicht nur eine Liste aller passenden Apotheken, sondern führt auch Detailinformationen mit auf. Die Suche liefert nicht nur eine Liste aller passenden Apotheken, sondern führt auch Detailinformationen mit auf.](https://images.t3n.de/magazin/wp-content/uploads/2009/09/dms_481de86cba04c7ca972704e26665e07f.jpg?class=content)
Die Suche liefert nicht nur eine Liste aller passenden Apotheken, sondern führt auch Detailinformationen mit auf.
Überzeugende Performance
Pro Tag besuchen einige Tausend Ratsuchende apotheken.de. Um diesen die rund 30.000 Seiten in einer überzeugenden Performance ausliefern zu können, setzen die Entwickler auf die TYPO3-Extension „toi_file_cache“. Diese cached komplette Seiten im Filesystem des Servers, wodurch eine immense Geschwindigkeitssteigerung gegenüber dem Standard-Cache von TYPO3 erreicht wird.
Die 30.000 Seiten müssen zudem auch mit der Suche schnell und einfach gefunden werden. Die Seiten speisen sich zum Teil aus TYPO3, aber auch aus zwei weiteren Datenbanken. Die in TYPO3 integrierte Suche „Indexed Search“ stößt bei diesen Zahlen und der Komplexität der Suchanfragen sehr schnell an ihre Grenzen. Daher entschied sich das Projektteam für die neue TYPO3-Suchengine EXT:solr, die derzeit von der Frankfurter TYPO3-Agentur d.k.d entwickelt wird und zu einem späteren Zeitpunkt auch im TER zur freien Nutzung bereitgestellt werden soll. EXT:solr setzt auf Apache Solr [1], ein Open-Source-Suchserver, der auf Lucene basiert (siehe Artikel „Schneller suchen mit Lucene“ ab Seite 124). Mit XML/HTTP und JSON-APIs, Treffer-Highlighting, Facettensuche, Caching, Replikation, einer Webadministrationsschnittstelle sowie vielen weiteren Features bietet diese Extension ein professionelles Werkzeug für umfangreiche Suchanfragen. Solr benötigt für den Betrieb einen Java-Servlet-Container, beispielsweise Tomcat.
Solr hat einige Tücken, die es bei der Installation zu beachten gilt. So muss dem Tomcat ein Servlet-Container mitgegeben werden, damit URLs in korrekter UTF-8-Kodierung behandelt werden. Zusätzlich muss das Schema den Filter „solr.ASCIIFoldingFilterFactory“ erhalten, der entsprechende UTF-8-Zeichen durch ihr ASCII-Pendant ersetzt. „München“ wird so in „Munchen“ umgewandelt und dadurch für Solr besser indizierbar. Ohne diesen Filter würde „München“ zwar gefunden werden, „münchen“ aber nicht. Wer sich für die möglichen Filterarten interessiert, findet im Apache-Wiki [2] eine Auswahl möglicher Kombinationen.
Optimierte Schnittstelle für Drittanbieter
Die Daten für die Apotheken sowie die Notdienstinformationen werden über einen Web Service integriert. Die Schnittstelle kann diese Daten beliebigen Anwendungen und anderen Websites zur Verfügung stellen. Der Web Service wird über Smarty-Templates gesteuert und ist so in der Lage, Drittanbietern jedes gewünschte Format zu liefern.
So speist BMW die Daten über die Schnittstelle beispielsweise in sein Fahrerinformationssystem „ConnectedDrive“, die Callcenter der KVB (Kassenärztliche Vereinigung) nutzen die Informationen zur Anzeige der Notdienstdaten. Aber auch große Portale wie focus.de, t-online.de und apotheken.de selbst nutzen den Web Service zur Darstellung der Inhalte.
Die gesamte Suchintelligenz ist dabei in PHP entwickelt und muss vom Drittanbieter nicht nachgebaut werden. Über die Steuerungsparameter werden die fertigen Suchergebnisse im gewünschten Format zur Verfügung gestellt. Für die Integration in TYPO3 wurde ein spezielles Plugin entwickelt, das die Formulardaten validiert, an den Web Service weiterleitet und die Ergebnisse im XML-Format entgegennimmt. Diese werden dann entsprechend der jeweiligen Anforderungen (Quicksearch, Detailsuche) aufbereitet.
Fazit
Nicht nur der Betreiber ist mit dem neuen Auftritt sehr zufrieden, auch die Nutzer sind es. Das zeigt die stetig wachsende Zahl der Unique Visitors auf der Website. Als besonders beliebt haben sich hierbei die bereits im alten Auftritt enthaltenen vielfältigen Suchfunktionen erwiesen. Der Einsatz von Solr gestaltete sich komplizierter als gedacht, lohnt sich aber durch die reichhaltigen Konfigurationsoptionen und die performantere Suche.
Bitte beachte unsere Community-Richtlinien
Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.
Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.
Dein t3n-Team
Schade, dass bei der Umsetzung nicht darauf geachtet wurde, dass (gerade im Gesundheitsbereich) es nicht schlecht wäre, wenn die Benutzer auch die Schriftgröße ändern können. Tut man dies nämlich, wird die Seite nicht mehr les- bzw. z.T. bedienbar.
..und mit 166 Errors, 93 Warning(s) ist die Seite in Sachen valides HTML und Barrierefreiheit auch nicht gerade Paradebeispiel.
Nicht deren ernst oder?
Mal abgesehen davon, dass die Seite aus gestalterischer Sicht nicht grade eine Offenbarung ist (vor allem nicht für ältere Menschen: 11px fitzelschriftgröße [im CSS in absoluten Werten angegeben] für eine geschätzte Ü50 Zielgruppe. lustig! [NOT!]), ist sie ohne Javascript komplett unbenutzbar. Weiter in den Source zu schauen traue ich mich nach diesen beiden Feststellungen garnicht mehr.
Fazit: Umsetzung 6, Setzen!
„required attribute „alt“ not specified.“
6, setzen.
1. „Valides“ (X)HTML ist diskutierbar. Was „valide“ ist, entscheidet der Validator. so gibt es Validator, die ein als Fehler ausgeben, andere verlangen ein
2. Design ist Geschmacksfrage.
3. Barrierefreiheit war explizit nicht gefordert, da es Designanforderungen gab, die höher gewichtet wurden.
4. In Zeiten von web 2.0 und 98,6% User MIT Javascript braucht man nicht über 1.4% diskutieren, die OHNE Javascript kommen. Hier wurde einfach Kosten und 1.4% gegeneinander abgewägt.
Bevor man mit Kommentaren wie „Setzen 6“ kommt, sollte man die Hintergründe von Projekten, Budgets und Kundenanforderungen kennen. ;-)
ad 3.: das verstößt gegen Artikel 3, Abstaz 3, Satz 2 Grundgesetz und eine ganze Reihe nachrangiger Normen. Und da es im Jahre 2010 einfach nur noch ärgerlich ist, dass man über sowas immer noch mit Agenturen dikkutieren muss bleibe ich bei “6, setzen“.
Der W3C Validator entscheidet übrigens, das die Startseite jetzt valide ist :). Schade das hier ansonsten nur die Missing Features besprochen werden.
Ok, dann mal ins Detail. Können wir uns darauf einigen dass Menschen mit Behinderung zur Kernzielgruppe eines Apotheken-Portals gehören? Ja? Wäre es dann vermessen festzustellen, dass ein input vom Typ image ohne Alternativtext für einen blinden Nutzer unbedienbar ist? So, und jetzt dürft Ihr gerne versuchen, mit mir weiterhin über “Geschmacksfragen“ zu diskutieren …
#6 „Barrierefreiheit war explizit nicht gefordert, da es Designanforderungen gab, die höher gewichtet wurden.“ Und wo stecken die?
Wo ist das Problem, so ein simples Kastendesign barrierefrei zu gestalten, geht das mit dem Frickelo3 nicht?
Hier verstösst gar nix gegen irgendein Artikel 3, Abstaz 3, Satz 2 Grundgesetz. Da das ein privatunternehmens-Website ist, ist der Unternehmer nicht verpflichtet, eine Barrierefreiheit zu implementieren. Da dies nicht gefordert war und dafür auch kein Budget zur Verfügung stand, zudem Artikel aus einem alten CMS übernommen wurden, wurde darauf verzichtet. In einer Phase 2 mag das kommen, momentan lag der Fokus nicht darauf. ist das so schwer zu akzeptieren ?
Amateure. Da ist der Kunde aber schlecht beraten, eine seiner Hauptzielgruppen zu vernachlässigen. Und die „Designanforderungen“ möchte ich sehen, ein Design sehe ich nämlich nicht… Behinderte Menschen ganz bewusst und damit vorsätzlich von der Webseite auszuschließen ist sicherlich nicht rechtens.
@Joern: Art. 3, Absatz 3 GG gilt auch für private Unternehmen, es ist für jedes Unternehmen gültig und jeden Bürger, der unter das Grundgesetz fällt. Und das sind Apotheken ganz sicher.
Wie hoch wäre denn so ungefähr das Budget für ein simples Attribut-Werte-Paar im Suchformular anzusetzen, um dies zugänglich zu machen?
@ Eric: Grundsätzlich richtet die BITV sich nur an Einrichtungen des öffentlichen Rechts. (siehe auch Wikipedia).
@Caspers: Grundsätzlich geht es nicht nur um ein Attribut sondern um 10.000 existierende Artikel und andere Komponenten, die aus alten Systemen stammen und daher per se nicht Barrierefrei gehalten sind, da nicht immer CSS ausgezeichnet. Insofern geht es nicht nur um ein paar „Attribute“ sondern um die grundsätzliche Konvertierung alter Inhalte, etc. Dies war – nochmal betont – im ersten Release nicht Bestandteil der Aufgabe – auch wenn seitens der Agentur darauf hin gewiesen wurde. Wenn es der Auftraggeber nicht will, ist es nicht verschulden der Agentur. Daher finde ich diese platten Angriffe an die Entwickler unangemessen, wenn der Hintergrund nicht bekannt ist…
@Joern: Von der BITV hat niemand geredet. Es geht um allgemeine Diskriminierung nach Artikel 3, Absatz 3 GG (s.o.). Und die Argumentation „Einige/Alte Inhalte sind nicht barrierefrei, also brauchen wir uns beim Rest ja auch nicht anzustrengen“ finde ich sehr seltsam.
Ah, jetzt wird’s interessant: es war also ausdrücklicher Wunsch des Kunden, dass das Suchformular links oben auf den Seiten für viele Menschen mit Behinderung unzugänglich ist?
Diese Diskussion finde ich langsam relativ seltsam… Aber egal. Der Auftraggeber hat kein zusätzliche Budgets zur Verfügung gestellt, um die Inhalte a) barrierefrei zu gestalten, b) auf barrierefreiheit zu prüfen. Das ist für Phase 2 vorgesehen, sobald klar ist, welche Inhalte etc. konvertiert werden müssen. Damit ist dann das Thema für mich auch erledigt. Barrierefreheit wird mit Phase zwei vorgesehen, wenn auch die Designs der Apothekenhomepages überarbeitet werden.
Ich fände die Diskussion weit weniger seltsam, wenn du statt abzukanzeln mal meine ganz konkreten Fragen beantworten tätest.
Hmm, ich hatte mir von einem TYPO3-Forum etwas mehr Sachkompetenz erhofft.
Bin ich hier denn im Kindergarten.
Also liebe Kinderlein erstens: Das Grundgesetz kann mir, euch, euren Chefs, euren Daddys wem auch immer
sowas von pissegal sein, es hat für Privatpersonen, Unternehmen etc. nullkommagarkeine Relevanz.
Ich amüsier mich jedesmal wenn in nem Forum wieder mal einer kompetent sein will, und einen der ersten
20 Artikel zitiert.
Das Grundgesetz gilt NUR und AUSSCHLIESSLICH für den Staat, Behörden, Körperschaften des öffentlichen Rechts.
Für „uns“ gelten nur Gesetze, die der Staat erlässt, um SEINER verpflichtung beizukommen, dem
Grundgesetz zu entsprechen.
Und in der Regel sind die Gesetze weitaus konkreter, aber viel „lascher“ als das GG.
Ihr könnt keinen Diskothekenbesitzer verklagen, weil Ladies-Night ist, und Ihr ned reinkommt.
Ihr könnt keinen Barbesitzer verklagen, weil zu seiner Kneipe im Keller keine Rollstuhlrampe installiert ist.
Und ein Gesetz, das einer nicht-staatlichen Webseite alt-tags für Bilder vorschreibt möchte ich gerne mal lesen.
Davon abgesehen, gab es wohl schon eine schnelle Reaktion der Agentur, die Startseite ist nämlich in der Tat
html-valide, inzwischen.
Wenn Ihr hier weiterdiskutiert, bringt doch Konkrete verbesserungsvorschläge, wo euch etwas fehlt, wahrscheinlich
werden die sogar zu Herzen genommen.
@Casper: Hab ich doch mehr als ausführlich beantwortet
Zudem schmeissen hier Leute mit Steinen, die selbst im Glashaus sitzen. Hier wird die Verwendung von Javascript vorgeworfen, wenn man dann deren Seiten anschaut, bekommt man Warnungen, dass Javascript aktiv sein muss um die Seite korrekt zu betrachten, etc.
andere werfen das Design vor, deren Seiten sind aber nahezu „designlos“. Natürlich auch eine Möglichkeit – und relativ einfach und ohne grossen aufwand BF.
Der Hinweis mit dem ALT Text für das Suchfeld ist gut, vielen Dank dafür. Wird zeitnah berücksichtigt.
Ich versteh nicht worin die Zeitersparnis liegt, wenn man ein img-tag mit onclick verwendet anstatt eines links oder eines submit-buttons.
Und komplette Barrierefreiheit ist ja eine Sache.. aber die Seite ist ja auch mit einem normalen Browser teilweise schwer zu bedienen.
Der Bereich links oben unter der Suche verwirrt mich total.
Das wär vielleicht ein Verbesserungsvorschlag von mir, in diesem die Usability verbessern.
@Joer: sorry, aber konkrete Antworten auf die konkreten Fragen #9, #13 und #16 kann ich hier keine finden, ebensowenig Fundstellen, wo ich irgendwas zum Thema JavaScript gesagt haben soll. Vielleicht kannst du mir ja weiterhelfen und konkrete Stellen benennen?
noch ein Verbesserungsvorschlag:
mehere javascript files zusammenfassen, mit jsmin o.ä. verkleinern und mit gzip komprimiert verschicken (natürlich nur wenns der browser versteht…). Weil 484.3KB JavaScript auf 16 Dateien aufgeteilt ist doch etwas viel.
So, so TRheinhard, das Grundgesetzt hat für Privatpersonen also keine Relevanz. Kann ich das schriftlich haben, bevor ich Dir die Rechte auf Meinungsfreiheit und körperliche Unversehrtheit entziehe?
Davon losgelöst: Wo steht eigentlich, dass man für Barrierefreiheit zusätzliche Budgets braucht? Das ist, als würde man beim Hausbau zusätzliche Budgets für das Aufräumen verlangen. Aber ich habe gehört, dass es auch Maurer geben soll, die zuerst eine Wand bauen, und anschließen die Fenster- und Türausschnitte reinflexen. Zu dieser Spezies scheint, im übertragenen Sinne, hier die ausführende Agentur zu gehören. Oder seid Ihr eher kölnisch geprägt und habt Armiereisen und Beton, dass ihr dem Auftraggeber in Rechnung gestellt habt anderweitig verbaut uns berechnet?
Was mich darüber hinaus interessiert: Wie kann man 10.000 Artikel migrieren OHNE sie quasi in einem Aufwasch ordentlich auszuzeichnen?
Ohne die genauen Projektanforderungen zu kennen, kann man am Quellcode sehr schnell feststellen, dass hier einer mehr oder weniger halbherzig TYPO3-Extensions installiert hat und sich keine weiteren Gedanken über den erzeugten Quellcode -geschweige denn zur Zugänglichkeit der Website- gemacht hat, als diese, dass das Layout korrekt dargestellt wird. Es gibt einfach immer noch zu viele Agenturen, die Ihre Hausaufgaben nicht machen. Leider merken die Kunden das meistens nicht, da die Website ja genau so aussieht wie auf dem Layoutausdruck.
@nasumi Interessant was Du so alles fest stellst, durch einen einzigen Blick in den HTML-Code. Ich finde auf Deiner Website leider weder ein TYPO3-Zertifikat, noch kenne ich Dich aus der Community. Die Agentur für die Du arbeitest widerum hat auf Ihrer Webseite nichts als ein Kontaktformular. Von daher kann ich leider nicht beurteilen wer sich da zu solchen Äusserungen herab lässt.
De facto sind die Entwickler an dem Projekt fast alle zertifiziert, und ich persönlich engagiere mich im Certification Team der Association. Da gehört dann noch ein wenig mehr zu als erzeugter Quellcode. Generell kann man von einer mehr oder weniger halbherzigen Installation diverser TYPO3 Extensions schon deshalb nicht sprechen, da die meisten Erweiterungen aus unterschiedlichen Gründen selber entwickelt oder weiter entwickelt wurden.
Wie oben ja schon häufig geschrieben wurde, ist Barrierefreiheit in Phase 2 des Projektes ein Thema.
@ausi die JS-Optimierung werden wir vornehmen, das ist ein guter Hinweis. Danke. Mit welchem Browser hast Du Bedienschwierigkeiten? Wir bekommen viel positives Feedback seit dem Relaunch und selten Beschwerden das irgendetwas nicht ginge. Von daher kann ich diese Behauptung nicht recht nachvollziehen. Den Hinweis bzgl. des Quicksearch-Bereiches werde ich an die Usability-Agentur weiter reichen.
Grundsätzlich arbeitet hier nicht nur eine Agentur an diesem Projekt, sondern es ist aufgeteilt auf etwa 4 Agenturen. Zur Barrierefreiheit gehört viel mehr als die Attribut-Werte-Paare, von daher macht es imho keinen Sinn die Diskussion auf diese Einzelheit zu konzentrieren.
@Sebastian Es hat nicht wirklich etwas mit dem Browser zu tun, z.B. sind auf einigen Seiten die Breadcrumbs nicht klickbar. Es sind viele Kleinigkeiten…
Und ob die Entwickler nun zertifiziert sind oder nicht, eine solche Verwendung von HTML, CSS und JavaScript ist nicht wirklich State of the Art.
@Sebastian: Man muss nicht ein Zertifikat haben um etwas zu können. Das die Entwickler alle zertifiziert sind, heißt noch lange nicht, dass sie sich Gedanken um den erzeugten Quellcode im Frontend machen. Und das dem offensichtlich nicht so war, zeigen Beispielsweise folgende Punkte: Verwendung von zwei JavaScript-Bibliotheken, inline JS-Code der auf sämtlichen Seiten zu finden ist, HTML-Elemente die lediglich auskommentiert wurden, anstelle sie direkt aus dem Template zu entfernen. Letztendlich sagt das was über die Qualität des produzierten Quellcodes und damit auch der Website aus, nicht über die TYPO3-Fähigkeiten der Entwickler.
Mein eigentlicher Kritikpunkt ist aber, dass Kunden Barrierefreiheit als zusätzlicher Kostenaufwand verkauft wird. Das führt dazu, dass Barrierefreiheit immer wieder zusätzlichen Kosten gegenüber gestellt wird und dadurch oft auf der Strecke bleibt. Es ist schön zu hören, dass diese in einer zweiten Phase noch realisiert werden soll, in der Realität ist es dann aber leider oft so, dass diese Phase von Kundenseite nie angegangen wird.
@nasumi: Den Kritikpunkt kann ich nachvollziehen, es ist aber im Alltagsgeschäft gar nicht anders möglich. Wenn sich ein Kunde 3 Angebote von unterschiedlichen Agenturen einholt, dann bekommt er vermutlich (überspitzt formuliert) diese 3 Varianten:
a) Die Agentur hat im Ergebnis keinen barrierefreien Quellcode, zeichnet dies aber auch nicht aus: günstig
b) Die Agentur hat im Ergebnis einen barrierefreien Quellcode, zeichnet den im Angebot nicht aus: teuer
c) Die Agentur zeichnet Barrierefreiheit als optional aus: günstig-teuer
b fliegt raus, weil sein Angebot ohne ersichtlichen Grund zu teuer ist. a und b kommen in die engere Auswahl, wobei b sich erklären muss. Ist a zu verurteilen weil er miese Quali abliefert? Ohne Zweifel ja. Ist b zu verurteilen weil er es dem Auftraggeber überlässt über die Zugänglichkeit seiner Website zu entscheiden?
Um mal auf Deine angesprochenen Punkte zu sprechen zu kommen:
2 JS-Bibs: beide gefordert
Inline: in der Tat unschön, da sind wir dran
auskommentierte HTML-Elemente: Beispiel? Ich hab jetzt auf die schnelle nur 3 marginale Zeilen gefunden. Die werd ich an den Entwickler weitergeben.
Dass dies im Endeffekt dazu führt das das Thema barrierefreiheit (by the way „Freiheit“ gibt es nicht, es müsste barrierearm heissen) oftmals weg gelassen wird ist sicher richtig, Du kannst es aber nicht der Agentur vorwerfen die Aufträge für Ihre Entwickler braucht.
@ausi: Ich werd sicher nicht behaupten das die Seite fehlerfrei ist. Nicht klickbare Breadcrumbs könnten sein, werden wir kontrollieren und ggf. korrigieren. Aber bzgl. der Verwendung von HTML/CSS/JS als State of the Art hätt ich gerne ein Gegenbeispiel.
@Sebastian: Deine Annahme beruht darauf, dass barrierefreie Webseiten wesentlich teurer sind als welche bei denen man nicht darauf achtet. In der Praxis ist dem nicht so, wenn die Standardabläufe bereits barrierefrei sind und es einfach zur Routine gehört. Barrierefreiheit ist (bei mir) eine Inklusivleistung, schon alleine weil ich mich für mangelnde Qualität der Webseiten schämen würde.
Ich stimme Eric zu, wenn Agentur intern Barrierefreiheit als Kostenpunkt definieren werden muss, sollte man etwas an seinen Standardabläufen ändern oder die Frontendentwickler auf eine Schulung schicken. Letztendlich werden barrierefreie Websites massgeblich aus „sauberem“ Quellcode realisiert.
@Sebastian: ich verstehe nicht, wieso 2 JS-Bibs gefordert sein können? Von wem gefordert? Was kann man z.B. mit Prototype realisieren, was mit JQuery nicht geht?
@Sebastian Auf die schnelle würde ich mal sagen das diese Seite „State of the Art“ ist: http://2009.full-frontal.org/
hier hab ich auch noch Artikel gefunden, wie man html einsetzen sollte:
http://net.tutsplus.com/tutorials/html-css-techniques/30-html-best-practices-for-beginners/
http://brainstormsandraves.com/articles/semantics/structure/
Zu den technischen Details bzw. der Barrierefreiheit etc. kann und möchte ich mich hier nicht äussern, da mir dafür die Fachkompetenz fehlt.
Losgelöst von diesem Thema möchte ich doch mal eine Frage stellen :
Lieber Herr TRheinhard,
woher nehmen Sie denn dieses geballte Fachwissen über das Grundgesetz und dessen Gültigkeit bzw. Nichtgültigkeit ?
Das wäre ja ganz neu, dass die Artikel 1-20 nur für Staat, Behörden, Körperschaften des öffentlichen Rechts gelten.
Wenn Sie sich doch so gut mit dem Grundgesetz auskennen, dürfte Ihnen ja auch Artikel 146 nicht ganz fremd sein, denn dort steht geschrieben
“ Dieses Grundgesetz, das nach Vollendung der Einheit und Freiheit Deutschlands für das g e s a m t e d e u t s c h e V o l k gilt (….)“
Ferner prangern Sie noch die fehlende Sachlichkeit in diesem Forum an, vielleicht sollten Sie dann auch einmal Ihre Wortwahl überdenken…..
In diesem Sinne …
Beim Punkt „Design ist Geschmacksfrage“ (#6) offenbart sich eine eklatante Wissenslücke, für die ich mich persönlich in Grund und Boden schämen würde.
> Beim Punkt „Design ist Geschmacksfrage“ (#6) offenbart sich eine eklatante Wissenslücke, für die ich mich persönlich in Grund und Boden schämen würde.
echt ? Design ist immer Geschmacksfrage. Einige Dinge finde ich hässlich, andere nicht. Einige Websites finde ich gelungen, andere hässlich. Du findest vielleicht blau schön, ich mag es nicht.
Seit wann ist Geschmack eine Wissenslücke, für die man sich schämen muss.
Insgesamt klinke ich mich hier aus der Diskussion aus, da wenig konstruktives kommt, meist nur Flames von Leuten, die sowohl Designtechnisch, als auch optisch, als auch programmiertechnisch vor der eigenen Türe kehren sollten.
@Joer: du verwechselst Design mit Dekoration. In einem funktionierenden Design könnte man zum Beispiel die in gängigen Browsern eingebaute Möglichkeit zur Schriftskalierung nutzen, ohne dass das Angebot dadurch unbenutzbar wird und ohne dass einem dann die Dekoration um die Ohren fliegt. In einem funktionierenden Design könnte man auch per Tastatur die Telefonnummer der nächstgelegenen Giftnotrufzentrale herausfinden. Usw. etc. pp.
@Joern Design solltest du nicht mit Layout bzw. Gestaltung gleichsetzen.
Vielleicht ließe sich die Diskussion verkürzen, wenn die Apotheker ihren Lektürerückstand von grob geschätzt 10 Jahren aufholen und sich dann wieder zu Wort melden.
Bitte hier entlang: http://www.einfach-fuer-alle.de/
Ich lese hier in den Kommentaren, daß Barrierefreiheit nicht gefordert und nicht im Budget vorhanden war. Das ist wieder mal die alte Mär vom angeblich ach so teuren barrierefreien Webdesign, das angeblich ach so hohe Zusatzkosten verursacht! Das ist QUARK! Eine barrierefreie Umsetzung belastet ein Budget NICHT zusätzlich, wenn der Webdesigner sein Handwerk versteht und die Seite professionell umgesetzt wird! Ich schließe mich daher voll und ganz Grundgesetzgütiger an, wenn er schreibt:
„Davon losgelöst: Wo steht eigentlich, dass man für Barrierefreiheit zusätzliche Budgets braucht? Das ist, als würde man beim Hausbau zusätzliche Budgets für das Aufräumen verlangen. Aber ich habe gehört, dass es auch Maurer geben soll, die zuerst eine Wand bauen, und anschließen die Fenster- und Türausschnitte reinflexen.“
DANN wird Barrierefreiheit natürlich teurer.
Ich wollte nochmal das Grundgesetzt-Thema aufgreifen, auch wenn es hier eigentlich nicht hingehört.
Zugegebenermaßen hat TReinhard recht.
Das Grundgesetzt regelt die Rechte die ein Bürger gegenüber dem Staat hat.
Hierzu ein Zitat aus der Wikipedia:
„Das Grundgesetz legt im Abschnitt „Grundrechte“ (Art. 1–19 GG) fest, welche Rechte jeder Mensch (Menschenrechte oder Jedermannsrechte) und speziell jeder Staatsbürger (auch Bürgerrechte oder Deutschenrechte) gegenüber den Trägern der Hoheitsgewalt hat.“
Quelle: http://de.wikipedia.org/wiki/Grundgesetz_f%C3%BCr_die_Bundesrepublik_Deutschland#Inhalt
Also:
Der Staat muss sich ans Grundgesetzt halten und Gesetze erlassen, die den Bürgern die Grundrechte sichern.
Ich lese hier in den Kommentaren, daß Barrierefreiheit nicht gefordert und nicht im Budget vorhanden war. Das ist wieder mal die alte Mär vom angeblich ach so teuren barrierefreien Webdesign, das angeblich ach so hohe Zusatzkosten verursacht! Das ist Quark! Eine barrierefreie Umsetzung belastet ein Budget nicht zusätzlich, wenn der Webdesigner sein Handwerk versteht und die Seite professionell umgesetzt wird! Ich schließe mich daher voll und ganz Grundgesetzgütiger an, wenn er schreibt:
„Davon losgelöst: Wo steht eigentlich, dass man für Barrierefreiheit zusätzliche Budgets braucht? Das ist, als würde man beim Hausbau zusätzliche Budgets für das Aufräumen verlangen. Aber ich habe gehört, dass es auch Maurer geben soll, die zuerst eine Wand bauen, und anschließen die Fenster- und Türausschnitte reinflexen.“
Dann wird Barrierefreiheit natürlich teurer.
@Rechtso: deswegen schrub ich von nachrangigen Normen und Gesetzen wie dem BGG und vor allem dem AGG, das auch für das Verhältnis zwischen privaten Nutzern auf der einen und nicht-staatlichen Anbietern auf der anderen Seite gilt. Und wenn ich so Aussagen lese wie „der Kunde hat das explizit so verlangt, dass die Seite keine Anforderungen an die Barrierefreiheit erfüllt“, dann kann ich da nur eine bewusste Diskriminierung von Menschen mit Behinderung ableiten.
@Rechtso Danke, für eine eindrucksvolle Demonstration dessen, was passiert, wenn man versucht, das Gehirn durch Wikipedia zu ersetzen. Ich empfehle die Lektüre einer Primärquelle: http://www.gesetze-im-internet.de/bundesrecht/gg/gesamt.pdf
Es dürfte ausreichen, die Präambel zu lesen. Dort heißt es u.a.: „Damit gilt dieses Grundgesetz für das gesamte Deutsche Volk“
Nochmal, wenn man keine Ahnung vom Projekt und dessen Anforderungen hat, sollte man hier keine solchen Aussagen treffen. Was Budgets, angeblich Standards oder „Ahnung“ bzw. „Nicht-Ahnung“ von Entwicklern oder Designern kennt hier keiner die Details, Zeitpläne, etc. Insofern ist die Diskussion nur Flaming, meist von Leuten deren Webseiten zwar barrierefrei sein mögen, aber auch genauso design- und funktionsfrei.
Wie kann man denn ein Apothekenportal im Jahr 2010 nicht barrierefrei machen? Das geht doch völlig an der Zielgruppe vorbei. Da braucht man gar nicht mit Gesetzen kommen. Wer sind denn die wichtigsten Kunden der deutschen Apotheker? Behinderte Menschen, chronisch Kranke und Senioren. Ohne die könnten die zumachen. Schon allein aus wirtschaftlichen Gründen (die ja angeblich gegen die Barrierefreiheit sprechen) hätte man recht schnell darauf kommen können, dass man da was tun sollte. Ich bin auch der Meinung, dass da eine Agentur beratend zur Seite stehen sollte, wenn es der Kunde nicht weiß.
Und nein, ich bin keine Konkurrentin, sondern einfach nur behinderte Kundin, die erschüttert ist über so viel Ignoranz.
Dilettant heißt der kuriose Mann,
der findet sein Vergnügen dran,
etwas zu machen, was er nicht kann.
[Paul Heyse]
Wenn schon so ein Relaunch, dann bitte nicht so großspurig auftreten. Leise treten wäre angesagt.
@joern Barrierefrei bedeutet dass alle Funktionen für alle verfügbar sind (nicht nur Behinderte). Warum hat die Tagcloud in IE6 mehr Tags als in IE8? Warum hat die Tagcloud auf Windows mehr Tags auf Mac/Linux? Warum brauche ich Javascript um Text richtig darzustellen? Warum habe ich auf Symbian kein Content? Warum fehlt auf den iPhone die Detailsuche und Service?
Nochmal, und damit auch zum letzten Mal. Die Barrierefreiheit ist geplant für die nächste Phase. Das hat rein technische Gründe, dass es momentan nicht berücksichtigt wurde und hat weder was mit Inkompetenz oder fehlender Beratung zu tun. Alle die hier diskutieren haben keine Ahnung, was im Hintergrund abläuft. Der Grossteil der Informationen, die auf der Oberfläche zu sehen ist, wird über Code erzeugt, der 10 Jahre alt ist und wo barrierefreiheit, geschweige denn CSS ein Thema war.
Um die Seite wirklich barrierefrei zu bekommen, muss auch dieser ALTE Code neu programmiert und umgesetzt werden. Und das war weder zeitlich noch aus ressourcengründen noch aus organisatorischen Gründen in einem Zug zu realisieren. An dem Produkt hängen 500 Drittanbieter, 900 Mitarbeiter, die Daten pflegen, etc. Daher wird das sukzessive nachgezogen und als TODO abgearbeitet. Damit sollte die Diskussion jetzt auch ein Ende finden oder ?
weil es z.B. fürs iPhone eine eigene Lösung gibt.
Barrierefreiheit ist kein Hexenwerk, und ein gewisses Grundmaß an Qualität und Semantik gehört für eine professionelle Agentur einfach dazu. Barrierefreiheit nachträglich dranzudübeln wird teuer, und es ist mir unverständlich, wie es mit einer Kernzielgruppe, die altersgemäß ein besonders hohes Risiko hat, eine Behinderung zu erwerben, zu vereinbaren ist, Barrierefreiheit erst in Phase 2 einzuplanen. Wie teuer ist denn ein label Element oder ein em statt einem px? Entschuldigung, aber Eure Inkompetenz in diesem Segment, aber auch in zeitgemäßer Frontend-Entwicklung, ist leider offensichtlich. Der Kunde ist mal ganz schön schlecht beraten.
Mit Verlaub, Joern, wenn du ernsthaft der Meinung bist, dass „Design“ = „wie etwas aussieht“ ist, dann hast du meilenweit deinen Beruf verfehlt.
Sorry, aber bei so einem Blödsinn fällt mir keine klare Argumentation mehr ein.
@Joern
1. Die Website einer Apotheke hat barrierefrei zu sein, sonst verfehlt sie ihre Zielgruppe. Das ist undiskutierbar. Deswegen muß ich die Projektanforderungen nicht kennen, um das zu diskutieren.
2. Dein Flaming gegen Leute, deren Webseiten barrierefrei sind, verfehlt das Thema komplett. Barrierefreie Webseiten müssen weder design- noch funktionsfrei sein. Genauso fragwürdig ist deine Aussage „1. „Valides“ (X)HTML ist diskutierbar. Was „valide“ ist, entscheidet der Validator.“. Das ist schlicht falsch. Was Validität ist, legt nicht der Validator, sondern der W3C-Standard fest. Daß es fehlerhaft implementierte Validatoren gibt, ist kein Geheimnis. Der vom W3C gehört übrigens leider dazu.
@Joern
1. Die Website einer Apotheke hat barrierefrei zu sein, sonst verfehlt sie ihre Zielgruppe. Das ist undiskutierbar. Deswegen muß ich die Projektanforderungen nicht kennen, um das zu kritisieren.
2. Dein Flaming gegen Leute, deren Webseiten barrierefrei sind, verfehlt das Thema komplett. Barrierefreie Webseiten müssen weder design- noch funktionsfrei sein. Genauso fragwürdig ist deine Aussage „1. „Valides“ (X)HTML ist diskutierbar. Was „valide“ ist, entscheidet der Validator.“. Das ist schlicht falsch. Was Validität ist, legt nicht der Validator, sondern der W3C-Standard fest. Daß es fehlerhaft implementierte Validatoren gibt, ist kein Geheimnis. Der vom W3C gehört übrigens leider dazu.
@Joern
Dann hätte man mit der PR und dem Relaunch vielleicht warten sollen bis man wirklich fertig ist. Wie gesagt, ich bin keine Entwicklerin, aber soweit ich weiß, ist Barrierefreiheit nachträglich einzubauen immer teurer als sie von Anfang zu berücksichtigen. Ich bin mal gespannt auf Phase 2. Gibts schon einen Zeitplan bis wann man mit einer barrierefreien Seite rechnen darf?
Stichwort „iPhone“ http://www.quirksmode.org/blog/archives/2010/02/the_iphone_obse.html
man hat einen Zeitvorgabe Z, ein Budget X und einen Funktionskatalog Y. diese drei Dinge muss man unter einen Hut bekommen und dabei fallen einfach einige Dinge nach hinten runter ode werden in eine Phase zwei verschoben. Insgesamt sind für den gesamten Relaunch 2 Jahre geplant, wir sind gerade mal in den ersten 3/4 davon. Was mich hier stört ist die Art und Weise wie diskutiert wird, weniger über was diskutiert wird. Dazu äussere ich mich aber nicht weiter…
>> Die Website einer Apotheke hat barrierefrei zu sein, sonst verfehlt sie ihre Zielgruppe
Müssen tut hier gar nix. Das entscheidet der Auftraggeber, was muss und was nicht. Zudem ist es nicht die Seite einer Apotheke sondern ein Projekt eines Verlags.
Flaming: Das tun hier alle schon die ganze Zeit – und zwar grundlos. JA, die Seite ist derzeit nicht Barrierefrei, wie 1.000.000 andere auch. NEIN, der Zustand wird nicht so bleiben, JA, wir arbeiten schon seit einiger Zeit dran… reicht das ?
Validator: Eben, was valide ist, entscheidet das W3C. Wenn man aber 10 Redakteure hat, die HTML Code eingeben, wie sie gerade lustig sind, hilft weder das W3C noch ein Validator… ;-)
Und wenn hier diskutiert wird, warum auf einem Symbian Gerät die Seite nicht angzeigt wird, dann muss ich einfach sagen, das war nicht der Fokus und wird es auch in Zukunft nicht sein. Auf einem Symbian funktioniert auch Ebay nicht vernünftig.
Nachdem ich ein paar Postings hier gelesen habe, will nur kurz einwerfen: Barrierefreiheit für diese Seite wäre keine Hexerei gewesen und wäre wohl einer der wichtigsten Punkte auf einer vernünftig erstellten Anforderungsliste gewesen. Scheinbar hat man hier geschlampt.
Wenn man ein Projekt startet, dann beginnt man gleich an die Barrierefreiheit zu denken und nicht erst danach. Je früher man daran denkt, umso weniger Kosten entstehen dann in weiteren Entwicklungsphasen. Aus eigener Erfahrung sind Kosten für Barrierefreiheit deutlich schneller amortisiert, als viele denken. Meist rechnet sich das ganze schon nach wenigen Entwicklungszyklen – also noch während der Entwicklung einer Webseite! Einfachere Wartung, bessere Codequalität und besseres HTML sind Folgeerscheinungen.
@Joern: Gerade weil soviele Drittanbieter und User mit dem System arbeiten, hätte sich also die Beachtung von Barrierefreiheit schon in der Entwicklung und Konzeption positiv auf die User des Backend-Systems ausgewirkt. Barrierefreiheit HILFT Redakteuren bzw. Kunden, wenn man es richtig macht.
Das hier ist doch eindeutig eine „Webstandards“ vs. „Normale Agenturwelt“ Diskussion. Unterm Strich steht doch eines Fest, komplett Valide und perfekt barrierefrei dauert für eine Agentur bei der das Thema nicht Default gesetzt ist mehr Zeit, ergo mehr Geld. Dies wird inkl. Marge an den Kunden weitergegeben der meist sparen will. Deshalb ist eine Auslagerung solcher Themen, jedenfalls so wie ich es kennen, in Step 2, Usos in der Agenturwelt. Nebenbei auch legitim. Sollen doch Kunde und Agentur entscheiden in welcher Reihenfolge vorgegangen wird.
Bei Webkraus und Agenturen wo das Thema Webstandards extrem groß geschrieben wird, mach das anders aussehen und vielleicht auch dem reineren Weg entsprechen. Die Realität sieht logischerweise anders aus und das Wissen wir alle.
Warum also dieser Flamewar hier, wir wissen doch alle genau wie der Hase läuft und das Barierefreiheit und Validität Stück für Stück mehr Aufmerksamkeit im Markt bekommt.
Warum Flamewar? Weil sich eine Seite wie diese eigentlich nicht erlauben dürfte, nicht barrierefrei zu sein!
@Frank Vorwald
Zwischen „Webstandards“ und „Normale Agenturwelt“ sollte eigentlich kein VS stehen!
@Joern
„Die Website einer Apotheke hat barrierefrei zu sein, sonst verfehlt sie ihre Zielgruppe
Müssen tut hier gar nix. Das entscheidet der Auftraggeber, was muss und was nicht.“
Das ist eine Einstellung, die ich ganz und gar nicht teile. Natürlich vergibt am Ende der Auftraggeber den Auftrag, aber ihm muß klar sein: Was muß und was nicht, muß zielgruppenorientiert entschieden werden. Auftraggeber denken oft, daß ihre Vorstellungen und Prioritäten die einzigen sind, die wirklich zählen – bis sie verstanden haben, daß es nicht so sehr darauf ankommt, was sie wollen, sondern was die Besucher der Site wollen.
Ich hab mit den Verantwortlichen telefonische Interviews gemacht. Das Highlight war: „Barrierefreiheit? Das sagt mir jetzt gar nichts“ Mehr unter: http://www.bizeps.or.at/news.php?nr=11060
Ich finde was man hier ganz klar merkt, ist, das hier scheinbar Leute am Werk sind die ihren Job einzig und alleine des Geldes wegen machen. Ich höre ständig „kein Budget, kein Budget“. Natürlich, umsonst ist nur der Tod, aber es gibt dinge, die gehören einfach dazu, sofern man in seiner Arbeit aufgeht.
Mal davon ab, dass wenn man ein fähiger Entwickler ist, die Einhaltung von Standards die Entwicklunszeiten sogar noch ordentlich verkürzen, ist Barrierefreiheit schon lange kein Posten mehr auf einer Rechnung, er gehört einfach zum guten Handwerk dazu.
Das wäre ja so, als würde ich dem Kunden es in Rechnung stellen das ich die Bilder der Seite komprimiert habe und nicht als BMP in die Seite einbinde.
Ich würde mich ehrlich gesagt schämen solch eine Seite einem Kunden zu übergeben und sie dann auch noch als meine Referenz auszuhängen.
Das ihr mit der Seite noch so an die Öffentlichkeit geht zeigt eigentlich schon, das ihr keine Ahnung habt was aktuell der Standard ist, den ein Entwickler/eine Agentur für einen Kunden erfüllen müsste damit der Kunde (und damit meine ich nicht nur den, der euch euer Geld gibt) am Ende zufrieden ist.
@Frank: du solltest nicht deine Realität als Massstab für eine ganze Branche setzen! Das es in vielen Agenturen so abläuft, wie du es beschreibst, mag sein, aber genau das verursacht ja diese Diskussion und letztendlich das Problem des Kunden.
Er kann nicht ohne weiteres unterscheiden, wer Projekte von Anfang bis Ende qualitativ hochwertig realisiert -genau darum geht es hier- und wer nicht. Der kann Kunde erwarten, dass sein Projekt nach den allgemein anerkannten technischen Standards umgesetzt wird und diese definiert nicht eine vermeintliche Mehrheit im Web.
Wie dein Hase läuft weiß ich nicht, aber Barrierefreiheit und Webstandards erhalten nicht erst die letzen paar Monate erhöhte Aufmerksamkeit.
#55 „Wenn man aber 10 Redakteure hat, die HTML Code eingeben, wie sie gerade lustig sind, hilft weder das W3C noch ein Validator… ;-)“
Hier könnte einer der zahlreichen zertifizierten Entwickler in Ihrem Haus sicher weiterhelfen und den RTE ordentlich konfigurieren. Das kann schlechten Redakteurscode signifikant mindern.
Zunächst ein Disclaimer: Auch ich habe in den letzten Jahren Quellcode abgeliefert bzw. übernommen bzw. durchgehen lassen, der nicht barrierefrei ist, der nicht valide ist und mitunter auch unschön. Auch da gab es die unterschiedlichsten Gründe für, die (insbesondere heute) für den einen mehr, für den anderen weniger gültig sind.
Was hier aber im gegenseitigen Flaming/Bashing oder was-auch-immer untergeht, ist der berechtigte Punkt, dass man sich als Agentur damit unabhängig von Kundenprojekten allgemein einmal befassen kann und sollte. Denn dann stellt man fest, dass man ein gewisses Minimum an Barrierearmut (früher hieß das mal so, weil sich alle einig waren, dass es 100% barrierefrei gar nicht gibt) ganz ohne Zusatzaufwand beim einzelnen Projekt erreichen kann, indem man einfach die wichtigsten Regeln von Anfang an in der Arbeit beachtet.
@Joern: Auch wenn die Kritik hier für meinen Geschmack im Ton daneben ist, würde es sicher nicht schaden, wenn du dir mal die Zeit nimmst, das Thema von der Warte aus anzugehen und dich in der Richtung auf den aktuellen Stand bringst. Da liegt eine Chance drin.
@Alle: Vielleicht gelingt es ja allen, die Emotionen ein bisschen wieder herunterzufahren und Joern (und den Rest) vielleicht mit weiteren sinnvollen Links zu der Thematik zu versorgen. Offensichtlich gibt es da ja Nachholbedarf. Wie kann ich mit möglichst wenig Aufwand möglichst viel erreichen?
@Joern Für eine ausführliche, selbstbezügliche Case Study waren aber Zeit und Mittel vorhanden? Nun stinkt Eigenlob nicht grundsätzlich, aber man darf sich heute nicht wundern, wenn das Publikum ruft, der Kaiser ist ja nackt. Willkommen im Web.
Gut wäre es gewesen, kenntlich zu machen, dass man erst 3/4 des Weges gegangen ist. Besser wäre es gewesen, erst zu Krähen, wenn die Sonne wirklich aufgegangen ist. Und richtig Klasse wäre es gewesen, die Türen und Fenster zu mauern und nicht erst nachträglich reinzuflexen.
@Frank Warum heißen die Webstandards wohl Webstandards und nicht Websonderumweglösungen? Und gerade bei den Webstandards stehen keine abgehobenen Funktionäre dahinter, sondern die Entwickler selbst. Daraus einen Gegensatz zwischen Standardistas und „normaler Agentur“ ableiten zu wollen begrüße ich nur, wenn ersteres mit „Gut“, zweiteres mit „Schlecht“ gelabeled wird.
Es gibt ein nicht gerade kleines Unternehmen namens DHL, dass genau deshalb bei seinem weltweiten Re-Launch mit 126 Länderauftritten genau deshalb die Standardisierung als Top-Priority festgelegt hat. To be seen from July on. Eben weil es Kosten spart, die Integration externer Partner sichert und die Migration bestehender Contents erleichtert. Aber klar ist auch: If all you have is a hammer, everything looks like a nail – woran wieder deutlich wird, dass gerade bei der Ausbildung der digitalen Handwerker noch viel zu tun ist.
@All das ist keine Flamewar, sondern Ausdruck des schlechten Gewissens derer, die man mit den Fingern in der Keksdose (oder unter der Bettdecke) erwischt hat. Wenn ich mich schäme, reagiere ich auch böse.
@Frank Vorwald eine Agentur, bei der Webstandards und Barrierefreiheit nicht default gesetzt sind, sollte den Laden dicht machen und ihre Mitarbeiter zum Arbeitsamt in die Umschulung schicken. Mangelnde Kompetenz und mangelndes Fachwissen kann nun wahrlich keine Entschuldigung dafür sein, daß die Einhaltung von Webstandards Mehrkosten verursacht – auch wenn es das in der Realität in dem Bereich oft ist. Barrierefreiheit ist übrigens seit 11 Jahren genauso ein Standard wie die Standards zu HTML oder XHTML. Daß sich das Bewußtsein dafür erst jetzt durchsetzt, ist durch nichts zu entschuldigen. Die betreffenden Agenturen und Webdesigner hatten wahrlich genug Zeit.
Das will ich als allgemeines Statement verstanden haben, das sich explizit nicht auf die hier tätig gewordene Agentur bezieht.
@Joern
„Valides“ (X)HTML ist diskutierbar.
-> http://w7t.de/Q
Interessante Diskussion. Wie oben schon angemerkt ist es ein Streit zwischen Webstandards und der alltäglichen Agenturarbeit. Klar, das sollte sich gegenseitig ergänzen – macht es aber oft nicht. Persönlich wundert es mich aber, dass Godwin’s law bislang noch nicht erwähnt wurde ;)
Im voraus Entschuldigung für die Polemik, aber: Webstandards sind die Grundlage für die professionelle Arbeit einer Webagentur, was denn sonst? Als Maurer muss ich mich eben mit Steinen und Mörtel auskennen, als Webentwickler mit Webstandards, als Web-Consultant mit der Zielgruppe, als Webdesigner mit Wahrnehmbarkeit für die Zielgruppe, und als Informationsarchitekt muss ich den richtigen Inhalt auswählen (nicht einfach alle historischen Dokumente). Irgendwie haben die hier alle versagt. Und nun wird darüber diskutiert, dass es völlig OK ist, Menschen mit Behinderungen zu diskriminieren und die Reichweite der Website künstlich zu beschränken, nur weil man nicht verklagt werden kann? Das ist mir unbegreiflich.
Da ich zuerst nur die Kommentare gelesen habe, hatte ich erwartet, dass der Artikel inhaltlich auf Webstandards und Barrierefreiheit Bezug nimmt.
Was er aber in keinem Fall macht. Es handelt sich mehr um die Darstellung von Features wie Solr und vor allem um das Backend. Das Frontend – etwa Templating – wird gar nicht erwähnt.
Sieht man sich den Relaunch an, stellt sich mir aufgrund der Wichtigkeit für die Nutzer natürlich die Frage der Barrierefreiheit. Sieht man sich die quellcodetechnische Umsetzung an, ist aber klar, dass auch auf Webstandards und Semantik nur bedingt Wert gelegt wurde.
Man kann jetzt natürlich weiter über die fehlenden Standards und Barrierefreiheit diskutieren, aber – soweit mir das jetzt durch die Seite und den Artikel erläutert wurde, war das niemals die Intention.
Das ist schade und im Fall einer Apothekenportalseite völlig unzureichend.
Nachdem dieser Artikel hier ja nun sehr engagiert diskutiert wird, möchte ich kurz darstellen, wie unsere (t3n) Sicht der Dinge ist.
Wir haben uns primär dafür entschieden, einen Showcase-Artikel von apotheken.de im t3n Magazin Nr. 17 zu veröffentlichen, weil bei dem Projekt die neue TYPO3-Extension Solr zum Einsatz kommt, die ziemlich neu und sehr vielversprechend ist, da sie die TYPO3-Standard-Suche extrem verbessert und beschleunigt (mehr dazu in t3n Nr. 19).
Den Faktor Barrierefreiheit haben wir bei der Auswahl des Themas ehrlich gesagt vernachlässigt bzw. nicht beachtet. Das war ein Fehler, das kann man nicht anders sagen und da brauchen wir auch nicht drum herum zu reden. Zwar ist es grundsätzlich erstmal ein Thema, dass der Kunde mit seiner umsetzenden Agentur klären muss, aber natürlich hat t3n den Anspruch, nur Projekte vorzustellen, die technologisch fortschrittlich umgesetzt wurden. In Bezug auf das Grundsystem war das in diesem konkreten Case (TYPO3 + Solr) sicher der Fall, in Puncto Barrierefreiheit nicht. Wir hätten also zumindest im Artikel deutlich darauf hinweisen müssen, dass das Projekt keinen Fokus auf das Thema Barrierefreiheit hatte. Das haben wir versäumt.
Im Rückblick muss ich sagen, dass wir das Thema Barrierefreiheit hätten besser checken sollen. Wir sind hier zugegebenermaßen bislang etwas schwach aufgestellt gewesen, haben mit unserem neuen Kollegen David Maciejewski mittlerweile aber einen kompetenter Verfechter von Webstandards an Bord und geloben hier Besserung.
@Jan Christe: Das Versäumnis sehe ich weniger auf Eurer Seite. Im Gegenteil, ich finde es gut, wenn Ihr kontroverse Themen aufgreift und diesen Debatten eine Plattform bietet. Dass man sich streitet, zeigt ja zumindest, dass man über das gleiche redet, und es für relevant genug hält. Das ist auch journalistisch und ökonomisch wertvoll, denn PR-Bla-Bla gibt es genug.
Zu Kommentar #47 (»Der Grossteil der Informationen, die auf der Oberfläche zu sehen ist, wird über Code erzeugt, der 10 Jahre alt ist und wo barrierefreiheit, geschweige denn CSS ein Thema war.«):
Auch das ist falsch und kann auch ohne Hintergrundwissen über die Innereien des Projekts widerlegt werden. Die »Informationen, die auf der Oberfläche zu sehen« sind, stehen in einem Codegerüst, das auf dem YAML-Framework aufbaut. Dieses Framework gibt es noch keine 10 Jahre. Insofern muss irgendwer beim aktuellen Relaunch Hand an den Code gelegt haben, sonst wäre da dieses Framework nicht drin. Und genau dabei hat dann irgendwer bei den Teaserboxen auf der Startseite eine hartverdrahtete Höhe in Pixeln eingebaut (.tdw {height: 200px;} in der content.css), die eine effektive Schriftskalierung verhindert. Erzähl‘ mir nicht dass das schon seit 10 Jahren so hartverdrahtet im Content steht.
Und jetzt versuch‘ bitte nicht wieder abzukanzeln und zu behaupten dass ich keine Ahnung von nix hätte – mein Name steht bei YAML in den Credits, ich habe also ein ganz kleines bisschen Ahnung von dem was ich hier schreibe. Und ich müsste mir schon richtig Mühe geben in ein solches (von Hause aus eigentlich schon sauberes und zugängliches) Framework einen derartigen Murks einzubauen.
Der Relaunch zeigt aus meiner Sicht vortrefflich, dass Barrierefreiheit in der deutschen Agenturlandschaft immer noch nicht angekommen ist. Offensichtlich hat es der ausführenden Agentur nicht nur an Know-how in Webstandards gefehlt. Schaut man sich die Website etwas genauer an, finden sich elementare Fehler in der Semantik. Ordentliche Semantik, Label-Elemente und Alt-Attribute sind gutes Handwerk und ein guter Frontend-Entwickler sollte dies umsetzen können. In der Summe der gemachten Fehler hat die ausführende Agentur ihre Inkompetenz offen zu schau gestellt.
Leittragende ist der Kunde! Offensichtlich hat die Agentur eine Kuh gefunden, die man schön melken kann. Barrierefreiheit wird ja erst in der zweiten Phase umgesetzt und dass für wahrscheinlich viel Geld. Der Kunde sollte sich lieber überlegen die Agentur in Regress zu nehmen. Vermutlich ist das Pflichten- und Lastenheft ebenfalls so schlecht formuliert, dass die Agentur aus dem Schneider ist.
Die Aussage: Barrierefreiheit war keine explizite Forderung, ist doch gelinde gesagt ein Witz. Zumal dann noch nachgeschoben wird, Barrierefreiheit wird erst in Phase 2 angegangen. Entschuldigung das ich hier anfangen muss zu lachen. Wenn ich bei http://www.bizeps.or.at/news.php?nr=11060 das Zitat eines Verantwortlichen lesen kann: „Barrierefreiheit? Das sagt mir jetzt gar nichts“. Die Aussagen muss nicht weiter kommentiert werden.
Aussagen zu Budget, Zeitvorgaben und Funktionsumfang werte ich eher als peinlichen Versuch der Schadensbegrenzung.
Barrierefreiheit ist doch kein Thema, was man nachgelagert umsetzten kann. Barrierefreiheit gehört bereits in die Konzeptionsphase. Barrierefreiheit richtig geplant und umgesetzt ist dann auch kein Kostenfaktor, der das Budget sprengt. Das ist schon lange bekannt und auch von fähigen und Kompetenten Leuten nachgewiesen.
Auch wenn die ursprüngliche Intention des Artikels durch die vielen Kommentare eine völlig andere Wendung gekommen hat. Zeigt sich das tolle Features nicht alles sind und nicht unbedingt eine gute Website ausmachen.
Zusammengefasst hat die Agentur in ihrer Funktion versagt und der Kunde wurde schlecht beraten.
@ Peter Rozek: Sei nicht so streng – das ist so deutsch. Sehen wir es so: Die Welt ist schlecht, damit wir sie besser machen, und der Apotheker Verlag hat uns allen eine Chance gegeben, etwas zu lernen.
Hallo,
Mein kleiner Beitrag zum Barrierefreiheit-Flamewar:
Meiner direkten Erfahrung nach besitzen beeinträchtige Menschen in den meisten Fällen sehr leistungsstarke, moderne Rechner und Screenreader die sehr ‚intelligent‘ sind. Ein fehlendes alt-Attribut ist für einen beeinträchtigten User im Internet kein Problem.
Ich habe das Gefühl das es in der Diskussion hier um die Verteidigung eines Dogmas geht, das erinnert mich irgendwie an einen Religionskrieg. Ich denke man muss die Sache Barrierefreiheit pragmatisch sehen und nicht blind Regeln folgen die in den 90er Jahren aufgestellt wurden.
Gruß aus Wien,
Boris
Hallo,
Eine Frage interessiert mich brennend:
Ist schonmal jemand von euch gemeinsam mit einem blinden Menschen vor seinem Rechner gesessen und hat ein paar Webseiten abgesurft?
+1 / -1 als Antwort
Tät mich über Antworten freuen!
Cheers!
Ohne die Grundaussage, dass hier nicht optimal gearbeitet wurde, in Frage zu stellen, halte ich nichts von Aussagen wie „Barrierefreiheit kostet nichts extra“.
Das lässt sich nur aufrecht halten, wenn man Barrierefreiheit nahezu ausschließlich auf die Quellcode-Qualität beschränkt.
Wie sieht es denn mit den Inhalten aus? Leichte Sprache, barrierefrie PDFs oder andere Medien, Video- oder Audiomaterial? Bekommt man das auch barrierefrei ohne Kosten? Schon die sinnvolle und technisch sehr einfache Auszeichnung von Bildern mit Alternativtexte _kostet Zeit_. Für ein Bild nicht so viel aber bei einigen tausend Bildern kommen da auch ein paar Stündchen zusammen…
Wie sieht es mit dynamischen Anwendungen aus – wie viele der hier Anwesenden können ohne Testing sicher sagen, wie sich dynamische Applikationen, die über einen simplen Slider hinausgehen in der Mehrzahl der Screenreader anhören?
Wie gesagt, das geht vielleicht ein wenig am aktuellen Fall vorbei, weil
a) hier tatsächlich grundlegende, einfache Dinge falsch sind und
b) der Kunde das erforderliche Budget hätte bereit stellen sollen (notfalls auf andere Dinge hätte verzichten)
aber wer meint, einen umfassenden Ansatz von Barrierefreiheit zu Nullkosten realisieren zu können, macht sich (und seinen Kunden) etwas vor.
@brx, ja. Mehrmals. Und dann merkt man auch, dass selbst der modernste Screenreader ein Bild nicht interpretieren kann, wenn nicht (per alt-Attribut) dran steht was es ist. Kann dir nur empfehlen man den Accessibility-Stammtisch von Accessible Media zu besuchen, der ca. 1x pro Monat stattfindet, da gibt es immer umfangreiche Infos und Kontakt mit Leuten, die tatsächlich täglich Screenreader nutzen: http://ya.tl/cPQgcK
@Lab, du kennst die folgenden Beispiele?
Case Study of Accessibility Benefits: Legal & General Group (L&G)
http://www.w3.org/WAI/bcase/legal-and-general-case-study
Case Study of Accessibility Benefits: Tesco
http://www.w3.org/WAI/bcase/tesco-case-study
Brinck, T. Return on Goodwill: Return on Investment for Accessibility . In Cost-Justifying Usability, Randolph G. Bias, Deborah J. Mayhew, eds. 2005. Example calculation gives a market increase of 8% and ROI of 2.4:1.
http://www.w3.org/WAI/bcase/resources.html#roi
Und das altbekannte Gegenbeispiel:
Target.com Accessibility
http://webaim.org/blog/target-com-accessibility/ ?
@brx +1
@brx
+ 1 für die Frage nach der Screenreadernutzung, ansonsten eher -1 zum Posting davor.
Natürlich sind blinde Nutzer, die oft und viel im Netz unterwegs sind, einiges gewöhnt und kommen auch erstaunlich gut mit mangelhaften Seiten zu Recht. Das gilt aber nicht für alle Nutzer und ist absolut keine Entschuldigung, es ihnen unnötig schwer zu machen.
Hier groß auf Webstandards rumreiten und aber nicht wissen worum es im Artikel eigentlich geht… Im Ansatz und in Bezug auf den Apotheker-Verlag ist die Barrierefreiheitsdiskussion nicht falsch, aber für mich ist dies hier alles am Ende doch nur ein Flamewar der von validitäts Fanatikern angestoßen worden ist. Wie gesagt nicht falsch, aber ein komisches, oberlehrerhaftes Vorgehen mit dauerhaft unsympathischen unterton. Vor allem nix neues dabei, in dem ganzen Gefasel… Das die Site nich valide ist, weiß doch selbst mein Azubi im ersten Lehrjahr. Das ist hier im Artikel auch nicht der Punkt wie von Frau Egger richtig angemerkt. Darüber streiten, dass es besser wäre, wenn eine Apotheken Site besser barierefrei wäre, muß man nicht.
Schaut Euch doch besser mal Apache Solr an, das eigentlich spannende Thema an dem Relaunch und im Vergleich zu allen anderen Suchsystematiken der Hit!
@brx dass die meisten beeinträchtigten Menschen neueste Rechner und Software benutzen würde ich nicht unbedingt sagen (Quelle: http://blog.aperto.de/?p=635 Punkt 9)
-1 zur Frage. Ich beschäftige mich erst seit kurzer Zeit mit Barrierefreiheit, und habe auch noch keine barrierefreie Website erstellt. Aber ich teste meine Seiten schon seit langem ohne CSS und javascript auf Funktion und Sinnhaftigkeit.
Schade.
Da wird ein vielversprechendes T3-Plugin durch eine unprofessionelle Umsetzung einer Website mit in den Dreck gezogen.
Mich würde nur interessieren, wer diese 4 Agenturen waren. :P
Aber zur Sache mit Solr: „30.000“ Seiten? Ich gehe mal davon aus, daß damit unique URLs gemeint sind. Das ist doch für große Webauftritte nun nicht gerade etwas besonderes?
Wo ist diese Lösung denn besser als die Verwendung von einer „normalen“ Suchmaschinenlösung wie beispielsweise MNoGoSearch?
(Ok, mit einer Zahl von 30.000 Seiten kann man Homepagebastler und Juristen beeindrucken… Aber ich denke mal, wer schon mit Webauftritten zu tun hatte von größeren Organisationen, dürfte da nur drüber lächeln.)
Hier aber wird noch extra TomCat benötigt um ein javabasiertes Aplet zu haben. Somit kommt es zur Nutzung von weiteren Technologien die betreut werden müssen neben der T3-Installation.
Sprich: Die Admins müssen am Ende nur nicht Typoskript können, sondern auch Java.
Ist das nicht etwas teuer im Unterhalt?
@Wolfgang Die genauen Details der Installation kenne ich nicht, aber sicher sind 30 000 Seiten auch für Solr nicht viel. Für eine Indexed Search jedenfalls wäre da das Ende schon längst erreicht. Ob nun Solr, MNoGoSearch oder auch Sphinx, das kommt doch wie immer auf den jeweiligen Fall und das Projekt an. Soweit mir bekannt (Achtung, möglicherweise nur Halbwissen), legen MnoGo und Sphinx ihre Indexe in einer DB ab.(?)
Solr basiert hier auf dem mächtigen Lucene Kern, ich denke auf Apache Projekte ist hier gut verlass. Als Apache Projekt gibt es auch ein großes Ökosystem von Schwesterprojekten um Lucene herum die alle super miteinander funktionieren. So stellt Solr etwa einen dedizierten Suchserver dar wie FAST oder Google Mini in den man aus verschiedenen Quellen / Anwendungen indizieren kann und aus einer zentralen Oberfläche (in diesem Fall TYPO3) durchsuchen kann. Nutch bietet die Möglichkeit Crawler auch für fremde Websites zu realisieren, Tika dient zur Metadaten und Contentextraktion.
Ein weiteres gites Bsp ist t3n, hier werden Inhalte aus den unterschiedlichen Portalen indiziert und zentral durchsucht.
Weitere Punkte für Solr sind vor allem die Leistungsfähigkeit und der Funktionsumfang. Facettierte Suche, Boosting, Content Elevation, Geo Search, Replikation, flexibles Indexschema…
Zum Thema Tomcat; wer sagt das sich der gleiche Admin um TYPO3 und Tomcat kümmern muss? Zum anderen haben wir die Erfahrung gemacht, dass wenn der Tomcat einmal läuft er keines großen Pflegeaufwands bedarf.
Das kurz zum Thema Solr, bei weiteren Fragen stehe ich gerne zur Verfügung.
@Tomas
Zumindest die beiden W3C-Sachen kenne ich.
Die stehen aber nicht im Gegensatz zu dem, was ich schrieb. Da ist von Kosten von £35.000 (Tesco) die Rede und im anderen Fall von ROI in 12 Monaten, was ja zumindest ein Investment voraussetzt.
Aussage der Case Studies: Barrierefreiheit kostet Geld, lohnt sich aber auf die lange Sicht. (Gilt im übrigen generell für Qualität…)
Genau meine Meinung.
Warum sich Webstandards, Semantik und Barrierefreiheit nicht durch setzen…
http://www.multimedia-garten.de/pinnwand/webstandards-durchsetzen/