KLARTEXT - Der Podcast für IT OHNE BARRIEREN. Interessante Informationen und wertvolles Wissen zur digitalen Barrierefreiheit in der Arbeitswelt. Ein Podcast zum Forschungsprojekt iDESkmu, gefördert vom Bundesministerium für Arbeit und Soziales, unter der Federführung des Blinden- und Sehbehinderten- vereins Hamburg. Hallo und herzlich willkommen zur Episode #03! Mein Name ist Nadia David. Hören Sie heute einen Vortrag von Anne-Marie Nebe der T-Systems Multimedia Solutions GmbH. Als Accessibility und Usability Expert spricht sie über Kriterien für die Standardkonformität von DMS und CMS. Anschließend redet Wolfgang Haase mit Vanessa Matz, freie Beraterin, über das Thema "Erfolgreiche Führung in IT Projekten". In den Shownotes finden Sie die Timecodes zu den Beiträgen und die Hintergrundinformationen zu unseren Gesprächspartnern und Gästen. Zum Einstieg in die Episode hören Sie wieder einen kurzen Auszug aus einem bekannten Märchen. Es war einmal ein kleines Mädchen, das von allen gemocht wurde. Ihre Großmutter schenkte ihr ein schönes rotes Käppchen aus Samt. Und weil ihr das Käppchen sehr gefiel, wollte sie es garnicht mehr ausziehen. Darum wurde es von allen Rotkäppchen genannt. Eines Tages sprach ihre Mutter zu ihr: "Rotkäppchen, ich gebe dir ein Körbchen mit einem Kuchen und eine Flasche Wein. Bringe dieses Körbchen bitte zur Großmutter hinaus. Sie ist krank und schwach und wird sich darüber freuen." "Ja, das möchte ich gern tun.", sagte Rotkäppchen zur ihrer Mutter. Die Großmutter wohnte draußen im Wald, eine halbe Stunde vom Dorf entfernt. Das war Rotkäppchen. Gelesen von Petra aus der Mac internen Screenreader Software VoiceOver in der Geschwindigkeit 90 von 100. Hören wir nun den Vortrag von Anne-Marie Nebe. Ja, einen wunderschönen guten Tag! Detlef Girke mein Name und ich habe heute im Studio Anne-Marie Nebe, ihres Zeichens Expertin für barrierefreie IT bei T-Systems. Hallo Anne-Marie! Hallo! Ja, du hast mich ja schon ganz gut vorgestellt. Mein Name ist Anne-Marie Nebe. Ich arbeite als Experte für digitale Barrierefreiheit und Software-Ergonomie bei der T-Systems Multimedia Solutions GmbH. Ein ganz langer Name. Ja, herzlich willkommen auch von meiner Seite. Vielen Dank! Bevor du startest - heute soll es ja darum gehen, dass du uns etwas über Standards der barrierefreien IT erzählst. Erzähle doch mal ein bisschen was über dich kurz. Wie überhaupt bist du zur barrierefreien IT gekommen? Ja, das war ein langer und sehr abwechslungsreicher Weg. Aber ich glaube, wir sind dem Thema im Moment alle Quereinsteiger. Ich habe ursprünglich mal Design studiert und war sehr, sehr lange selbstständig und habe zum Schluss dann sehr viel Web-Optimierung gemacht, unter anderem Gestaltungs- optimierung, aber auch SEO. Und irgendwann habe ich beschlossen, das, was ich für Maschinen mache, nämlich die Suchmaschinenoptimierung, was sehr viel mit Semantik zu tun hat, das möchte ich gerne für Menschen machen und bin dann irgendwie bei einem super Team gelandet hier in Dresden und arbeite jetzt mit einem Team von 25 Leuten, die sich ausschließlich mit diesem Thema beschäftigen. Und das macht unwahrscheinlich viel Spaß. Super, großartig! Gut, du hast einen Vortrag vorbereitet. Ich werde mich jetzt einfach mal stummschalten und freue mich von dir zu hören. Ja, ihr habt mich gebeten, ein kurzes Statement zu geben, was man beachten sollte bei barrierefreien Dokumentmanagementsystemen. Und da diese Systeme ja innerhalb der Digitalisierung, die wir gerade auch in Deutschland machen, eine riesengroße Rolle spielen, möchte ich einen kurzen Einblick da auch reingeben. Erst mal: Wie funktioniert eigentlich so ein Dokumentmanagementsystem? Wo wird es eingesetzt? Warum sollte es barrierefrei sein? Und dann möchte ich eigentlich einsteigen. So ein Überblick über die gesetzlichen Anforderungen, aber auch Standards, die es hier gibt. Und das soll uns führen zu der rein praktischen Frage: Was muss ich denn tun, um tatsächlich ein barrierefreies Dokument- managementsystem anbieten zu können, nutzen zu können, zur Verfügung zu stellen? Schauen wir uns also erst mal an, wie funktioniert so ein DMS, also Dokumentmanagementsystem. Und das ist ein recht komplexes Teil, weil ich habe hier unterschiedliche Herangehensweisen, Workflows, Arbeitsschritte, die insgesamt alle irgendetwas mit Dokumenten zu tun haben. Wir reden bei einem DMS natürlich von einem digitalen System. Nichtsdestotrotz kann es passieren, dass wir hier Papierdokumente haben, die eben noch digitalisiert werden müssen. Das wäre auch eine Aufgabe, die so ein DMS vollziehen muss. Das heißt, wir müssen hier Papierdokumente scannen, zum Beispiel klassifizieren oder auch in Ordner packen. Und das führt uns auch zur zweiten großen Aufgabe von so einem Dokumentmanagementsystem. Das wäre die Verwaltung, die Archivierung oder die Zuordnung eben beispielsweise eines Dokumentes in eine digitale Akte. Und die letzte ganz große Aufgabe ist natürlich auch, solche Dokumente innerhalb des Systems zu verteilen, weiter zu bearbeiten oder auch zu archivieren, in Signierungsketten zu geben, ähnliche Dinge. Und wo werden eigentlich solche Dokumentmanagementsysteme eingesetzt? Eigentlich überall, also in jedem größeren Unternehmen, in Regierungsbehörden, in der Justiz. Und wenn ich jetzt das Stichwort E-Akte mal ausspreche, dann glaube ich, wird klar, was für eine große Rolle Dokument- managementsysteme bei der Digitalisierung spielen. Und wir sehen diese große Ausprägung, diesen vollen Funktionsumfang von DMS Systemen nicht überall und immer. Also, es wird nicht immer mit allen Funktionen eingesetzt, aber der Umgang mit elektronischen Akten ist doch ein essenzieller Bestandteil der heutigen Verwaltungstätigkeit. Egal ob wir jetzt in einem privaten Unternehmen, in einer öffentlichen Stelle, in einer Behörde oder in der Justiz sind. Und das führt uns auch zu der Frage oder zu der Feststellung eigentlich schon: Warum sollte ein Dokument- managementsystem barrierefrei sein? Eben weil sie überall Anwendung finden. Und weil wir viele, viele Menschen haben, die mit unterschiedlichsten Rollen im Arbeitsprozess auf dieses Managementsystem zugreifen. Da haben wir Menschen, die archivieren, die bearbeiten, die administrieren, die Dokumente lesen oder verteilen oder signieren. Also, wir merken sehr, sehr viele Aufgaben von sehr, sehr vielen Menschen, die alle auf ein System zugreifen. Und das Fazit, was man hier eigentlich ziehen kann, ist, dass wir ein vielfach eingesetztes System haben mit einer hohen Nutzung durch viele Menschen und das impliziert eigentlich Barrierefreiheit, denn barrierefreie Anwendungen sind so gestaltet, dass sie von der größtmöglichen Anzahl von Menschen genutzt werden können. Barrierefreiheit ist also, wenn wir aus der Nutzersicht herausgehen, eine notwendige Software- oder auch Dokumentqualität. Und damit stellt sich eigentlich die Frage nicht mehr, muss ein Dokument- managementsystem barrierefrei sein? Nein? Oder doch? Es ist eine Grundvoraussetzung, die wir hier schaffen wollen. Und um diese Grundvoraussetzung soll es eben auch gehen. Wie gesagt, eine Grund-Qualität, die ich hier bei diesem System auf jeden Fall sehe. Was braucht es denn für ein Dokumentsystem? Wenn ich sage, es soll barrierefrei sein, was für Komponenten davon müssen denn dann eigentlich barrierefrei sein? Prinzipiell alle! Das ist eine sehr vage Aussage, deshalb will ich die auch ein bisschen verifizieren. Das heißt, wir brauchen für ein barrierefreies Dokumentmanagementsystem zum einen die Software zum Erzeugen von barrierefreien Dokumenten. Das kann also zum Beispiel sein eine Quellsoftware wie eine Textverarbeitung, wie zum Beispiel Microsoft Word oder auch ein Layout-Programm wie Adobe InDesign oder ähnliche Dinge. Das kann natürlich auch eine System- software sein, die sagt, ich wandle beispielsweise über ein Scan ein Papier- dokument in ein digitales Dokument um. Auch das ist eine Software zum Erzeugen von Dokumenten. Diese Software muss eben auch barrierefrei sein, damit ich zum Schluss ein barrierefreies Dokument- managementsystem habe. Das zweite, was ich brauche, ist natürlich das Managementsystem an sich. Das muss selbst auch barrierefrei sein. Das heißt, ich brauche das Anwendungsprogramm zum Verteilen, zum Bearbeiten, zum Archivieren. Wir haben ja die Rollen alle schon genannt. Und die Aufgaben. Was braucht es noch? Es braucht das barrierefreie Dokument oder viele, viele barrierefreie Dokumente, die in diesem System verarbeitet werden. Und es braucht natürlich auch eine Software, in dem ich das barrierefreie Dokument auch barrierefrei angucken kann, um es zum Beispiel zu bearbeiten und so weiter. Das heißt, wir haben hier vier Komponenten, die in so einem Dokument- system zum Tragen kommen, wenn ich mit digitalen Anwendungen oder mit digitalen Dokumenten arbeite. Das ist zum einen die Software zum Erzeugen, das Dokumentmanagementsystem an sich, das Dokument selbst und die Software zum Lesen des Dokumentes. Nur wenn alle diese vier Komponenten auch wirklich barrierefrei sind, kann ich von einem barrierefreien DMS im Großen und Ganzen auch reden und davon ausgehen. Jetzt haben wir die Nutzersicht so ein bisschen aufgemacht und ich möchte neben der Nutzersicht auch eine Gesetzessicht aufmachen und einen Überblick geben über die Mindestanforderungen für solche barrierefreien Dokumentsysteme, wie sie uns aus dem Gesetz vorgegeben werden. Und jetzt nenne ich eine Richtlinie, die schon mal in aller Munde ist und jetzt ganz fleißig in Deutschland auch daran gearbeitet wird, diese umzusetzen. Das ist die EU-Richtlinie 2016, die 21 02: barrierefreie IKT-Anwendungen für öffentliche Stellen und diese Web Accessibility Directive, die die EU hier herausgegeben hat, die hat auch ins deutsche Recht Überführung gefunden und schlug sich nieder in eine Änderung des Behinderten- gleichstellungsgesetzes und der daraus hervorgehenden Barrierefreien Informationstechnik Verordnung, kurz BITV, die 2019 aktualisiert wurde, gleichwohl die Nummer der Verordnung sich nicht geändert hat. Es bleibt also weiterhin die BITV 2.0. Ich rede da immer von der Version 2019. Das ist ein gesetzlicher Hintergrund hinter barrierefreien DMS. Ein zweiter Hintergrund - und der ist ziemlich aktuell auch gerade durch die Medien gegangen - ist die Umsetzung der EU-Richtlinie aus dem Jahr 2019, die 8802, der European Accessibility Act. Und der soll die Barrierefreiheitsanforderungen von Produkten und Dienstleistungen im europäischen Wirtschaftsraum gleichschalten. Und das schlägt sich jetzt gerade auch nieder in einem neuen Stammgesetz, was aktuell verabschiedet wurde. Das ist das Barrierefreiheits- stärkungsgesetz. Es schlägt sich auch nieder diese Richtlinie in den Medienstaatsvertrag, in das Telekommunikationsmodernisierungs- gesetz und so weiter und so weiter. Das heißt, wir haben hier neben den öffentlichen Stellen jetzt auch die Privatunternehmen, die zukünftig barrierefreie unter anderem auch Dokumente oder barrierefreie DMS zur Verfügung stellen sollen und damit arbeiten sollen. Daneben gibt es natürlich auch noch - das Gesetz ist vielfältig - Anforderungen aus dem E-Justice-Raum oder aus dem E-Government-Raum. Das heißt, wir brauchen auch barrierefreie Dienstleistungen für Bürger oder innerbehördliche oder auch zwischenbehördliche Kommunikation. Als Beispiel möchte ich hier vielleicht mal nennen das Onlinezugangsgesetz, das Barrierefreiheit schon als konstituierendes Ziel sieht, d. h. als Grundvoraussetzung für Dienstleistungen der öffentlichen Hand oder der öffentlichen Stellen für den Bürger definiert. Also, wirklich Barrierefreiheit als Grundvoraussetzung und als Grundqualität definiert. Die Gesetzgebung, auf die ich ein bisschen mehr eingehen möchte und tiefer eingehen möchte, ist die BITV 2.0, die Barrierefreie- Informationstechnik-Verordnung, die quasi wie... Ja, also wieso eine grundgesetzliche Voraussetzung für alle möglichen Arten von Technologien darstellt, die barrierefrei veröffentlicht werden sollen. Das geht also von Web Technologien über Software über Dokumente, also alles das abbildet, was wir ja auch in unserer Definition eines DMS abgegeben haben. Also, wir brauchen die Software für die Verarbeitung des Dokumentes, wir brauchen das Dokument selber, wir brauchen eine Software zum Lesen. Die Software kann eine Webanwendung sein, kann aber auch eine Desktop Anwendung sein. Das heißt, die BITV bildet das alles ab und bildet hier den großen Rahmen dafür, wo ich sagen kann, da finde ich alle Anforderung, die ich von gesetzlicher Seite her erfüllen muss, wenn ich etwas barrierefrei gestalten möchte. Die BITV wiederum selbst enthält nicht eigens in sich selbst definiert Anforderungen zur Barrierefreiheit, also rein technische Anforderungen. Die finden wir in der EN - also wieder eine europäische Norm diesmal, nicht Richtlinie, sondern Norm - die 301 549, die Nutzeranforderungen für alle möglichen Anwendungen, Angebote und Dienste regelt. Und die den jetzigen Stand der Technik darstellt, wie ich eine barrierefreie Gestaltung umsetzen kann. Und wenn wir aus dieser BITV und der aus der BITV verwiesenen EN einmal hier eine Zusammenfassung machen wollen für ein barrierefreies Dokument- managementsystem, dann gelten hier sozusagen als gesetzlicher Rückhalt die BITV 2.0 und als Rückhalt für Normen und Standards für die Ausführung eines barrierefreien DMS die EN 301 549. Und da unterschiedlichste Abschnitte. Dann nehmen wir zum einen den allgemeinen Abschnitt, der allgemeine Richtlinien zur Barrierefreiheit zum Zugang für alle Menschen regelt, zu digitalen Angeboten. Dann haben wir die technologisch spezifischen Abschnitte, wie zum Beispiel Software oder Web oder auch den Abschnitt Dokumente, die also zum Beispiel Anforderung an das Dokument an sich definieren. Aber wir haben auch Abschnitte, die auf die Darstellungssoftware, also auf den Benutzeragenten, den ich benötige, um ein barrierefreies Dokument überhaupt anzeigen zu können. Auch dafür sind Anforderungen in der EN 301 549 definiert. Und wir haben einen Abschnitt, der sich um Autorensysteme kümmert, also Anforderungen definiert an die Erzeugungs- software von Dokumenten. Das heißt, die BITV bietet den gesetzlichen Rahmen. Die EN 301 549 bietet den standardisierten Rahmen, um alle Bestandteile eines barrierefreien Dokumentmanagement- systems abbilden zu können. Aus beiden heraus, also sowohl aus den Erläuterungen zur BITV als auch aus der EN 301 549, wird noch ein weiterer Standard aufgerufen, wenn es um eine spezielle Dokument- form geht oder ein Dateiformat geht. Und das bezieht sich auf die PDF Dokumente. Beide verweisen hier auf die DIN ISO 14 289 für die Barrierefreiheit von Dokumentmanagement-Anwendungen, also direkt das Thema, worum es hier auch geht. Allerdings, und das sollte man im Hinterkopf behalten, behandelt diese DIN ISO 14 289 ausschließlich PDF Dokumente und die Anforderungen, die für diesen Dateityp gelten. Und auf diesen Dateityp, weil er so häufig auch genutzt wird und weil er sich auch so super archivieren lässt, möchte ich vielleicht ein bisschen näher eingehen. PDF ist also ein digitales Format zur Repräsentation von Dokumenten und PDF-Dateien können zum einen nativ in PDF-Form sowie durch Konvertierung aus anderen elektronischen Formaten, zum Beispiel von TXT zu PDF oder von HTML zu PDF oder durch Digitalisierung von Papierdokumenten erstellt werden. Und da haben wir schon die erste große Säule. Was bietet eigentlich ein Dokumentmanagementsystem, nämlich die Digitalisierung oder die Bereitstellung überhaupt von Dokumenten? Zum einen nativ: ich sage, ich habe also direkt ein PDF erzeugt. Oder eben, ich habe ein PDF aus einem anderen Dokument erzeugt. Oder ich habe ein Papierdokument gescannt und digitalisiert. Die Anforderung, die wir hier finden, die DIN ISO 14 289, die sich also um Dokument- management-Anwendungen für PDF Dokumente kümmert, die ist auch sehr, sehr gut bekannt unter dem Standard PDF/UA Universal Access, also PDF Universal Access, abgekürzt PDF/UA. Und dieses Dateiformat ist sozusagen das Dateiformat, was alle Anforderungen an barrierefreie PDF Dokumente definiert. In der DIN ISO 14 289 finden wir zusätzlich neben den Anforderungen für das reine Dokument auch Anforderungen definiert für die Lese-Anwendung für das Dokument, also zum Beispiel den Acrobat Reader oder den Visual Impaird Reader oder Foxit Reader. Egal welchen oder eben selbst erstellte Lese-Anwendungen in Dokumentmanagementsystemen. Und es definiert auch die Barrierefreiheit vom Autorensystem selbst. Das heißt, in der DIN ISO 14 289 finden wir für das Dateiformat PDF ganz konkrete Definitionen. Für alle anderen Dokument-Dateiformate schauen wir in die EN 301 541 in die entsprechenden Kapitel. Jetzt in der Zusammenfassung. Schritt eins: ich mache das Managementsystem an sich barrierefrei, zum Beispiel gemäß der europäischen Norm 301 549. Zum Beispiel, indem ich die Anforderungen aus dem Kapitel "Desktop Software" mir anschaue. Oder eben aus, wenn ich eine Webanwendung bauen möchte als DMS, wenn ich hier das Kapitel Webanwendung anschaue, das ist das Kapitel 9 der europäischen Norm. Als zweiten Schrittich: ich erstelle nur noch barrierefreie Dokumente. Dazu benötige ich eine Erstellungs- software, die die Fähigkeit hat, dies auch zu tun oder eben eine Digitalisierungssoftware, die Papierdokumente in barrierefreie Dokumente umwandeln kann. Das heißt, hier muss ich auch aufpassen, egal was ich für einen Prozess fahre, egal ob ich sage, ich stelle meine Dokumente selber her. Ich lasse meine Dokumente digitalisieren und möchte, dass sie dann barrierefrei geliefert werden. Oder ich habe eine serverseitige Umwandlung des Dokuments von einem Dateiformat in ein anderes Dateiformat. Egal wie, ich erstelle nur noch barrierefreie Dokumente. Das ist eine Voraussetzung, dass mein DMS auch wirklich barrierefrei funktioniert. Den dritten Schritt, den ich brauche: Ich gebe tatsächlich auch nur noch barrierefreie Dokumente in das System ein. Also, ich brauche sozusagen die Erstellung des Dokumentes und ich brauche auch die Software, die barrierefreie Dokumente überhaupt zur Verfügung stellen kann. Und den vierten Schritt: ich habe oder stelle bereit einen barrierefreien Dokument-Leser. Das heißt, ich brauche auch ein barrierefreies Anzeige-Programm für meine barrierefreien Dokumente. Das Ganze möchte ich noch mal an dem Beispiel Dokument oder Dateiformat PDF/UA zeigen. Das PDF/UA stellt prinzipiell erst mal sicher, dass PDF Dokumente den Anforderungen der EN 301 549 entsprechen. Was für ein Ziel hat eigentlich das PDF/UA? Alle Menschen sollen selbstständig Informationen in PDF Dokumenten wahrnehmen und nutzen können. Dabei sollen sie ein bestimmtes Ziel in einem bestimmten Nutzungskontextes erreichen können, zum Beispiel eben eine Information im Dokument auf eine einfache und direkte Weise und in angemessener Zeit erreichen können und dabei natürlich PDF Dokumente in der gleichen Qualität nutzen können wie andere Menschen ohne Beeinträchtigung. Aus diesem Standard heraus, also aus der DIN ISO eins vier zwei acht neun, ist ein Protokoll entstanden, das sogenannte Matterhorn Protokoll, was es uns ermöglicht, mithilfe von Fehlerbedingungen die Konformität zu diesem Standard abzufragen. Das heißt zu gucken, ist das PDF Dokument und auch die Software, die das Dokument herstellt, in der Lage, eine barrierefreie Ausgabe zu ermöglichen. Und dabei werden Fehler- bedingungen abgefragt. Dieses Matterhorn Protokoll hat dabei 31 Prüfpunkte mit 136 Fehlerbedingungen. Und einen Hinweis möchte ich hier geben, denn zur Prüfung oder zur Konformitätsaussage wird sehr, sehr häufig der PDF Accessibility Checker benutzt, sogenannte PAC, der auf dem Matterhorn Protokoll basiert. Der ist in der Lage 89 von 136 Fehlerbedingungen automatisiert zu prüfen. Bitte aber nicht vergessen, dass es da noch 47 Fehlerbedingungen gibt, die die interaktive Bewertung durch einen menschlichen Prüfer erfordern. Wenn wir von Dokumentmanagementsystemen reden und jetzt hier speziell von welchen, die PDF Dokumente verarbeiten, dann habe ich eventuell, um Barrierefreiheit wirklich zur Verfügung stellen zu können, einiges an Handlungsbedarfen, die ich zur Einführung von barrierefreien PDF-Dateien auch benötige. Das sind beispielsweise, dass ich erst einmal identifizieren muss, welche Quellsysteme nutze ich denn zur Erzeugung von PDF-Dateien? Sind das zum Beispiel textverarbeitende Programme, Layout-Programme, sind das serverseitige PDF Bibliotheken? Sind das große schon Dokumentsysteme, wie zum Beispiel der Akrobat Designer oder auch Adobe Forms oder ähnliche. Diese Quellsysteme, und das haben wir am Anfang auch schon gesagt, die müssen natürlich erst einmal barrierefrei auch zugänglich sein, damit ich dort arbeiten kann, um überhaupt eine Datei oder ein Dokument, ein - hier in dem Fall - PDF-Dokument zu erzeugen, das auch barrierefrei ist. Dazu lohnt es sich mal zu gucken, wenn ich schon Dokumente da habe und das ist in den meisten Unternehmen der Fall, dass also bereits Dokumente digitalisiert vorliegen, die nicht barrierefrei sind oder die geprüft werden sollen, ob sie barrierefrei sind oder nicht. Dass ich mir einfach mal angucke: Ich mache einen Statustest von mindestens zwei Dokumenten pro Erzeugungstechnologie, um festzustellen, ob es Barrierefreiheits- probleme gibt und wo ich gegebenenfalls nachsteuern muss. Ob ich nachsteuern muss im Programm, was das PDF-Dokument erzeugt oder nachsteuern muss an dem Betreiber, also an demjenigen, der das Programm bedient und das PDF-Dokument erzeugt. Und natürlich auch, ob das Programm überhaupt in der Lage ist, ein barrierefreies Dokument zu erzeugen. Das muss ich vielleicht herausfinden. Als Drittes ist die Definition von Anforderungen für die barrierefreie Ausgabe von PDF aus den unterschiedlichsten Systemen sehr nützlich. Das heißt, wenn ich zum Beispiel mittels Leitfäden die Architekten, Konzeptioner, Designer und Entwickler in die Lage versetze, auch tatsächlich barrierefreie PDF zu erzeugen oder eine Software zu entwickeln, die barrierefrei ist und die Möglichkeit bietet, mir barrierefreie Dokumente zu erzeugen. Beispielsweise ein Wandler, der aus Papierdokumenten barrierefrei PDF-Dokument macht, eine sehr, sehr komplexe Aufgabe. Was ich noch als Handlungsbedarf identifiziert habe, ist auch eine rollenspezifische Schulung von Prozess -Beteiligten, beispielsweise mit Seminaren oder dass man hier eben sich entweder Barrierefreiheits-Spezialisten heranzieht im Unternehmen oder eben von außen dazu holt und in Entwicklungsworkshops schaut. Wie kann ich wirklich meine Stakeholder in meinen Dokumentmanagementsystem-Prozessen sensibilisieren und auch technologisch und technisch in die Lage versetzen, barrierefreie Dokumente und die dazugehörigen Softwareanwendung zu entwickeln und bereitzustellen? Ich sollte natürlich auch eine Klassifizierung vornehmen als nächsten Handlungsbedarf aller vorhandenen veröffentlichten PDF-Dateien und diese auch tatsächlich in nicht barrierefrei und barrierefrei einordnen und sortieren, damit ich auch den Nutzern zum einen die Möglichkeit gebe, barrierefreie Dokumente zu entdecken. Und zum Zweiten auch, damit ich hier einer gesetzlichen Formalität, nämlich der Erklärung zur Barrierefreiheit, genüge tun kann und alle nicht barrierefreien Dokumente auch namentlich hier nennen kann. Und als letzten Handlungsbedarf sehe ich hier auch eine Priorisierung und eine Roadmap. Wie kann ich jetzt in einer angemessenen Zeit mit einem angemessenen Budget auch PDF Dokumente barrierefrei herstellen? Nicht alles kann man an einem Tag erschaffen. Der Weg zu barrierefreien Dokumenten oder auch Dokumentmanagementsystemen, der ist, ich sag mal, noch nicht vollständig gegangen. Da brauchts noch eine Roadmap und eben auch eine Abschätzung von Bedarfen. Aber der Weg ist das Ziel. Das heißt, das Ziel haben wir hier definiert. Was brauche ich alles für ein barrierefreie DMS? Und im Umkehrschluss und in der letztendlichen Zieldefinition für eine barrierefreie digitale Welt, hier in Bezug auf digitale Dokumente. Soweit von mir. Vielen Dank! Jetzt erhalten Sie die Antwort auf die Frage aus der letzten Episode: Welches sind die bisher geltenden Kriterien für die Standard-Konformität von dem DMS und ECMS? Nach dem Vortrag von Anne-Marie Nebe beantwortet Detlef Girke, einer der externen Berater im Projekt iDESkmu, die Frage nach diesen Kriterien. Die wichtigsten Prüfverfahren stützen sich auf vier globale Prinzipien, um Barrierefreiheit sicherzustellen. Das sind Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit. Und hier die Frage, die wir Ihnen in der nächsten Episode beantworten werden: Woher stammt der Begriff Scrum? Antwort A: Der Begriff ist dem Rugby entlehnt. Im Rugby handelt es sich bei Scrum um eine dichte Ansammlung von fünf bis acht Spielern, die in dieselbe Richtung drücken und so versuchen, als Einheit den Ball in ihrem Sinne ins Spiel zu bringen. Antwort B: Scrum kommt aus dem Englischen und bedeutet Gedränge und ist Sinnbild für verschiedene Mitarbeiterinnen und Mitarbeiter, die als ein eng zusammenarbeitendes Team spontan reagierend in die selbe Richtung arbeiten, um erfolgreich zu sein. Antwort C: Scrum ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung. Dazu gehört ein agiles Mindset. Das ist die innere Haltung eines oder mehrerer Menschen, die es ihnen ermöglicht, Ungewissheit zuzulassen, mit Veränderung situativ und konstruktiv umzugehen und zu akzeptieren, dass Veränderung permanent stattfindet. Es folgt das Interview zum Thema Führung in IT-Projekt. Guten Tag und herzlich willkommen! Wir wollen heute sprechen über Barrierefreiheit in IT Projekten bzw. wie es sich vermeiden lässt, dass genau diese Anforderung hinten runterfällt und den Verantwortlichen bei der Produktabnahme auf die Füße. Ich darf dazu heute bei uns Vanessa Matz begrüßen. Frau Matz, ich danke Ihnen vielmals, dass Sie heute zu uns gekommen sind. Würden Sie unseren Zuhörern zum Einstieg bitte einen kurzen Abriss zu Ihrer Person geben? Hallo, Herr Haase und vielen Dank für die Einladung! Gerne! Ja, ich bin gelernte Verwaltungsfachangestellte und studierte Betriebswirtin. Ich bin seit ungefähr 1995 in der IT tätig und seit 2006 auch in der IT-Beratung bzw. im Projektmanagement. Meine Erfahrungen erstrecken sich unter anderem auf die Branchen Banken, Versicherungen. Ich war an der Maut tätig, habe in einem Unternehmen für erneuerbare Energien gearbeitet. In der Telekommunikation. Ja. Und aktuell bin ich in der Gesundheitsbranche tätig. Meistens als externe Beraterin und ja, eigentlich immer in unterschiedlichen Rollen, aber als Teil oder als Mitglied eines Projektteams. Ein sehr breites Spektrum. Vielen Dank! Bevor wir uns dem Thema heute, also dem Projektmanagement, zuwenden, würde ich gerne in Erinnerung bringen, warum es bei den technischen Anforderungen barrierefreie IT Lösungen überhaupt geht. Dazu möchte ich noch einmal ganz kurz auf die Unterschiede zwischen Standardkonformität einerseits und Barrierefreiheit andererseits eingehen. Die Standardkonformität verlangt zuerst einen validen Code, die saubere Trennung von Struktur, Layout und Funktion, eine sinnvolle Text Auszeichnung und die semantisch korrekte Verwendung von HTML Elementen und Attributen. Das heißt, die Bedeutung dieser Elemente muss ihrer Spezifikation entsprechen. Also Überschriften-Hierarchien müssen eingehalten werden, Absätze als solche im Code erkennbar sein und so weiter. Auf diesen Kriterien bauen die Anforderungen der Barrierefreiheit auf. Zusätzlich ist hier gute Übersichtlichkeit und Orientierung erforderlich, eine leichte Bedienbarkeit und gute Erkennbarkeit und Kontraste und so weiter. Man sieht also, dass die Einhaltung der Standard- konformität schon ein wichtiger Schritt in Richtung Barrierefreiheit ist. Aber soweit dieser kleine Exkurs. Frau Matz, wie haben sich die Projekt- managementmethoden im Projektalltag entwickelt, vor allem in Bezug auf die Einhaltung der einzelnen Projektanforderungen? Ja, eine sehr gute Frage. Mit den klassischen Wasserfall-Projekten fing es damals an. Da haben wir konzeptioniert, geplant, strukturiert und dann haben wir so sequenziell umgesetzt. Das Problem war, wenn sich dann im Laufe des Projektes noch etwas geändert hat oder sich ein Stakeholder mit Anforderung gemeldet hat, dann war es wirklich schwer das noch umzusetzen oder nur mit hohem Aufwand, weil eben schon alles durchgeplant war. Jetzt in unseren aktuellen Projekten sind wir tatsächlich agil unterwegs. Das bedeutet, dass es cross-funktionale Teams gibt, die sich aus unterschiedlichen Rollen zusammensetzen. Es wird gemeinsam mit allen Beteiligten von Anfang bis Ende gearbeitet. Von der ersten Idee eines Projektes oder eines Produktes bis zum letzten Inkrement, also dem Endprodukt. Der große Vorteil agiler Methoden ist das Feedback. Das kommt relativ schnell von Kunden oder Usern direkt ins Team, sodass man dann Verbesserungen am Produkt vornehmen kann. Man startet ein Produkt nämlich erst mal nur mit den Grundfunktionalitäten aus. Und Stück für Stück erweitert man es dann im Laufe des Projektes quasi agil. Das heißt, dass das Kundenfeedback dann direkt in das Produkt einfließt. Die Anforderungen zur Barrierefreiheit zum Beispiel können entweder am Anfang gleich als Bestandteil mit dabei sein oder eben auch später hinzukommen. Kleiner Exkurs aus der Praxis: Ich würde es immer am Anfang machen. Natürlich! Warum, kann ich ja später noch mal ausführen. Beim agilen Projektmanagement ist es aber kein Problem mehr, dass auch später Anforderung hinzukommen. Barrierefreiheit ist für 10 Prozent der Bevölkerung unentbehrlich. Für 40 Prozent essenziell und alle komfortabel und ein Qualitätsmerkmal. Das ist in der Tat ein praxisnaher und flexibler Ansatz, der auch alle mitnimmt. Wie können Sie denn im Projekt sicherstellen, dass die unterschiedlichen Ansprüche und teilweise auch komplexen Anforderungen umgesetzt werden? Na, wir haben zum Beispiel die Rolle des Product Owner, der dafür zuständig ist, die Kommunikation mit den Stakeholdern zu übernehmen. Der erfasst durch den Einsatz unterschiedlicher Anforderungsmanagement -Methoden und -Werkzeuge die Anforderungen aller Stakeholder. So werden keine starren Anforderung mehr geschrieben, zum Beispiel, die nicht problembezogen sind, sondern sogenannte User Stories. Ich kann Ihnen mal ein Beispiel für eine User Story zur Barrierefreiheit geben. Eine könnte könnte lauten. Als Nutzer möchte ich meine Rechnung zusätzlich drucken können. Das wäre so eine User Story und bei der Barrierefreiheit würde ich die immer mit Akzeptanzkriterien anreichern. Also, ein Akzeptanzkriterium könnte sein, dass die Druckfunktion, also ein Button, tastaturbedienbar sein muss und ausreichende Farbkontraste aufweisen muss. Oder auch ein akzeptables Kriterium: das Druck-Layout muss ausreichende Farbkontraste aufweisen. So. Und diese User Stories, die sollten möglichst zu Beginn des Projektes einfließen, damit man nicht in die Gefahr kommt, das in eine spätere Phase zu verlagern. Wenn die Wichtigkeit und der Nutzen nicht allen Projektbeteiligten klar ist, dann kann es natürlich sein, dass das hinten rüber kippt. Agiles Projektmanagement verlangt, dass das Team seine Arbeit in sogenannte kleine Mini-Projekte unterteilt. Die werden Sprints genannt. Diese Sprints, die werden gemeinsam geplant. Am Ende eines Sprints wird das Produkt abgenommen und dann wird das den Usern präsentiert und freigegeben. Und noch mal ein Satz zum Anforderungs- management: Das unterscheidet sich vom klassischen Anforderungsmanagement vor allem darin, dass es den laufenden Umsetzungungsprozess begleitet. Und wir haben halt ständig just in time Anforderungen, die geliefert werden und auch gleich umgesetzt werden. Somit kann besser auf Veränderung reagiert werden und das Feedback von den Usern wird jederzeit in die Produktentwicklung mit einfließen können. In der Regel entstehen dadurch bessere Produkte und wir haben einfach eine höhere Usability. Es wird also im Projekt viel mehr kommuniziert als zum Beispiel im klassischen Wasserfall Modell, verglichen mit dem agilen Projektmanagement. Wie schätzen Sie die Bedeutung generell der Kommunikation in IT Projekten ein? Die Kommunikation in IT-Projekt ist elementar. Sie hat wirklich eine Schlüsselfunktion. Ohne Kommunikation funktioniert das nicht. Schon allein durch die konsequente Orientierung am Markt und den Anwender- Bedürfnissen ist ein kontinuierlicher Austausch auch mit externen Stakeholdern notwendig. Ich würde meinen Kunden immer eine entsprechende Kommunikationskultur empfehlen, die das abbilden kann. Die muss natürlich dann im Unternehmen auch etabliert werden. Ohne Kommunikation können wir auch gar keine Agilität gewährleisten. Wir arbeiten Feedbacks direkt in die Entwicklung ein, um das Produkt an die Bedürfnisse anzupassen. Und dadurch schaffen wir eben auch einen echten Mehrwert. Für die ständige Feinjustierung ist einfach eine kommunikationsintensive Projektmethode unumgänglich. Und da wir nun zudem zu diesem Aspekt der Kommunikation jetzt noch den der Mitarbeitereinbindung betrachten? Also im klassischen Wasserfall Modell zum Beispiel werden Entwickler und Anforderungen in der Konzeption sehr stark eingebunden. Im späteren Projektverlauf dann nicht mehr oder eben nur, wenn Fragen auftauchen oder Probleme existieren. Bei Scrum zum Beispiel, da gibt es übergreifende Teams, die über den gesamten Lebenszyklus des Produktes zusammenarbeiten. Da sitzen das Entwicklungsteam mit dem Product Owner in einem Boot. Es gibt die unterschiedlichen Rollen, also der Product Owner, das Entwicklerteam, der Scrum Master und alle werden entsprechend in die Projektorganisation eingebunden. Für die Barrierefreiheit speziell würde ich noch betonen, dass es wichtig ist, wirklich Betroffene als Stakeholder mit einzubinden. Die können zum Beispiel beim Testen unterstützen oder auch beim Feedback geben, damit das Feedback dann auch in das Produkt eingebaut werden kann. Okay, wenn man die verschiedenen Projektmanagement-Modelle vergleicht, gibt es da wirklich so große Unterschiede oder wenn ja, manche haben wir ja schon gehört, und wenn ja, wo liegen diese Unterschiede? Gut, dass Sie das ansprechen. Es gibt tatsächlich Unterschiede. Natürlich im Vorgehen, in den Rollen und alleine die Schwerpunkte der Methoden unterscheiden sich. Ich könnte Ihnen im Folgenden mal die wichtigsten Projektmanagement Methoden kurz vorstellen. Also wir haben einige schon angesprochen. Das ist die Wasserfall Methode. Da arbeiten wir sequenziell in einer fixen Reihenfolge die Arbeitspakete ab. Es ist so, dass die Projektmitarbeiter teilweise nur in einzelnen Phasen involviert werden und es ist insgesamt ein sehr starres System. Es kann zwischendurch eigentlich kaum noch etwas oder nur mit hohem Aufwand geändert werden. Und empfehlen würde ich diese Wasserfall Methode wirklich nur bei Projekten, wenn wir Aufgaben haben, die quasi voneinander abhängig sind oder Projekte die wenig umfangreich sind oder von kurzer Dauer oder sich ständig wiederholen und wo die Beteiligten genau wissen, das sind bekannte Aufgaben für mich. Gut eignen tut sich das Wasserfall Modell auch für Vorhaben in der Produktion. Zum Beispiel wenn vorrangig sequenziell abgearbeitet wird. So, agiles Projektmanagement ganz allgemein: hier ist entscheidend, dass die Umsetzungszüglen kurzfristige Änderungen ermöglichen, was ein großer Vorteil meiner Meinung nach ist. Das Feedback wird direkt eingearbeitet ins Produkt. Und die Mitarbeiter, die sind wirklich von Anfang bis Ende dabei. Oft existieren auch flache Hierarchien und eignen tut sich das hervorragend für große und komplexe Projekte, wo ich nicht genau von Anfang an die Anforderungen kenne. Und wenn die wenig vorhersagbar sind und wenn hohe Risiken eventuell vorhanden sein könnten. Und ganz speziell würde ich hier noch mal Scrum hervorheben. Das ist auch eine agile Methode. Sie hebt sich noch mal ab dadurch, dass sie feste Rollen, feste Abhängigkeiten oder Abläufe und Regeln hat. Da wird zu Beginn ein Backlog erstellt, das angepasst wird und es finden so Daily Scrums statt. Da spricht man die Aufgaben, Probleme und Fortschritte im gesamten Projektteam ab. Und empfehlen würde ich die Methode auch wieder für umfangreiche komplexe Projekte, aber eher auch für welche, wo ich nicht im Voraus definieren kann, was für Anforderungen ich habe. Scrum würde ich empfehlen, vor allem bei Teams, die nicht so groß sind, also weniger als sieben Personen. Davon profitiert auf jeden Fall Scrum. Dann wäre da noch Kanban zu nennen. Das basiert auf regelmäßigen Feedback Schleifen und setzt voraus, dass Teams eigenverantwortlich arbeiten. Wurde mal von Toyota in Japan entwickelt. Hier sind sinnvoll, dass man kurze, aber täglich stattfindende Standups macht. Also so kurze Meetings, in denen sich dann alle Teammitglieder unterhalten und Fortschritte, Erfolge, Probleme und das weitere Vorgehen besprechen und sich dann zum Projekt austauschen. Und hier aufgrund der transparenten Strukturierung und der hohen Flexibilität würde ich hier empfehlen, dass bei der Projekdurchführung eben kontinuierliche Verbesserung und Feedback Prozesse gemacht werden können. Ist auch bei großen und komplexen Projekten sehr von Vorteil. Als letztes würde ich noch Six Sigma nennen. Das wurde mal von Motorola entwickelt, um Prozesse als mathematische Funktion darzustellen. Die Beschreibung, Messung, Analyse, Kontrolle und Optimierung der Prozesse, die wird mit statistischen Mitteln durchgeführt. Hier ist es wichtig, dass wirklich ausgebildete Fachkräfte die Leitung übernehmen. Diese Rollen basieren auf den Gürtelfarben der japanischen Kampfsport - haben Sie bestimmt schon mal gehört. Das habe ich noch nicht gehört. Aber das ist interessant. Das ist vor allem in großen Unternehmen. Und zum Beispiel in der Fertigungsindustrie und im Dienstleistungssektor wird Six Sigma eingesetzt. Okay, also man sieht, da sind sehr deutliche Unterschiede bei den Gewichtungen, bei den Prioritäten vor allem. Das ist enorm. Haben Sie denn zum Schluss noch ein paar Praxistipps für ein erfolgreiches IT Projektmanagement? Auf jeden Fall. Ich würde zusammenfassen, dass es wirklich sehr, sehr wichtig ist, sich für eine Projektmanagement Methode zu entscheiden. Also, schwierig ist es dann zu switchen. Ich würde empfehlen, wenn man sich vorher einmal hinsetzt und sich überlegt, wie möchte ich mein Projekt durchführen? Gerne erst mal für eine Projektmanagement Methode entscheiden. Dann ist es sehr sehr wichtig, eine geeignete Kommunikationskultur zu etablieren. Und zwar dann in dem gesamten Projekt oder in dem Unternehmen, wenn es möglich ist oder notwendig ist. Es ist ganz, ganz wichtig. Frühe Einbindung aller relevanter Beteiligter. Das ist wirklich essenziell, dass ich von Anfang an jeden mitnehme, der Anforderung hat oder der etwas einzubringen hat ins Projekt oder der einfach wichtig ist auch für meine Entscheidung, die ich dann treffen muss. Ich würde die Anforderungen zur Barrierefreiheit tatsächlich ganz am Anfang berücksichtigen. Das Problem ist immer das, was ich nicht am Anfang gleich mit einfließen lasse, könnte Gefahr laufen, nicht berücksichtigt zu werden. Externe und interne Betroffene würde ich einbinden, also Betroffene in Bezug auf die Barrierefreiheit, damit ich eben auch das Feedback erhalte und das einarbeiten kann in mein Produkt, damit das Produkt auch wirklich barrierefrei ist. Und - last but not least - viel und oft kommunizieren. Es kann gar nicht genug kommuniziert werden. Das erlebe ich auch in meinen Projekten. Lieber einmal zu viel sprechen als zu wenig. Und das ist eigentlich schon fast das Geheimrezept. Vielen Dank für Ihre sehr klaren Tipps. Frau Matz, ich danke Ihnen vielmals für diesen Einblick in die Praxis des IT Projektmanagements. Danke Ihnen für Ihr Kommen. Bitte, sehr gerne! Und auf Wiedersehen. Gerne! Vielen Dank! Herr Haase, hat mir viel Spaß gemacht. Das Team von iDESkmu bedankt sich bei Anne-Marie Nebe und Vanessa Matz für die Unterstützung des Projektes durch ihren Beitrag. Hier noch mal der Hinweis auf unsere Shownotes. Sie finden dort neben den Hintergrundinformationen zu unseren Gesprächspartnerinnen grundsätzlich umfangreiche Quellenangaben und Tipps rund um die Beiträge und Themen dieser Episode. In der nächsten Episode spreche ich mit Alexander Paulczynski über das Thema Projektmanagement mit Scrum. Im dann anschließenden Gespräch zwischen Christiane Möller, Rechtsreferentin des Deutschen Blinden- und Sehbehinderten Verbandes e.V. in Berlin, und Uwe Boysen, Jurist, Diplom Sozialwissenschaftler und ehemaliger Vorstand des DVBS und Richter am Bremer Amts-, Landes- und Oberlandesgericht, geht es um das Thema Nationales Recht. Auch heute freuen wir uns, wenn wir Ihr Interesse geweckt haben. Abonnieren Sie diesen Podcast und teilen Sie ihn mit Ihrem Netzwerk und folgen Sie uns auf Facebook und Twitter. Lernen Sie uns noch besser kennen und besuchen Sie unsere Webseite unter www.projekt-iDESkmu.de. Sind Fragen offen geblieben oder haben sich neue Fragen ergeben? Dann senden Sie uns wie immer gerne eine Nachricht. Wir freuen uns darauf. Das war die Episode #03, der Podcast Serie KLARTEXT FÜR IT OHNE BARRIEREN des Projektes IDESKMU. Mein Name ist Nadia David. Vielen Dank für Ihr Zuhören!