2. Entwicklungsphase - Entwurf - _Bericht_AG_SVPBIT ... Web viewBericht der Interministeriellen...

Bericht der Interministeriellen Arbeitsgruppe für die Ermittlung geeigneter Standardverfahren zur

Prüfung der Barrierefreiheit von IT-Produkten (AG SVPBIT)

Arbeitsblock I:Barrierefreiheit von web-basierten und

nicht web-basierten Software-Produkten mit User-Interface

(Juni 2013 – Februar 2015)

Referenzen / Anforderungen / Handlungsempfehlungen

GZ: BMASK-44175/00**-IV/A/10/2015

AutorInnen:

● Predrag RADIC, BA (Sozialministerium)● Edith VOSTA (BKA)● Mag. Stephan LIEBHART, BSc. (BMF)● ObstltdhmtD DI (FH) Mag. Alexander LINTENHOFER (BMLVS)● Dr. Gregor EIBL (BKA)● Michael BEDNAR (Sozialministerium)● Mag. Herwig ZACZEK (Sozialministerium)● Dr. Herbert RANNER (Sozialministerium)● Richter Mag. Peter BAUER (BMJ)

Letzte Aktualisierung: 11.02.2015

Dokumentstatus: Entwurf V 1.1

AG-SVPBIT Bericht Arbeitsblock 1 – Referenzen/Anforderungen/Handlungsempfehlungen 1

Inhalt

Executive Summary...................................................................................................................6

1 Ausgangssituation.............................................................................................................8

2 Zur Arbeitsgruppe...........................................................................................................11

2.1 Mitglieder.................................................................................................................11

2.2 Arbeitsziele...............................................................................................................11

2.3 Stellungnahme über die Realisierung von den Arbeitsblöcken II und III sowie zum Vorschlag über die Errichtung der Steuerungsgruppe........................................................13

2.3.1 Budgetäre Ressourcen für die weitere Arbeit der Arbeitsgruppe.....................13

2.3.2 Zu Einrichtung, Tätigkeit und Befugnis der Steuerungsgruppe.........................14

3 Anwendungsbereich, Begriffsbestimmungen und Rechtsgrundlagen.............................15

3.1 Anwendungsbereiche...............................................................................................15

3.1.1 Web-basierte Anwendungen mit User-Interface..............................................15

3.1.2 Nicht web-basierte Anwendungen mit User-Interface......................................15

3.1.3 Nicht-Geltungsbereich.......................................................................................15

3.2 Begriffsbestimmungen..............................................................................................16

3.3 Rechtliche Rahmenbedingungen..............................................................................16

3.3.1 Rechtslage in Österreich....................................................................................16

3.3.2 Europäische Union – Strategien und Recht.......................................................17

4 Technische Referenzwerke.............................................................................................21

4.1 Europäischer Standard – Anforderungen an barrierefreie IKT-Produkte im Rahmen öffentlicher Beschaffung.....................................................................................................21

4.1.1 EN 301 549 V1.1.1 (2014-02) – Accessibility requirements suitable for public procurement of ICT products and services in Europe.....................................................21

4.1.2 TR 101 550 V1.1.1 (2014-02) – Technical Report – Documents relevant to EN 301 549 "Accessibility requirements suitable for public procurement of ICT products and services in Europe"...................................................................................................22

4.1.3 TR 101 551 V1.1.1 (2014-02) – Technical Report – Guidelines on the use of accessibility award criteria suitable for public procurement of ICT products and services in Europe.........................................................................................................................23

4.1.4 TR 101 552 V 1.0.0 (2014-02) – Guidance for the application of conformity assessment to accessibility requirements for public procurement of ICT products and services in Europe...........................................................................................................23

4.2 Referenzwerk für nicht web-basierte Anwendungen...............................................24


4.2.1 ÖNORM EN ISO 9241-171:2008 11 01 – Ergonomie der Mensch-System-Interaktion – Teil 171: Leitlinien für die Zugänglichkeit von Software............................24

4.3 WAI-Referenzwerke für web-basierte Anwendungen..............................................24

4.3.1 Web Content Accessibility Guidelines – WCAG 2.0...........................................25

4.3.2 Richtlinien für Autorensysteme (englisch: Authoring Tools Accessibility Guidelines) – ATAG 2.0....................................................................................................25

4.3.3 Weitere WAI-Referenzwerke.............................................................................26

4.4 Barrierefreie PDF-Dokumente..................................................................................26

4.4.1 Interaktive PDF-Formulare – eingeschränkte Umsetzbarkeit............................27

4.4.2 Lösung zum Problem technische Positionierung der elektronischen Signatur im PDF (tag-Baum)...............................................................................................................28

5 Auftragsverfahren – Praxisempfehlungen.......................................................................30

5.1 Anwendungsmatrix empfohlener Regelwerke.........................................................30

5.2 Anwendungsübersicht der Prüfinstrumentarien......................................................31

5.2.1 Für web-basierte Anwendungen mit User-Interface.........................................31

5.2.2 Für nicht web-basierte Anwendungen mit User-Interface................................32

5.2.3 PDF-Unterlagen.................................................................................................32

5.2.4 für PDF-Formulare.............................................................................................32

5.2.5 Einsatz von Probanden......................................................................................32

5.2.6 Externe Überprüfungs- / Zertifizierungsstellen.................................................32

5.3 Definierung der Bewertungskriterien als Beispiel.....................................................33

5.3.1 Übersicht der Zuschlagskriterien als Beispiel....................................................33

5.3.2 Bewertungsfragen als Beispiel...........................................................................33

5.3.3 Bewertungsfaktoren als Beispiel.......................................................................34

5.4 Accessibility Statement.............................................................................................34

5.5 Vergabepraxis...........................................................................................................34

5.5.1 Vor Beauftragung..............................................................................................34

5.5.2 Bei Beauftragung...............................................................................................36

5.5.3 Nach Beauftragung – Leistungsabnahme..........................................................37

5.5.4 Bei Routineüberprüfung....................................................................................37

6 Betriebswirtschaftliche Dimension.................................................................................38

6.1 Definition der Begriffe „Nutzen" und „Nutzenbewertung"......................................38

6.2 Methoden und Techniken der Nutzenidentifikation und Nutzenbewertung...........39


6.3 Analyse kritischer Erfolgsfaktoren............................................................................39

6.4 Nutzenbewertungsmodell der Barrierefreiheit........................................................40

6.5 Leistungen der Barrierefreiheit von Web-Präsenzen................................................40

6.6 Nicht-monetäre Wirtschaftlichkeit der Barrierefreiheit von Web-Präsenzen..........40

6.7 Opfer der Barrierefreiheit von Web-Präsenzen........................................................41

6.8 Zusammenfassung aus betriebswirtschaftlicher Sicht..............................................41

7 IKT-Barrierefreiheit in Bezug auf fachliche Fortbildung..................................................43

7.1 Empfehlung.............................................................................................................. 43

8 Barrierefreie Zugänglichkeit zu Fachliteratur bzw. (Cluster)Bibliotheken der Ressorts. .45

8.1 Ausgangssituation.................................................................................................... 45

8.2 Vorgeschlagene Vorgehensweise.............................................................................46

9 Anhang A: Prüfvorgangsweisen und Prüftools................................................................46

9.1 Prüfvorgangsweise für nicht web-basierte Anwendungen.......................................46

9.2 Prüfwerkzeuge für web-basierte Anwendungen (empfehlenswerte Beispiele).......47

9.2.1 Empfehlenswerte Prüf-Tools.............................................................................47

9.2.2 Werkzeuge zur Code-Validierung......................................................................48

9.3 Dynamische Web-Anwendungen.............................................................................49

10 Anhang B: Prüftools – ergänzende Informationen..........................................................52

10.1 Prüftools und Werkzeuge für PDF-Dokumente.....................................................52

10.1.1 PDF Accessibility Checker (PAC) 2.....................................................................52

10.1.2 Unterstützungswerkzeuge zur Erstellung barrierefreier PDF-Dokumente (kommerziell)..................................................................................................................52

10.1.3 Prüf- und Korrektur-Tools für PDF-Dokumente (kommerziell)..........................53

10.2 Prüfwerkzeuge für Webseiten-Inhalte nach WCAG 2.0........................................53

10.2.1 Möglichkeiten zur Überprüfung für Online-Redaktion und Designer................53

10.2.2 Evaluierung von Webseiten-Inhalten nach WCAG 2.0 für Professionals und Entwickler....................................................................................................................... 54

11 Anhang C: Quellen vom E-Government-Referenzserver.................................................56

11.1 Relevante Werke mit thematischen Bezug zur Barrierefreiheit............................57

11.2 Weitere Werke mit Bezug zu Barrierefreiheit.......................................................61

11.3 Veraltete bzw. wenig relevante Werke.................................................................62

11.4 Hilfedokument für Redaktion – Erstellen barrierefreier PDF-Dokumente............63

12 Anhang D: Ergänzende Literatur- / Quellenliste..............................................................65


_Toc391545668


Executive SummaryZusammenfassung erzielter Ergebnisse der Interministeriellen Arbeitsgruppe für die Ermittlung geeigneter Standardverfahren zur Prüfung der Barrierefreiheit von IT-Produkten (AG SVPBIT) im ersten Arbeitsblock – Barrierefreiheit von web-basierten und nicht web-basierten Software-Produkten mit User-Interface:

- Schlussfolgerung 1: Verständnis der IKT-Barrierefreiheit bedeutet in der Praxis Qualität für alle, unabhängig von einer Behinderung bzw. einer bestimmten Art der Behinderung;

- Schlussfolgerung 2: Verständnis des Begriffes „Barrierefreiheit“ als Oberbegriff für umfassende Bedienungsfreundlichkeit, Zugänglichkeit, möglichst intuitive Bedienung und mögliche Systemneutralität (bei den web-basierten Anwendungen mit User Interface);

- Schlussfolgerung 3: Die Ergebnisse betreffen web-basierte (im Browser laufende) und nicht web-basierte (außerhalb des Browsers laufende) Software-Anwendungen mit User-Interface (keine dynamischen Anwendungen);

- Schlussfolgerung 4: IKT-Barrierefreiheit betrifft protokollarische Software für direkte Kommunikation zwischen Maschinen ohne User-Interface nicht;

- Schlussfolgerung 5: Keine explizite Orientierung nach bestimmten Arten der Behinderung, sondern nach Benutzungsmodalitäten (Maus, Tastatur, Touchscreen – auch kombiniert);

- Schlussfolgerung 6: Vollständige Bedienung aller Applikationen mittels Maus und Tastatur, bei web-basierten Applikationen auch über Touchscreen);

- Schlussfolgerung 7: Anwendung einer leichten, verständlichen Sprache sowohl im User-Interface, als auch in den Bedienungsanleitungen / Hilfesystemen, die o.g. Bedienungsmodalitäten ebenbürtig berücksichtigen;

- Schlussfolgerung 8: Gestaltung entsprechender deskriptiver Beschreibungen als Erklärungen zu den Screenshots in den Bedienungsanleitungen, so dass die vollständige inhaltliche Verständlichkeit, auch ohne Screenshots, gegeben ist (Mehr-Sinne-Prinzip);

- Schlussfolgerung 9: Eine gesonderte Beschäftigung mit der Barrierefreiheit von Hardware mit User-Interface und dynamischen Software-Anwendungen ist erst in weiteren Arbeitsblöcken möglich;

- Schlussfolgerung 10: Identifizierung geeigneter, herstellerneutraler Normen, Standards, Richtlinien und fundierter technischer Empfehlungen für Erstellung barrierefreier web-basierter und nicht web-basierter Anwendungen im umfassenden Sinne durchgeführt;

- Schlussfolgerung 11: Identifizierung geeigneter, teils automatisierter, maschineller Überprüfungstools für web-basierte Anwendungen durchgeführt;


- Schlussfolgerung 12: Eignung empfohlener Standards, Prüftools und teilweise automatisch / maschinell generierbare Dokumentation als Instrumentarien sowohl für den Auftraggeber als auch für den Auftragnehmer identifiziert;

- Ergebnis 1: Die identifizierten Prüftools für teils automatisierte, maschinelle Überprüfung von web-basierten Anwendungen können menschliche Interaktion keinesfalls vollständig ersetzen, allerdings wesentlich als Orientierungshilfen unterstützen.

- Ergebnis 2: Die hausinternen Richtlinien für bspw. Qualität oder Barrierefreiheit der IKT-Produkte des jeweiligen Softwareanbieters weisen für den Auftraggeber lediglich einen informellen Charakter auf. Für den Auftraggeber sind ausschlaggebend herstellerneutrale Normen, Standards, Richtlinien (Önorm, ISO, WCAG 2.0), WAI etc.

- Ergebnis 3: Keine systemneutralen Prüftools für nicht web-basierte Anwendungen mit User-Interface, die außerhalb des Browsers laufen, identifiziert; Orientierung nach Richtlinien und Werkzeugen des jeweiligen Betriebssystemherstellers, die jedoch die anerkannten Richtlinien wie WCAG 2.0, ISO (Önorm)-Standards berücksichtigen müssen, wäre erforderlich.

- Ergebnis 4: Der Einsatz von Probanden mit Medienkompetenz und Erfahrungen mit Assistierender Technologie wird allgemein empfohlen.

- Ergebnis 5: Erweiterung des bestehenden Seminarangebots an der Verwaltungsakademie des Bundes (VAB) zum Thema IKT-Barrierefreiheit wird empfohlen, ggf. tiefergehende Verankerung in der Grundausbildung, insbesondere bzgl. Vermittlung der Kenntnisse über die Standards, Normen, Richtlinien sowie Umgang mit diesen und begleitenden Instrumentarien, Vermittlung des grundlegenden Verständnisses für das Thema als Qualitätsmerkmal eines Vergabeverfahrens mit Integration von Übungen mit Assistierender Technologie zwecks Erhöhung des Problembewusstseins, sowohl auf der Ebene der Sachbearbeiter, als auch auf der Ebene der Entscheider;

- Ergebnis 6: Im Hinblick auf Konsolidierungsbestrebungen der Europäischen Union, wäre ein eigenes nationales Regelwerk – vergleichbar mit der deutschen Barrierefreie-Informationstechnik-Verordnung - BITV 2.0 – kontraproduktiv. Die bestehenden in Österreich gültigen, in diesem Werk behandelten Standards, Normen, Richtlinien, beziehen sich auf die neue EU-Norm EN 301549 bzw. auf die anerkannten Regelwerke wie etwa WCAG 2.0 oder internationale Standards (ISO), die im Allgemeinen auch von dem Österreichischen Normungsinstitut übernommen worden sind (Önorm). In Bezug auf Web-Anwendungen gilt WCAG 2.0 Level AA als Mindeststandard, wie es auch die neue EU-Norm EN 301 549 vorsieht.


1 AusgangssituationPraktische Erfahrungswerte zeigen immer wieder bei der Anwendung der im professionellen Einsatz kommenden IKT-Produkte, dass einzelne Softwareprodukte, trotz gleicher grundlegender technischer Voraussetzungen (PC, Monitor, Betriebssystem, Anwendersoftware), für alle in Frage kommenden Nutzergruppen, unabhängig von einer Behinderung und individueller Medienkompetenz, nicht überall uneingeschränkt bzw. ungleich nutzbar sind. Da dies zu massiven Problemen bei der sozialen und beruflichen Teilhabe und einem selbstbestimmten Leben der betroffenen Personen, insbesondere Menschen mit Behinderung, führt und somit dem Inklusionsgedanken abträglich ist, gilt es etwa bei der Beschaffung von IKT-Produkten bestimmte Qualitätsstandards zu berücksichtigen. IKT-Produkte müssen wahrnehmbar, bedienbar, verständlich und robust sein.

Die technischen Erfordernisse für Herstellung, Nachvollziehung und Beurteilung der IKT-Barrierefreiheit der Software-Anwendungen mit User-Interface1 sind hinlänglich bekannt. Sämtliche Regelwerke sind mittlerweile von Seiten nationaler Normungsinstitutionen der CEN-Mitglieder2, darunter auch Österreich, als Normen übernommen worden. Die Einhaltung dieser Standards erhöht die Eignung für eine möglichst breit gefächerte Nutzung einer Software-Anwendung. Diese Regelwerke und Standards haben zum Ziel, Lösungen anzubieten, die für eine innerhalb der vorgesehenen BenutzerInnengemeinschaft möglichst weit gestreute Gruppe von BenutzerInnen unter Berücksichtigung ihrer jeweiligen individuellen und situativen Fähigkeiten und Möglichkeiten, der Schwankungen ihrer Leistungen, der Verschiedenartigkeit ihrer Arbeitsaufgaben und ihrer unterschiedlichen umwelttechnischen, wirtschaftlichen und sozialen Umstände – nicht nur in Bezug auf eine Behinderung – nützlich, annehmbar und verfügbar zu sein.

In den aktuellen Allgemeinen Vertragsbedingungen IT für Software und Projekte (AVB-IT/SW bzw. AVB-IT/Projekte) des Bundes aus dem Jahr 2011 ist die Berücksichtigung barrierefreier Nutzung von Softwareprodukten rudimentär enthalten, jedoch werden diese – aus diversen Gründen – in der Praxis nicht hinreichend berücksichtigt. Die wesentliche Problemstellung erweist sich in Bezug auf fehlende operative Konkretisierung mit Blick auf Leistungsdefinierung, Leistungsbeauftragung und Leistungsabnahme und zwar nicht ausschließlich im hochpreisigen Segment des öffentlichen Auftragswesens. Zu dieser Problematik gehören auch fehlende Begleitempfehlungen geeigneter Verfahren und

1 Benutzungsschnittstelle/en: user interface, UIsämtliche Bestandteile eines interaktiven Systems (Software oder Hardware), die dem BenutzerInnen Informationen und Steuerungselemente zur Verfügung stellen, um bestimmte Arbeitsaufgaben mit dem interaktiven System zu erledigen[ISO 9241-110:2006, 3.9]2 EUROPÄISCHES KOMITEE FÜR NORMUNG


Werkzeuge, welche etwa zur möglichst objektiven Prüfung des barrierefreien Gebrauches von Software-Produkten mit User-Interface herangezogen werden können.

Ein weiteres Aspekt für eine nicht bzw. eine nur zögerliche Einhaltung grundlegender Prinzipien der IKT-Barrierefreiheit wird mit vermeintlich höheren Umsetzungskosten als bei der Realisierung einer Applikation, bei der die Barrierefreiheit keine oder eine untergeordnete Rolle spielt, argumentiert. Dabei wird angenommen, dass man bloße Erstellungskosten und nicht hinreichend die betriebswirtschaftliche Mehrdimensionalität z. B. der Folgekosten (bspw. in Bezug auf das Produktleben) im Entscheidungsprozess würdigt. Von Beginn an berücksichtigte Anforderungen der Barrierefreiheit entsprechen schon weitgehend dem state-of-the-art Designansatz des Universellen Designs, womit nachweislich viele Vorteile inklusive wirtschaftliche verbunden sind. Bei der Realisierung einer Software-Anwendung mit User-Interface können zweifellos etwas höhere Kosten entstehen, wie bei Einhaltung sonstiger hochqualitativer Kriterien. Dabei relativieren sich diese höheren Kosten durch die gestiegene Bedienungsfreundlichkeit / Bedienungsqualität, Zugänglichkeit für einen möglichst breiten Kreis der BenutzerInnen sowie durch gestiegene Nachhaltigkeit, Wirtschaftlichkeit, Zweckmäßigkeit, also Effektivität3 und Effizienz4. (siehe Kap. 6 Betriebswirtschaftliche Dimension).

%%offene Frage in Bezug auf UNO im nachstehenden Absatz , Abklärung mit Abt. IV/A/1 des BMASK, Erledigung Radic$$

Die Barrierefreiheit und die entsprechende Verpflichtung zu angemessenen Vorkehrungen finden sich auch in der UN-Konvention über die Rechte von Menschen mit Behinderungen, derer Umsetzung von Seiten des Unabhängigen Monitoringausschusses5, samt periodischer Erstattung der Staatenberichte an die Vereinten Nationen überwacht wird.

Der Nationale Aktionsplan Behinderung der Österreichischen Bundesregierung zur Umsetzung der UN-Behindertenrechtskonvention 2012-2020 (fortan NAP-Behinderung genannt) erkennt u.a. die eingangs beschriebene Problemstellung an und sieht Maßnahmen zur Verbesserung des Status Quo in Bezug auf IKT-Barrierefreiheit vor. Ein wesentliches Ziel des NAP-Behinderung ist die Stärkung der Bedeutung der Barrierefreiheit als Menschenrecht im Bewusstsein der Gebietskörperschaften, der Wirtschaft und der Bevölkerung, wozu die einzelnen Bestimmungen des Bundesvergabegesetzes sowie einschlägige EU-Richtlinien einen nicht zu unterschätzenden Beitrag leisten. Ergebnisse dieser Arbeitsgruppe leisten einen Beitrag insbesondere zur Maßnahme 82 („Laufende Einbeziehung der aktuellen Anforderungen bezüglich Barrierefreiheit in die allgemeinen Vertragsbedingungen IT“); sowie im Bedarf nach einer Neufestlegung der IKT-Barrierefreiheit in den AVB-IT Software, Hardware, Projekte“, unter inhaltlicher Berücksichtigung der Maßnahme Nr. 77 („Sondierung

3 Effektivität: Genauigkeit und Vollständigkeit, mit der BenutzerInnen bestimmte Ziele erreichen [ISO 9241-11:1998, 3.2]4 Effizienz: der im Verhältnis zur Genauigkeit und Vollständigkeit eingesetzte Aufwand, mit dem BenutzerInnen ein bestimmtes Ziel erreichen [ISO 9241-11:1998, 3.3]5 siehe http://www.monitoringausschuss.at


möglicher Potentiale im Infrastruktur- und Beschaffungsbereich im Hinblick auf Barriere- und Diskriminierungsfreiheit unter Einbeziehung bzw. im Zusammenwirken mit der Bundesbeschaffungs-GmbH“) sowie Maßnahme 79 ("Laufende Integration der aktuellen Anforderungen betreffend barrierefreies Webdesign in das E-Government") und Maßnahme 81 ("Laufende Evaluierung der Webauftritte in Bezug auf Accessibility und Usability") des NAP Behinderung, unabhängig von der jeweiligen formalen Maßnahmen-Zuständigkeit.


2 Zur ArbeitsgruppeNach einem Vortrag von Hrn. Predrag Radic, BA, BMASK, über den Status quo der Barrierefreiheit der aktuellen Elak-Version in der IKT-Bund-Sitzung vom 27.02.2013 regte das BMF die Gründung dieser Arbeitsgruppe an. Die Aufteilung von operativen Zuständigkeiten zwischen BMASK (inhaltliche Koordinierung) und BKA (administrative Unterstützung) wurde getroffen.

2.1 Mitglieder

Aktuelle Mitglieder der Arbeitsgruppe per Februar 2015:

- Dr. Hansjörg HOFER, Sozialministerium, [email protected] - Predrag RADIC, BA, Sozialministerium, [email protected]

(inhaltliche Leitung)- Mag. Herwig ZACZEK, Sozialministerium, [email protected] - Dr. Herbert RANNER, Sozialministerium, [email protected] - Ing. Wolfgang Ryvola, Sozialministerium, [email protected] - Edith VOSTA, BKA, [email protected] (Inhaltliche Leitung Stv.) - Dr. Gregor EIBL, BKA, [email protected] - Mag. Ferdinand Scheidbach, BKA, [email protected] (administrative

Unterstützung)- Mag. Stephan LIEBHART, BSc., BMF, [email protected] - ObstdhmtD DI (FH) Mag. Alexander LINTENHOFER, BMLVS,

[email protected] - Dr. Thomas MENZEL, BMBF, [email protected] - Ing. Michael GERSTENBAUER, BMBF, [email protected] - Richter Mag. Peter BAUER, BMJ, [email protected] - Dr. Markus WOLF, BMFJ, DI Andrea WILDNER, BMLFUW,

[email protected] - Dipl. Ing. Sigibert HÖCK, BMLFUW, [email protected]

- Martina SAVEL, BMWFW, [email protected] - Johann DRABEK, BMWFW, [email protected]

Inzwischen ausgeschieden:

- Michael BEDNAR, Sozialministerium- Mag. Kurt KREIBICH, BMLVS- Michael GLATZ, BMJ - Dr. Markus WOLF, BMFJ - Enrique VICH, BMF


mailto:[email protected]









2.2 Arbeitsziele

Es wurde festgestellt, dass das ursprüngliche Arbeitsziel – Erarbeitung eines Vorschlages zur Identifizierung eines geeigneten Standard-Toolsets zur automatisierten Prüfung webbasierter Anwendungen für eine bestmögliche barrierefreie Nutzung von IKT-Produkten mit User-Interface ohne oder mit geringer menschlicher Interaktion - nicht erreicht werden kann. Die eruierten Prüfwerkzeuge können die menschliche Interaktion nicht ersetzen, aber die Beschaffung bedingterweise unterstützen (Orientierung). Auf Grund hoher Komplexität wurde der Umfang der Arbeitsgruppe ausgedehnt und in grobe thematische Arbeitsblöcke unterteilt [siehe unten]. Unter IKT-Produkten sind sowohl Software, als auch Hardware-Produkte zu verstehen und entsprechend zu behandeln. Im ersten Schritt fokussiert die AG auf IKT-Produkte im Sinne Software mit User-Interface.

Der erste Arbeitsblock hat als Zielsetzung, die Beschaffer von IKT-Produkten mit Richtlinien bzgl. der Einhaltung von Barrierefreiheit von IKT-Produkten zu unterstützen und Empfehlungen zu geben, an welchem Punkt einer Beschaffung diese einzufordern bzw. zu prüfen sind.

Das vorliegende Werk hat zudem zum Ziel, eine Darstellung wesentlicher Status quo Gegebenheiten in Bezug auf IKT-Barrierefreiheit zu liefern und soll den mit der Beschaffung von IKT-Produkten mit User-Interface betrauten Stellen als Orientierung und Hilfestellung dienen, um einerseits die Anforderungen im Hinblick auf die IKT-Barrierefreiheit im Rahmen des Beschaffungsvorganges möglichst klar zu definieren, und andererseits bei der jeweiligen Leistungsabnahme die Einhaltung der erforderlichen Qualität nachvollziehen zu können.

Eine vertiefende Ausarbeitung operativer Empfehlungen in den Abschnitten 5 (Vergabeverfahren) und 7 (VAB-Schulungsangebot) könnte nach Bedarf durchgeführt werden.

Es hat sich eingangs herausgestellt, dass eine thematische Differenzierung nach Schwerpunkten

● Barrierefreiheit der Software-Anwendungen mit User-Interface (inkl. Medien / digitale Unterlagen),

● Barrierefreiheit der Hardware mit User-Interface sowie● nach Barrierefreiheit dynamischer Software-Applikationen

sinnvoll wäre, so dass die Fortsetzung der Arbeit u.a. wie folgt empfohlen wird:

- Arbeitsblock I: Barrierefreiheit von web-basierten und nicht web-basierten Software-Produkten mit User-Interface (Juni 2013 – Februar 2015)

- Arbeitsblock II: Barrierefreiheit von IKT-Hardware Produkten mit User-Interface- Arbeitsblock III: Barrierefreiheit dynamischer Software-Applikationen (Flash, Ajax,

Java etc. – siehe Kap. 8.3)


Angemerkt wird, dass bei einer möglichen Fortsetzung der AG-Arbeit, insbesondere in Bezug auf Arbeitsblock II und Arbeitsblock III, die rechtzeitige Anschaffung / Zurverfügungstellung sämtlicher (überwiegend kostenpflichtiger) ISO-Standards sowie zutreffender Fachliteratur, vor allem in digitaler Form, erforderlich sein wird.

2.3 Stellungnahme über die Realisierung von den Arbeitsblöcken II und III sowie zum Vorschlag über die Errichtung der Steuerungsgruppe

Vorbehaltlich der Beauftragung durch IKT-Bund und der Bedeckung der budgetären Voraussetzungen wird die Arbeitsgruppe nach ergänzenden Ausarbeitungen für Arbeitsblock I die restlichen Arbeitsblöcke in der folgenden Reihenfolge bearbeiten:

1. Arbeitsblock III Dynamische Webanwendungen2. Arbeitsblock II Hardware mit User Interface

2.3.1 Budgetäre Ressourcen für die weitere Arbeit der Arbeitsgruppe

Einmalige Beschaffungskosten:

Schätzung einmaliger Beschaffungskosten für den Arbeitsblock III € 5.000,-für Standards, Normen und Fachliteratur

Schätzung der einmaliger Anschaffungskosten für Arbeitsblock II € 5.000,-für Standards, Normen und Fachliteratur

Es wird jedenfalls versucht, den Betrag weitgehend minimal zu halten durch Kooperationsvereinbarung mit der Administrativen Bibliothek des Bundes und fach-einschlägiger Clusterbibliotheken im BMWFW.

Die Unterlagen müssen in elektronischer Form jedenfalls für die Mitglieder der Arbeitsgruppe verfügbar sein. Siehe dazu aktuelle Problematik mit barrierefreier Zugänglichkeit zu Fachliteratur bzw. (Cluster)Bibliotheken der Ressorts im Kapitel 8.

Ebenso sollen geeignete Maßnahmen zur Erfüllung der NAP-Maßnahme Nummer 71: „Schaffung eines kostengünstigen und barrierefreien Zugangs zu den für Barrierefreiheit wesentlichen Normen“ dringend überlegt werden.

Für Einbindung von Expertinnen und Experten:

Schätzung € 3.000,- – jeweils im Jahr 2015 und 2016 – zur Abdeckung von Reisekosten von facheinschlägigen Expertinnen und Experten aus Österreich und der EU zu Arbeitsgruppensitzungen bzw. Themen-Workshops

Für Dienstreisen zu einschlägigen Institutionen der Verwaltung und NGOs in Europa:


Bedeckung von Dienstreise-Kosten in Europa im Ausmaß von 3 Personentagen pro Ressort, jeweils im Jahr 2015 und im Jahr 2016.

Geplant: Deutschland, Besuch der Verantwortlichen der Plattform BaNu, weitere (EU-)Länder in Aussicht

Bedeckung der Dienstreisekosten sollte im Rahmen der Ressorts möglich sein.

Budget für Test-Infrastruktur:

Sollte im Rahmen der IKT-Ausstattung der Ressorts möglich sein.

2.3.2 Zu Errichtung, Tätigkeit und Befugnis der Steuerungsgruppe

AusgangslageEs ist bislang keine bekannte offizielle Anlaufstelle für Fragen zu Barrierefreiheit von IKT-Systemen bekannt.

Viele der in jedem Ressort eingesetzten Barrierefreiheitsverantwortlichen sehen das Thema zumeist auf die Barrierefreiheit in baulicher Hinsicht beschränkt und suchen ihrerseits informell Ansprechpartner bei facheinschlägigen Fragen.

Im Bereich Websites und Web-Anwendungen wird das Thema Barrierefreiheit bislang in diversen Arbeitsgruppen (E-Gov, BLSG) bzw. in informellen Koordinationsgruppen (z. B. KORU der Internetverantwortlichen in den Öffentlichkeitsarbeitsstellen der Ressorts) mit behandelt. Darüber hinaus fand Hilfestellung und Wissenstransfer bislang meist vereinzelt und ausschließlich im informellen Rahmen bzw. unter Nennung von einzelnen Fach-Expertinnen und -experten statt. Eine Vernetzung zwischen den Gruppen ist (offiziell) selten gegeben.

Andererseits gibt es aus Bund, aber auch aus Ländern und Gemeinden, immer wieder Fragen zu verschiedenen Aspekten der Barrierefreiheit hinsichtlich (Web-)Anwendungen und Dokumenten, Sprache und weiteren Themen. Gleichermaßen sind noch immer viele Internet-Angebote nur unzulänglich oder noch gar nicht barrierefrei. Ob neue Angebote barrierefrei online gehen hängt in vielen Fällen mehr vom Engagement Einzelner ab. Noch größer scheint der Bedarf bei elektronischen Dokumenten, aber auch hinsichtlich einfacher und verständlicher Sprache.

Organisation der SteuerungsgruppeDie Steuerungsgruppe sollte als ständige Einrichtung ehebaldigst, in einem Ressort (z. B. Bundeskanzleramt, Sozialministerium) oder einer nachgeordneten Dienstsstelle (z. B. Sozialministeriumservice) angesiedelt oder im künftigen Amt der Bundesregierung eingerichtet werden.

Ca. 3 Personen mit facheinschlägigen Kenntnissen und Kompetenz in Barrierefreiheit, Umgang mit Assistierenden Technologien; Testen, Prüfen, Beraten.


%% Bearbeitungshinweis, der Unterlagenentwurf wird bis 13.02. zur Stellungnahme an die AG übermittelt – für weiterführende Informationen siehe vorläufig gesonderte Arbeitsdokumente in googleDocs und Zwischenstände im WIKI der Arbeitsgruppe: SteuerungsgruppeUseCases.docx und SteuerungsgruppeOrganisation.docx (Stand: 12.2.2015)$$

3 Anwendungsbereich, Begriffsbestimmungen und Rechtsgrundlagen

3.1 Anwendungsbereiche

Die vorliegenden Empfehlungen dienen der Sicherstellung der barrierefreien Anwendung von web-basierten und nicht web-basierten Software-Anwendungen mit User-Interface und beziehen sich auf den gleichen Wirkungsbereich wie die AVB-IT. Die vorliegenden Empfehlungen sind als Mindestanforderungen und Handlungsempfehlungen zu betrachten. Derer Einhaltung steigert massiv die Wahrscheinlichkeit, dass ein IKT-Produkt als barrierefrei bezeichnet werden kann.

3.1.1 Web-basierte Anwendungen mit User-Interface

Beispiel: Websites, Elak, ESS, Pro-Fit etc.

Eine Webanwendung oder Webapplikation, kurz Web-App, ist ein Anwendungsprogramm, das beim User in einem Webbrowser abläuft bzw. dargestellt wird. Webanwendungen werden meist auf einem Webserver gespeichert und auch größtenteils dort ausgeführt. Der Zugriff erfolgt über das Internet oder ein Intranet über ein Übertragungsprotokoll wie HTTP. Webanwendungen erfordern im Gegensatz zu Desktopanwendungen kein spezielles Betriebssystem, teilweise jedoch spezielle Laufzeitumgebungen6. Um in die Interaktion mit einer Webanwendung zu treten, bedarf es eines User-Interface7.

3.1.2 Nicht web-basierte Anwendungen mit User-Interface

Beispiel: Desktop, Offline-Anwendungen, Standalone etc.

Mit Anwendungssoftware (auch Anwendungsprogramm, kurz Anwendung oder Applikation; englisch application software, kurz App) werden Computerprogramme bezeichnet, die außerhalb des Browsers laufen und die genutzt werden, um eine nützliche oder gewünschte nicht systemtechnische Funktionalität zu bearbeiten oder zu unterstützen8. Um in die Interaktion mit der Anwendung zu treten, bedarf es eines User-Interface.

6 Siehe auch http://de.wikipedia.org/wiki/Webanwendung 7 Siehe bspw. http://de.wikipedia.org/wiki/Grafische_Benutzeroberfl%C3%A4che 8 Siehe auch http://de.wikipedia.org/wiki/Desktop-Anwendung


3.1.3 Nicht-Geltungsbereich

In diesem Arbeitsblock lag kein Fokus auf Hardware wie Smartphones, Drucker mit Display, digitale Fotoapparate, Kopierer und dgl. mit User-Interface. Dasselbe gilt für dynamische Software-Applikationen, die etwa auf Flash, Ajax, Java usw. basieren.

3.2 Begriffsbestimmungen

IKT-Produkte: IKT-Produkte sind all jene Gebrauchsgegenstände und Anwendungen, die im Bereich der Informationstechnologie zum Einsatz gelangen. Mitumfasst sind damit sämtliche Hard- und Softwareerzeugnisse, die auf die Bedienung und Nutzung durch Menschen ausgerichtet sind.

Barrierefrei: Barrierefrei sind IT-Produkte, wenn sie für alle in Frage kommenden Nutzergruppen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe zugänglich und nutzbar sind.

Benutzeroberfläche / User-Interface: Benutzeroberflächen sind all jene Vorrichtungen und Anwendungsteile, die die Schnittstelle zwischen Mensch und Maschine darstellen9.

Universelles Design: Universelles Design ist der Prozess, Produkte für die größtmögliche Zielgruppe zu entwickeln, wobei der Bedarf der Hilfestellungen aller Art möglichst reduziert wird. Universelles Design richtet sich nach den vier Gestaltungsprinzipien: wahrnehmbar, bedienbar, verständlich und robust. Die Regeln für barrierefreie Gestaltung werden kombiniert mit den Regeln für gute Gebrauchstauglichkeit. Die Anpassungsfähigkeit und die Schnittstellen für technische Hilfen werden berücksichtigt.

3.3 Rechtliche Rahmenbedingungen

Vorliegende Anforderungen gründen sich auf praktische Erfahrungswerte, international anerkannte technische Referenzwerke sowie insbesondere auf folgende Rechtsvorschriften in Österreich sowie Strategien und Initiativen der Europäischen Union:

9 Die Benutzerschnittstelle (nach Gesellschaft für Informatik, Fachbereich Mensch-Computer-Interaktion auch Benutzungsschnittstelle) ist die Stelle oder Handlung, mit der ein Mensch mit einer Maschine in Kontakt tritt. Im einfachsten Fall ist das ein Lichtschalter: Er gehört weder zum Menschen, noch zur „Maschine“ (Lampe), sondern ist die Schnittstelle zwischen beiden.Systematisch betrachtet gehört die Benutzerschnittstelle zu den Mensch-Maschine-Systemen (MMS): Mensch ↔ Mensch-Maschine-Schnittstelle ↔ Maschine. Verschiedene Wissenschaften widmen sich dem Thema, etwa die Informatik, die Kognitionsforschung und die Psychologie.Damit eine Benutzerschnittstelle für den Menschen nutzbar und sinnvoll ist, muss sie auf seine Bedürfnisse und Fähigkeiten angepasst sein. Die Grundlagenkenntnisse für eine ergonomische und benutzerfreundliche Schnittstellen-Gestaltung werden in der Wissenschaftsdisziplin der Ergonomie erarbeitet. Die konkreten Tätigkeitsfelder sind hier Kognitive Ergonomie, Systemergonomie und Software-Ergonomie (usability engineering) (siehe auch http://de.wikipedia.org/wiki/Benutzerschnittstelle)


3.3.1 Rechtslage in Österreich

1. UN-Behindertenrechtskonvention, BGBl. III Nr. 155 vom 23.10.200810, insbesondere Artikel 3 lit. c.

2. Artikel 7 und 8 B-BG Art. 7: „Niemand darf wegen seiner Behinderung benachteiligt werden. Die Republik (Bund, Länder und Gemeinden) bekennt sich dazu, die Gleichbehandlung von behinderten und nichtbehinderten Menschen in allen Bereichen des täglichen Lebens zu gewährleisten“.Art. 8: „Die Österreichische Gebärdensprache ist als eigenständige Sprache anerkannt.“

3. Bundes-Behindertengleichstellungsgesetz BGBl. I Nr. 82/2005 idgF11, insbesondere § 6 Abs. 5.

4. Behinderteneinstellungsgesetz, BGBl I Nr. 22/1970 idgF12, insbesondere §§ 6ff5. E-Government-Gesetz BGBl. I Nr. 10/2004 idgF13, insbesondere § 1 Abs. 3.6. Signaturgesetz20 BGBl. I Nr. 190/1999 ( i.d.g.F – Bedeutung für IKT-Barrierefreiheit in

seiner Gesamtheit, für Begründung siehe Kap. 4.5). 7. Zustellgesetz BGBl. Nr. 200/1982 igdF26 insbesondere Abschnitt 3 bzw. § 29 Abs. 78. Allgemeines Verwaltungsverfahrensgesetz BGBl. Nr. 51/1991 igdF27 insbesondere §

13 Abs. 2

3.3.2 Europäische Union – Strategien und Recht

Mit der Initiative „eEurope 2002“14 wurde im Dezember 1999 von der Europäischen Kommission der erste Impuls für eine breite Diskussion über die zukünftige Entwicklung der Europäischen Union im Informationszeitalter gesetzt. Zielsetzung von eEurope 2002 war es, durch eine Reihe von Maßnahmen die Nutzung der neuen Medien in Europa voranzutreiben, die Bürgerinnen und Bürger mit dem Internet und den Informations- und Kommunikationstechnologien vertraut zu machen und allen Menschen den Zugang zu den neuen Medien zu ermöglichen. In Österreich wurde daraufhin im Rahmen der IKT-Strategie 2002-2005 die Zielsetzung zugunsten barrierefreier Informationsangebote im Rahmen des E-Government-Gesetzes 2004 verankert, was praktisch die Verpflichtung zur Einhaltung der WAI-Leitlinien (insb. WCAG) beinhaltet.

10 Siehe http://www.ris.bka.gv.at/Dokument.wxe?Abfrage=BgblAuth&Dokumentnummer=BGBLA_2008_III_155 11 Siehe http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20004228 12 Siehe http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10008253 13 Siehe http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20003230 14 eEurope 2002 Abschlussbericht siehe http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1402853806460&uri=CELEX:52003DC0066


Das Nachfolgeprogramm „eEurope 2005“15 unternahm weitere Anstrengungen, um den gesellschaftlichen und wirtschaftlichen Wandel in Richtung Informationsgesellschaft für alle zu fördern und geeignete Rahmenbedingungen zu schaffen.

„i2010 – Eine europäische Informationsgesellschaft für Wachstum und Beschäftigung“ war von 2005 bis 2010 der strategische Rahmen der Europäischen Kommission, mit dem große politische Leitlinien für die Informationsgesellschaft und die Medien definiert wurden. Diese integrierte Politik zielte vor allem darauf ab, Wissen und Innovation zu fördern, um das Wachstum und die Schaffung von mehr und besseren Arbeitsplätzen voranzutreiben.

Die Deklaration von Riga16, eine Erklärung der Ministerinnen und Minister, die am 11.06.2006 einstimmig verabschiedet wurde, umfasste als eine zentrale Forderung, bis 2010 alle öffentlichen Webseiten barrierefrei zu gestalten (Anm. ursprüngliches Ziel bis 2008). Gleichzeitig wurde der Privatsektor aufgefordert, dieselben Normen und Standards anzuwenden. Für das Thema Barrierefreiheit sind zwei Schlüsselbegriffe von Bedeutung, „e-Accessibility“ (uneingeschränkte Nutzung von IKT durch Menschen mit Behinderungen oder temporären funktionellen Einschränkungen) und „e-Inklusion“ (sowohl integrative IKT als auch der Einsatz von IKT zugunsten der Teilhabe aller Menschen und Gruppen an der Informationsgesellschaft in jeder Hinsicht). Da bereits bei der europäischen Ministerkonferenz zu E-Inclusion 2007 in Lissabon festgestellt wurde, dass das erklärte Ziel, alle Websites bis 2010 barrierefrei zu gestalten, nicht erreicht werden kann, wurden 2008 von der europäischen Kommission besondere Schritte zur Beschleunigung der Fortschritte bei der Barrierefreiheit im Web definiert:

● Nach der Neufassung der Web-Zugangsleitlinien (WCAG 2.0) durch das World Wide Web Consortium sollten die europäischen Normenorganisationen nun zügig europäische Normen für die Barrierefreiheit im Web verabschieden.

● Die Mitgliedstaaten sollten ihre Bemühungen um eine leichtere Zugänglichkeit zu öffentlichen Websites verstärken und sich gemeinsam auf eine reibungslose Einführung europäischer Normen für die Barrierefreiheit im Web vorbereiten.

● Die Kommission wird die Fortschritte beobachten und veröffentlichen und bei Notwendigkeit zu einem späteren Zeitpunkt Legislativvorschläge vorlegen.

Aktuell ist „EU-2020“ - die neue Strategie für intelligentes, nachhaltiges und integratives Wachstum, wobei eine der sieben Leitinitiativen, die „Digitale Agenda für Europa“17, die Zielsetzungen für E-Government18 konkretisiert. Im Rahmen der Digitalen Agenda sei hier vor

15 eEurope 2005 Aktionsplan siehe http://eur-lex.europa.eu/legal-content/DE/ALL/?uri=CELEX%3A52002DC0263 16 European Press Release zur RIGA Deklaration: http://europa.eu/rapid/press-release_IP-06-769_de.htm, Memo zur Erläuterung (in Englisch): http://europa.eu/rapid/press-release_MEMO-06-237_en.htm?locale=EN 17 Siehe http://ec.europa.eu/digital-agenda/ (Englisch), Mitteilung der EU – Digitale Agenda: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1402857539311&uri=CELEX:52010DC0245 18 E-Government Aktionsplan 2011-2015: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=COM:2010:0743:FIN:DE:PDF


allem die Action für barrierefreie Websites der EU im öffentlichen Sektor mit dem Ziel 2015 erwähnt (Kapitel 2.6.2. Integrative digitale Dienste).19.

3.3.2.1 Europäische Standard EN 301 549Im Auftrag der Europäischen Kommission (Mandat 376) wurde 2014 von den europäischen Standardisierungs-Organisationen (CEN, CENELEC und ETSI) der neue Europäische Standard "Accessibility requirements suitable for public procurement of ICT products and services in Europe" (EN 301 549) veröffentlicht und wird gleich anschließend unter Punkt 4.1 näher erläutert. Gemeinsam mit den 3 Technischen Reports (TR 101 550, TR 101 551 und TR 101 552) bietet der Standard ein Framework zur Unterstützung der Anstrengungen der EU-Mitgliedsländer, um deren elektronische Services allen NutzerInnen barrierefrei zugänglich zu gestalten.

Anmerkung: Die Veröffentlichung der neuen EU-Norm EN 301 549 erfolgte zu einem Zeitpunkt, als die Arbeitsgruppe bereits eingesetzt war. Sie wurde in der Folge bereits als ein prioritäres technisches Referenzwerk aufgenommen. Diese Norm ersetzt keine der angeführten technischen Referenzwerke und Prüfinstrumente. Zur Norm siehe Kapitel Technische Referenzwerke unter 4.1 Europäischer Standard – Anforderungen an barrierefreie IKT-Produkte im Rahmen öffentlicher Beschaffung.

3.3.2.2 Richtlinie des Europäischen Parlaments und des Rates über den barrierefreien Zugang zu Websites öffentlicher Stellen

Barrierefreier Zugang zum Internet (18-Monatsprogramm des Rates; Arbeitsprogramm der Kommission)

Die Kommission legte am 3. Dezember 2012 den Vorschlag für eine Richtlinie über den barrierefreien Zugang zu Webseiten öffentlicher Stellen vor. Mit der Richtlinie soll eine Angleichung der Rechts- und Verwaltungsvorschriften der Mitgliedstaaten zum barrierefreien Zugang zu Webseiten öffentlicher Stellen erfolgen. Dies soll dabei unterstützen, die nationalen Verpflichtungen hinsichtlich eines barrierefreien Webzugangs zu erfüllen und das Bekenntnis der Mitgliedstaaten zum Übereinkommen der Vereinten Nationen über die Rechte von Menschen mit Behinderungen in Bezug auf die Websites öffentlicher Stellen umzusetzen. Gegenstand der vorgeschlagenen Richtlinie sind Webseiten öffentlicher Stellen, da sie Informationen und Dienste bereitstellen, die für Bürgerinnen und Bürger von grundlegender Bedeutung sind. In technischer Hinsicht ist geplant, als Richtschnur die Erfüllung des Konformitätslevels AA der Richtlinien für barrierefreie Webinhalte („Web Content Accessibility Guidelines“) in der Version 2.0 (WCAG 2.0) festzulegen.

Unter irischer EU-Ratspräsidentschaft (erstes Halbjahr 2013) wurden erste Verhandlungen gestartet. Der Vorschlag zur Richtlinie des Europäischen Parlaments und des Rates über den 19 Siehe Mitteilung der EU – Digitale Agenda: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1402857539311&uri=CELEX:52010DC0245


barrierefreien Zugang zu Websites öffentlicher Stellen wurde im 25. Februar 2014 im Europäischen Parlament erstmals verlesen. Die eingebrachten Stellungnahmen des Europäischen Parlaments wurden im Rahmen der Italienischen Ratspräsidentschaft weiter behandelt. Umstritten ist derzeit insbesondere noch der Umfang des Anwendungsbereichs der Richtlinie. Im Vorschlag der Kommission wurden einzelne Webseiten aufgelistet, die von der Richtlinie umfasst sein sollen, das Europäische Parlament hingegen verlangt die Einbeziehung aller Webseiten öffentlicher Stellen. Ebenso werden noch Fragen zur Überprüfung, Monitoring behandelt. Unter der lettischen Ratspräsidentschaft (erstes Halbjahr 2015) soll das Vorhaben abgeschlossen werden.

Österreichische Position20: Die grundsätzliche Zielsetzung des Vorschlags wird begrüßt, das Thema ist für Österreich wichtig. Innerstaatlich ist das Thema bereits seit 2004 gesetzlich adressiert: Der diesbezügliche § 1 Abs. 3 E-GovG lautet: „Bei der Umsetzung der Ziele dieses Bundesgesetzes ist Vorsorge dafür zu treffen, dass behördliche Internetauftritte, die Informationen anbieten oder Verfahren elektronisch unterstützen, so gestaltet sind, dass internationale Standards über die Web-Zugänglichkeit auch hinsichtlich des barrierefreien Zugangs für behinderte Menschen eingehalten werden.“

Das Bundeskanzleramt, Referat I/11/a: E-Government – Internationales, informiert Interessierte laufend über den Mailverteiler „EU-RL Web-Accessibility“. Kontakt: Mag. Heidi Havranek, LL.M., E-Mail: [email protected].

20 aus: BKA Ressortbericht zum Arbeitsprogramm der Europäischen Kommission für 2015 und zum 18-Monatsprogramm des Rates



4 Technische Referenzwerke Dieses Kapitel beschreibt kurz die wesentlichen Normen und Standards für den Gegenstand des Arbeitsblocks I: Barrierefreiheit von web-basierten und nicht web-basierten Software-Produkten mit User-Interface.

4.1 Europäischer Standard – Anforderungen an barrierefreie IKT-Produkte im Rahmen öffentlicher Beschaffung

Der neue Europäische Standard "Accessibility requirements suitable for public procurement of ICT products and services in Europe" (EN 301 549) beinhaltet Vorgaben für web-basierte und nicht web-basierte Anwendungen, Dokumente und IKT im Allgemeinen im Rahmen des öffentlichen Beschaffungswesens. Gemeinsam mit den drei Technischen Reports (TR 101 550, TR 101 551 und TR 101 552) bietet der Standard ein Framework zur Unterstützung der Anstrengungen der EU-Mitgliedsländer, um deren elektronische Services allen NutzerInnen barrierefrei zugänglich zu gestalten.

Die Anforderungen im neuen Standard-Dokument sind konsistent mit bestehenden internationalen Richtlinien für barrierefreie IKT und enthalten entsprechende Referenzen: zum Beispiel auf WCAG – Richtlinien für barrierefreie Webinhalte, auf EN ISO 9241-171:2008 (ÖNORM EN ISO 9241-171:2008 11 01 – Ergonomie der Mensch-System-Interaktion – Teil 171: Leitlinien für die Zugänglichkeit von Software), betreffend Konformitätsbewertung und -verfahren auf EN ISO/IEC 17000:2004 und weitere.

Alle Dokumente und Informationen zum Stand der Publikationen sind bei ETSI (European Telecommunications Standards Institute) abrufbar – http://www.etsi.org/standards-search http://www.etsi.org/standards-search

Zu den einzelnen Dokumenten:

4.1.1 EN 301 549 V1.1.1 (2014-02) – Accessibility requirements suitable for public procurement of ICT products and services in Europe

Das Dokument legt die funktionalen Anforderungen an die Barrierefreiheit für IKT-Produkte und Dienstleistungen zusammen mit einer Beschreibung der Testverfahren und Bewertungsmethoden für jede Zugänglichkeits-Anforderung in einer Form fest, die für den Einsatz in der öffentlichen Beschaffung in Europa einsetzbar ist und kann auch für andere Bereiche, so etwa die Beschaffung in der Privatwirtschaft zu Grunde gelegt werden. Öffentliche Beschaffer, die Anforderungen für ihre Einkäufe zu identifizieren haben, als auch Hersteller, finden damit ein grundlegendes Toolkit vor.


http://www.etsi.org/standards-search

Das Dokument umfasst die notwendigen funktionalen Anforderungen und stellt ein Referenzdokument dar, so dass, wenn die Verfahren von verschiedenen Akteuren verfolgt werden, die Ergebnisse der Tests ähnlich sind und die Interpretation dieser Ergebnisse klar ist. Die Testbeschreibungen und Bewertungsmethodik orientieren sich in ihrer Detailstufe gemäß ISO / IEC 17007:2009, so dass die Konformitätsprüfung aussagekräftige Ergebnisse liefern können.

Die Anforderungen umfassen (Abschnitte im Dokument):

● Allgemeine Anforderungen● Elektronik und Computertechnik mit Zwei-Wege-Sprachkommunikation● Elektronik und Computertechnik mit Video-Ressourcen ● Hardware● Web (Dokumente und Software) – enthält alle Level A und Level AA - Erfolgskriterien

von WCAG 2.0 als Mindestanforderung● Nicht-Web-Dokumente – orientiert sich an den Richtlinien der WCAG2ICT21 Task

Force22 ● Software – allgemein, ausgenommen Web, Interoperabilität mit Assistierenden

Technologien, Autorenwerkzeuge etc. (referenziert u.a. EN ISO 9241-171:2008)Dokument: http://www.etsi.org/deliver/etsi_en/301500_301599/301549/01.01.01_60/en_301549v010101p.pdf

4.1.2 TR 101 550 V1.1.1 (2014-02) – Technical Report – Documents relevant to EN 301 549 "Accessibility requirements suitable for public procurement of ICT products and services in Europe"

TR 101 550 listet alle Dokumente auf, die bei der Erstellung der Anforderungen an die Barrierefreiheit für die öffentliche Beschaffung von IKT-Produkten und -Dienstleistungen in Europa gemäß EN 301 549 berücksichtigt wurden und werden und bietet damit eine Referenzquelle zur Durchführung der Testverfahren. Neben den Quellangaben enthalten sie zusätzlich Erläuterungen für die Nutzer der Europäischen Norm mittels Klarstellungen und ergänzenden Informationen zu den Mess- und Testmethoden, insbesondere dann, wenn kein weltweit vereinbarter Test existiert. Lücken werden als solche benannt, Testbeschreibungen und Bewertungsmethoden entwickelt. In den Ausnahmefällen (in denen keine Beschreibungen und Methoden angeführt werden können), sind Empfehlungen angegeben, wie die Lücken gefüllt werden sollen.

Dokument: http://www.etsi.org/deliver/etsi_tr/101500_101599/101550/01.01.01_60/tr_101550v010101p.pdf http://www.etsi.org/deliver/etsi_tr/ 101500_101599/101550/01.01.01_60/tr_101550v010101p.pdf

21 Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT): http://www.w3.org/TR/wcag2ict/ 22 Siehe http://www.w3.org/WAI/GL/WCAG2ICT-TF/


http://www.etsi.org/deliver/etsi_tr/101500_101599/101550/01.01.01_60/tr_101550v010101p.pdf


4.1.3 TR 101 551 V1.1.1 (2014-02) – Technical Report – Guidelines on the use of accessibility award criteria suitable for public procurement of ICT products and services in Europe

Dieser Technische Report beschäftigt sich mit möglichen Vertragskriterien hinsichtlich der funktionalen Anforderungen an die Barrierefreiheit von IKT-Produkten und Dienstleistungen gemäß EN 301 549. Es enthält Leitlinien für die Beschaffungsbehörden, die beabsichtigen, IKT-Produkte und Dienstleistungen auf den Einsatz von preisrelevanten Kriterien zu den einzelnen Bereichen der Bedürfnisse der Nutzer in der öffentlichen Beschaffung von IKT-Produkten und Dienstleistungen zu erwerben. Mögliche Ausnahmen von der Anwendung der EN bei öffentlichen Aufträgen (z.B. nationale Sicherheit, Wartung, Reparatur oder gelegentliche Überwachung) sind in TR 101 550 behandelt.


4.1.4 TR 101 552 V 1.0.0 (2014-02) – Guidance for the application of conformity assessment to accessibility requirements for public procurement of ICT products and services in Europe

Dieser Technische Bericht (TR) beinhaltet alle Informationen und Dokumentation, die im Rahmen des Beschaffungsprozesses notwendig sind, um die Erfüllung der funktionellen Anforderungen an Barrierefreiheit gemäß EN 301 549 und nach den Vergabekriterien überprüfen zu können (Konformität) – unabhängig davon, ob die Konformität über eine Selbsterklärung, mittels Bescheinigung durch eine zweite Partei oder durch Zertifizierung erfolgt.

Darüber hinaus bietet dieser Fachbericht Leitlinien für Konformitätsbewertungsmechanismen für die Barrierefreiheit im Rahmen des Vertragsmanagements in der Post-Vergabephase. Es ist auch in der Pre-Procurement-Forschungsphase und auch bei den Vertragsverhandlungen nützlich. Die Bieter können es bei der Angebotserstellung heranziehen.







4.2 Referenzwerk für nicht web-basierte Anwendungen

4.2.1 ÖNORM EN ISO 9241-171:2008 11 01 – Ergonomie der Mensch-System-Interaktion – Teil 171: Leitlinien für die Zugänglichkeit von Software

Dieser Teil stellt ergonomische Leitlinien und Anforderungen für die Gestaltung zugänglicher Software (zum Beispiel Büroanwendungen, das Internet, Lernunterstützung, Bibliothekssysteme, etc. – allgemein: Plattformsoftware und Anwendungssoftware) zum Einsatz bei der Arbeit, zu Hause, im Bildungswesen und an öffentlichen Plätzen zur Verfügung. Die Überlegungen zur Softwarezugänglichkeit ergänzen die Festlegungen in den Normen zur allgemeinen Gestaltung – beispielsweise hinsichtlich der allgemeinen Gebrauchstauglichkeit von Informationspräsentationen, Benutzerschnittstellen, Benutzerführung etc. (ISO 9241-11:1998 bis ISO 9241-17:1998, ISO 9241-110:2006) sowie dem benutzerzentrierten Designprozess für interaktive Systeme (ISO 13407:1999) und alle Teile der ISO-Reihe 14915 "Software ergonomics for multimedia user interfaces".

Sämtliche thematische Überschneidungen/Referenzen zu und von WCAG 2.0 sind gegeben. Die normativen Prinzipien, Richtlinien und Erfolgskriterien für barrierefreie Webinhalte (WCAG 2.0) selbst sind im ISO-Standard ISO/IEC 40500:2012 1:1 abgebildet.

Eine beispielhafte Checkliste, mit deren Hilfe eine Software überprüft und dokumentiert werden kann, ob die in ISO 9241-171 enthaltenen Anforderungen erfüllt sind und der Empfehlung gefolgt wurde, ist als informativer Anhang C im Dokument dieses ISO-Standards enthalten.

Dokument:

ÖNORM EN ISO 9241-171:2008 11 01 – Ergonomie der Mensch-System-Interaktion – Teil 171: Leitlinien für die Zugänglichkeit von Software (ISO 9241-171:2008) Bezugsquelle: ON Österreichisches NormungsinstitutHeinestraße 38, 1020 Wien, E-Mail: [email protected], Internet: http://www.on-norm.at/shop, Fax: +43 1 213 00-818, Tel.: +43 1 213 00-805

4.3 WAI-Referenzwerke für web-basierte Anwendungen

Richtlinien, Empfehlungen, Techniken für die Zugänglichkeit von Webinhalten und Anwendungen von WAI/W3C: Das World Wide Web Consortium (W3C) ist das Gremium zur Standardisierung von Internet-/Web-Techniken. Die Web Accessibility Initiative (WAI) innerhalb des W3C entwickelt Empfehlungen, um Internetangebote und -techniken für Menschen mit Behinderungen, ältere Menschen und BenutzerInnen im Allgemeinen zugänglich zu gestalten.


Web Accessibility Initiative: http://www.w3.org/WAI/ http://www.w3.org/WAI/

Relevante Dokumente von WAI/W3C sind unter anderen:

4.3.1 Web Content Accessibility Guidelines – WCAG 2.0

Diese Richtlinien erläutern, wie Web-Inhalte (inklusive Kommunikation und Interaktion) für Menschen mit Behinderung zugänglich gemacht werden können. Von der Einhaltung der Richtlinien profitieren letztendlich auch alle anderen BenutzerInnen.

WCAG 2.0 basiert auf vier wesentlichen Prinzipien, welche die Grundlage für Zugänglichkeit im Web darstellen. Darunter geben insgesamt 12 allgemein formulierte Richtlinien die wesentlichen Ziele vor und liefern Informationen zum Verständnis der insgesamt 61 testbaren technologieunabhängigen Erfolgskriterien in drei verschiedenen Konformitätslevels zur Erfüllung der Richtlinien.

Dokument:

Normatives Richtliniendokument in Deutsch: http://www.w3.org/Translations/WCAG20-de/, in Englisch: http://www.w3.org/TR/WCAG20 http://www.w3.org/TR/WCAG20

Relevante unterstützende nicht-normative Dokumente:

● WCAG 2.0 verstehen (Englisch) http://www.w3.org/TR/UNDERSTANDING-WCAG20/ http://www.w3.org/TR/UNDERSTANDING-WCAG20/

● technologieunabhängige und technologiespezifische Techniken für WCAG 2.0 (Englisch) http://www.w3.org/TR/WCAG20-TECHS/ http://www.w3.org/TR/WCAG20- TECHS/

● Empfohlener Einstiegspunkt für Entwickler und Tester/Evaluatoren: How to meet WCAG (quick reference in English): http://www.w3.org/WAI/WCAG20/quickref/ http://www.w3.org/WAI/WCAG20/ quickref/

4.3.2 Richtlinien für Autorensysteme (englisch: Authoring Tools Accessibility Guidelines) – ATAG 2.0

Die Richtlinien für Autorensysteme richten sich primär an die Hersteller/Betreiber von Autorensystemen – einfache Editoren bis Content Management Systemen und mehr.

Part A der Richtlinie regelt den barrierefreien Zugang und die barrierefreie Benutzbarkeit des Autorensystems selbst.

Part B stellt sicher, dass die von Autoren bei der Erstellung der Webinhalte so unterstützt werden, dass die Webinhalte barrierefrei nach WCAG 2.0 sein können.


http://www.w3.org/WAI/WCAG20/quickref/


http://www.w3.org/TR/WCAG20-TECHS/


http://www.w3.org/TR/UNDERSTANDING-WCAG20/

http://www.w3.org/TR/WCAG20

http://www.w3.org/WAI/

Wenn Webseiten BenutzerInnen erlauben, selbst Inhalte zu erstellen oder zu bearbeiten, beispielsweise wikis, blogs, sharing sites und social network sites im allgemeinen, sind auf die dafür verfügbaren Editier-Werkzeuge die Richtlinien für Autorensysteme (Part A und Part B) anzuwenden.

Dokumente (in Englisch):

● Normatives Richtliniendokument, Status: Candidate Recommandation, 7. November 2013: http://www.w3.org/TR/ATAG20/ http://www.w3.org/TR/ATAG20/

● Implementing ATAG 2.0, Status: Working Draft, 7. November 2013 : http://www.w3.org/TR/2013/WD-IMPLEMENTING-ATAG20-20131107/ http://www.w3.org/TR/2013/WD-IMPLEMENTING-ATAG20-20131107/

4.3.3 Weitere WAI-Referenzwerke

Weitere relevante Richtlinien und Materialien von WAI/W3C:

● User Agent Accessibility Guidelines (UAAG) von W3C, Richtlinien für Benutzeragenten wie beispielsweise Videoplayersoftware, VoIP-Phone, Internet-Browser-Software etc. http://www.w3.org/WAI/intro/uaag.php http://www.w3.org/WAI/intro/uaag.php

● WAI-ARIA, the Accessible Rich Internet Applications Suite von W3C, Ergänzung für interaktive Webanwendungen (so genannte Rich Clients) um semantische (bedeutungstragende) Informationen und Auszeichnungen; Einsatz zum Beispiel bei Webformularen http://www.w3.org/WAI/intro/aria.phpAccessible Rich Internet Applications (WAI-ARIA) 1.0 (Recommandation seit März 2014): http://www.w3.org/TR/wai-aria/

● Independent User Interface (IndieUI) von W3C, http://www.w3.org/WAI/intro/indieui.php http://www.w3.org/WAI/intro/indieui.php

● Evaluation and Report Language (EARL) von W3C, http://www.w3.org/WAI/intro/earl.php http://www.w3.org/WAI/intro/earl.php

● Accessibility Evaluation Resources von W3C, http://www.w3.org/WAI/eval/Overview.html http://www.w3.org/WAI/eval/ Overview.html

● Planning and Implementing Web Accessibility von W3C, http://www.w3.org/WAI/managing.html http://www.w3.org/WAI/managing.html

● Easy Checks: http://www.w3.org/WAI/eval/preliminary

4.4 Barrierefreie PDF-Dokumente

Dokumenten-Management – Erweiterung zur Barrierefreiheit für das Elektronische Dokumenten-Dateiformat – Teil 1: Anwendung der ISO 32000-1 (PDF/UA-1) (ISO 14289-1:2012) ist der Standard für barrierefreie PDF-Dokumente und -Formulare.


http://www.w3.org/WAI/managing.html

http://www.w3.org/WAI/eval/Overview.html


http://www.w3.org/WAI/intro/earl.php

http://www.w3.org/WAI/intro/indieui.php

http://www.w3.org/WAI/intro/uaag.php

http://www.w3.org/TR/2013/WD-IMPLEMENTING-ATAG20-20131107/

http://www.w3.org/TR/ATAG20/

Original in Englisch: Document management applications – Electronic document file format enhancement for accessibility – Part 1: Use of ISO 32000-1 (PDF/UA-1) (ISO 14289-1:2012)

PDF/Universal Accessibility wurde vom Komitee der ISO/AWI 14289 erarbeitet (http://pdf.editme.com/PDFUA).

Die Norm legt fest, wie ISO 32000-1 (PDF/UA-1) zur Erstellung von barrierefrei zugänglichen elektronischen Dokumenten zu verwenden ist. PDF-Dateien können nativ in PDF-Form sowie durch Konvertierung aus anderen elektronischen Formaten oder durch Digitalisierung von Papierdokumenten erstellt werden. Unternehmen, Regierungen, Bibliotheken, Archive sowie andere Einrichtungen und Menschen in aller Welt nutzen PDF zur Repräsentation erheblicher Bestände an wichtigen Informationen. Diese PDF-Dateien sollten Anwendern mit Behinderungen mit Hilfe dieses Norm-Entwurfs barrierefrei zugänglich gemacht werden. Dieser Teil ISO 14289:2012 regelt die Erstellung und Verwendung von barrierefreien PDF-Dokumenten und Formularen.

Dokumente sind beziehbar bei ISO (www.iso.org) und DIN (http://www.din.de).

Unterstützende nicht-normative Dokumente und Prüftools:

● Techniken zur Umsetzung und Prüfwerkzeuge: PDF-Techniken für WCAG 2.0 (englisch): http://www.w3.org/TR/WCAG20-TECHS/pdf.html

● Prüfwerkzeug für PDF-Dokumente und -Formulare: PAC (entwickelt im Auftrag der Initiative Zugang für alle in der Schweiz) http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac.html

4.4.1 Interaktive PDF-Formulare – eingeschränkte Umsetzbarkeit

Die Interaktion mit PDF-Formularen für NutzerInnen mit assistierenden Technologien stellt eine Herausforderung an umfangreiche Kombinationsoptionen technischer Ausstattung dar. Trotz Standardisierungsfortschritten eignet sich weder PDF, noch sonstige file-basierten Formulare (Word, Excel udgl.) – aus heutiger Sicht – noch nicht für barrierefreie interaktive Formulare.

Drei Grundregeln für PDF-Formulare sind jedenfalls:

1. Formulare sollen primär immer in einer HTML-Oberfläche (Web-Formular) zur Interaktion (zum Ausfüllen) angeboten werden (Geltungsbereich der WCAG 2.0).

2. Die Umwandlung von HTML in PDF muss server- und nicht clientseitig erfolgen.3. Das Ergebnis – das PDF-Dokument muss barrierefrei sein (Geltungsbereich der

PDF/UA).Ergänzende Erklärungen zur aktuellen Problematik mit interaktiven PDF-Formularen:

- Die Voraussetzungen für Interaktion mit PDF-Formularen stellt eine Herausforderung an mögliche Kombinationsoptionen technischer Ausstattung dar.


- Trotz Standardisierungsfortschritten eignet sich weder PDF, noch sonstige file-basierten Formate (Word, Excel udgl.) – aus heutiger Sicht –für barrierefreie Formulare.

- Die PDF-Reader weisen in der Praxis zu häufig Inkompatibilitäten mit der Version der PDF-Erstellungssoftware auf.

- Zudem bestehen weitere Schwierigkeiten hinsichtlich möglicher Kombinationsoptionen bei der technischen user-seitigen Ausstattung:

- Aus diversen Gründen ist davon auszugehen, dass nicht immer eine bestimmte Software-Kombination auf der User-Seite verfügbar sein kann: eine bestimmte Version des PDF-Readers sowie des Betriebssystems und assistierender Technologie;

- Auch wenn die erforderliche Version des PDF-Readers installiert wird, wird dies nicht automatisch bedeuten, dass sie mit dem Screenreader benutzbar ist (eine Situation, die im Web Ende der 90-er Jahre geherrscht hat „diese Website ist für Browser X Version Y optimiert“). Dies gilt sinngemäß auch für sonstige file-basierten Formate, die etwa auf MS-Word oder MS-Excel udgl. basieren. Die Bearbeitung von PDF-Formularen direkt im Internetbrowser ist für assistierende Technologie u.U nicht oder nur sehr eingeschränkt möglich.

- Die Erstellung / Finalisierung des ausgefüllten PDF-Formulars am Ende der Bearbeitung soll Server-seitig und nicht Client-(Browser-)seitig erfolgen.

- Siehe auch PDF – Barrierefreie PDF prüfen: http://barrierekompass.de/pdf/barrierefreie-pdf-pruefen.html http:// barrierekompass.de/pdf/barrierefreie-pdf-pruefen.html

4.4.2 Lösung zum Problem technische Positionierung der elektronischen Signatur im PDF (tag-Baum)

Die elektronische Signatur könnte im PDF Tag-Baum unter Umstenden falsch positioniert werden, insbesondere dann, wenn sie nicht zum Ende des Dokuments integriert werden kann. Zur Lösung des Problems sollen bei bereits der Erstellung von zu signierenden PDF-Dokumenten spezielle Platzhalter-Bilder an den Positionen der Signatur eingebaut werden. Für die Einbindung von den QR-Code-Platzhaltern für elektronische Signatur im barrierefreien Formularwesen bzw. in den allfälligen digitalen Unterlagenvorlagen siehe https://www.buergerkarte.at/pdf-as/wai?locale=de.

Für praxisrelevante Informationen zur elektronischen Signatur siehe http://www.buergerkarte.at bzw. für verwaltungstechnische Umsetzung siehe http://www.digitales.oesterreich.gv.at/site/5285/default.aspx (letzte Abfrage am 10.12.2014).

Bedeutung elektronischer Signatur nach SigG für IKT-Barrierefreiheit:

Die elektronische Signatur nach Signaturgesetz idgF bietet in ihrer Natur qualitative, institutionelle Voraussetzungen für die Verhinderung des Medienbruches, insbesondere im Hinblick auf die Anfertigung unterzeichnungspflichtiger Dokumente. Medienbruch: Digitales


http://www.digitales.oesterreich.gv.at/site/5285/default.aspx

http://barrierekompass.de/pdf/barrierefreie-pdf-pruefen.html

http://barrierekompass.de/pdf/barrierefreie-pdf-pruefen.html

zum Papier zwecks händischer Unterfertigung, in weiterer Folge das Papier wieder digitalisieren / bspw. durch das Scannen oder Abfotografieren. Der Medienbruch bewirkt eine massive Verschlechterung technischer Struktur bzw. technischer Qualität des jeweiligen elektronischen Dokuments, da durch die OCR-Erkennung im Zuge des nachträglichen Digitalisierungsprozesses die ursprüngliche tiefe, native technische Qualität des elektronischen Quelldokuments nicht vollständig rekonstruiert werden kann. Die OCR-Erkennung kann bestenfalls eine visuelle Gleichheit des eingescannten Papier-Dokuments pixelmäßig simulieren, ergänzt durch eine rudimentäre Durchsuchbarkeit des eingescannten Inhalts (aller grundlegendste Zugänglichkeit für assistierende Technologie), die möglichen Erkennungsfehler ausgeklammert. Dabei geht die ursprüngliche technische Qualität des elektronischen Dokuments, definiert durch die Ermöglichung einer tiefergehenden Interaktion mit dem Dokument, bspw. durch die Gestaltung von diversen interaktiven, orientierbaren und navigierbaren Inhalte wie Inhaltsverzeichnisse, Überschriften, Tabellen udgl. vordefiniert durch die verwendeten Formatvorlagen und entsprechend (weitgehend automatisch) PDF-mäßig getaggt bei der Umwandlung (Beachte bspw. im MS-Word die verfügbaren ISO-Optionen bei der Umwandlung ins PDF). Die hier angeführte Möglichkeit für Interaktion mit dem digitalen Dokument, unabhängig von einer konkreten Behinderung (assistierender Technologie) oder vom verwendetem Betriebssystem spiegelt die Verkörperung der lebenspraktischen Barrierefreiheit, die durch den PDF/UA-Standard (siehe Kap. 4.4) vorgegeben ist.

%%Radic, Verfeinerung des Kapitels$$


5 Auftragsverfahren – Praxisempfehlungen

5.1 Anwendungsmatrix empfohlener Regelwerke

Bei Ausschreibungen (Beschaffung, Beauftragung) und zur Beurteilung der Barrierefreiheit von IT-Produkten sind insbesondere folgende Referenzwerke heranzuziehen:

Tabelle 1: Welche Standards/Referenzen werden für welche IKT-Produkte und Services zur Überprüfung benötigt (x)

Einsatzgebiet/-zweck

ISO 9241-171

EN 301 54923

WCAG 2.0

ATAG

UAAG

PDF/UA

WAI-ARIA

Software mit Benutzerschnittstelle (UI) X xBenutzeragent (Clients wie Videoplayer, VoIP-Phone, …) X x xWebseiten, -anwendungen x x x xAutorensysteme x x x xPDF-Dokumente x x xOffice-Dokumente (MS-Office, OpenOffice,…) x xMedia-Dateien (Audio, Video, Foto/Grafik) x xInteraktive Animation (E-Learning, GIS, ...) x x

Alle genannten Dokumenten und Quellen stehen den Mitgliedern der Arbeitsgruppe und dem IKT-Bund im BKA-WIKI der Arbeitsgruppe24 zur Verfügung.

Anmerkung: Das in das AG-Wiki hochgeladene PDF-Exemplar der Ö-Norm 9241-171:2008 ist kostenpflichtig und wie folgt digital signiert: „AS+ Shop 08.05.2013 773858-9, BM für Wirtschaft, Familie und Jugend Pers/7-Clusterbibliothek, Stubenring 1,1011-Wien“. Sohin wird u.a. um entsprechende Beachtung des Copyrights, insbesondere bezüglich Weitergabe besagter Kopie an Dritte dringend ersucht.

Zu beachten: Die neue EU-Norm EN 301549 wird für alle IKT-Produkte- und Services-Beschaffungen das primäre Referenzdokument darstellen. In den in Folge angeführten Praxisempfehlungen und Beispielen ist dieser Standard noch nicht explizit berücksichtigt. Der Inhalt der EU-Norm EN 301549 widerspricht aber keinesfalls den angeführten

23 inkl. den 3 Technischen Reports TR 101 550, TR 101 551 und TR 101 55224 Siehe https://stp.portal.intern.bka.gv.at/at.gv.bka.wiki-bka/index.php/Portal:SVPBIT


internationalen und nationalen Standards und Normen. Es wird empfohlen, die EU-Norm EN 301549 operativ vollständig zu berücksichtigen (z.B. in Bezug auf Empfehlungen und Unterlagen für Ausschreibungskriterien).

5.2 Anwendungsübersicht der Prüfinstrumentarien

Beispiel aus Deutschland: BaNu (Barrieren finden, Nutzbarkeit sichern) – Die Anwendung zur Prüfung von E-Government Angeboten des deutschen Bundesverwaltungsamts – Bundesstelle für Informationstechnik http://www.banu.bund.de/DE/Pruefkatalog/Pruefkatalog_node.html.

BaNu wurde im Rahmen des deutschen Regierungsprogramms E-Government 2.0 entwickelt. Die Anwendung führt Qualitätskriterien für Barrierefreiheit und Nutzungsfreundlichkeit zusammen, um Sie bei der Optimierung von E-Government Angeboten zu unterstützen. BaNu hilft Fachleuten bei der Selbstanalyse von Internetangeboten, PDF- und Officedokumenten sowie Client-Anwendungen. Mit BaNu kann man sich Prüfungen anlegen und selber beurteilen, wie das E-Government Angebot einzuordnen ist.

Dieses Werkzeug bietet eine sehr gute Orientierungshilfe und Checklisten hinsichtlich Leistungsdefinierung und Leistungsabnahme. Die Prüfschritte in BaNu sind unter anderem dem deutschen Standard BITV 2.0 zugeordnet; BaNu berücksichtigt in Summe eine Reihe von Standards (E-Government, Qualitätssicherung, Nutzerfreundlichkeit, Barrierefreiheit). Darüber hinaus werden Prüfschritte nach Anforderungen der Nutzer weiterentwickelt. Ein schrittweiser Ausbau Richtung Wissenscommunity ist angedacht.

Bei BaNu zu berücksichtigen: Zur Beurteilung der Barrierefreiheit von Web-Anwendungen sind in Österreich die WAI-Leitlinien (WCAG 2.0) heranzuziehen.

5.2.1 Für web-basierte Anwendungen mit User-Interface

Ausschlaggebend sind die WAI-Referenzwerke von W3C, insbesondere WCAG 2.0 (siehe Kapitel 4.3.)

Ein Toolset zur Überprüfung von Webseiten/-anwendungen explizit nach WCAG 2.0 findet sich in der beispielhaften Checkliste zur Prüfung von Webinhalten nach WCAG 2.0 AA inklusive Erläuterungen , zur Verfügung gestellt von der Schweizer Initiative "Zugang für Alle": http://www.access-for-all.ch/ch/barrierefreiheit/barrierefreies-webdesign/checklist-2.html (berücksichtigt WCAG 2.0 und die Schweizer Verwaltungsrichtlinie P028)

WAI/W3C stellt umfassende Ressourcen zur Evaluierung nach den WAI-Leitlinien sowie zur Planung und Durchführung von Überprüfungen auf Barrierefreiheit (siehe relevanten unterstützenden nicht-normativen Dokumente (Kapitel 4.3.1). und weitere Referenzen (Kapitel 4.3.2).


Empfohlene Prüfwerkzeuge (Online/Offline-Tools – Auszug) siehe im Anhang A (Kapitel 8.2.). Die Prüfwerkzeuge können – wo möglich – nur ergänzend eingesetzt werden, keinesfalls ausschließlich (siehe auch Hinweis im Kapitel 8.2)

5.2.2 Für nicht web-basierte Anwendungen mit User-Interface

Ausschlaggebend ist die Önorm 9241-171:2008 (siehe Kapitel 4.2.1).

Mögliche Checklisten und Anleitungen zur Überprüfung u.a.: als Prüfinstrument die Checkliste C1 im Anhang C der Önorm 9241-171:2008.

5.2.3 PDF-Unterlagen

Ausschlaggebend ist WCAG 2.0 und ISO Standard PDF/UA. Referenzwerke und Prüfinstrumentarien siehe Kapitel 4.4.

5.2.4 für PDF-Formulare

Betreffend PDF-Formulare siehe Abschnitt 4.4.1.

5.2.5 Einsatz von Probanden

Für Fälle lt. Abschnitt 5.2.1 bis 5.2.4 wird der Einsatz von Probanden mit entsprechender Medienkompetenz, mit und ohne Behinderung und im Falle der Behinderung mit Praxiserfahrung mit Assistierender Technologie , insbesondere im Rahmen der begleitenden Evaluierung von Großprojekten und in der Leistungsabnahmephase aller Projekte, insbesondere solcher, die auf breite Öffentlichkeit bezogen sind, dringend empfohlen.

5.2.6 Externe Überprüfungs- / Zertifizierungsstellen

Da diese Frage einen strategischen Charakter aufweist, wird die Übersicht externer Überprüfungs- und Zertifizierungsanbieter nach Bedarf weiterentwickelt. Zur Orientierung wird der Önorm 9241-171:2008 folgendes entnommen:

Normkonformität. Um die Einhaltung von Normen objektiv nachweisen zu können, bieten das Österreichische Normungsinstitut und „Austrian Standards plus Certification" die Möglichkeit der Zertifizierung von Produkten, Dienstleistungen und Personen auf Normkonformität.

Austrian Standards plus Certification (AS+C)Heinestraße 38, 1020 WienE-Mail: [email protected]: +43 1 213 00-520www.as-plus.at/certification Tel.: +43 1 213 00-524


ISO 9001:2000Die „Austrian Standards plus GmbH" ist ein certified by SQS Unternehmen des Österreichischen Normungsinstituts.

%%tiefergehende Ausarbeitung erforderlich, insbesondere die Ergänzung der Anbieterliste bspw. durch einzelne Institute der TU Wien, Uni Linz usw.$$

5.3 Definierung der Bewertungskriterien als Beispiel

Die Gewichtung der Barrierefreiheit zur Gesamtleistung sollte mindestens 20% der Gesamtbewertung betragen und zugleich ein K.O.-Kriterium darstellen.

5.3.1 Übersicht der Zuschlagskriterien als Beispiel

Zuschlagskriterien können beispielsweise die Referenzen, die im Angebot vorgeschlagenen qualitativen Lösungen - insbesondere aus der Sicht der Bedienungsfreundlichkeit und Barrierefreiheit, in Bezug auf Hosting auch Sicherheit, Zuverlässigkeit und Verfügbarkeit, der Projektablauf / die Nachvollziehbarkeit des Angebotes und der Preis sein.

5.3.2 Bewertungsfragen als Beispiel

Bewertung der Referenzen als Beispiel zur Orientierung (keine taxative Zusammenstellung):

● Welche Erfahrungen können in sämtlichen geforderten Themengebieten: Relaunch und Hosting der Website, Portierung und Hosting von E-Mail-Accounts, Schulung von RedakteurInnen , insbesondere in Bezug auf Bedienungsfreundlichkeit unter Berücksichtigung der Barrierefreiheit sowie Sicherheit, Zuverlässigkeit, Verfügbarkeit in Bezug auf Durchführung sowie Hosting etc. vorgelegt werden: durchgeführte Projekte, veröffentlichte Fachbeiträge, Trainings etc.?

● Liegen die dargelegten Ergebnisse nachvollziehbar und professionell vor?● Ist das Qualifizierungs- und Erfahrungsniveau des Teams ausreichend (Bereitstellung

eines geeigneten, erfahrenen und qualifizierten Personals)?● Bewertung des inhaltlichen Angebotes● Bewertung der im Angebot vorgeschlagenen Lösungen - Nachvollziehbarkeit auf Basis

der vorgelegten Leistungsbeschreibung● Professionalität der Aufbereitung● Kreativität der Vorschläge● Wurden alle vorgegebenen Inhalte berücksichtigt (Gender, Diversity, Zentrum-

Peripherie, etc.)● Sind zusätzliche Inhalte eingeflossen● Umfassende Berücksichtigung der Rahmenbedingungen● Entsprechen die Vorschläge den gestellten Anforderungen● Gibt es entsprechende realistische und nachvollziehbare Empfehlungen


● Projektablauf – Nachvollziehbarkeit des Angebotes● Geplante Arbeiten sind nachvollziehbar, effizient und klar dargestellt● Können durch die Wahl der Lösungsvorschläge aussagekräftige Ergebnisse erzielt

werden● Preis

5.3.3 Bewertungsfaktoren als Beispiel

Ein Beispiel für Gestaltung von Bewertungskategorien inkl. Bewertungsfaktoren (max 100% = Faktor 1,0):

● Bewertungskategorie 1: verlangte / vorgelegte Referenzen in Bezug auf bereits durchgeführte vergleichbare Projekte, Leistungen etc.; Bewertungsfaktor: 0,1;

● Bewertungskategorie 2: Vorschläge / qualitative Lösungen in Bezug auf Bedienungsfreundlichkeit und Barrierefreiheit; Bewertungsfaktor 0,2 (= K.O.-Kriterium);

● Bewertungskategorie 3: Vorschläge / qualitative Lösungen in Bezug auf technische Ausführung, Sicherheit, Hosting, Verfügbarkeit usw.; Bewertungsfaktor: 0,2 (könnte selbstverständlich auch als K.O.-Kriterium dienen).

● Bewertungskategorie 4: Erfahrung und Qualifikation des eingesetzten Personals / Projekt-Teams, Projektablauf, Nachvollziehbarkeit des Angebotes; Bewertungsfaktor 0,2;

● Bewertungskategorie 5: Preis, Preis-Leistungsverhältnis, Bestbieter-Prinzip; Bewertungsfaktor: 0,3.

5.4 Accessibility Statement

Vom Auftragnehmer soll gem. Abschnitt 2.2 AVB-IT/SW bzw. Abschnitt 2.3 AVB-IT/Projekte (jew. 2011), verpflichtenderweise ein Accessibility Statement im Rahmen der Leistungsübergabe zur Abnahme von Seiten des Auftraggebers verlangt werden. Diese sollte optimalerweise bei der Anbotslegung vorgelegt und bei der Leistungsübergabe an den Auftraggeber ergänzt werden. Dabei handelt es sich um eine detaillierte und nachprüfbare Beschreibung der zu erreichenden (bei der Anbotslegung) bzw. erreichter Ziele und Vorgaben (vor der Leistungsabnahme) in Bezug auf die in der Angebotsunterlage angeführten verpflichtenden Regelwerke und um Erklärung zu evtl. aufgetretenen punktuellen Abweichungen, samt Definierung gleichwertiger alternativer Problemlösungsansätze in Bezug auf Bedienungsfreundlichkeit und Zugänglichkeit für Assistierende Technologie. Weiters hat der Auftragnehmer eine Kontaktperson für Nachfragen zum Thema Barrierefreiheit zu benennen.


5.5 Vergabepraxis

Die Vergabepraxis wird in vier Abschnitte unterteilt: vor Beauftragung, bei Beauftragung, nach Beauftragung / bei der Leistungsabnahme und bei Routineprüfungen.

5.5.1 Vor Beauftragung

Bei der Definierung der Anforderungen des Ausschreibungsgegenstandes können folgende Situationen auftreten:

1) Neuausschreibung einer Software mit User-Interface: beigezogene betroffene Personengruppen und Experten formulieren im Detail die Anforderungen in Bezug auf Barrierefreiheit mit Verweis auf die aktuellen Standards, Normen, Richtlinien.

2) Bei bestehender Software mit User-Interface: Evaluierung / Tests durch betroffene Personengruppen und Experten in Hinblick auf Barrierefreiheit durchführen; Orientierung immer an den aktuellen Standards, Normen, Richtlinien, die bei einer Beschaffung / Korrektur umzusetzen sind, erforderlich.

Empfehlung an Beschaffer: Aussagen zur Barrierefreiheit der zu beschaffenden Software (des IKT-Produktes) schon bei der Angebotslegung einfordern.

Die Orientierungs- bzw. Leitfragen können nach Bedarf ausgearbeitet werden.

In die Überlegungen zur Leistungsdefinierung sollen Detail-Überlegungen einfließen wie etwa, dass es uns bewusst sein muss, dass es Menschen mit diversen Arten der temporären oder langfristigen Beeinträchtigung in allen Altersklassen, Berufsgruppen und Lebensbereichen gibt, wobei dies keine Behinderung im herkömmlichen Sinne sein muss.

Nicht jedem sieht man die Behinderung an, manch einer würde sich selbst nicht als behindert bezeichnen z.B.:

- Ein 33jähriger Einkäufer für Büroausstattung nutzt für seine Aufgabe verschiedene Online–Shops. Er ist farbenblind und hat oftmals Mühe, Einzelheiten auf den Produktfotos zu erkennen. Am liebsten kauft er dort ein, wo es aussagekräftige Texte zur Beschreibung der Produkte gibt. Ebenso hat er Probleme, Sonderpreise zu entdecken, wenn sie nur mit roter Farbe gekennzeichnet sind. 8 bis 10 % der Männer sind farbfehlsichtig, insbesondere bezüglich Rot-Grün-Farbkombinationen (genetische Veranlagung), viele von ihnen wissen gar nicht um ihre Behinderung.

- Eine 48-jährige Journalistin hat sich durch exzessive Computerarbeit und Mausgebrauch eine langwierige Sehnenscheidenentzündung zugezogen. Sie muss lernen, den Computer mit der Tastatur zu bedienen, und bekommt eine Spracheingabe für das Diktieren von Texten. Sie ist froh über jede Webseite und jedes Computerprogramm, die nicht mit der Maus bedient werden muss.

- Ein junger Mann mit Down-Syndrom findet sich im Supermarkt nur schwer zurecht, vor allem wenn dort häufig umgeräumt wird. Ein Freund zeigt ihm ein besonders gut gemachtes Bestellservice im Internet. Hier gibt es eine Suchfunktion mit


Wortvorhersage, so dass er nur die ersten Buchstaben eintippen muss, um das richtige Produkt zu finden. Außerdem kann er seine alten Bestellungen als Vorlage nutzen. Trotz seiner Lernbehinderung kauft der junge Mann jetzt seine Lebensmittel im Internet.

Diese beispielhafte Szenarien erläutern den Nutzen von Universellem Design im Internet. Sie stammen vom WAI, der Web Accessibility Initiative des World Wide Web Consortiums (W3C). In ähnlicher Weise wenden Usability Professionals die Methode der Personas25 an, um realistische Anforderungen verschiedener Nutzergruppen zu beschreiben. Vor allem wenn allgemein nutzbare Produkte entwickelt werden sollen, ist es wichtig, mögliche Funktionseinschränkungen und deren Auswirkungen von Anfang an mitzudenken.

5.5.2 Bei Beauftragung

Bei der Beauftragung geht es um die konkrete Vertragsunterzeichnung und kann sich dabei auf das Ergebnis (siehe Anmerkung zu 5.5.1) beziehen bzw. die Bestätigung des Lieferanten beinhalten, dass die Software (das IKT-Produkt) barrierefrei geliefert wird unter Einhaltung der entsprechenden Regelwerke.

Bei Vertragsabschluss kann auch eine Prüfung vereinbart werden (Festlegung, wer die Prüfung durchzuführen, zu beauftragen bzw. zu bezahlen hat).

Empfehlung an Beschaffer: Ein fixes Set an Richtlinien ISO, EN, WCAG, PDF/UA (siehe Matrix) sowie evtl. der Verweis auf die AVB-IT und evtl. der gesetzliche Rahmen sollte in den Vertrag aufgenommen werden (es muss dem DL klar sein, dass Barrierefreiheit eine Vorgabe ist);

Der Beschaffer sollte hier schon klären, wie eine Abnahme in Bezug auf Barrierefreiheit aussehen soll (wer bezahlt die Abnahme bzw. wer führt die Abnahme durch).

Beispiele:

- Verpflichtend: Anzuwendende Regelwerke und Tools; welche Dokumentation muss zum Schluss vom Auftragnehmer abgegeben werden

- Einen Entwurf des Statements zur Einhaltung der BF gem. AVB-IT Software / Projekte (Software oder Projekte-Teil) beilegen

- Im Entwurf Bezug auf die erforderlichen Richtlinien, die bei der Leistungsausschreibung vorgegeben waren, nehmen

25 Definition lt. Onlinemarketing-Praxis: "Personas (lat. Maske) sind Nutzermodelle, die Personen einer Zielgruppe in ihren Merkmalen charakterisieren. Sie können z. B. einem Entwicklerteam aufgrund ihrer umfangreichen Beschreibung helfen, sich in die Lage der potenziellen Nutzer zu versetzen und diese Perspektive während des gesamten Designprozesses leicht zu vertreten. Sie werden mit einem Namen, einem Gesicht, einer Funktion, einem Werdegang und einem Privatleben versehen. Personas verfügen über Ziele und Verhaltensweisen, haben Vorlieben und Erwartungen. Um sie entwickeln zu können, bedarf es vorerst anderer quantitativer und qualitativer Methoden, um geeignete Nutzerdaten erheben zu können, wie beispielsweise Online-Befragungen oder Interviews. Liegen diese Daten vor, lassen sich durch Segmentierung- und Clusteranalyseverfahren sog. Kern- und Rand-Personas, die Hauptnutzergruppen und deren Untergruppen repräsentieren, ermitteln." für weitere Details siehe http://www.onlinemarketing-praxis.de/glossar/personas, letzte Abfrage 26.06.2014


- Elemente für Accessibility Statement formblattmäßig definieren- Was ist erfüllt, und was nicht; wenn nicht, warum nicht udgl.- Was ist verpflichtend und was optional?- Auch Nicht-Zutreffendes in Bezug auf Standards, Normen, Regelwerke und damit

Nicht-Prüfbares und -Geprüftes ist im Bericht/Statement mit anzuführen- Für beide Seiten, Auftraggeber und Auftragnehmer, ist wichtig, das Verständnis über

Regelwerke, Prüf-Kriterien und Prüfinstrumentarien, sowie über die Ergebnisdokumentation zu erhalten.

- Überprüfung bezieht sich immer auf den jeweiligen Zeitpunkt der Überprüfung. Die Vorgangsweise bzgl. Leistungsabnahme bei nachträglichen Korrekturen wäre unbedingt zu definieren.

5.5.3 Nach Beauftragung – Leistungsabnahme

Die vereinbarte Personengruppe und Experten prüfen die Software (das IKT-Produkt) für die Abnahme. Eine erfolgreiche Abnahme kann nur nach erfolgreicher Prüfung erfolgen.

Empfehlung an Beschaffer: Das Ergebnis der Prüfung in Bezug auf Barrierefreiheit sollte im Abnahmeprotokoll aufscheinen.

Die tiefergehenden Orientierungs- bzw. Leitfragen können nach Bedarf ausgearbeitet werden.

Beispiele:

- Siehe auch Kapitel 4.3, 5 und 5.1- Für nicht web-basierte Anwendungen: Anhang C1 der Önorm 9241-171:2008

Checkliste zur Überprüfung (5.2)- Dokumentation, von Seiten des Auftragnehmers vorzulegende Berichte begleitend

zum Accessibility-Statement (maschinelle Auswertungen von automatisierten Prüftools, bei der ÖNORM 9241-171 Formblätter C1 aus dem Anhang C der Norm.

- Was muss der Auftraggeber überprüfen und wie?

5.5.4 Bei Routineüberprüfung

Jederzeit durch den Auftraggeber. Bei Mängeln an der Software (dem IKT-Produkt) ist es ein Teil der Vertragsgestaltung, wer für die Behebung der Mängel aufkommen muss.

Empfehlung an Beschaffer: Bei Durchführung einer Routineprüfung sollte vorab klar sein, ob die Behebung allfälliger Mängel durch den Auftragnehmer erfolgen wird (vertraglich gesichert) bzw. ob ein Rechtsstreit angestrebt wird oder ob es um das Aufzeigen von Problemen im Bereich Barrierefreiheit geht, die behoben werden sollen (egal von wem)

Die Orientierungs- bzw. Leitfragen können nach Bedarf ausgearbeitet werden.


6 Betriebswirtschaftliche DimensionObwohl der Nutzen der IKT-Barrierefreiheit weder nach beispielsweise rechtlichen, noch nach soziologischen Gesichtspunkten zur Disposition steht, trifft man immer wieder auf einzelne ablehnende Meinungen oder Überlegungen, die einer minimalistischen Realisierungsform entsprechen – „Barrierefreiheit = ausschließlicher Behinderungsbezug; Schlussfolgerung: Haben wir nicht, brauchen wir nicht“; „wegen des geringen Bedarfs doch sekundär, die Barrierefreiheit lässt sich doch nachträglich, nach Bedarf, irgendwie herstellen - Flickwerk“, „intern unnötig, extern wegen des Öffentlichkeitsdrucks am Ende doch aber halbherzig / minimalistisch realisiert“ usw. – die man dabei mit vermeintlich betriebswirtschaftlichen, überwiegend quantitativen, budgetären Hintergründen zu untermauern versucht. Die beispielhaften Überlegungen in der Dissertation von Puhl (2008) und in seinem Vortrag (2009), der nachfolgend punktuell zitiert wird (siehe Anhang C), lassen sich unschwer auch auf sämtliche anderen Umsetzungsfälle der IKT-Barrierefreiheit, etwa von digitalen Medien und Unterlagen aller Art , nicht web-basierten Anwendungen sowie von dynamischen Anwendungen jeweils mit User-Interface, die bspw. in der Verwaltung eingesetzt werden, übertragen.

6.1 Definition der Begriffe „Nutzen" und „Nutzenbewertung"

Im Mittelpunkt des Beitrags von Puhl (2009) „stehen die qualitativen Leistungen, die aus der Barrierefreiheit von Web-Präsenzen resultieren können. Diese qualitativen Effekte bzw. Vorteile werden im weiteren Verlauf als „Nutzen" (Plural) bezeichnet. Diese Nutzen sind zu identifizieren und verbal zu beschreiben und sie müssen zur Bewertung in ihrer tatsächlichen Ausprägung gemessen sowie ins Verhältnis zur jeweiligen Vorgabe/Erwartung gesetzt werden. Aus der Sicht eines Web-Nutzers steht das Ergebnis einer Nutzenbewertung das Maß für seine Bedürfnisbefriedigung an einem bestimmten Ort und zu einem bestimmten Zeitpunkt dar. Aus Sicht eines Unternehmens hingegen ist das Ergebnis einer Nutzenbewertung das Maß für die Erreichung vorgegebener (Projekt-)Ziele. Im Allgemeinen deutschen Sprachgebrauch bezeichnet der Begriff „Nutzen" (Singular) die genannten Maße der Bedürfnisbefriedigung und Zielerreichung.“ (o.V. 1997, S.487f., zit.n. Puhl (2009)) „Jede Unternehmensentscheidung, so auch die über die barrierefreie Aus- oder Umgestaltung der Unternehmens-Website, muss ökonomisch gerechtfertigt sein. Dazu ist eine Wirtschaftlichkeitsrechnung, die auf das Verhältnis von quantitativen Leistungen zu Kosten abstellt, alleine nicht ausreichend. Die Begründung dafür ist, dass die Leistungen einer barrierefreien Web-Präsenz nur sehr bedingt quantitativer, sondern vor allem qualitativer Art sind. Folglich ist es bei der ökonomischen Rechtfertigung geboten, zwischen Wirtschaftlichkeitsrechnung und Nutzenbegründung zu differenzieren. Solange die Leistungen aus steigenden Umsätzen und quantitativ messbaren Ressourceneinsparungen bestehen, können bei der Wirtschaftlichkeitsrechnung statische und dynamische


„eindimensionale“ Investitionsrechenverfahren angewendet werden. Die überwiegend qualitativen Leistungen (Nutzen) der Barrierefreiheit von Web Sites lassen sich nicht in eine solche Wirtschaftlichkeitsrechnung fassen bzw. mit einer solchen berechnen, so dass zur ökonomischen Rechtfertigung jener IT-Entscheidung zwingend eine Nutzenbegründung erforderlich ist.“ (Kargl 2000, S 41 ff., zit.n. Puhl (2009))

6.2 Methoden und Techniken der Nutzenidentifikation und Nutzenbewertung

Nach Puhl (2009) bedarf es „im Rahmen der ökonomischen Rechtfertigung jeder einzelnen IT-Entscheidung einer Ex-ante-Bewertung der Handlungsalternativen und der Investition. Eine solche Ex-ante-Bewertung26 findet prinzipiell in einem Spektrum statt, das in seinen Extremen durch die interpretative und die formal-rationale Perspektive bestimmt ist. Die interpretative Perspektive fokussiert auf der Analyse und dem Verständnis der sozialen und subjektiven Natur von IT-Anwendungssystemen. Besonders adressiert wird hier die Interaktion der Technologie mit Organisationsstrukturen, Kulturen und Anspruchsgruppen. Die formal-rationale Perspektive hingegen leitet den Wert eines IT-Systems aus seiner Performanz und (monetären) Wirtschaftlichkeit ab, wodurch die ökonomischen und technischen Aspekte betont werden. Der Erfolg eines IT-Systems bzw. einer Web Site ist aber nicht allein von technischen Aspekten determiniert, sondern zu großen Teilen von „menschlichen Problemen" sowie von organisatorischen und marktlichen Aspekten.“ (Walter und Spitta 2004, S. 172 ff., zit.n. Puhl (2009)). Siehe Anhang C. Literaturverzeichnis

6.3 Analyse kritischer Erfolgsfaktoren

Nach Puhl (2009) bietet die top-down durchgeführte Analyse kritischer Erfolgsfaktoren , ergänzt um die bottom-up durchgeführte IT-Potenzialanalyse einen ersten Ansatz zur Nutzenidentifikation. „Das Konzept der kritischen Erfolgsfaktoren ist auf die Ergebnisse der Situationsanalyse im Rahmen des strategischen Managements anzuwenden und erlaubt es Entscheidern, strategische IT-Handlungsbedarfe anhand von Umweltfaktoren und internen Begrenzungsfaktoren zu identifizieren und zu beschreiben. In Anlehnung an Potthoff 1998, S. 19 (zit.n. Puhl (2009)) sind bezogen auf die Barrierefreiheit die folgenden kritischen Erfolgsfaktoren von Bedeutung: Strategie, Wettbewerb und Marktgängigkeit (Marktdurchdringung, Marktentwicklung, Produktentwicklung und Diversifikation), Strategie, Sozialkompetenz und Image-Überlegungen (Verankerung der Barrierefreiheit im Wertesystem des Unternehmens), Nutzerorientierung (Ausrichtung an Wünschen und Bedürfnissen der Web-Nutzer), Qualität (Qualität der Leistungserstellung, Leistungsqualität),

26 Ex-Ante-Kontrolle (Definition nach Gabler Wirtschaftslexikon): Versucht wird, Soll-Wird-Abweichungen zu antizipieren.


Information, Flexibilität und Motivation (Abbau von Akzeptanz- und Willensbarrieren bei Mitarbeitern und Geschäftspartnern.“

6.4 Nutzenbewertungsmodell der Barrierefreiheit

Die Ausführungen von Puhl (2009) „zu den Nutzen der Barrierefreiheit von Web-Präsenzen“ begründen qualitativ, dass die Realisation der Barrierefreiheit Kosten verursacht diese nachfolgend zu identifizieren und zu analysieren sind: „Bezogen auf die einzelnen Projekt- bzw. Prozessphasen der Barrierefreiheit (Planung, Umsetzung, Betrieb, Pflege und Wartung sowie Relaunch) ist festzustellen, dass die Planung (und Konzeption) einer barrierefreien Web-Anwendung etwas höhere Kosten im Vergleich zur selben Phase bei einer nicht barrierefreien, verursacht.“

6.5 Leistungen der Barrierefreiheit von Web-Präsenzen

Nach Puhl (2009) stehen „der vorbeschriebenen Kostensituation auch quantitative Leistungen, bspw. in Form wachsender Umsatzerlöse, in Form von Kosten- und Zeiteinsparungen und/oder in Form technischer Vorzüge gegenüber.“ Zu den Kosten- und Zeiteinsparungen zählen (Deutsche Behindertenhilfe Aktion Mensch e.V. 2003, S. 4f. , zit.n. Puhl (2009)): „geringere Übertragungsraten, verringerte Serverlast, vereinfachte Pflege und Wartung, schnellere Ladezeiten.“ Die technischen Vorzüge sind (Leonhardt Multimedia GmbH 2002, S. 5, zit.n. Puhl (2009)): „plattformunabhängige Ausführbarkeit, Funktionsfähigkeit der Web Site trotz abgeschalteter Features, korrekte Darstellung auch bei Infrastruktur-Defiziten, vollständige Druckbarkeit der Seiteninhalte, Suchmaschinenoptimierung, Ausgabe auch auf alternativen Endgeräten wie Handy, PDA oder Autobordcomputer.“

Nach Puhl (2009) können „in einer Gesamtbetrachtung die vorbeschriebenen Ressourceneinsparungen und technischen Vorzüge einerseits zu Effektivitäts- und Effizienzsteigerungen bei der Leistungserstellung im Unternehmen führen. Andererseits stellen diese Leistungen für alle Web-Nutzer, Nichtbehinderte und Behinderte, den Abbau von Infrastruktur-Barrieren dar, was bedeutet, dass sie die von ihnen auf einer Web Site gesuchten Informationen und Services schneller finden sowie effektiver und komfortabler nutzen können.“

6.6 Nicht-monetäre Wirtschaftlichkeit der Barrierefreiheit von Web-Präsenzen

Nach Puhl (2009) bedarf es „zur Bestimmung der nicht-monetären Wirtschaftlichkeit der Barrierefreiheit von Web-Präsenzen einerseits der Bewertung der Nutzen der Barrierefreiheit. Andererseits sind die möglichen Opfer der Barrierefreiheit zu erörtern und zu bewerten.“


6.7 Opfer der Barrierefreiheit von Web-Präsenzen

Nach Puhl (2009) werden hier „analog zur Definition des „Nutzens" unter „Opfern" qualitative Effekte bzw. Nachteile verstanden. Aus diesem Grunde ist zu klären, ob mit der barrierefreien Aus- oder Umgestaltung von Unternehmens-Websites Nachteile qualitativer Art für die Unternehmen verbunden sind und wenn ja, welche. Unternehmen müssen nicht grundsätzlich auf den Einsatz moderner Formate (z. B. Flash) und Techniken (wie z. B. AJAX) verzichten, sondern sie müssen die auf Basis dieser Formate und Techniken gestalteten Elemente der Web Sites im Rahmen der Möglichkeiten, die diese Formate und Techniken bieten, barrierefrei gestalten. Die barrierefreie Gestaltung dieser Elemente geht mit Kosten einher.

Setzt ein Unternehmen bspw. ein Flash-Video auf seiner Web Site ein, so ist dieses mit den Möglichkeiten, die das Format bietet, barrierefrei zu gestalten, z. B. mit Untertiteln, Audiodeskriptionen und Gebärden zu versehen. Dies ist mit Kosten verbunden. An dieser Stelle sind keine Opfer der Barrierefreiheit für das Unternehmen feststellbar, denn es muss nicht auf den Einsatz von Flash verzichten.

Moderne Rich Internet Applications (RIA)27, bspw. unter Verwendung von AJAX, sind z.B blinden Web-Nutzern ab der Version 7.10 des Screenreaders Jaws (verfügbar seit Mitte 2006) erstmals technisch zugänglich, sofern die RIA von den Entwicklern der Unternehmens-WebSites entsprechend programmiert sind.“ (Faulkner und Lemon 2007, zit.n. Puhl (2009)) „Für die barrierefreie Programmierung fallen Kosten an. Gleichwohl sind derartige barrierefrei programmierte RIA Nutzern anderer Screenreader oder älterer Versionen von z.B. Jaws auch weiterhin technisch nicht zugänglich, so dass das Unternehmen in diesem speziellen Fall entscheiden muss, ob es auf den Einsatz von AJAX zugunsten der Zugänglichkeit für alle Web-Nutzer verzichten will. Im Rahmen eines solchen Verzichts erbringt das Unternehmen ein Opfer. Innerhalb des gerade betrachteten ökonomischen Handlungsrahmens können nur für den vorbeschriebenen Spezialfall „AJAX" Opfer der Barrierefreiheit für das Unternehmen ausgemacht werden, die zur Bestimmung der nicht-monetären Wirtschaftlichkeit dem Nutzen der Barrierefreiheit von Web-Präsenzen gegenüberzustellen wären.“

6.8 Zusammenfassung aus betriebswirtschaftlicher Sicht

Nach Puhl (2009) bedarf es im Rahmen der ökonomischen Rechtfertigung jeder einzelnen IT-Entscheidung, so auch zur barrierefreien Aus- oder Umgestaltung der Unternehmens-Web-Präsenz, der Ex-ante-Bewertung der Investition. „Bei der Entscheidung zu Gunsten der barrierefreien Aus- oder Umgestaltung der Unternehmens-Website ist es für das Top-Management in Unternehmen bedeutsam, die Barrierefreiheit nicht mehr bloß als

27 RIA (rich Internet application) (Definition nach ITWissen.info): (RIA) ist ein Ansatz, mit der intuitive Benutzeroberflächen im Internet aufgebaut werden können. Als Basis für Rich Internet Application gilt AJAX (asynchronous JavaScript and XML AJAX).


technische Komponente der Web Site zu begreifen, sondern es muss die Barrierefreiheit als integralen Bestandteil der Unternehmenszielsetzung und der Unternehmensstrategie verstehen und sich auf die damit erreichbaren „strategischen Mehrwerte" konzentrieren.“ (Puhl 2009)

Die Ergebnisse der Accessibility and Business Value Study28, durchgeführt von The Customer Respect Group (2008, zit.n. Puhl), bestätigen diese Sichtweise: „Executives interviewed by The Customer Respect Group cited increases in product sales, market opportunities, and customer loyalty as key benefits derived from accessibility and marketing efforts targeted toward people with disabilities and aging consumers. Study findings show that companies that approach accessibility as part of a larger corporate strategy realize the greatest return on investment. According to the study, ».. .for some of the best-performing companies... accessibility is part of a much bigger vision. The broad corporate strategy was not based upon a set of evolving technical standards but on a much more wide-ranging ambition to remove as many obstacles as possible between the corporation and its existing or potential clients.«"

28 erwerbbar unter http://archive.today/A9ZNL (letzte Abfrage am 23.05.2014)


7 IKT-Barrierefreiheit in Bezug auf fachliche Fortbildung

Im Jahr 2015 sind folgende Kurse (1-Tages-Seminare) mit dem Schwerpunkt „Barrierefreiheit“ an der Verwaltungsakademie des Bundes (VAB) geplant:

- BS 162 Barrierefreie Informationssysteme - Grundlagen- BS 163 Barrierefreie Inhalte - Leicht verständlich schreiben, damit der Inhalt

ankommt- BS 167 Barrierefrei präsentieren mit MS Powerpoint und PDF- BS 164 Barrierefrei publizieren mit MS Word und PDF- BS 165 Barrierefrei publizieren mit Adobe InDesign und PDF- BS 166 Barrierefreies Webdesign - Techniken und Best Practises

Jeweils zu finden unter dem Thema E-Government des VAB-Angebots:

https://www.oeffentlicherdienst.gv.at/vab/seminarprogramm/in_verwaltung_arbeiten/egovernment_2015.html

Diese Kurse eignen sich primär für den Erwerb grundlegender thematisch bezogener Kenntnisse und dienen vor allem dem Problemverständnis zum Thema Barrierefreiheit. Die TeilnehmerInnen werden damit keine ExpertInnen für Barrierefreiheit. Die Kurse dienen aber zur Ergänzung bestehender Vorkenntnisse und Erfahrungen der Teilnehmenden in deren beruflichem Umfeld.

7.1 Empfehlung

Wegen der hohen thematischen Komplexität wird eine Erweiterung und Spezialisierung des Schulungsangebotes an der VAB, auch im Hinblick auf die Grundausbildung, empfohlen.

Der Erwerb fundierter praxisbezogener Basiskenntnisse beispielsweise über empfohlene Normen, Standards und Richtlinien sowie das Erlernen des grundlegenden Umgangs mit hier angeführten Instrumentarien in einem Vergabeverfahren, wäre ein enormer positiver Beitrag im Sinne des eingangs beschriebenen rechtlichen und strategischen Auftrags.

Anmerkung aus Önorm 9241-171:2008:

Weiterbildung zu Normen. Ein Plus an Wissen rund um Normen und ihr Umfeld bietet die „Austrian Standards plus Trainings«. In Seminaren, Vorträgen, Workshops und Lehrgängen bieten Experten, die zum Großteil selbst an der Entwicklung der Normen mitwirken, Informationen und Know-how aus erster Hand.




Austrian Standards plus Trainings (AS+T)Heinestraße 38, 1020 WienE-Mail: [email protected] Fax: +43 1 213 00-350www.as-plus.at/trainings Tel.: +43 1 213 00-318


8 Barrierefreie Zugänglichkeit zu Fachliteratur bzw. (Cluster)Bibliotheken der Ressorts

Ausgangssituation

%%Zaczek, Ergänzung und Verfeinerung des Kap. 8 folgt$$

Derzeit ist Fachliteratur überwiegend nur als Printwerke verfügbar. Laut Auskunft der Clusterbibliothek beim Sozial- bzw. Wirtschaftsressort liefert derzeit nur der Verlag ÖGB zu sämtlichen gekauften Werken auch eine (kostenfreie) elektronische Version. Insbesondere Verlage, die rechtswissenschaftliche Literatur anbieten, etwa Manz, Österreich und Linde, bieten nach Auskunft der Clusterbibliothek so gut wie keine elektronischen Bücher an. Seitens Manz wird in diesem Zusammenhang auf das Manz-Online -Angebot hingewiesen, darin findet sich jedoch nur eine relativ kleine Auswahl an rechtswissenschaftlicher Fachliteratur. Seitens des Verlages Österreich wird auf Nachfrage mitgeteilt, dass an einem umfangreicheren Online bzw. E-Book-Angebot gearbeitet werde. Ähnlich verhält es sich mit anderer Fachliteratur, wobei zu bemerken ist, dass die Verlage von rechtswissenschaftlicher Literatur am wenigsten in Richtung barrierefreiem Zugang zu Literatur zu bieten haben.

Die oben beschriebene Situation führt dazu, dass Menschen mit Sehbehinderungen, denen das Arbeiten mit gedruckten Werken aufgrund ihrer Behinderung nicht möglich ist, der Zugang zu einschlägiger Literatur über weite Teile unmöglich ist. Das eigenhändige Digitalisieren bzw. Einscannen von Druckwerken kann – allein aus Zeitgründen – als keine zweckmäßige Lösung dieser Problematik angesehen werden.

Die Nichtbereitstellung von digitalen Versionen von Fach(Literatur) seitens der betroffenen Verlage kann als mittelbare Diskriminierung im Sinn des Behindertengleichstellungsgesetzes betrachtet werden, welche – nach derzeitigem Stand der Technik – wohl mit verhältnismäßig geringem Aufwand beseitigt werden könnte.

Insbesondere seitens des Verlages Manz wird dazu jedoch eingewandt, dass an ein über Manz-Online hinausgehendes Online oder E-Book-Angebot nicht gedacht wird, da dies auch seitens einiger Autoren aus Bedenken um die Wahrung ihrer Urheberrechtsinteressen, nicht gewünscht sei.

Seitens des Verlages Österreich wird nach Rückfrage im Gegensatz dazu zugesichert, dass an einem großflächigen E-Book bzw. Online-Angebot gearbeitet werde und man bis dahin im Einzelfall darum bemüht sei, Lösungen für die betroffenen Kunden zu finden, die jedoch stets im Einklang mit den (berechtigten) Rechtsschutzinteressen der Autoren steht.

Wie sich die Situation etwa im benachbarten Deutschland darstellt, wird in den kommenden Tagen im Rahmen mehrerer Anfragen an die einschlägigen deutschen Verlagshäuser


ermittelt. Bisher ist jedenfalls bekannt, dass etwa der HEISE-Verlag ein spezielles Angebot für sehbehinderte und blinde Menschen bietet.

8.1 Vorgeschlagene Vorgehensweise

1. Ressortintern wäre nunmehr Gespräche mit der Clusterbibliothek aufzunehmen, um abzuklären, wie bereits bestehende digitale Werke zugänglich gemacht werden könnten.

2. Auf einer zweiten Ebene wären (politische) Gespräche bzw. Verhandlungen mit den betroffenen Verlagen aufzunehmen, mit dem Ziel, bestehende Barrieren zu beseitigen und insbesondere die Verfügbarkeit von Fachliteratur in digitaler Form zu ermöglichen. Dazu wären gegebenenfalls sämtliche Stellen (Schlichtungsstelle beim Sozialministeriumservice, Behindertenanwaltschaft, Monitoringausschuss, Behindertenorganisationen, Behindertenbeirat) miteinzubeziehen.

%%Zaczek, ergänzung / Verfeinerung Kap. 8$$

9 Anhang A: Prüfvorgangsweisen und Prüftools

9.1 Prüfvorgangsweise für nicht web-basierte Anwendungen

Desktopanwendungen barrierefrei zu gestalten ist kein immenser Zusatzaufwand, wenn diese Anforderung frühzeitig im Entwicklungsprozess mit eingeplant wurde. Die wichtigste Vorentscheidung ist die Auswahl einer Plattform, die für die Nutzung mit technischen Hilfen geeignet ist.

Die Richtlinien für barrierefreie Computerprogramme sind in der ISO-Norm 9241-171 niedergelegt. Eine beispielhafte praktische Handreichung liegt in der IBM-Checkliste für barrierefreie Software vor, die auf der älteren US-Richtlinie ADA Section 508 basiert. Grundsätzlich gelten die gleichen Anforderungen, wie sie für Webanwendungen in den WCAG-Richtlinien (WCAG 2.0) beschrieben sind.

Für die Umsetzung der Regeln in den verschiedenen Plattformen und Programmiersprachen gibt es Anleitungen und Best-Practice der jeweiligen Hersteller, die lediglich einen informativen Charakter für den Auftragnehmer während der Entwicklung haben können. Der Auftraggeber prüft die Ergebnisse nach den Normen, Standards und Richtlinien laut gegenständlichem Dokument.

Grundanforderungen für barrierefreie Computerprogramme:

- Einhaltung der Gestaltungsprinzipien für Universelles Design- Vollständige Maus- / Tastatur / ggf. Touchscreen-Bedienbarkeit- Einhaltung der Betriebssystem-Standards für Bedienelemente


- Beachtung der Accessibility-Optionen des Betriebssystems (Schriftvergrößerung, Kontrastmodus)

- Barrierefreie DokumentationFür den Test der Barrierefreiheit von Desktop–Software gibt es kaum Unterstützung durch automatische Tools. Der Test besteht im Wesentlichen in vollständiger Bedienung der Software mit der Tastatur, mit den Accessibility-Optionen des Betriebssystems und mit assistierenden Technologien. Ein effizientes und sicheres Testverfahren basiert auf Testszenarien, die an typischen Aufgaben orientiert sind. Spätestens in der Testphase sind Experten gefragt. Dies können externe Experten für Barrierefreiheit sein, unterstützt durch behinderte Nutzer, die die Software mit ihren Hilfsmitteln testen.

Worauf man beim Testen von Desktop-Anwendungen beispielsweise achten sollte:

● Testen Sie typische Benutzungs-Szenarien mit allen Hilfsmitteln komplett durch.● Ist der Fokus in Dialogen immer sichtbar?● Ist die Tab-Reihenfolge bei Tastatur - Navigation logisch und nachvollziehbar?● Sind alle Bedienelemente erkennbar?● Testen Sie, ob die Accessibility-Optionen des Betriebssystems vollständig benutzbar

sind. Das Ziel der Überprüfung ist die uneingeschränkte Wahrnehmbarkeit, Bedienbarkeit, Verständlichkeit und Robustheit der Anwendung mit User-Interface.

9.2 Prüfwerkzeuge für web-basierte Anwendungen (empfehlenswerte Beispiele)

Ein reichhaltiges Angebot von Open-Source-Tools erleichtert es Webdesignern, Barrierefreiheit während der Produktion umzusetzen. Empfehlenswert sind vor allem Browser–Erweiterungen, die auf einfache Weise genutzt werden können.

9.2.1 Empfehlenswerte Prüf-Tools

- Web Accessibility Toolbar – http://www.wob11.de/watkomplett.html - Web Developer Toolbar – https://addons.mozilla.org/de/firefox/addon/toggle-web-

developer-toolbar - Juicy Studio Accessibility Toolbar –

https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/ - Firebug – https://addons.mozilla.org/en-US/firefox/addon/firebug/ - W3C–Validator – http://validator.w3.org - Contrast Analyser – http://www.paciellogroup.com/resources/contrast-analyser.html - PDF Accessibility Checker (PAC) – http://www.access-for-all.ch/ch/pdf-werkstatt/pdf-

accessibility-checker-pac.html Nachstehend die Liste geeigneter Prüfwerkzeuge für maschinelle – teilweise automatisierte – Überprüfung einzelner Elemente einer web-basierten Anwendung. Diese Werkzeuge


stellen eine wesentliche Orientierungshilfe und bieten Unterstützung im Leistungsabnahmeprozess, können jedoch die menschliche Interaktion keinesfalls vollständig ersetzen.

9.2.2 Werkzeuge zur Code-Validierung

Validierung nach HTML – W3C-HTML-Validator: http://validator.w3.org/ http://validator.w3.org/

Validierung nach CSS – W3C-CSS-Validator: http://jigsaw.w3.org/css‐validator/ http://jigsaw.w3.org/css validator/‐

Überprüfung von Webseiten nach WCAG 2.0:

Hinweis (12.2.2015): Kein Tool kann eine Prüfung nach den WCAG-Techniken durch Menschen ersetzen! Sie können ergänzend eingesetzt werden – wo möglich. Die Tools berücksichtigen bislang noch unzureichend den Einsatz neuer Technologien (HTML 5 …) und bieten wenig bis keine Unterstützung bei der Prüfung von Webseiten und -anwendungen mit Javascript, insbesondere dynamische Anwendungen (siehe auch Kapitel 9.3).

9.2.2.1 Cynthiasays – Webanwendung: http://www.cynthiasays.com http://www.cynthiasays.com/

Prüfoptionen:

● WCAG 2.0 A, AA, AAA und Section 508Eingabeoptionen:

● URL der WebseitePrüfergebnis:

● Ein Bericht mit Links zu WCAG 2.0 Techniken

9.2.2.2 AChecker – Webanwendung: http://achecker.ca http://achecker.ca/ Prüfoptionen:

● WCAG 2.0 A, AA, AAA und andere (BIT-V, Section 508)● HTML-Validierung● CSS-Validierung

Eingabeoptionen:

● URL der Webseite● lokale HTML-Datei

Prüfergebnis:

● Liste an Fehlern, Probleme und manuell zur Prüfendes in Bezug und mit Links zu WCAG 2.0 Techniken


http://achecker.ca/

http://www.cynthiasays.com/

http://jigsaw.w3.org/css%E2%80%90validator/

http://validator.w3.org/

9.2.2.3 Total Validator – Client Programm und Erweiterung für Browser: http://www.totalvalidator.com http://www.totalvalidator.com/

Prüfoptionen:

● WCAG 2.0 und Section 508● HTML-Validierung● Link-Check● Spell-Check

9.2.2.4 WAVE – Webanwendung: http://wave.webaim.org http://wave.webaim.org/ Prüfoptionen:

● WCAG 2.0 AAEingabeoption: URL der Webseite

Prüfergebnis:

● Icons zu Bereichen der gescannten und dargestellten Webseite, Erklärung zu Icons

9.2.2.5 Site Valet 2.0: http://valet.webthing.com/2.0/ http://valet.webthing.com/2.0/ Kommerzielles Produkt zur Prüfung von Websites nach Accessibility und Qualitätssicherung.

Checkt:

● Code-Validität● WCAG 2.0 AA● Links● Metadaten

9.2.2.6 Browser-Erweiterungen für Tester und EntwicklerWeb Accessibility Toolbar – Browser-Erweiterung für IE: http://www.wat c.org/tools/index.html‐ http://www.wat c.org/tools/index.html‐

Web Developer Toolbar – Browser-Erweiterung für Firefox: https://addons.mozilla.org/de/firefox/addon/60/ https://addons.mozilla.org/de/firefox/ addon/60/

Firebug – Browser-Erweiterung für Firefox: http://getfirebug.com/ http://getfirebug.com/

9.2.2.7 Weitere Test-ToolsDiverse Online Werkzeuge zur Überprüfung von Farbkontrasten, Simulation nach Farbfehlsichtigkeiten:

● Viceck simuliert Farbfehlsichtkeiten und Farbblindheiten: http://www.vischeck.com/ http://www.vischeck.com/

● Luminosity Colour Contrast Ratio Analyser: Prüft Farbkontrast nach WCAG 2.0 AA, Eingabe von Vordergrund-/Hintergrundfarbe. Link:


http://www.xn--watc-n86a.org/tools/index.html

http://www.vischeck.com/

http://getfirebug.com/

https://addons.mozilla.org/de/firefox/addon/60/

https://addons.mozilla.org/de/firefox/addon/60/

http://valet.webthing.com/2.0/

http://wave.webaim.org/

http://www.totalvalidator.com/

http://juicystudio.com/services/luminositycontrastratio.php http://juicystudio.com/ services/luminositycontrastratio.php

Prüf-Techniken und Tools für PDF-Dokumente nach WCAG 2.0 und PDF/UA siehe Kapitel 4.4.

9.3 Dynamische Web-Anwendungen

Obwohl die dynamischen Web-Anwendungen keine explizite Berücksichtigung in diesem Bericht finden, wird nachfolgend eine kurze Darstellung der Problematik mit dem Hinweis auf den angedachten Arbeitsblock III gegeben.

Während die Verfahren zur barrierefreien Gestaltung von Informations-Websites schon relativ ausgereift sind, stellen die dynamischen Webanwendungen im Moment noch eine Pionieraufgabe dar. Anwendungen wie Online–Editoren oder Routenplaner im Internet halten einige Herausforderungen für die Entwicklung einer barrierefreien Bedienoberfläche bereit.

Dynamische Webanwendungen stellen sich der Aufgabe, die Komplexität und den Bedienungskomfort klassischer Computerprogramme auf die allgemein verfügbare Plattform des Internetbrowsers zu übertragen. Verarbeitungsprozesse, die sonst serverseitig liefen, werden durch Javascript und AJAX direkt im Browser ausgeführt. Dabei ergeben sich einige Schwachstellen, die beim Einsatz Assistierender Technologie kritisch werden können.

Neue Bedienelemente. Bedienelemente wie z. B. Schieberegler, die im Formularsatz von HTML nicht enthalten sind, müssen sich assistierenden Geräten in ihrer Funktion zu erkennen geben.

Komplexität. Eine Vielfalt von Bedienfunktionen übersichtlich anzuordnen, ist häufig nur durch das Ein- und Ausblenden von Ebenen möglich. Geräte, die nur einen kleinen Ausschnitt des Bildschirms anzeigen, benötigen zusätzliche Strukturierungs- und Orientierungshilfen.

Nachladen von Informationen. Hierbei setzt das statische Konzept der Internetseite Grenzen, z. B. greift die Zurück-Navigation des Browsers bei solchen Änderungen nicht. Screenreader müssen Änderungen des Bildschirminhalts beobachten und dem Nutzer sofort oder auf Abfrage melden.

Tastaturbedienung. Der Internetbrowser verfügt nur über eine eingeschränkte Tastatursteuerung. Komplexe Anwendungen benötigen eine Feinsteuerung, die mit Javascript realisiert werden muss.

Unter der Bezeichnung Rich Internet Applications (RIA) sind auch Anwendungen in Flash und Silverlight auf dem Markt, die sich als komfortablere Konkurrenz zu HTML und Javascript anbieten. Diese Plattformen beanspruchen ebenfalls eine Eignung für die barrierefreie Gestaltung, werden aber von der „Accessibility– Szene“, den engagierten Entwicklern, (aus


http://juicystudio.com/services/luminositycontrastratio.php


heutiger Sicht – zurecht) nicht in demselben Maße angenommen wie die Standards des W3C. Diese „Webstandards“ entwickeln sich ebenfalls weiter. Für einige dynamische Funktionen, die früher nur in Flash@ realisiert werden konnten, soll es heute Lösungen in HTML5, CSS3 und Javascript geben.

In diesem Zusammenhang sein auf die aktuellen Standards und Materialien auf W3C/WAI hingewiesen, unter anderem:

● Accessible Rich Internet Applications (WAI-ARIA) 1.0 (Recommendation seit 2014): http://www.w3.org/TR/wai-aria/

● Independent User Interface (IndieUI) von W3C, http://www.w3.org/WAI/intro/indieui.php http://www.w3.org/WAI/intro/indieui.php

Eine ausführliche Beschäftigung mit dem Thema dynamischer Web-Anwendungen ist dem Arbeitsblock III vorbehalten.


http://www.w3.org/WAI/intro/indieui.php

10Anhang B: Prüftools – ergänzende InformationenDie folgende Übersicht an Prüftools mit ergänzenden Informationen wurde in Folge der bei der Präsentation der AG SVPBIT seitens IKT-Bund-Mitgliedern gestellten Fragen zusammengestellt und von Predrag Pradic bei der IKT-Bund-Sitzung Ende 2014 übergeben.

10.1 Prüftools und Werkzeuge für PDF-Dokumente

10.1.1 PDF Accessibility Checker (PAC) 2

http://www.access-for-all.ch/ch/pdf-werkstatt/pdf-accessibility-checker-pac.html Kostenfreies Prüftool für PDF-Dokumente nach ISO PDF/UA

prüft alle Maschinen-prüfbare Checkpunkte des Matterhorn-Protokolls. bietet zusätzliche Ansichten und Features zur Unterstützung der manuellen Prüfung:

o vereinfachte Strukturansichto detaillierte Parallelansicht PDF-Tags & Dokumento alle Attribute zu PDF-Tags; Rollenzuordnung; Statistik u. m.

Manuell visuell prüfen, ob

die logische Reihenfolge stimmt ein dem jeweiligen Inhaltselement angemessener Tag verwendet wurde, Attribut-Inhalte (bsp. Alternativtext zum Bild) Sinn ergeben, einige weitere Anforderungen wie barrierefreie Silbentrennung oder

gekennzeichnete Sprachwechsel erfüllt sind.

Prüfung der visuellen Gestaltung, Farben (Kontrasterfüllung)manuell mit Hilfe der Farbkontrast-Prüftools nach WCAG 2.0 (siehe WCAG Check-Tools)

10.1.2 Unterstützungswerkzeuge zur Erstellung barrierefreier PDF-Dokumente (kommerziell)

Für Word

axesPDF for Word http://www.axespdf.com/ Adobe PDF Maker; Teil des Produkts Adobe Acrobat Professional

Für InDesign

● InDesign-Plugin MadeToTag http://www.axaio.com/doku.php/de:products:madetotag prüft das Dokument und bietet Möglichkeiten zum Korrigieren.


http://www.axaio.com/doku.php/de:products:madetotag

http://www.axespdf.com/

10.1.3 Prüf- und Korrektur-Tools für PDF-Dokumente (kommerziell)

● axesPDF QuickFix: Professionelle Version von PAC 2.0http://www.axespdf.com/ Prüftool analog PAC inklusive Möglichkeit zum Korrigieren von z. B. PDF-Dokumenten, zusammengesetzt aus Word und anderen Formaten, bzw. erstellt aus automatischen Prozessen.Eine kommerzielle Version des PDF Accessibility Checkers (PAC) 2.● Adobe Acrobat Professional

http://www.adobe.com Prüft ab Version XI nach PDF/UA und bietet aus dem Prüfergebnis heraus Möglichkeiten zum Korrigieren.

10.2 Prüfwerkzeuge für Webseiten-Inhalte nach WCAG 2.0

10.2.1 Möglichkeiten zur Überprüfung für Online-Redaktion und Designer

10.2.1.1 im CMS:Die Metaansicht (oder Blockansicht) eines Online-Editors wie beispielsweise Aloha-Editor oder CKeditor zeichnet die Blockelemente und weitere visuell aus. Online-Redakteure können damit direkt bei der Bearbeitung der Contents z.B. überprüfen:

● die logische Struktur (z.B. Überschriften),● Sprachwechselauszeichnungen,● Abkürzungsauszeichnungen etc.

10.2.1.2 Checkliste zur einfachen manuellen Prüfung einzelner Webseiten:Checkliste für barrierefreies Webdesign 2.0 inklusive Erklärungen von „Zugang für alle“ (berücksichtigt WCAG 2.0 und Verwaltungsrichtlinie P028), Schweiz: http://www.access-for-all.ch/ch/barrierefreiheit/barrierefreies-webdesign/checklist-2.html

Das Erklärungs-Dokument dient als Anleitung zur systematischen einfachen Überprüfung, enthält Beispiele und Angaben zur Prüfmethoden (inkl. Test-Tools) für den jeweiligen Checkpunkt; kann geändert werden – z. B. um eigene Beispiele, Tests und Erklärungen ergänzt werden.

Die Checkliste dient zur Dokumentation des Prüfergebnisses einer Webseite.

10.2.1.3 Einfache Test-Tools zur Unterstützung der manuellen Überprüfung in Form von Plug-Ins für Internet Explorer und Firefox:● Web Accessibility Toolbar (WAT 2012):

http://www.paciellogroup.com/resources/wat/ ● Web Developer Toolbar: https://addons.mozilla.org/de/firefox/addon/toggle-

web-developer-toolbar


https://addons.mozilla.org/de/firefox/addon/toggle-web-developer-toolbar

https://addons.mozilla.org/de/firefox/addon/toggle-web-developer-toolbar

http://www.paciellogroup.com/resources/wat/

http://www.access-for-all.ch/ch/barrierefreiheit/barrierefreies-webdesign/checklist-2.html

http://www.access-for-all.ch/ch/barrierefreiheit/barrierefreies-webdesign/checklist-2.html

http://www.adobe.com/

http://www.axespdf.com/

● Juicy Studio Accessibility Toolbar: https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/

10.2.1.4 Farb-Test-Tools für Grafiker/Designer:● Colour Contrast Analyser (Client-Anwendung für Windows und Mac):

http://www.paciellogroup.com/resources/contrastanalyser/ ● Luminosity Colour Contrast Ratio Analyser (Online-Tool):

http://juicystudio.com/services/luminositycontrastratio.php ●

10.2.2 Evaluierung von Webseiten-Inhalten nach WCAG 2.0 für Professionals und Entwickler

Zur Überprüfung der WCAG-Erfolgskriterien stehen mehr als 400 Techniken von W3C/WAI zur Verfügung.

● Techniques and Failures for Web Content Accessibility Guidelines 2.0: http://www.w3.org/TR/WCAG20-TECHS/ http://www.w3.org/TR/WCAG20-TECHS/

Mit Hilfe dieser Techniken kann manuell, semi-automatisiert und Teile automatisiert eine (oder mehrere) Webseiten nach WCAG 2.0 überprüft werden. Ein Großteil der Techniken ist in maschinenlesbarer Form im Format Evaluation and Report Language (EARL) den im Bericht angeführten Test-Tools hinterlegt.

Ausgangsdokument für Professionals für manuelle bzw. semi-automatisierte Prüfung:

● How to meet WCAG (quick reference in English): http://www.w3.org/WAI/WCAG20/quickref/

10.2.2.1 Test-Tools zum unterstützenden Einsatz einzelner Webseiten:Tools und APIs für (semi-)automatisierte (und tw. eigene) Tests:

Einige der gelisteten Test-Tools können nach Registrierung bzw. Lizensierung auch zur wiederholten Prüfung mehrerer Webseiten eingesetzt werden bzw. bieten API für Entwickler, beispielsweise:

● Total Validator Pro Tool– Client Programm zur Prüfung mehrerer Webseiten: https://www.totalvalidator.com/tools/protool.html https://www.totalvalidator.com/ tools/protool.html● Total Validator Embedded tool – command line tool (kommerziell)

https://www.totalvalidator.com/help/embedded.html https://www.totalvalidator.com/help/embedded.html ● AChecker: http://achecker.ca/checker/index.php (Registrierung möglich, um

Sites wiederholt zu testen; Web Service API)● WAVE API: http://wave.webaim.org/api/


http://wave.webaim.org/api/

http://achecker.ca/checker/index.php

https://www.totalvalidator.com/help/embedded.html



https://www.totalvalidator.com/tools/protool.html







http://www.paciellogroup.com/resources/contrastanalyser/

https://addons.mozilla.org/en-US/firefox/addon/juicy-studio-accessibility-too/

Hinweis (12.2.2015): Kein Tool kann eine Prüfung nach den WCAG-Techniken durch Menschen ersetzen! Sie können ergänzend eingesetzt werden – wo möglich. Die Tools berücksichtigen bislang noch unzureichend den Einsatz neuer Technologien (HTML 5 …) und bieten wenig bis keine Unterstützung bei der Prüfung von Webseiten und -anwendungen mit Javascript, insbesondere dynamische Anwendungen.

10.2.2.2 Maschinelle Prüfung (Quellcode-Validierung) und Browser-Plug-Ins für Professionals/Entwickler (Quellcode-Prüfung und Änderung):● W3C-HTML-Validator: http://validator.w3.org/ ● W3C-CSS-Validator: http://jigsaw.w3.org/css ‐

validator/ http://jigsaw.w3.org/css validator/‐ ● Firebug: https://addons.mozilla.org/en-US/firefox/addon/firebug/ ● Greasemonkey:

https://addons.mozilla.org/de/firefox/addon/greasemonkey/ http://wave.webaim.org/api/

10.2.2.3 Referenzen (Auswahl) zur Evaluierung/Prüfung von Webseiten-Inhalten und Anwendungen nach WCAG 2.0 bei W3C/WAI● Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0,

10.7.2014: http://www.w3.org/TR/WCAG-EM/ http://www.w3.org/TR/WCAG-EM/ ● Techniques for Automated and Semi-Automated Evaluation Tools, 24.7.2014:

http://www.w3.org/TR/WAET/ ● Developer Guide for Evaluation and Report Language (EARL) 1.0, 10.5.2011:

http://www.w3.org/TR/EARL10-Guide/ http://www.w3.org/TR/EARL10-Guide/ ● Requirements for web developers and web commissioners in ubiquitous Web

2.0 design and development, I2Web Consortium, 6.6.2011http://i2web.eu/downloads/201201_I2Web_D32.pdf http://i2web.eu/downloads/ 201201_I2Web_D32.pdf● UWEM, Unified Web Evaluation Methodology version 1.2, 3.12.2007:

http://www.wabcluster.org/uwem1_2/ Migration UWEM von WCAG 1.0 auf 2.0 bildete u.a. Ausgangsbasis für die WAI-Techniken zum Testen nach WCAG 2.0.● Accessibility Evaluation Resources (allg.):




http://www.wabcluster.org/uwem1_2/

http://i2web.eu/downloads/201201_I2Web_D32.pdf



http://www.w3.org/TR/EARL10-Guide/

http://www.w3.org/TR/EARL10-Guide/

http://www.w3.org/TR/WAET/

http://www.w3.org/TR/WCAG-EM/

http://www.w3.org/TR/WCAG-EM/

http://wave.webaim.org/api/

https://addons.mozilla.org/de/firefox/addon/greasemonkey/

https://addons.mozilla.org/de/firefox/addon/greasemonkey/

https://addons.mozilla.org/en-US/firefox/addon/firebug/





http://validator.w3.org/

11Anhang C: Quellen vom E-Government-Referenzserver

Am Referenzserver werden die gemeinsam erarbeiteten Vorschläge der Arbeitsgruppen und die daraus resultierenden Konventionen in Form von "Empfehlungen" und "Informationen" zum Thema E-Government publiziert. Die Empfehlungen und Informationen sollen hinsichtlich der Normen, Standards und Richtlinien auf Aktualität überprüft und unter Umständen entsprechend adaptiert werden.

Beauftragung des IKT-Bundes vom 08.10.2014, Aktualisierung Oktober - Februar 2015: Eine erste Überprüfung der Werke hinsichtlich ihres Bezugs zur Barrierefreiheit ergab, dass in geltenden Dokumenten Verweise auf WCAG enthalten sind. Es fehlt überall allerdings die klare Vorgabe auf WCAG 2.0 Level AA als Mindestanforderung, ältere Dokumente weisen überdies noch eine Referenz auf WCAG 1.0 aus (z. B. SKEG 1.0.0). Wo eine Mindestanforderung im Werk genannt ist, weist diese nur Level A aus.

Da einige Fällen neben Verweis auf WCAG auch Verweise auf das Dokument Gestaltung barrierefreier Internet-Angebote (webacc 2.1.1) enthalten, wird empfohlen, das Werk „Gestaltung barrierefreier Internet-Angebote“ um den fehlenden Mindeststandard wie auch um Informationen und Referenzen zu aktuellen Technologien, Werkzeugen, technischen Standards (z. B. dem neuen EU-Standard).Empfohlen wird auch eine Aktualisierung bzw. Erweiterung des Referenzwerks „E-Government Schulungskonzept (SKEG 1.0.0)“ um das Thema Barrierefreiheit in E-Government-Schulungen ebenso wie um die Notwendigkeit für barrierefreie Lehr- und Lernunterlagen.

Im Bereich der Themengruppe „Präsentation und Standarddaten“ wird gerade an neuen Versionen der Styleguides für E-Formulare etc. gearbeitet. Diesbezüglich und allgemein für neue Werke bzw. neuen Versionen von bestehenden Empfehlungen wird weiters ein Review-Prozess hinsichtlich Erwähnung der Anforderung zur Barrierefreiheit bzw. Prüfung der UI- und Code-Beispiele auf Barrierefreiheit vor Veröffentlichung angeregt.

Spätestens zur Veröffentlichung der geplanten neuen EU-Richtlinie über den barrierefreien Zugang zu Websites öffentlicher Stellen wären alle Dokumente entsprechend zu überarbeiten.

Vormalig angeführte veraltete bzw. nicht mehr gültige oder für die gegenständliche Beschreibung weniger prioritär relevante E-Government-Dokumente, sind am Ende des Kapitels zur Nachlese ausgelistet. Weitere Werke hinzugefügt.


11.1 Relevante Werke mit thematischen Bezug zur Barrierefreiheit

E-Government Styleguide für Webanwendungen (sg-stgwa 1.0.0) 1. 7. 2012

Der Styleguide für Webanwendungen soll für neu entwickelte behördenübergreifende Webanwendungen zum Einsatz kommen. Dadurch soll mittelfristig eine höhere Akzeptanz und eine verbesserte Usability sowie eine geringere Einarbeitungszeit der über verschiedene Organisationen verteilten Benutzerinnen und Benutzern erreicht werden.

http://reference.e-government.gv.at/uploads/media/sg-stgwa_1-0-0_20120701_01.pdf

Gestaltung barrierefreier Internet-Angebote (webacc 2.1.1) 30. 8. 2010

Dieses Dokument beinhaltet Informationen zu den rechtlichen Rahmenbedingungen für barrierefreie E-Government Services sowie zu den entsprechenden Standards für die Gestaltung von barrierefreien Internetangeboten. Weiters werden verschiedene Zielgruppen und Ansätze für Unterstützungsmaßnahmen skizziert.

http://reference.e-government.gv.at/uploads/media/webacc-2-1-1_2010-0830.pdf http:// reference.e-government.gv.at/uploads/media/webacc-2-1-1_2010-0830.pdf

Online Dialoge in E-Formularen (sg-od 2.1.1) 24. 6. 2010

Die Dienstleistungen der öffentlichen Verwaltung können im zunehmenden Maße unter Nutzung des Internet in Anspruch genommen werden. Da dies auch für die vielfältigen Formulare gilt, wurde mit dem "Styleguide für E-Formulare (sg-stg)" die Grundlage für ein einheitliches Layout von interaktiven elektronischen Formularen (E-Formulare) geschaffen.Darauf aufbauend werden in diesem Dokument Empfehlungen zur Handhabung von E-Formularen und dem damit verbundenen Dialog gegeben und zwar

● für das Auffinden von E- Formularen,● für den Einstieg in E-Formulare (Einstiegsdialog),● für das Ausfüllen von E-Formularen (Bearbeitungsdialog),● für die Übermittlung der ausgefüllten Formulare an die jeweilige Verwaltungseinheit

(Abschlussdialog) und● für die Dokumentation der Übernahme von E-Formularen und deren Weiterleitung

an die zuständige interne Organisationseinheit zur Bearbeitung.In die vorliegende Fassung dieses Dokuments wurden die Änderungen aufgrund der neuen Version 2.1.1 des Styleguides eingearbeitet. Diese Fassung berücksichtigt somit die relevanten Grundsätze für zugängliches Webdesign konform zu Level A der Web Accessibility Guidelines 2.0 (WCAG 2.0). Änderungen aufgrund des EPG (Eingetragene Partnerschaft-Gesetz) wurden ebenfalls berücksichtigt.


http://reference.e-government.gv.at/uploads/media/webacc-2-1-1_2010-0830.pdf

http://reference.e-government.gv.at/uploads/media/webacc-2-1-1_2010-0830.pdf

http://reference.e-government.gv.at/uploads/media/sg-od_2_1_1_2010-06-24_01.pdf http://reference.e-government.gv.at/uploads/media/sg-od_2_1_1_2010-06- 24_01.pdf

E-Government Styleguide für E-Formulare (sg-stg 2.1.1) 24. 6. 2010

Der Styleguide für E-Formulare ist Grundlage für ein einheitliches Layout von interaktiven Online-Formularen (EFormulare) des E-Governments der öffentlichen Verwaltung Österreichs. Seit der Veröffentlichung der ersten Version am 10.10.2002 haben sich viele Behörden und vor allem auch die beauftragten Software-HerstellerInnen an dieser Rahmenvorgabe orientiert.Der vorliegende Styleguide 2.1 ist eine Aktualisierung und berücksichtigt

● die relevanten Anforderungen der Web Accessibility Guidelines 2.0 (WCAG 2.0), welche seit 11.12.2008 als Standard veröffentlicht sind. In das vorliegende Dokument sind die Grundsätze für zugängliches Webdesign konform zu Level A integriert.

● Ergebnisse der Evaluierungsstudie, welche durch das Kompetenznetzwerk Informationstechnologie zur Förderung der Integration von Menschen mit Behinderung (KI-I), Linz, durchgeführt wurde. Insbesondere grundlegenden Usability-Anforderungen, welche eine nachhaltige Verbesserung für die größtmögliche Nutzergruppe entfalten, sind eingearbeitet. Änderungen aufgrund des EPG (Eingetragene Partnerschaft-Gesetz) wurden in der Version 2.1.1 berücksichtigt.

Ausblick:Mittelfristig wird es eine Styleguide Version 3.0 geben, welche weitere Evaluierungsergebnisse integriert: diese strukturellen Anpassungen stellen eine wesentliche Weiterentwicklung des Styleguide für E-Formulare dar

http://reference.e-government.gv.at/uploads/media/sg-stg_2_1_1_2010-06-24_01.pdf http://reference.e-government.gv.at/uploads/media/sg-stg_2_1_1_2010-06- 24_01.pdf

Standarddaten für E-Formulare (sg-stdat 2.1.1) 24. 6. 2010

Laut Styleguide für E-Formulare (sg-stg) muss es neben grafischen Gestaltungsgrundsätzen auch inhaltliche Festlegungen geben, um das Formularwesen der öffentlichen Verwaltung kundinnen- und kundenfreundlich zu gestalten.

Daher ist es erforderlich,

● die immer wiederkehrenden Daten (Standarddaten) eindeutig zu bezeichnen● die Zusammenstellung von Standarddaten zu Blöcken (Standard-Formularbausteine)

und deren Positionen in einem Block zu definieren● auf Grund von Erfahrungen Empfehlungen für die minimale Länge zu geben● einheitliche Hilfetexte zum Ausfüllen besonderer Datenfelder bereitzustellen.


http://reference.e-government.gv.at/uploads/media/sg-stg_2_1_1_2010-06-24_01.pdf

http://reference.e-government.gv.at/uploads/media/sg-stg_2_1_1_2010-06-24_01.pdf

http://reference.e-government.gv.at/uploads/media/sg-od_2_1_1_2010-06-24_01.pdf

http://reference.e-government.gv.at/uploads/media/sg-od_2_1_1_2010-06-24_01.pdf

Mit den so definierten Standarddaten und Formularbausteinen können einheitliche E-Formulare konzipiert werden.In die vorliegende Fassung dieses Dokuments wurden die Änderungen aufgrund der Version 2.1.1 des Styleguides eingearbeitet. Diese Fassung berücksichtigt somit die relevanten Grundsätze für zugängliches Webdesign konform zu Level A der Web Accessibility Guidelines 2.0 (WCAG 2.0). Änderungen aufgrund des EPG (Eingetragene Partnerschaft- Gesetz) wurden ebenfalls berücksichtigt.

http://reference.e-government.gv.at/uploads/media/sg-stdat_2_1_1_2010-06-24_01.pdf http://reference.e-government.gv.at/uploads/media/sg-stdat_2_1_1_2010-06- 24_01.pdf

E-Formulare auf mobilen Endgeräten darstellen (sg-stg-mobiles 1.0.0) 27.9.2011

Dieses Dokument beinhaltet Empfehlungen und Abgrenzungen betreffend der Darstellung von elektronischen Formularen auf Tablet-Computer und Smartphones. Es wurden dazu Themen im Styleguide für E-Formulare (sg-stg) identifiziert, die für die Darstellung von E-Formularen auf mobilen Endgeräten relevant sind. Ziel ist es, ein Differenzpapier zum Styleguide für elektronische Formulare zur Verfügung zu stellen, das die Darstellung von E-Formularen auf unterschiedlicher mobiler Hardware beschreibt.

http://reference.e-government.gv.at/uploads/media/sg-stg-mobiles_1-0-0_20110927.pdf http://reference.e-government.gv.at/uploads/media/sg-stg-mobiles_1-0- 0_20110927.pdf

Mehrsprachigkeit von E-Formularen (sg-sprachen 2.1.1) 21. 12. 2011

Mehrsprachige Formulare gewinnen in der österreichischen Verwaltung immer mehr an Bedeutung. Während für deutschsprachige E-Formulare seit vielen Jahren BLSG-Konventionen existieren, gibt es für andere Sprachen bis dato wenig Unterstützung.Dieses Dokument soll Hilfestellungen und Ankerpunkte bieten, um effizient mehrsprachige Dokumente anzubieten:

● Wichtige Grundsätze zur Mehrspachigkeit von E-Formularen ● Englische Übersetzungen wichtiger Begriffe, wie Bezeichnung von Feldern der

Standard-Formularbausteine und Buttonbezeichnungen● Verweis auf das AG-P/S Best-Practice Wiki mit Übersetzungen von wichtigen

Formularbegriffen in mehr als zehn europäischen SprachenDieses Dokument bezieht sich auf die Version 2.1.1 der Dokumente der Arbeitsgruppe "Präsentation Standarddaten".

http://reference.e-government.gv.at/uploads/media/sg-sprachen_2-1-1_2011-1221.pdf http://reference.e-government.gv.at/uploads/media/sg-sprachen_2-1-1_2011- 1221.pdf


http://reference.e-government.gv.at/uploads/media/sg-sprachen_2-1-1_2011-1221.pdf

http://reference.e-government.gv.at/uploads/media/sg-sprachen_2-1-1_2011-1221.pdf

http://reference.e-government.gv.at/uploads/media/sg-stg-mobiles_1-0-0_20110927.pdf

http://reference.e-government.gv.at/uploads/media/sg-stg-mobiles_1-0-0_20110927.pdf

http://reference.e-government.gv.at/uploads/media/sg-stdat_2_1_1_2010-06-24_01.pdf

http://reference.e-government.gv.at/uploads/media/sg-stdat_2_1_1_2010-06-24_01.pdf

Feedback für E-Formulare (sg-feedback 2.1.1) 3. 11. 2010

Das Dokument beschreibt die Einbindung von Feedback-Formularen in elektronische Formulare. Das Ziel ist, Informationen zu erhalten, die eine nachhaltige Verbesserung des E-Government Angebots ermöglichen.

Folgende Inhalte werden definiert

● Einbindung eines Feedback-Formulars in ein E-Formular und der dazugehörigen Verfahrens-Beschreibungsseite

● Standardisiertes Fragenset inklusive einheitlicher Bewertungsskala und zusätzliche, individuelle Fragen

● Definition der Datenstruktur der Antworten● Definition von allgemeinen Auswertungen

http://reference.e-government.gv.at/uploads/media/sg-feedback_2-1-1_20101103.pdf http://reference.e-government.gv.at/uploads/media/sg-feedback_2-1- 1_20101103.pdf

Schulungskonzept E-Government (SKEG 1.0.0)

Ziel des Schulungskonzeptes ist es einerseits, die Mitarbeiterinnen und Mitarbeiter aus den eigenen Reihen mit den wesentlichen Aspekten des E-Governments vertraut zu machen – denn kompetente und informierte Mitarbeiterinnen und Mitarbeiter sind ein wesentliches Medium zur Kommunikation der E-Government Zielsetzungen sowie dessen Nutzens innerhalb der Verwaltung und nach außen.Andererseits haben spezielle Berufsgruppen wie E-Government Projektmanager oder Entwickler Bedarf an Schulungen in der Umsetzung und Anbindung spezifischer E-Government Komponenten, welche im Rahmen der verschiedenen Arbeitsgruppen und E-Government Strategie-Gremien erarbeitet wurden (z.B. die Anbindung der MOA-Module für die Signatur oder die spezielle Gestaltung der Online Formulare gemäß Formular-Styleguide).

Das Schulungskonzept E-Government ist mehrdimensional konzipiert:

● Inhaltliche Strukturierung je nach Berufsfeld, Verwaltungsebene und individuellem Ausbildungsniveau

● Qualitätssichernde Maßnahmen● mögliche Business Cases● grundlegender Infrastrukturbedarf sowie Maßnahmenkatalog.

http://reference.e-government.gv.at/uploads/media/SKEG_1-0-0_20050905_03.pdf


http://reference.e-government.gv.at/uploads/media/sg-feedback_2-1-1_20101103.pdf

http://reference.e-government.gv.at/uploads/media/sg-feedback_2-1-1_20101103.pdf

Leistungsbeschreibung für Leistungen und Teilleistungen des E-Government Leistungskatalogs (lb 1.0.0) 20. 12. 2006

Der Austausch von Leistungskatalogen, Verfahrensinformationen und Formularen, wie im Vorschlag „elkat 1.0.0“ beschrieben, verlangt eine Festlegung der Struktur und des Wordings von Leistungsbeschreibungen.

http://reference.e-government.gv.at/uploads/media/lb-1-0-0-2006-1220_WAI_02.pdf

Elektronischer-Leistungskatalog der österreichischen Verwaltung: strukturierter Austausch von Informationen zu Verfahren und Leistungen (elkat 1.1.0, 2012)http://reference.e-government.gv.at/uploads/media/elkat-1-1-0-2011-0707_01.pdf

Elektronische Zustellung Dokumente

EDVO-TODO: Ist noch zu aktualisieren

11.2 Weitere Werke mit Bezug zu Barrierefreiheit

EDVO-TODO – gehört noch überarbeitet/ergänzt/kommentierthttp://reference.e-government.gv.at/uploads/media/lb-1-0-0-2006-1220_WAI_02.pdf

Rahmenbedingungen für Open Government Data Plattformen (Open Government Data – 1.1.0) 30.7.2012

Die Offenlegung von Verwaltungsdaten wird als Mittel zur Steigerung der Beteiligung in einem gemeinsamen Werterstellungsprozess von Politik, Verwaltung, Bürgerinnen und Bürgern und Wirtschaft diskutiert. Die damit einhergehende Transparenz von Daten und Informationen steigert das Vertrauen aller an Verwaltungsprozessen Beteiligter, führt zu neuen Geschäftsmodellen und festigt mittel- bis langfristig die bestehenden demokratischen Institutionen. Dieses White-Paper-Dokument stellt Basisinformationen zum Thema Open Government Data bereit und definiert rechtliche, technische und organisatorische Anforderungen an Open Government Data Plattformen.

http://reference.e-government.gv.at/uploads/media/OGD-1-1-0_20120730.pdf http:// reference.e-government.gv.at/uploads/media/OGD-1-1-0_20120730.pdf

Positionspapier zu E-Democracy und E-Participation in Österreich (EDEM 1.0.0) 9.6.2008

Europaweit finden sich unterschiedlichste Pilotprojekte im Bereich Öffentlichkeitsbeteiligung. Auch in Österreich gibt es bereits diverse Ansätze auf Gemeinde-, Landes- und Bundesebene. E-Demokratie ist ein ebenenübergreifendes Thema, das nur


http://reference.e-government.gv.at/uploads/media/OGD-1-1-0_20120730.pdf

http://reference.e-government.gv.at/uploads/media/OGD-1-1-0_20120730.pdf



http://reference.e-government.gv.at/uploads/media/elkat-1-1-0-2011-0707_01.pdf

gemeinsam erarbeitet werden kann. Um hier ein abgestimmtes Vorgehen zu gewährleisten und Doppelgleisigkeiten zu vermeiden, ermittelt und definiert die Arbeitsgruppe EDEM wesentliche Grundlagen von E-Democracy und E-Participation.Dieses Dokument richtet sich vorrangig als Erstinformation an die verantwortlichen Fachleute in der Verwaltung. Zugleich dient es als Ausgangspunkt für weitere Aktivitäten, zur Sammlung und Einordnung von Beteiligungsprojekten und schließlich als Grundlage zur Erarbeitung konkreter Leitfäden für verschiedene Partizipationsprozesse.

Entscheidungsgrundlage für die Nutzung von Soziale Medien & Netzwerken in der Verwaltung (Soziale Medien & Netzwerken in der Verwaltung Version 1.0.0) 30. 3. 2011

Für Behörden und Organisationen stellt sich immer stärker die Frage, ob und wie man dienstliche Aktivitäten im Umfeld von Sozialen Medien & Netzwerken aufnimmt und regelt. Soziale Medien & Netzwerken sind Dienste im Internet, welche interaktiv verwendet werden und in denen hauptsächlich durch BenutzerInnen beigestellter Inhalt bearbeitet, weiterverwendet und verwaltet werden. Dieses Dokument dient Entscheidungsgrundlage für die Nutzung von Soziale Medien & Netzwerken in der Verwaltung bzw. kann als Grundlage zur Ausgestaltung organisationsspezifischer Leitfäden herangezogen werden. Es umfasst keine Regeln für eine Organisationspräsenz in Soziale Medien & Netzwerken. Es sollte jedoch immer in Verbindung mit den weiteren Leitfäden, wie etwa dem „Leitfaden – Umgang mit Web 2.0 für MitarbeiterInnen der öffentlichen Verwaltung“, den „Leitfäden für die Nutzung des Sozialen Netzwerkes Facebook in der Verwaltung“ oder des „Leitfadens für die Nutzung des Micoblooging Dienstes Twitter in der Verwaltung“ gesehen werden. Alle Leitfäden sowie weitere Informationen finden Sie im BKA Wiki unter https://www.ag.bka.gv.at/at.gv.bka.wiki-bka/index.php/Portal:EDEM.

http://reference.e-government.gv.at/uploads/media/Leitfaden_Soziale-Medien-und-Netzwerke-in-der-Verwaltung__1-0-0_20110330.pdf http://reference.e-government.gv.at/ uploads/media/Leitfaden_Soziale-Medien-und-Netzwerke-in-der-Verwaltung__1-0-0_20110330.pdf

11.3 Veraltete bzw. wenig relevante Werke

Design-Prototypen von E-Formularen mit MS-Visio (sg-visio 2.1.1) 24. 6. 2010

http://reference.e-government.gv.at/uploads/media/sg-visio_2_1_1_2010-06-24_02.pdf http://reference.e-government.gv.at/uploads/media/sg-visio_2_1_1_2010-06- 24_02.pdf


http://reference.e-government.gv.at/uploads/media/sg-visio_2_1_1_2010-06-24_02.pdf




http://reference.e-government.gv.at/uploads/media/Leitfaden_Soziale-Medien-und-Netzwerke-in-der-Verwaltung__1-0-0_20110330.pdf



Domain-Policy (domainpol 1.0.1) 15. 11. 2005

http://reference.e-government.gv.at/uploads/media/domainpol_1-0-1.pdf http:// reference.e-government.gv.at/uploads/media/domainpol_1-0-1.pdf

http://reference.e-government.gv.at/uploads/media/EDEM-1-0-0-20080525.pdf http:// reference.e-government.gv.at/uploads/media/EDEM-1-0-0-20080525.pdf

Elektronische Zustellung Technische Spezifikation (zuse-spec 1.2.0) 19.11.2007

http://reference.e-government.gv.at/uploads/media/zusespec_1-2-0_20070425.pdf http:// reference.e-government.gv.at/uploads/media/zusespec_1-2-0_20070425.pdf

SAGA Standards und Architekturen für E-Government-Anwendungen Version 2.0 (Dezember 2003)

http://reference.e-government.gv.at/uploads/media/SAGA-Version-2.0_01.pdf http:// reference.e-government.gv.at/uploads/media/SAGA-Version-2.0_01.pdf

Bericht des Verfassungsausschusses vom 22. 1. 2004 über die Regierungsvorlage (Erlassen des E-Government-Gesetzes, Änderung des Allgemeinen Verwaltungsverfahrensgesetzes, Zustellgesetzes, Gebührengesetzes, Meldegesetzes und Vereinsgesetzes)

http://reference.e-government.gv.at/uploads/media/E-Gov-Gesetz_Verfasssungsausschuss-20040122_01.pdf

11.4 Hilfedokument für Redaktion – Erstellen barrierefreier PDF-Dokumente

Das folgende für die Redaktion der E-Government-Dokumente am Reference-Server wesentliche Bedienungshandbuch beinhaltet Referenzen auf inzwischen veraltete Technologieversionen und soll gegen ein aktuelles mit Verweis auf PDF/UA ersetzt werden.

Dokument zu „PDF und Barrierefreiheit“ (11.11.2008)

Folgender Beitrag ist an Redakteure gerichtet, die Dokumente in barrierefreie PDF konvertieren und ins Web stellen. Wesentliche Voraussetzung ist die Verfügbarkeit von Adobe Acrobat 5 oder höher.

http://reference.e-government.gv.at/uploads/media/PDF_und_Barrierefreiheit-20081111.pdf http://reference.e-government.gv.at/uploads/media/ PDF_und_Barrierefreiheit-20081111.pdf


http://reference.e-government.gv.at/uploads/media/PDF_und_Barrierefreiheit-20081111.pdf

http://reference.e-government.gv.at/uploads/media/PDF_und_Barrierefreiheit-20081111.pdf

http://reference.e-government.gv.at/uploads/media/SAGA-Version-2.0_01.pdf

http://reference.e-government.gv.at/uploads/media/SAGA-Version-2.0_01.pdf

http://reference.e-government.gv.at/uploads/media/zusespec_1-2-0_20070425.pdf

http://reference.e-government.gv.at/uploads/media/zusespec_1-2-0_20070425.pdf

http://reference.e-government.gv.at/uploads/media/EDEM-1-0-0-20080525.pdf

http://reference.e-government.gv.at/uploads/media/EDEM-1-0-0-20080525.pdf

http://reference.e-government.gv.at/uploads/media/domainpol_1-0-1.pdf

http://reference.e-government.gv.at/uploads/media/domainpol_1-0-1.pdf

12Anhang D: Ergänzende Literatur- / QuellenlisteAnmerkung: die vorliegende Literatur- / Quellenliste dient zur groben informativen Orientierung insbesondere aus betriebswirtschaftlicher Sicht. Diese erhebt jedenfalls keinen Anspruch auf Vollständigkeit oder Aktualität aus forschungs- bzw. wissenschaftlicher Sicht.

Puhl, Steffen: Dissertationsschrift: „Betriebswirtschaftliche Nutzenbewertung der Barrierefreiheit von Web-Präsenzen“, Aachen: Shaker Verlag 2008, ISBN 978-3-8322-7441-2).

Puhl, Steffen (2009): Vortragsunterlage: „Betriebswirtschaftliche Nutzenbewertung der Barrierefreiheit“. Universität Giessen. Unter http://ebookbrowsee.net/puhl-iwp2-09-internet-pdf-d116863087 (letzte Abfrage 20.06.2014).

Weltbank-Bericht "Inclusion Matters" unter http://issuu.com/world.bank.publications/docs/9781464800108 (letzte Abfrage 22.05.2014)

Wesentliche Quellen aus Puhl (2009):Angermeier, Markus (2005): Barrierefreiheit als Wirtschaftsfaktor. Avgerou, Chrisanth (1995): Evaluating Information Systems by Consultation and Negotiation. In: International Journal of Information Management 15 (6), S. 427-436.

BIENE (2004): Bewertungskriterien, Quelle: http://www.einfach-fuer-alle.de/award2004/kriterien/ http://www.einfach-fuer-alle.de/ award2004/kriterien/

BITV (2002): Deutsche) Verordnung zur Schaffung barrierefreier Informationstechnik, Deutsche Behindertenhilfe Aktion Mensch e.V. (2003): Einfach für alle – Informationen zur barrierefreien Webgestaltung. 2. Aufl., Bonn. (Anm. Sammlung fundierter Informationen auch unter http://www.einfachfueralle.de)

Faulkner, Steve; Lemon, Gez: Improving Ajax applications for JAWS users, Quelle: http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php http:// juicystudio.com/article/improving-ajax-applications-for-jaws-users.php

Grimm, Sebastian (2005): Prozessportale: Schnittstelle zwischen Anwendern und Unternehmen. In: IT Management (10), S.16-22.

Hein, Ansgar (2005): Kosten und Nutzen -Qualitätsmanagement für Websites – von früher bis heute. In: Information Wissenschaft & Praxis 56 (8 – Sonderheft Barrierefreiheit), S. 425-430.

Hellbusch, Jan Eric (2006): Online ist besser barrierefrei.


http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php

http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php

http://www.einfach-fuer-alle.de/award2004/kriterien/

http://www.einfach-fuer-alle.de/award2004/kriterien/

Hellbusch, Jan Eric; Mayer, Thomas (2005): Barrierefreies Webdesign. 2. Aufl. Osnabrück: KnowWare.

Ives, Blake; Learmonth, Gerard P. (1984): The Information System as Competitive Weapon. In: Communications of the ACM 27 (12), S. 1193-1201.

Kargl, Herbert (2000): Management und Controlling von IV-Projekten. München; Wien: Oldenbourg.

Krüger, Wilfried; Achenbach, Antje; Bach, Norbert; Kraft, Stephan; Müssig, Bernd (2006): Konzeptionelle Integration und methodische Berücksichtigung personeller Barrieren. In: ZWF – Zeitschrift für wirtschaftlichen Fabrikbetrieb 101 (10), S. 566-570.

Leonhardt Multimedia GmbH (2002): Studie: Barrierefreiheit von Unternehmens-Webseiten. Berlin.

o. V. (1997): Nutzen. In: Groffmann, Hans-Dieter; Rau, Karl-Heinz; Stickel, Eberhard (Hrsg.): Gabler Wirtschaftslexikon. Wiesbaden: Gabler, S. 487-488.

Peter, Ulrike (2003): Barrierefreies Webdesign.

Potthof, Ingo (1998): Kosten und Nutzen der Informationsverarbeitung-Analyse und Beurteilung von Investitionsentscheidungen. Wiesbaden: Gabler Verlag.

Schmidt, Herrad (2005): Customer Relationship Management. In: WISU 34 (12), S. 1517-1524

Schwickert, Axel C. (2001): Web Site Engineering -Ökonomische Analyse und Entwicklungssystematik für eBusiness-Präsenzen. Stuttgart; Leipzig; Wiesbaden: B. G. Teubner.

The Customer Respect Group (2008): Accessibility and business value study.

Thommen, Jean-Paul (1996): Betriebswirtschaftslehre. 4. Aufl. Zürich:Versus. Walter, Sascha G.; Spitta, Thorsten (2004): Approaches to the Ex-ante Evaluation of Investments into Information Systems. In: Wirtschaftsinformatik 46 (3), S. 171-180.

Weber, Jürgen (2002): Einführung in das Controlling. 9. Aufl. Stuttgart: SchäferPoeschel.

Benutzerfreundlichkeit, Wirtschaftlichkeit, Kostenbewertung, Barrierefreiheit, Informationstechnik

Gabler Wirtschaftslexikon URL: http://wirtschaftslexikon.gabler.de/

ITWissen.info URL: http://www.itwissen.info/

/ Ende des Berichts


2. Entwicklungsphase - Entwurf - _Bericht_AG_SVPBIT ... Web viewBericht der Interministeriellen...

Documents

Transcript of 2. Entwicklungsphase - Entwurf - _Bericht_AG_SVPBIT ... Web viewBericht der Interministeriellen...