Illustration der Zugänglichmachung von Wissen

Mit 7 Tipps zu barrierearmen Powerpointfolien

Für viele Menschen ist es schwierig oder gar nicht möglich, Inhalte von Dokumenten gut zu erkennen. Ein Grund können unterschiedliche Beeinträchtigungen des Auges sein (bspw. Farbenblindheit). Oftmals fällt in diesem Zusammenhang der Begriff „Barrierefreiheit“. Letztere bedeutet, dass u. a. Gegenstände oder Medien so gestaltet sind, dass sie von allen Menschen unabhängig von einer Behinderung ohne Einschränkungen genutzt werden können. Zum Teil wird anstelle von „barrierefreien“ Inhalten auch von „barrierearmen“ Inhalten gesprochen. Fortan wird letzterer Begriff auch in diesem Beitrag überwiegend verwendet, da trotz aller Bemühungen meist nicht alle Hindernisse behoben werden können.

Gedacht wird beim Thema Barrierearmut nicht selten zunächst an technische Möglichkeiten bei der Umsetzung bzw. Nutzung von Webseiten. Hier spielen Kontraste, Schriftgrößen oder Optionen für Screenreader eine Rolle. Vergessen wird dabei häufig, dass dieses Thema auch viele weitere Inhalte und Kommunikationsmittel im Alltag abseits von Webseiten betrifft. Ob E-Mails, Tools zur Online-Kommunikation oder Präsentationen: Mit wenigen kleinen Maßnahmen lassen sich auch diese Inhalte ohne großen Aufwand verständlicher gestalten. Nachfolgend soll dies am Beispiel von Powerpointfolien mit Hilfe von sieben Tipps verdeutlicht werden.

Illustration der Zugänglichmachung von Wissen
Auch Powerpoint-Folien können von Barrieren befreit werden (Abbildung: „Accessible Knowledge“ von Kati Szilágyi for Wikimedia Deutschland e.V., Lizenz: CC-BY-SA-4.0)

Powerpoint dient in diesem Beitrag als Beispiel, da sich das Programm als Präsentationssoftware durchgesetzt hat und selbst abseits von Lehr-Lernkontexten in Hochschulen und Schulen nahezu überall eingesetzt wird. Zudem hat Powerpoint je nach Version bereits einige nützliche Funktionen eingebaut, die bei der barrierearmen Gestaltung unterstützen. Die Umsetzung ist nicht schwer und bietet auch für Personen ohne Beeinträchtigung durchaus einen Mehrwert. Viele der sieben Tipps für die Erstellung zugänglicherer Powerpoint-Inhalte lassen sich auch auf andere Programme übertragen.

Tipp 1: Eine „barrierefreie“ Designvorlage von PowerPoint verwenden

Bei PowerPoint kann gezielt nach „barrierefreien“ Foliendesigns gesucht werden (Datei > Neu > „barrierefrei“ eintippen > das Design, das gefällt auswählen). Es gibt viele verschiedene Designvorlagen zu vielen verschiedenen Themen. Außerdem hat man so bereits eine gute Grundlage und kann das entsprechende Foliendesign mit ein paar Mausklicks schnell und ohne großen Aufwand verwenden. Hier sind viele der Tipps bereits beherzigt und es hilft bei der Erstellung.

In Powerpoint lassen sich „barrierefreie“ Folienvorlagen suchen (Screenshot nicht unter freier Lizenz)

Tipp 2: Lesereihenfolge manuell festlegen und überprüfen

Häufig wird die Lesereihenfolge vom Programm automatisch so festgelegt, wie die Objekte auf einer Seite angelegt wurden. Dies macht nicht unbedingt immer Sinn, wenn die entsprechenden Folien von einem Bildschirmleseprogramm vorgelesen werden.

Besser ist es, die fertigen Folien noch einmal auf die korrekte Lesereihenfolge zu überprüfen und ggf. die Reihenfolge der Objekte anzupassen. Dann kann das Leseprogramm die Seite von oben nach unten in korrekter Logik so vorlesen, wie es auch sehende Personen lesen würden. Einer möglichen Verwirrung wird somit vorgebeugt.

Lesereihenfolge in Powerpoint
In Powerpoint lässt sich die Lesereihenfolge überprüfen (Screenshot nicht unter freier Lizenz)

Um die Lesereihenfolge überprüfen zu können, öffnet man bei der 365-Version von Office den Reiter „Überprüfen“ und wählt dort die Barrierefreiheitsprüfung aus. Dort lässt sich der Punkt „Lesereihenfolgebereich“ auswählen und man bekommt an der rechten Seite die Reihenfolge angezeigt, in der jede Folie gelesen werden würde. Dort lässt sich die Reihenfolge auch sehr leicht ändern.

Hierbei kann vor allem auch helfen, das vorgegebene Titelfeld der Folien als solches zu nutzen und kein eigenes Eingabefeld einzufügen. Wenn das Feld als Titelfeld definiert ist, kann es sehbeeinträchtigen Personen bei der Navigation durch die Präsentation helfen, da es als Orientierung durch den Foliensatz dient.

Microsoft-Hilfe: Lesereihenfolge festlegen

Tipp 3: Bilder mit aussagekräftiger Bildunterschrift und Alternativtext

Wenn in Präsentationen verwendete Bilder nicht erkannt werden können, ist es schwierig, die Aussagekraft dahinter zu beurteilen. Deshalb sollten Abbildungen möglichst mit einem prägnanten Alternativtext belegt werden, um sehbeeinträchtigte Menschen bzw. Personen mit Leseprogramm die Möglichkeit zu geben, diese im Kopf visualisieren zu können. Eine kurze Beschreibung des Bildes, seiner Absicht und das, was an dem Bild wichtig ist, reicht hier bereits aus.

  • Beim Einfügen eines Alternativtextes gibt es auch die Möglichkeit, einen Titel einzufügen. Diese Möglichkeit sollte nur genutzt werden, wenn der eingefügte Alternativtext sehr lang ist. Außerdem sollte darauf verzichtet werden, hier den identischen Text einzufügen, der als Alternativtext bereits verwendet wurde. Wenn Titel und Alternativtext denselben Text enthalten, wird dieser doppelt vorgelesen, ohne seine Aussagekraft zu vergrößern.
  • Ab der Officeversion von 2019 können Bilder auch als „Dekoration“ gekennzeichnet werden. Dies sollte man tun, wenn die eingefügten Abbildungen lediglich der visuellen Gestaltung dienen. Personen mit Bildschirmleseprogrammen wird somit signalisiert, dass keine wichtigen Informationen fehlen. Hierzu öffnet man den Reiter „Überprüfen“ und das Feld „Barrierefreiheitsprüfung“. Dort kann man den Punkt „Alternativtext“ auswählen. Sollte ein genutztes Foto keinen inhaltlichen Kontext haben, gibt es hier auch die Möglichkeit, das Kästchen mit „Als dekorativ markieren“ auszuwählen. So wird das Bild vom Leseprogramm ignoriert.
Bild als dekoratives Element markieren
In Office 2019 und neueren Versionen lassen sich Abbildungen als dekorative Elemente markieren (Screenshot nicht unter freier Lizenz)

Leseprogramme können häufig auch Linklisten durchsuchen. Hier ist es hilfreich, wenn die einzelnen Links zusätzlich mit einer „QuickInfo“ belegt sind. Dies sind kleine Fenster, in denen ein beschreibender Text angezeigt wird, sobald mit dem Mauszeiger auf einen Link gezeigt wird. So kann eingeschätzt werden, was sich hinter den einzelnen Links verbirgt, ohne jeden einzeln anklicken zu müssen. Der Hyperlink alleine ist in den wenigsten Fällen aussagekräftig und trifft keine Aussage über den Inhalt der Webseite.

Um eine QuickInfo für einen Link zu hinterlegen, wählt man den Link aus, macht einen Rechtsklick mit der Maus und wählt „Link bearbeiten“. Es öffnet sich ein Feld und man hat oben Rechts die Möglichkeit, eine QuickInfo zu hinterlegen. Diese wird dann ebenfalls angezeigt, wenn man mit der Maus über den entsprechenden Link fährt. Hier ist es ebenfalls sinnvoll, einen möglichst prägnanten Text einzugeben.

Tipp 4: Neben Farben weitere Möglichkeiten für inhaltliche Bewertung nutzen

Von einigen Menschen können gewisse Farben oder Farbkontraste nicht richtig erkannt werden und es fällt ihnen u. a. schwer, in einzelnen Diagrammen die Torten- oder Balken-Formen zu unterscheiden. Hilfreich ist es hier, diesen Formen neben unterschiedlichen Farben auch unterschiedliche Muster zuzuordnen. Hilfreich ist dies auch, wenn man sich die Folien später bspw. in schwarz-weiß ausdrucken möchte und aufgrund der fehlenden Farben eine andere Möglichkeit der Unterscheidung benötigt.

  • Um zu überprüfen, ob die Folien auch für farbenblinde Menschen identifizierbar sind, kann in Powerpoint unter „Ansicht – Graustufe“ das gesamte Design auf Graustufen umgestellt werden – so lässt sich leicht prüfen, ob einzelne Aspekte noch unterscheidbar sind. Wie in dem angefügten Beispiel lassen sich die Balken farblich nicht länger unterscheiden.
  • Balkendiagramm mit Farben
  • Balkendiagramm in Grautönen

Tipp 5: Farbkontrast und Schriftart

PowerPoint-Folien sollten generell nicht mit zu viel Text gestaltet werden. Dies ist auch bei barrierearmen Folien wichtig. Zudem ist für gute Lesbarkeit der beste Weg, einen Schriftgrad von 18 pt. (oder größer) und eine serifenlose Schriftart wie Arial oder Calibri zu verwenden. Serifenlos bedeutet hier, dass möglichst wenig Schnörkel an den einzelnen Buchstaben vorhanden ist. So können die Folien auch in den hinteren Reihen und gerade von Personen mit Sehbeeinträchtigung möglichst gut gesehen werden. Auch bei Text sollte darauf geachtet werden, dass wichtige Informationen nicht ausschließlich durch Farbe, sondern möglicherweise zusätzlich durch Unterstreichungen gekennzeichnet werden sollten.

Zudem sollte auf die entsprechenden Farbkontraste zwischen Text und Hintergrund geachtet werden.

Beispielsweise:

… weiße Schrift auf möglichst dunklem Hintergrund

…alternativ: schwarze Schrift auf weißem oder sehr hellem Hintergrund

Hier hilft die Regel: je geringer der Kontrast, umso schwieriger ist es, den Text zu entziffern und zu lesen. Je höher der Kontrast zwischen Schrift und Hintergrund, desto besser ist die Schrift am Ende lesbar. An dieser Stelle können die Designvorschläge von PowerPoint unterstützen. Dort sind häufig schon entsprechende Kontraste eingestellt.

Tipp 6: Gendern – ein Problem

Von vielen Leseprogrammen wird das Gendersternchen wie auch der Doppelpunkt als solches wörtlich ausgesprochen.

Beispiel:

  • (Dozent – Sternchen – innen).

Dies stört natürlich das Zuhören und ist nicht förderlich für das Verstehen des Vorgelesenen. Die TUHH und auch der Deutsche Blinden- und Sehbehindertenverband e.V. empfehlen, das Gendersternchen zu nutzen, da dies die meist verwendete Form ist und somit möglicherweise im Leseprogramm zum Vorlesen ausgestellt werden kann. Zudem bildet das Gendersternchen insgesamt die größte Geschlechtervielfalt ab. Generell ist eine erstrebenswerte Lösung, möglichst Wörter zu finden, die ohne Genderstern oder Doppelpunkt auskommen und hierbei zeitgleich kein Geschlecht ausschließen („Unternehmen“ statt „Arbeitgeber“ – „Studierenden“ statt „Studenten“). Hier kann möglicherweise auch ein Wörterbuch zur genderneutralen Sprache Abhilfe schaffen, wenn kein geeignetes Wort einfallen möchte.

Tipp 7: „Barrierefreiheitsprüfung“ von Microsoft

Ein letztes Mittel, um sicher zu sein, dass die erstellten Folien möglichst barrierearm sind, ist die „Barrierefreiheitsprüfung“ von Microsoft. Die Folien werden hier noch einmal abschließend auf Barrieren überprüft. Zudem werden Schwachstellen, die einem möglicherweise im Vorfeld nicht aufgefallen sind, noch einmal aufgelistet. So bietet sich hier dann die Möglichkeit, diese noch einmal zu ändern, wenn das Verständnis der Folien dies zulässt. In der Version von 2016 kann man die Barrierefreiheitsprüfung am einfachsten oben in die Suchleiste eingeben, um die einzelnen Folien prüfen zu lassen.

In neueren Versionen ist die Barrierefreiheitsprüfung über den Reiter „Überprüfen“ und dann „Barrierefreiheitsprüfung“ zu finden. Es öffnet sich an der rechten Seite eine Spalte, in der angezeigt wird, wenn etwas nicht barrierearm sein sollte. Microsoft gibt zudem auch gleich Änderungsvorschläge vor, um die Hürden möglichst schnell korrigieren zu können, wenn man den kleinen Pfeil öffnet, der neben den einzelnen Objekten zu sehen ist.

Ergebnis Barriereueberpruefung
Die Ergebnisse der Überprüfung von Barrieren werden in Powerpoint am rechten Bildschirmrand angezeigt (Screenshot nicht unter freier Lizenz)

Sollte noch mehr Hilfe nötig sein, kann man auf der Microsoft-Hilfe-Seite die Barrierefreiheitsprüfung aktivieren.

Habt Ihr weitere Tipps, Anregungen oder Informationen zu barrierearmen Materialien? Teilt diese doch gerne über die Kommentarfunktion.


Über die Autorin:

Frauke Wienert arbeitet seit September 2022 als Bibliothekarin in der Abteilung der Medienbearbeitung der Universitätsbibliothek der Technischen Universität Hamburg. Sie hat Bibliotheks- und Informationsmanagement an der HAW Hamburg studiert und währenddessen unter anderem für die Helmut-Schmidt-Universität sowie für das Hamburger Zentrum für Universitäres Lehren und Lernen der Uni Hamburg gearbeitet. Hier hat sie bereits Workshopmaterialien zum Thema „Barrierefreiheit“ zusammengestellt.


CC BY 4.0
Weiternutzung als OER ausdrücklich erlaubt: Dieses Werk und dessen Inhalte sind – sofern nicht anders angegeben – lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: Mit 7 Tipps zu barrierearmen Powerpointfolien von Frauke Wienert, Lizenz: CC BY 4.0. Der Beitrag und dazugehörige Materialien stehen auch im Markdownformat und als PDF zum Download zur Verfügung.
Tools

Open Access Publishing at TUHH: Exemplary Step-by-step guide for a toolchain with TORE, GitLab, Sherpa Romeo and Zenodo

The following step-by-step guide is updated regularly and should be seen as a kind of living document. A more recent version, if available, can be viewed via the repository linked in the license note at the end of the post.

Publishing a paper as preprint would work as described in the following steps:

  1. You have to get an overview on possibilities to publish and open access sharing rights (further information on the websites of the TU library)
  2. Check the permissions of your journal or publisher where you would like to publish via Sherpa Romeo. Example for IEEE proceeding is:
Example for aggregated permissions of IEEE proceedings via Sherpa Romeo

Here you can see that preprints (research papers that are shared before peer review) are possible and which rules you have to follow. For example for CDC (Conference on Decision and Control) you can upload the preprint with a notice that this paper is submitted for review and afterwards you have to place a copyright notice and a DOI link of the IEEE finally published version. You are not allowed to publish the final version, just an author version with the copyright terms. See IEEE policy, section 3 for that.

  1. Create a repository for your publication in our gitlab instance: TUHH – Gitlab (private repo, a public repo can be seen here). In general you create

    • a repository for your paper
    • a repository for your software code (See Code Section)

Use the following scheme: Year-paper-conference-FirstSixWordsOfTitleOfYourPublication (e.g. 2021-paper-ECC-A-Gradient-Descent-Method-for-Finite) while the code is in the corresponding Year-code-TitleOfYourContribution repository.

  1. Have in mind to add references to supplimentary material in the readme.
  2. Add submission or copyright terms to your paper and create a prefinal pdf. You might keep some space (Where??) to place the preprint DOI for references.
  3. Open tore submission page with your personal account (more details via tore help).
  4. Select Publications with fulltext and click on manual submission
  5. The next pages collect metadata:
    • Title
    • Authors (Add an ORCID if possible, Add Prof Werner, for example). Clicking on the magnifier allows searching for entries. Validated entries are marked with a green arrow.
    • Select Language: English
    • Type: Preprint
    • Enter Abstract in English
    • Select TUHH Institute: Type E14 and by using the magnifier select the validated entry.
    • Go next
A click on the magnifier allows searching for entries
  1. Next page collects publisher metadata:
    • These information will be updated with the final version to be submitted for publication
    • Enter Date of issue: Todays date
    • Go next
  2. License details
    • License: Copyright should be selected
    • Supplemented by: Here you can add your Code DOI
    • Project: If you are working for a DFG program, you should reference it here
    • Funder: Here you should add DFG or BMWI as Funder
  3. Now you get your DOI.
    • Copy this DOI into your paper and compile it with this DOI. The DOI is booked but not finally registered. This will be done in the next steps
  4. Now, upload the pdf of your preprint
    • upload pdf
    • check filename (should be meaningful)
    • Set embargo date if neccessary
    • next
  5. Verfiy your submission and accept the license of TORE
  6. Your submission is nearly done. TUHH Library will check your submission. Either they accept it or ask you to change things. You will be emailed. Your entry is so to say, peer review on metadata level
  7. For now you are done. Further version have to be uploaded when the paper got accepted and you can upload the final author version to TORE. Please make sure that you reference the publisher DOI and add the correct credits to the paper.

Publish your software files related to your paper publication

You want to publish files like your source code, your data or videos in a save manner and cite them using a DOI?

The code you publish should be able to reproduce all figures you show in your publication by running one or multiple files which are than related to your figure. If your code uses special software or libraries to run, you should note them down in a dependancies and software section in a readme file of the repository. You should not include these files to your repository. Installation steps should be explained.

Than this is one way to go:

  1. Create a repository for your publication in our gitlab instance: TUHH – Gitlab. In general you create
    • a repository for your paper (See Paper Section)
    • a repository for your software code in https://collaborating.tuhh.de/ICS/ics-private/phd-students/papers (private repo) by using the following scheme: Year-code-conference-FirstSixWordsOfTitleOfYourPublication (e.g. 2021-code-ECC-A-Gradient-Descent-Method-for-Finite) while the paper is in the corresponding Year-paper-conference-TitleOfYourContribution repository.
  2. Upload your code by using git (You can use this repo already when starting to work on an idea: Repositories can be renamed and moved in the gitlab structure). Code should be cleaned up and except for dependancies and libraries selfcontaining. (Be careful on which branch to push, master gets automatically pushed to github, others not)
  3. Add a License file to the repo using templates: GPLv3 (Software) and CC-BY-SA (for all other media) and remove all lines after End of Terms and Conditions around line 625
  4. Add the following header lines to the beginning of each of your files. In references your refere to papers, software or tools you base on to cite them. Make sure that our license in compatible with the build on software/library/code.
```
%------
% Project: Name and Link
% Copyright: 
% License: 
% References:
% Authors:
%------

%---------------------------------------------------------------------------------------------
% For Paper, 
% "A Gradient Descent Method for Finite Horizon Distributed Control of Discrete Time Systems"
% by Simon Heinke and Herbert Werner
% Copyright (c) Institute of Control Systems, Hamburg University of Technology. All rights reserved.
% Licensed under the GPLv3. See LICENSE in the project root for license information.
% Uses an own implementation of the work of 
% "A. Vamsi and N. Elia, Design of distributed controllers realizable over arbitrary directed networks,
% IEEE Conference on Decision and Control, 2010."
% Author(s): Simon Heinke
%--------------------------------------------------------------------------------------------
```
  1. You also might want to enter a section in the Readme file on how to cite your work. Therefore you should include bibtex code for citing authors to reference your work in their publication. E.g.:
``` 
@misc{1606.01540,
    Author = {Greg Brockman and Vicki Cheung and Ludwig Pettersson and Jonas Schneider and John Schulman and Jie Tang and Wojciech Zaremba},   Title = {OpenAI Gym},
    Year = {2016},
    Eprint = {arXiv:1606.01540},
}
 ```

Example for Readme.md from Christian Hespe:

Example for a Readme.md file
  1. Create a repository at github.com/TUHH-ICS
    • with the same name as in gitlab
    • Give a short meaningful description
    • Select public
    • Click on create repository
    • Ask Lennart Heeren or Patrick Göttsch to grant you maintainer rights in that particular repository
    • Copy the SSH url from github
  2. Enable mirroring in gitlab
    • Switch to your private gitlab repository
    • Left menu -> Settings -> Repository -> Expand Mirroring repositories
    • Paste your github url in Input the remote repository URL
    • Modify it this way: ssh:// at the beginning and replace the colon after github.com with a slash. It should look like this now: ssh://git@github.com/TUHH-ICS/REPO_NAME
    • Klick on Detect host keys button
    • Select (although it does not seam to be clickable) in authentification method SSH Public Key
    • And select Mirror only protected branches. By default only the master branch will be pushed as it is.
    • Click on mirror repository to setup the mirror.
    • Now you have to click on the Copy ssh public key
Copy the ssh public key via mousclick on the copy item
  • After a click on the key…
    • go back to GitHub;, click on Settings > Deploy Keys > Add deploy key
    • Give it some title, paste the copied key in the key field and check Allow write access abd than click on Add key
    • Now you can trigger the mirroring by pushing or merging into the master branch in gitlab or manually in the gitlab repo mirroring settings page
  1. Uploading to Zenodo
    • Login to Zenodo using ** Log in with this credentials **
      • user: ics@tuhh.de
      • passwd: JJ^Q?…
    • Click on setting->github (1),
    • Click on Sync now button (2),
    • and enable the repository (3, located at the end of the list),
    • Then we go back to github and create a new release (4):
  • give a version tag like v1.0
  • give a meaningful title
  • and some description (will also be published by zenodo)
  • click on Publish Release
Click on „Publish release“ after assigning a tag, a title and a description

This automatically generates a zip of the code and this zip gets uploaded to zenodo, also automatically.

  1. Creating a DOI/Publishing
  • Back in Zenodo click on upload at the top of the page
Upload-Button
  • Here you find your software code already published
Published software code
  • Since not all metadata is available on github, you have to edit your entry
    • Click on the title opens the entry and shows a view as readers would see it.
    • You can click on edit to add or change metadata. The next view is organised in multiple sections:
      • Files: Here you can upload a new version manually. But normmaly you would choose a github release as the way to go.
      • Communities: Please select Hamburg University of Technology to reference this contribution to TUHH
      • Upload Type: Should already be Software
      • Basic Information:
        • Adjust the Title because the github repo name has been used. E.g.: Code for paper: Name of my marvellous paper
        • Authors: Clean up authors list; Lastname, Firstname – Hamburg University of Technology – Institute of Control Systems – ORCID
        • Add Prof Werner to this list: Werner, Herbert Hamburg University of Technology – Institute of Control Systems – 0000-0003-3456-5539
        • Add a meaningful Description
        • Version tag got automatically set
        • Language: Choose English
        • Give similar Keyword as you choose for your paper
      • License: All should be okay. The License is provided in the repository. Zenodo so far does not support GPLv3.
      • Funding: Select nothing
      • Save the changes. And when you think they can be published, hit the publish button.
  1. Cite code
    • use Zenodo Bibtex generator to get a bibtex entry of your code for your latex literature file – Export section (bottom right)
BibTeX code export via Zenodo

Put a DOI patch into the readme -> Use latest version DOI by clicking on the DOI entry (1) and copying the markdown code (2) from the window. You can add a badge to your gitlab repo as well, either in the readme (2) or by adding a batch using (3a) and (3b)

Zendodo DOI Badge

You might want to change the DOI to the DOI for the latest version:

Adjust the DOI
  1. Updating
    • Create new release on github
    • update Description on zenodo
CC BY 4.0
Weiternutzung als OER ausdrücklich erlaubt: Dieses Werk und dessen Inhalte sind – sofern nicht anders angegeben – lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: Open Access Publishing at TUHH: Exemplary Step-by-step guide for a toolchain with TORE, GitLab, Sherpa Romeo and Zenodo von Patrick Göttsch, Christian Hespe, Adwait Datar, Simon Heinke und Lennart Heeren Lizenz: CC BY 4.0. Eine ggf. aktualisierte Version des Workflows kann über dieses GitLab-Repositorium abgerufen werden.
1 2 3 16