Archiv für die Kategorie 'Standards'

« Vorherige Seite
Neuere Beiträge »

Mythen – Menschen – Manager Projektmanagement und Usability Engineering

Dienstag, 07. September 2004

Dr. Stefan Voigt und Rainer Heers, basierend auf dem Vortrag auf der Tagung Mensch und Computer 2004

Inhalt

Abstract

Projektmanagement und Usability werden in Projekten oft von vornherein als Gegensätze begriffen: zuwenig Zeit, kein Geld, ‘ich weiß, was der Nutzer will’, Technologiezentrierung, illusorische Zeitpläne, Ausblendung von Folgekosten und die Mißachtung des ‘Faktors Mensch’ im IT-Management sind die häufigsten Gründe. Untersucht werden deshalb verschiedene Mythen zum Projektmanagement (Zeit, Planbarkeit, Machbarkeit, Kundenorientierung und Mitarbeitereinsatz), um zu analysieren, was Projektmanagement tatsächlich ausmacht. Die Rollen eines Usability Engineer im Projekt verdeutlichen, wie die Kombination von Nutzerfreundlichkeit mit gutem Projektmanagement zu einem inhaltlich und organisatorisch erfolgreichen Projekt und einem wirtschaftlich erfolgreichen Produkt führen kann.

Keywords

Projektmanagement, Projektsteuerung, Usability Engineering, Kundenorientierung, Nutzerorientierung, Qualitätssicherung, Gebrauchsfreundlichkeit

Einleitung

Projektmanagement und Usability haben einiges gemeinsam: Mythos und Realität vermischen sich zu diffusen Vorstellungen über den ‘Zauberer’ (Projektmanager) einerseits und den ‘Anwalt des Nutzers’ (Usability Engineer) andererseits. Was jedoch sind die tatsächlichen Rollen und Aufgaben, die beide in einem Projekt einnehmen? Welche Interessen verbinden oder trennen sie und worin liegen die Erfolgsfaktoren und Fallstricke im Projektalltag? Die damit bereits implizit genannten Faktoren gilt es zu betrachten, um eine erfolgreichen Zusammenarbeit dieser Schlüsselpersonen zu erreichen.

Mythos Projektmanagement

Modernes Projektmanagement zeichnet sich (zumindest in der IT-Industrie) nicht mehr nur durch die klassischen drei Kontroll- und Erfolgsfaktoren (Zeit, Kosten, Qualität) aus. Softwareprodukte sind keine Werkstücke, die am Ende des Produktionsprozesses bloß funktionieren müssen. Sie müssen vielmehr auch nach der Auslieferung sowohl in der Zeit (Updates, Skalierung, Anpassung) als auch in der Qualität (Nutzerfreundlichkeit, Trainingsbedarf, Servicefreundlichkeit, techn. Innovation) hohen Ansprüchen gerecht werden müssen, um am Markt zu bestehen. Damit entstand ein ‘Mythos des Projektmanagements’, erscheint es doch als Lösung für viele Probleme, in denen der Projektmanager beinahe als ‘Zauberer’ erscheint. Neben den fachlichen und betriebswirtschaftlichen Anforderungen des Projekts vollbringt er (scheinbar) das Wunder, die Interessen der eigenen Geschäftsleitung und interner oder externer Auftraggeber zu erfüllen. Da Zauberei aber eben nur Zauberei ist (im Gegensatz übrigens zum Erschaffen von Wundern, denen kein ‘Trick’ zugrundeliegt), haben sich verschiedene Autoren mit den Mythen des Projektmanagements genauer befasst, vgl. zum Beispiel DeMarco, 1999; Sprenger, 2002, Wischnewski, 2001. Wir beschäftigen uns hier mit fünf Mythen, die exemplarisch für den ‘Mythos Projektmanagement’ stehen sollen:

Mythos 1 – Zeit

Unter dem Mythos Zeit verstehen wir das Phänomen, dass beinahe jedes Projekt am Ende seiner Laufzeit in Zeitnot gerät. Dies gilt sogar für Projekte mit identischen Aufgaben, aber unterschiedlichen Zeiträumen für die Erfüllung dieser Aufgaben: ob fünf Wochen oder fünf Monate, am Ende ist Zeit knapp. Ãœber die Gründe wird in ‘lessons learned’ meist nur gemutmaßt: Es wurde falsch geplant, es wurde zuwenig, zuviel oder gar nicht geplant oder es wurde zu Beginn zu viel Zeit ‘vertrödelt’ (horror vacui-Effekt). Es stellt sich die Frage, ob es als unanständig gilt, in einem Projekt Zeit zu haben oder, horribile dictu, sogar vor dem Abgabetermin fertig zu werden. Warum ist das so?
Die Ursachen lassen sich nicht immer sauber herausarbeiten, jedoch erscheint es plausibel, in der (allerdings immer beklagten) Zeitnot eine condition sine qua non zu sehen. Zeitknappheit und -not muß von allen Beteiligten behauptet werden, da sonst nicht nur der Dienstleister bei seiner Kalkulation zu großzügig (sprich: verschwenderisch) mit dem eingesetzten Geld des Auftraggebers umgegangen wäre, sondern ebenso der Auftraggeber als allzu großzügiger, ja leichtfertiger Unternehmer gelten würde, der seine Leute nicht ‘im Griff’ hat. Den Mitarbeitern sind diese Abläufe meist besser vertraut als ihnen lieb ist. Auf der anderen Seite stehen Ihnen zuweilen Führungskräfte gegenüber, die grundsätzlich ‘keine Zeit’ haben: Weder für Diskussionen zur Verbesserung des Projektverlaufs noch für Gespräche mit Mitarbeitern. Vielmehr werden kurzfristig (sic) Anfragen zum Zustand des Projektes formuliert, um die nächsthöhere Führungsebene (mit noch weniger Zeit) zufriedenstellen zu können.

Mythos 2 – Planbarkeit

Beide Teile des Wortes Projektmanagement suggerieren: man hat die Sache im Griff. Alles ist geplant. Die Erfahrung zeigt: dem ist nicht so. Softwareproduktion ist ein Spiel mit vielen Unbekannten. Dabei ist noch nicht einmal von technischen Problemen die Rede. IT-Projekte scheitern äußerst selten an technischen Problemen, sondern fast immer an soziologischen bzw. Managementproblemen (DeMarco 1999).
Wie wenig diese Erkenntnis verbreitet ist, zeigt zum Beispiel das Prozedere bei Projektausschreibungen. Welcher Dienstleister wird eine Ausschreibung gewinnen, der mit dem perfekt bis ins Details geplanten Projektplan, in dem Hunderte von Einzeltätigkeiten auf jede Stunde hin genau auflistet sind, oder der andere mit dem Projektplan, in dem ca. 20 Blöcke von Leistungen aufgelistet sind, die untereinander flexibel gehandhabt werden können? Die Folge: ein irrwitziger Projektplan muß eingehalten werden, Verzögerungen aufgrund unrealistischer Planung gehen zu Lasten von Mitarbeitern und Qualität. Man wird evtl. fertig, aber für welchen Preis.

Mythos 3 – Machbarkeit

Das Scheitern von Projekten ist in Projektplänen nicht vorgesehen. Es widerspricht dem positiven erfolgsorientierten Denken von Managern: Jedes Ziel ist erreichbar (es kommt nur auf den Einsatz der richtigen Mittel an). Und dennoch scheitern Projekte. Die Machbarkeit eines Projektes hängt nämlich von (oft unüberschaubaren) Faktoren ab: die eigene Geschäftsleitung, der Auftraggeber, die Mitarbeiter, politische oder ökonomische Rahmenbedingungen. Wodurch das Scheitern des Projektes letztlichendlich ‘geschafft’ wird (denn auch hierzu gehört viel Energie), ist grundsätzlich nicht so relevant wie die Einsicht, dass Projekte scheitern können. Oft sind es inhärente Grenzen (der Plan, die knappe Zeit, s.o.), die zu enge Grenzen für den Erfolg setzen und so Produkte einschränken, die doch möglich wären (aber eben nicht wahrscheinlich sind).

Mythos 4 РK̦nig Kunde

Nur – wer ist der ‘Kunde’? Und was will er? Zunächst ist der Auftraggeber der Kunde. Der Endkunde oder Endverbraucher hingegen, der das fertige Produkt letztendlich bezahlt und / oder benutzt, ist nicht direkt am Projekt beteiligt. Aufgrund dieser Konstellation wird ein Projekt zunächst für andere ‘Kunden’ gemacht: den Auftraggeber, das Marketing, den Vertrieb, das Controlling, den Projektleiter, für Ruhm und Ehre. Ursprünglich gemeint ist mit Kundenorientierung jedoch die Orientierung am Nutzen, am Mehrwert des Endverbrauchers, da dieser das fertige Produkt schließlich kaufen soll. Konkret sind meist sehr keine oder nur diffuse Vorstellungen über den Kunden anzutreffen, die zur Rechtfertigung des eigenen Tuns herangezogen werden, ohne auf belastbaren Daten zu beruhen.

Mythos 5 – Teamarbeit

Entgegen der theoretischen Einsicht und einer allenthalben propagierten Teamarbeit nehmen sich Mitarbeiter oft wie ein winziges Rädchen in einer übermächtigen Maschine wahr. Sie sind häufig der am wenigsten verstandene und berücksichtigte Faktor in einem Projekt. Sie haben häufig den Eindruck beliebig austauschbar, jederzeit und ohne Einarbeitung verfügbar, beliebig kombinierbar und zueinander ohne Reibungsverluste addierbar zu sein. Für den Projektmanager liegt hier die nur selten (im mindestens doppelten Wortsinn) wahr-genommene Aufgabe: die alltägliche Koordination verschiedener Individuen mit all ihren Eifersüchteleien, Eitelkeiten etc. Diese kaum zu unterschätzende Aufgabe erscheint jedoch nicht in den fein säuberlich ausgearbeiteten Projektplänen. Die Mitarbeiter kommen erst dann ins Blickfeld, wenn ein Projekt doch einmal in Verzug gerät. Der Druck auf die vorhandenen Mitarbeiter steigt oder der Projektfortschritt soll durch einen kurzfristig erhöhten Personaleinsatz wettgemacht werden. Schließt sich der Projektmanager dieser Ansicht an, gerät das Projekt wahrscheinlich noch weiter in die Bredouille. Widersetzt er sich jedoch, riskiert er, für den absehbaren und sich aus vielfältigen Ursachen ergebenden Mißerfolg allein verantwortlich gemacht zu werden.

Diese Mythen zeigen, in welchem Spannungsfeld sich ein Projektmanager bewegt und welche heterogenen Anforderungen er letztlich erfüllen muss. Im Erfolgsfall erfüllt der zaubernde Projektmanager alle Anforderungen perfekt: Er schließt das Projekt im Zeitrahmen ab. Er plant alle Eventualitäten voraus. Er sorgt dafür, dass jede noch so abwegig erscheinende Anregung des Auftraggebers im Projekt umgesetzt wird. Er erfüllt jeden Wunsch des Kunden. Und natürlich sind alle im Projekt eingesetzten Mitarbeiter glücklich und zufrieden. Häufig ist jedoch zumindest in einigen Punkten das genaue Gegenteil der Fall. Deswegen ist der Projektmanager oftmals eher ein Krisenmanager als ein Zauberer.

Usability Engineering

Eine Methode, um die negativen Auswirkungen der oben beschriebenen Mythen zu minimieren, ist die Verfahrensweise des Usability Engineerings (UE). Aber, was ist das eigentlich? Und was sind die Aufgaben eines ‘Usability Engineers’? Diese einfachen Fragen führen schnell zum Kern des Problems: Idealerweise ist UE ein zielgerichtetes, strukturiertes Vorgehen im Projekt, das darauf ausgerichtet ist, ein gut bedienbares und mehrwertschaffendes Produkt zu entwickeln. In der Literatur (z.B. Mayhew, 1999; Nielsen & Mack, 1993; Hackos & Redish 1998) und in internationalen Standards (u.a. ISO DIN 13407) sind die notwendigen Prozesse, Verfahren und Methoden benannt und diskutiert, die UE zu einem anerkannten Referenzmodell machen, das

  • planvoll organisiert,
  • aus der Praxis entwickelt,
  • international anerkannt und bewährt,
  • hocheffizient ist.

Der Usability Engineer ist der fachlich ausgebildete Mitarbeiter, der die relevanten Methoden und Verfahren beherrscht und umsetzt. Kennzeichnend für sie oder ihn ist eine explizite Praxisorientierung, ein pragmatisches Vorgehen, die Integration in bestehende Prozesse (Softwareentwicklungsprozesse, Produktdesign, o.ä.) und eine klar definierte Rolle als Stakeholder im Projekt. Die Effizienz des Usability Engineers zeigt sich bei kostengünstigen down-to-earth Methoden (Paper Prototyping, Heuristische Evaluation, Walkthrough-Verfahren etc.) bis hin zu aufwendigen experimentellen Usability-Tests (vgl. Barnum, 2002, Mayhew, 1999). Die Zusammenarbeit des Usability Engineers auf der Arbeitsebene betrifft i.d.R. alle anderen beteiligten (Fach-)Abteilungen: Die Konzeption bzw. Informationsarchitektur, Design, Anwendungsprogrammierung und Projektmanagement. Nur: wann und wie der Usability Engineer konkret hinzugezogen wird, ist je nach Unternehmen und je nach den projektverantwortlichen Personen höchst unterschiedlich. Nicht selten müssen sich Usability Engineers ihre Position und ihren Einfluß langwierig erarbeiten.

Dementsprechend werden die Ziele von Usability Engineering von außen oftmals anders gesehen als von innen. Die heterogenen Interessenlagen innerhalb eines Projektes (s.o.) machen es zum Beispiel oft unmöglich, klar zu definieren, wann ein Projekt zuende ist: nach dem Roll-Out? Wenn die Vorgesetzten zufrieden sind? Wenn das Controlling zufrieden nickt? Oder gar erst dann, wenn ein Nutzer die Software tatsächlich bedienen kann (und dies gerne tut)? Zu einigen dieser Punkte kann der Usability Engineer sein Scherflein beitragen, denn UE führt u.a. zu einer deutlichen Kostenreduktion im Gesamtverlauf eines Projekts. Je später allerdings ein Produkt am Markt und am Endkunden ausgerichtet wird, desto höher sind Änderungs- sowie Folgekosten (von Garantie und Kulanzkosten einmal ganz abgesehen). Gutes UE kann neben einer hohen Gebrauchsfreundlichkeit des Endproduktes auch die Minimierung von Folgekosten gewährleisten (Mayhew, 1999), die ihre Ursache oft in einem kurzsichtigen Release- und Patch-Denken haben.

Im Projekt hat der Usability Engineer den Hut des tatsächlichen späteren Nutzers von Software auf. Nur, wer hat ihm dieses Mandat erteilt? Und wen vertritt der Usability Engineer wirklich? Wie jeder andere Projektbeteiligte auch hat er genuin eigene Interessen, z.B. sich selbst zumindest als wertvollen Mitarbeiter darzustellen oder sich zu profilieren. Andererseits sind es letztlich die Endkunden, die ein Produkt kaufen und somit dessen Erfolg sichern. Sie sind zumeist ein Konglomerat unterschiedlichster Käufergruppen, über die nicht sehr viel bekannt ist. Der Usability Engineer übernimmt in diesem (häufigen) Fall die Funktion, Vorurteile anderer Projektmitarbeiter oder des Auftraggebers über ‘den Endkunden’ kritisch zu hinterfragen, sei es mit umfassenden Zielgruppenanalysen, sei es mit kleinen Fokusgruppen. Ein minimalistisches Usability Engineering kann sich auch darauf beschränken, nur die Beachtung von Normen und Standards einzuhalten. Dem Usability Engineer kommt eine Querschnittsfunktion zu, die er, beginnend mit dem Bedien- und Anzeigekonzept des Produktes über die ergonomische Gestaltung bis hin zu Usability-Tests und der Begleitung der Markteinführung ausfällt. In der Praxis heißt das, dass der Usability Engineer in allen Projektphasen berät, Vorgaben macht, testet, Iterationen anstößt und Entwicklungsschritte evaluiert. Das bedeutet oft den Einsatz hoher sozialer und fachlicher Kompetenz, um eigene und fremde Interessen im Projekt miteinander verbinden zu können.

Usability Engineer und Projektmanager

Die Parallelen zwischen den Tätigkeiten von Usability Engineer und Projektmanager liegen auf der Hand. Beide müssen auf die Erfüllung von Vorgaben bei anderen Projektbeteiligten dringen. Beide müssen Ãœberzeugungsarbeit nicht nur gegenüber Geschäftsleitung und Auftraggeber leisten, dass der Erfolg des Projektes und des Produktes durch Usability Engineering zumindest erhöht, besser noch garantiert ist. Beide stehen zwischen oder neben den Kollegen, die das konkrete Produkt tatsächlich erstellen. Und selbst wenn der Usability Engineer das Anwendungskonzept erstellt hat, wird die Gestaltung und technische Umsetzung von ihm doch nur begleitet. Er ist einerseits Begleiter und Evaluator laufender Arbeiten, andererseits reicht seine Verantwortung oft bis zur inhaltlichen Leitung eines Projektes. Ein weiteres mögliches Problem für den Usability Engineer ist, dass dem Auftraggeber die Methoden und Verfahren des UE unbekannt sind und keine Bereitschaft vorhanden ist, scheinbaren ‘Mehraufwand’ zu bezahlen. Hinzu kommt oftmals eine gravierende Fehleinschätzung des Auftraggebers über die realen Endkunden (technische Fähigkeiten, Produkterfahrung, Lernfähigkeit, Zeitverfügung, Gebrauchskontext).

UE erfüllt Anforderungen des Marktes, die im IT-Management bisher oft zu kurz gekommen sind: Gebrauchstauglichkeit, Realitäts- und Nutzerorientierung. Qualitäten, die darüber hinaus zu differenzierenden Produkteigenschaften werden, wenn sich die Angebote des Wettbewerbs zu ähnlich sind. Hohe Gebrauchstauglichkeit bzw. Gebrauchsfreundlichkeit kann (neben anderen Qualitätsmerkmalen) zum Markenwert und als Unterscheidung gegenüber Konkurrenten genutzt (z.B. Mercedes-Benz, Braun Haushaltsgeräte). Wird die Minimalanforderung Gebrauchstauglichkeit dagegen mißachtet, kommt es zu Desastern wie TollCollect oder dem Internetauftritt der Bundesagentur für Arbeit.

Vermehrt anzutreffen ist grundlegendes Wissen der Beteiligten über die Vorteile und Methoden des UE. Großunternehmen etablieren UE im Rahmen von Qualitätssicherungsmaßnahmen und den Qualitätsansprüchen ihrer (Premium)Marken. Die Rolle eines Usability Engineers wird hier vom Kunden eingefordert. Kleineren Unternehmen hingegen ist es aufgrund der vielfältigen Anforderungen des Tagesgeschäfts selten möglich, eine derart hohe Spezialisierung zu erreichen.

Zwingende Vorgaben des Gesetzgebers für eine höhere Gebrauchstauglichkeit von Produkten sind bisher selten, mit den Ausnahmen der ISO DIN 13407 (einschließlich Vorgaben für die Softwareerstellung) und dem gesetzlichen Vorgehen im Zusammenhang mit Barrierefreiheit (Voigt & Heers, 2004).

Fazit

Projekterfolg und die Etablierung von UE zeigen sich für Geschäftsleitung wie Auftraggeber letztlich am Erfolg der Produkte. Konkret bedeutet dies Kostenreduktion, Minimierung von Folgekosten, Einhaltung von Zeitplänen, erhöhte Wiederbeauftragung, geringere Garantie- und Kulanzkosten, Umsatz- und Gewinnsteigerung. Im Endeffekt geht es für alle Beteiligten um eine erhöhte Kundenzufriedenheit und (mittel- bis langfristig) Kundenbindung, die zu höheren Absätzen und (bei angemessener Preisgestaltung) zu höheren Umsätzen und Gewinnen führen sollte (Mayhew, 1999). In erfolgreichen Projekten zur Interface-Entwicklung sind (ohne andere Tätigkeiten herabwürdigen zu wollen), zwei Schlüsselrollen vorhanden – der Projektmanager und der Usability Engineer. Beide können sich gegenseitig zum Wohle des Projekts unterstützen oder behindern. Allerdings können beide gemeinsam die Basis eines (intern und extern) erfolgreich verlaufenden Projektes bilden, das ein am Markt erfolgreiches Produkt entwickelt.

Referenzen

  1. Barnum, C., Usability Testing and Research. Longman (2002).
  2. ISO DIN 13407, Benutzer-orientierte Gestaltung interaktiver Systeme. Beuth (1999).
  3. DeMarco, T.: Wien wartet auf Dich! Der Faktor Mensch im DV-Management. Hanser (1999).
  4. Hackos, J. T. & J. C. Redish: User and Task Analysis for Interface Design, Wiley (1998).
  5. Mayhew, D., The Usability Engineering Lifecycle. Morgan Kaufman (1999).
  6. Nielsen, J. & Mack, R., Usability Inspection Methods. Wiley (1994).
  7. Sprenger, R., Vertrauen führt. Campus (2002).
  8. Wischnewski, E., Modernes Projektmanagement. Vieweg (2001).
  9. Heers, R., Voigt, S., Gutes Design per Gesetz? Anmerkungen zur Barrierefreiheit in der Informationstechnik. Beitrag im UPA-Track der Konferenz Mensch & Computer, Paderborn, 06.-08. Sept. 2004.

Geschrieben in der Kategorie Barrierefreiheit, Fachartikel | Keine Kommentare »

‘Gutes’ Design per Gesetz? Anmerkungen zur Barrierefreiheit in der IT

Dienstag, 07. September 2004

Dr. Stefan Voigt und Rainer Heers, basierend auf dem Vortrag auf der Tagung Mensch und Computer 2004

Abstract

Die Gesetze sind erlassen, die Standards sind bekannt, die Technologie ist fortgeschritten, öffentliche Träger müssen ihre Internetangebote barrierefrei gestalten – wie steht es aber um die konkrete Umsetzung von Barrierefreiheit? Und: Kann man gutes Design per Gesetz verordnen? Der Text beschreibt, ausgehend von den gesetzlichen Vorgaben, welche Besonderheiten die Umsetzung von Barrierefreiheit in Deutschland aufweist und warum nicht alles, was gut gemeint ist, schon gut gemacht ist.

Keywords

Barrierefreiheit; Behindertengleichstellungsgesetz, BGG; BITV; Accessibility, Zielvereinbarungen.

1. Voraussetzungen

Der deutsche Gesetzgeber hat mit dem am 1. Mai 2002 in Kraft getretenen Behindertengleichstellungsgesetz (BGG) vom 27.04.2002 umfassende Richtlinien für die Gleichstellung von Behinderten und Nicht-Behinderten geschaffen. Das Gesetz ist weniger ein Vorschriftengesetz als vielmehr ein Instrument, “mit dem man arbeiten muss” [1]. Es regelt u.a. die Verbesserung von baulichen Anlagen, Verkehrsmitteln, technischen Gebrauchsgegenständen, Systemen der Informationsverarbeitung, akustischer und visueller Informationsquellen und anderer gestalteter Lebensbereiche.

Die Konkretisierung der dem Gesetz zugrundeliegenden allgemeinen Forderung, dass diese Lebensbereiche behinderten Menschen “in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe zugänglich und nutzbar sind” (BGG § 4), liegt aber in den Händen der Bundesländer, die in eigenen Landesgleichstellungsgesetzen die Umsetzung regeln müssen; der behinderten Bürgerinnen und anerkannter Behindertenverbände, die über das neue Instrument der sog. Zielvereinbarungen mit privaten Unternehmen und Einrichtungen Verträge zur Herstellung von Barrierefreiheit schließen können (und vom Gesetz mit der Möglichkeit von Verwaltungs- bzw. Verbandsklage bewehrt wurden).

Im § 11 regelt das BGG barrierefreie Informationstechnik und stellt klar, dass Träger öffentlicher Gewalt “ihre Internetauftritte und -angebote sowie die von ihnen zur Verfügung gestellten grafischen Programmoberflächen, die mit Mitteln der Informationstechnik dargestellt werden”, so zu gestalten haben, “dass sie von behinderten Menschen grundsätzlich uneingeschränkt genutzt werden können”.

Außerdem verpflichtet sich die Bundesregierung, darauf hin zu wirken, “dass auch gewerbsmäßige Anbieter von Internetseiten sowie von grafischen Programmoberflächen, die mit Mitteln der Informationstechnik dargestellt werden, durch Zielvereinbarungen [...] ihre Produkte entsprechend den technischen Standards [...] gestalten.”

Ergänzend und konkretisierend zum BGG hat das Bundesministerium des Inneren am 27. April 2002 die “Verordnung zur Schaffung barrierefreier Informationstechnik nach dem Behindertengleichstellungsgesetz” (BITV) erlassen. In ihr und der ergänzenden Anlage wird sehr konkret und technisch auf der Höhe vorgeschrieben, was bei der Erstellung von Informationsangeboten zu berücksichtigen ist, damit sie die Ansprüche der Barrierefreiheit erfüllen. Die Verordnung beruft sich bei ihrer Vorgabenformulierung explizit auf die Zugänglichkeitsrichtlinien des World Wide Web Konsortiums (Web Content Accessibility Guidelines 1.0) [2] und sieht nach drei Jahren eine Ãœberprüfungsregelung vor, die als Indikator der technischen Entwicklung u.a. das Vorliegen einer neuen Fassung der Web Content Accessibility Guidelines des W3C berücksichtigen will.

2. Besonderheiten

Im Zusammenhang mit Barrierefreiheit in der Informationstechnik haben wir es also mit mehreren ungewöhnlichen Fakten zu tun:

  • Eine (verordnete) ‘Avantgarde’-Funktion öffentlicher Träger in Bezug auf die Umsetzung technischer Richtlinien und Standards für Internetangebote;
  • Ein (Bundes)Gesetz, dass seine Umsetzung nicht über Sanktionen erzwingen will, sondern über sog. Zielvereinbarungen als sozialen Regelungsmechanismus;
  • Gesetzliche Vorschriften zur Gestaltung von Internetauftritten öffentlicher Träger;
  • Eine Bundesregierung, die gewerbliche Internetangebote zur Beachtung technischer Standards bewegen will;
  • Eine Gesetzesverordnung, die sich auf die technischen Richtlinien eines nicht-staatlichen, größtenteils privat finanzierten Konsortiums [3] stützt;
  • Eine ‘Update-Funktion’ für eine Gesetzesverordnung in Hinblick auf weitere technische Entwicklungen.

Neben diesen Besonderheiten bleibt als Anekdote am Rand festzuhalten, dass das Globalisierungsmedium per se, das Internet, in der deutschen Gesetzgebung auf eine unzeitgemäße Kleinstaaterei trifft. Während sich die Bundesregierung mit BGG und BITV durchaus ambitioniert und innovativ für die international anerkannten und weitverbreiteten Standards des W3C stark gemacht hat, geht deren Ãœbernahme (und damit praktische Umsetzung) auf Ebene der Bundesländer nur sehr schleppend voran [4]. Es darf getrost bezweifelt werden, ob die sich bereits abzeichnenden unterschiedlichen Ausformungen der internationalen Standards auf Landesebene der Sache – der Durchsetzung umfassender Barrierefreiheit – dienen werden. Die global und oft technisch begründeten Ansprüche von W3C, Web Accessibility Guidelines und BITV werden an Ländergrenzen angepasst, die das Medium längst nicht mehr kennt.

3. Ãœberlegungen

Geht man von den beschriebenen Voraussetzungen aus, zeigt sich dem Beobachter, dass Bundesregierung und Bundesländer (mit Hilfe von BGG, BITV und deren Ãœbernahme in Landesgesetze) ihre Gesetzesgewalt dazu nutzen, um im Internet ‘gutes Design’ zu evozieren. Interessant ist dieses Phänomen zum einen, weil es etwa in Print- oder elektronischen Medien keine äquivalente zu diesem Vorgehen gibt. Keine Zeitung in Deutschland ist dazu verpflichtet, eine Blindenausgabe zu erstellen und kein Radio- oder Fernsehsender wird bisher qua Gesetz dazu angehalten, seine Sendungen mit eingeblendetem Gebärdendolmetscher oder einem Signal für Braille-Lesegeräte zu übertragen. Zum anderen zeigt das gesetzgeberische Engagement in Bezug auf die Barrierefreiheit von Internetangeboten, dass der Gesetzgeber (übrigens selbst im Vergleich mit Privatunternehmen relativ früh) begriffen hat, dass die Technologie des Internets sich nicht nur innerhalb kürzester Zeit von einer bloßen Technologie zu einer Kulturtechnik entwickeln wird, sondern auch, dass die Entwicklung auch mittel- und langfristig ausgesprochen dynamisch ablaufen wird. So gesehen sichern die gesetzlichen Initiativen zur Barrierefreiheit nicht nur die bloße, in ihrer Bedeutung aber gar nicht zu nicht überschätzende, Zugänglichkeit zu Informationen (als direkte Ãœbersetzung der angelsächsischen Accessibility) für behinderte Menschen, sondern sogar Grundrechte wie das Grundrecht auf Informationsfreiheit.

Begreift man den Gesetzgeber als Erzwinger von ‘gutem Design’, ergibt sich weiterhin der bemerkenswerte Umstand, dass sich die öffentlichen Träger in Bezug auf die Umsetzung barrierefreier Informationstechnik in einer (ungewohnten) Rolle als technische Avantgarde oder zumindest als early adopters wiederfinden. Eine Rolle, in der sie im öffentlichen Bewusstsein und faktisch sicherlich selten anzutreffen sind. Erschwerend kommt für sie hinzu, dass trotz fortgeschrittener Technologie, trotz wichtiger Verbesserungen im Bereich der Content Management Systeme, trotz steigender Praxiserfahrungen und trotz weiterer Arbeit des W3C die Umsetzung von Barrierefreiheit weiterhin ein Projekt mit hohen technischen und fachlichen Anforderungen bleibt [5]. Um der Verantwortung der öffentlichen Träger – und seinem eigenen Anliegen in Sachen Barrierefreiheit – Nachdruck zu verleihen, hat der Gesetzgeber den Regelungsmechanismus der Zielvereinbarungen eingeführt [6].

Betroffene behinderte Menschen oder ihre anerkannten Verbände sollen über die Aushandlung von Zielvereinbarungen (auch mit Unternehmen) konkrete Änderungen zur Barrierefreiheit in möglichst vielen Lebensbereichen durchsetzen. Zieht man hier, gewissermaßen auf halbem Weg zwischen Gesetzeserlass und der durch sie vorgeschriebenen Durchsetzung von Barrierefreiheit bis Ende 2005 [7], eine Halbzeitbilanz, erweist sich gerade dieses auf den ersten Blick innovative Instrument (s.o.) als das schwächste Glied in der Kette. In der Datenbank (sic) des Bundesministeriums für Gesundheit und Soziale Sicherung finden sich bisher (Stand Mitte Juni 2004) drei Zielvereinbarungen, zwei davon sind im Verhandlungsstadium, eine ist lediglich angekündigt [8].

Kommen wir zurück auf die Ausgangsüberlegung, dass der Gesetzgeber im Zusammenhang mit Barrierefreiheit als Erzwinger von gutem Design agiert. Berücksichtigt man das bisher Gesagte, ergibt sich als Fazit für die bisherige Umsetzung von Barrierefreiheit in Deutschland eine Erkenntnis, die auch aus anderen Lebensbereichen bekannt ist: Gut gemeint ist noch nicht gut gemacht. Dem Gesetzgeber sind zwar durchaus hehre Ziele und eine relativ schnelle und innovative Vorgehensweise zu bescheinigen, in Sachen Umsetzung aber auch eine Fehleinschätzung der Innovationskraft öffentlicher Träger, eine Ãœberschätzung des Instrumentariums von Zielvereinbarungen (den Versuch war es aber vielleicht wert) und die (bisher) völlig Ausblendung privatwirtschaftlicher Internetangebote. Hier ist zu fragen, ob bei einer demnächst anstehenden Ãœberprüfung der BITV nicht andere Steuerungsmittel zur Umsetzung von Barrierefreiheit in der Informationstechnik denkbar wären, etwa – anlog zum GS-Prüfzeichen für technische Produkte – eine Zertifizierung durch unabhängige Gutachter. Die Arbeiten des W3C an den Web Content Accessibility Guidelines 2.0 sind bereits weit fortgeschritten und weisen ebenfalls in Richtung einer besseren Ãœberprüfbarkeit der Richtlinien. Es bleibt also spannend in Sachen Barrierefreiheit.

4. Referenzen

  1. H.-Günter Heiden in einer Broschüre zur praktischen Umsetzung des BGG: http://www.netzwerk-artikel-3.de/dokum/bggleitfaden-standard.pdf (PDF)
  2. Die bei der Erstellung der Richtlinien federführende Web Accessibility Initiative des W3 Konsortiums findet sich unter http://www.w3.org/WAI/, die von ihr erstellten Web Content Accessibility Guidelines unter http://www.w3.org/TR/WCAG10/
  3. Vgl. die aktuelle Mitgliederliste des W3C: http://www.w3.org/Consortium/Member/List. Nach eigener Definition sind die Mitglieder des W3C vor allem Anbieter technologischer Produkte und Dienstleistungen, Inhalteanbieter, Firmen, Forschungslaboratorien, Standardisierungsgremien und Regierungen.
  4. Zum Stand der Umsetzung von BGG und BITV in Landesgesetz vgl. die gute und aktuelle Dokumentation bei Einfach-für-alle (http://www.einfach-fuer-alle.de/artikel/bitv/landesgleichstellungsgesetze).
  5. Dies zeigt sich auch daran, dass in der Privatwirtschaft und selbst bei IT-Dienstleistern und -Produzenten Barrierefreiheit immer noch ein weitgehend unbekanntes Qualitätskriterium für Internetangebote ist. Das Internetportal Einfach für Alle der Aktion Mensch listet ganze drei Internetangebote als ‘Ãœberflieger’ in Bezug auf realisierte Barrierefreiheit auf (Stand Mitte Juni 2004), zwei davon sind Projekte öffentlicher Träger.
  6. Zum Entstehen der Regelung über Zielvereinbarungen und ihrer (geplanten) Anwendung (http://www.netzwerk-artikel-3.de/dokum/refzielv.php)
  7. Zu den Umsetzungfristen s. BITV http://bundesrecht.juris.de/bundesrecht/bitv/__4.html
  8. Datenbank für Zielvereinbarungen (http://www.bmgs.bund.de/deu/gra/datenbanken/ziel/index.cfm)

Geschrieben in der Kategorie Barrierefreiheit, Fachartikel | Keine Kommentare »

Wider die Unart, neue Fenster zu öffnen

Dienstag, 27. Juli 2004

Der Geist ist willig, doch das Fleisch ist schwach; und der Mensch nach Schopenhauer nur ein zerstäubender Tropfen in einem tobenden Wasserfall. Aber: ist das ein aus- oder hinreichender Grund, nicht nachzudenken, nicht intelligent zu sein, nicht menschenfreundlich zu handeln? Wohl kaum! Deshalb, liebe Programmierer, liebe Web-Designer, liebe Content Manager: öffnet nicht ständig neue Fenster, benutzt nicht den HTML-Tag target="_blank" und schon gar nicht den Javascript-Schnipsel window.open! Eine Website sollte dem Nutzer / der Nutzerin niemals (in Worten: niemals) ein neues Fenster aufzwingen. Warum nicht? Darum:

  • Ob neues Fenster oder nicht, ist Sache der Nutzerin.
  • Wie jemand seinen Browser benutzt, ist seine Sache.
  • Neue Fenster verlieren den Verlauf der vorangegangenen Fenster.
  • Der Nutzer will selten ein neues Fenster.
  • Neuere Browser blockieren Pop-Ups.
  • Eine gute Website hat es nicht nötig, ständig neue Seiten zu öffnen (beim Fernsehen zappen wir ohne Probleme zwischen verschiedenen Anbietern – mit nur einem Bildschirm).
  • Neue Fenster beeinträchtigen die Bewegungsfreiheit des Nutzers und schränken die Nutzbarkeit von Seiten ein.
  • Neue Fenster sollten die (seltene) Ausnahme von der Regel sein.
  • Javascript funktioniert nicht immer (schon gar nicht, wenn es der Nutzer ausgeschaltet hat).
  • Mit Javascript geöffnete Seiten lassen sich schwerer auswerten.
  • Neue Fenster widersprechen dem Grundgedanken von H(yper)T(ext)ML.
  • Das target-Attribut ist in XHTML 1.1 nicht mehr relevant und als “deprecated” (=abgelehnt) eingestuft.
  • Valide target-Attribute funktionieren nur in modernen Browsern.

Conclusio: Das Öffnen von neuen Fenstern ist veraltet, verärgert die Seitenbesucher und bringt wenig Vorteile. Deshalb: sein lassen.

(Dieser Beitrag folgt den Ausführungen von Jesper Tverskov auf seiner Seite www.smackthemouse.com

Geschrieben in der Kategorie Barrierefreiheit, Design, Konzeption / IA, Usability | Keine Kommentare »

« Vorherige Seite
Neuere Beiträge »