BIT inklusiv Wiki und Test-Case-Datenbank - Benutzerbeiträge [de]

BITi 16 Schriften

2016-12-04T11:47:34Z

Petra:

{{PDF_16}}

===Was wird geprüft?===
====MP 31-010 rechtliche Einschränkung====
Dies ist eine Anforderung an Programme, die PDF/UA erstellen.
Ob ein eingebettetes Schriftprogramm aus rechtlichen Gründen nicht für eine uneingeschränkte, universelle Darstellung eingebettet werden darf, lässt sich in der Regel nicht ohne zusätzliche Information des rechtlichen Eigentümers feststellen, da sie nicht in Daten enthalten ist, die eine Software abfragen könnte. Die Grundlage dieser Information ist ein eventueller Lizenzvertrag.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>

PDF/UA → Basic requirements → PDF syntax → Fonts →

* Registry entries in type 0 fonts
* Ordering entries in type 0 fonts
* Supplement entries in type 0 fonts
* CID to GID mapping of Type 2 CID fonts
* Predefined or embedded CMaps
* WMode entry in CMap dictionary and CMap stream
* References to CMaps in CMaps
* Font embedding
* Encoding entry in non-symbolic TrueType font
* Encoding entry in symbolic TrueType font
* Use of glyph names in non-symbolic TrueType font

==== Prüfung ====

PAC, pdfapilot

===Vorschlag zur Korrektur===
====31-009====
Öffnen Sie in Acrobat Pro-Werkzeuge - Druckproduktion > Preflight > Reiter Profile – Icon Profile auswählen (linkes Icon) PDF Korrekturen Schriften einbetten. Klicken Sie auf Prüfen und korrigieren.

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

Einführung

2016-12-03T13:29:02Z

Petra: /* Maschinelle und manuelle Tests */

<h1>PDF/UA Testverfahren, BIT-inklusiv</h1>
<h2>Vorbemerkungen zum Prüfverfahren</h2>
Der PDF/UA Standard definiert die technischen Anforderungen an barrierefreie PDF-Dokumente, UA steht dabei für Universal Accessibility. Mit diesem Prüfverfahren kann ein PDF-Dokument auf PDF/UA Konformität (ISO 14289-1) geprüft und bewertet werden. Der Schwerpunkt liegt dabei auf der korrekten semantischen Umsetzung der enthaltenen Elemente und Strukturen.

Ein PDF/UA konformes PDF-Dokument ist nicht automatisch barrierefrei. Die WCAG 2.0 und die BITV 2.0 wurden in erster Linie für Web-Auftritte entwickelt und sind daher in ihren Anforderungen nicht immer auf PDF-Dokumente übertragbar. Es gibt bisher kein normatives Regelwerk für die Anforderungen an die Barrierefreiheit eines PDF-Dokuments. So fehlen verbindliche Vorgaben zu Themen wie z.B. ob und wann ein Inhaltsverzeichnis vorhanden sein und ob es verlinkt sein muss, ob und wann Seitenzahlen oder anderen Navigationshilfen vorhanden sein sollten sowie die Anforderung an eine gute Strukturierung der Inhaltsbereiche.

Ein nicht PDF/UA konformes PDF-Dokument hingegen bedeutet immer einen Verstoß gegen Barrierefreiheit.[[#Fußnote|1]]
<div id = Anfang>

===Qualifikation der Prüfer/Prüferinnen===
Bei diesem Test handelt es sich um ein Experten-Verfahren. Das bedeutet, dass Sie zur Durchführung über besondere Qualifikationen verfügen müssen. So sollte der Standard PDF/UA inhaltlich bekannt und ein Grundverständnis für die darin enthaltenen Anforderungen vorhanden sein.

Es gibt zahlreiche Tools für die Überprüfung und Korrektur eines PDFs. In diesem Prüfverfahren werden für die Überprüfung die in der unten stehenden Werkzeugliste genannten Tools verwendet. Andere Tools finden Sie z.B. auf den Seiten der [https://www.pdfa.org/products/ PDF-Association]. Prüfer/-innen sollten mit der Nutzung und Bedienung der gewählten Tools vertraut sein.

===Das Verfahren===
Dieses Prüfverfahren basiert auf dem aus der ISO 14289 abgeleitetem [https://www.pdfa.org/publication/the-matterhorn-protocol-1-02/ Matterhorn Protokoll]. Im Auftrag von BIT inklusiv wurde eine [https://www.pdfa.org/publication/matterhorn-protokoll-1-02-deutsche-uebersetzung/?lang=de deutsche Übersetzung] angefertigt. Alle Kriterien des Matterhorn Protokolls wurden in dieses Prüfverfahren übernommen.

Den Matterhorn Fehlerkonditionen ist ein MP vorangestellt. Einige Fehlerkonditionen sind direkt der ISO 32000-1:2008 bzw. der ISO 14289-1 entnommen und mit der entsprechenden Kapitelangabe gekennzeichnet. Dieses Verfahren prüft ausschließlich die PDF / UA Konformität.

Beabsichtigen Sie ein PDF-Dokument in ein PDF/UA konformes Dokument umzuwandeln, empfehlen wir Ihnen die in den Prüfschritten aufgezeichneten Korrekturvorschläge. Ist Ihnen eine Möglichkeit bekannt, Fehler mit einer anderen Vorgehensweise zu korrigieren oder eine Software einzusetzen, die Prüfschritte maschinell korrigieren kann, können Sie Ihr Wissen auch anderen Nutzern zur Verfügung stellen.

===Abweichungen zur Gliederung des Matterhorn-Protokolls===
Abweichend vom Matterhorn-Protokoll wurden die Prüfpunkte neu zugeordnet und thematisch gegliedert.

Die Gliederung von „BITi 2x Getaggter realer Inhalt / Strukturtypen“ basiert auf der Gruppierung der Strukturtypen in der ISO 32000-1, nämlich:

*Grouping Elements
*BLSE(Block Level Structure Element)
*ILSE (Inline Level Structure Elements)
*Illustrating Elements
Fehlerkonditionen des Matterhorn Protokolls mit Bezug auf mehrere Elemente wie z. B. „MP 01-006“ wurden thematisch geteilt. Dies ist in den Prüfschritten deutlich vermerkt, um Doppelbewertungen zu vermeiden.

Die Gruppierung der Prüfpunkte, welche sich nicht im speziellen auf Strukturelemente beziehen, wurde wie im Matterhorn Protokoll beibehalten.

===Quellen===
Die Beschreibungen und Erklärungen der Prüfschritte sind aus im Internet auffindbaren Schriftstücken (meistens in englischer Sprache) zusammengestellt. Am häufigsten genutzt wurden folgende Quellen:

*PDF Download [http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf ISO 32000-1:2008 (PDF 1.7)]
*Kostenpflichtiger [http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=64599 PDF/UA-Standard] (ISO 14289-1:20MP 12-07, DIN ISO 14289-1:20MP 14-02)
*[https://www.pdfa.org/publication/the-matterhorn-protocol-1-02/ Matterhorn Protokoll V1.02]
*Aiim [http://www.aiim.org/Global/AIIM_Widgets/Community_Widgets/Technical-Implementation-Guide Technical Implementation Guide]
*Aiim [http://www.aiim.org/Global/AIIM_Widgets/Community_Widgets/Achieving_WCAG Achieving WCAG 2.0 with PDF/UA]
*PDF Download [https://www.pdfa.org/wp-content/until2016_uploads/2013/08/PDFUA-kompakt-PDFUA.pdf PDF/UA kompakt]
*[https://www.pdfa.org/announcing-the-structure-elements-best-practice-guide-0-1-1/ PDF Structure Element Best Practice Guide]
*[http://blog.axespdf.com Blog axespdf]

==Vorgehensweise bzw. Durchführung und Korrektur==

Die PDF Dokumente werden vollständig geprüft. Durch Nutzung von Analyse-Software wie der Validatoren PAC, PDFaPilot und CommonLook können viele Fehler und Probleme auch bei sehr umfangreichen Dokumenten einfach identifiziert werden. Der Test einer repräsentativen Seiten- bzw. Element-Auswahl, wie z.B. beim [http://www.bitvtest.de BITV-Test], einem Testverfahren für Webangebote, ist deshalb nicht sinnvoll.

Jeder Fehler muss einzeln korrigiert werden. Korrigieren Sie ein großes Dokument, ist es eventuell sinnvoller erst das Quelldokument zu bearbeiten, sofern es zur Verfügung steht.

===Maschinelle und manuelle Tests===
Im Matterhorn-Protokoll wird bei der Prüfbarkeit der Fehlerbedingungen zwischen Mensch und Maschine (Software) unterschieden. Diese Einteilung ist nicht zwingend erforderlich, ist jedoch die zurzeit bewährte Methode zur Prüfung der jeweils zu prüfenden Fehlerkondition. Diese Einteilung wurde in diesem Prüfverfahren übernommen. Eine zentrale Rolle bei der Durchführung des Tests haben dabei Analyse-Werkzeuge. In den Erläuterungen in diesem Prüfverfahren („Wie wird geprüft?“) werden dazu die Validatoren PAC und pdfaPilot eingesetzt (siehe entsprechende Hinweise bei den Prüfschritten). Die Veröffentlichung von PAC 3.0 wird bis Ende 2016 erwartet.

===Werkzeugliste===
====Analyse====
*PAC in der aktuellsten Version (ist immer dann gemeint, wenn PAC ohne Versionsnummer genannt ist<br>Kostenloser [http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac/downloading-pac.html Download PAC]
*PAC 1.3<br>Kostenloser [http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac/downloading-pac.html Download PAC 1.3] (am Ende der Seite)
*Validator von pdfaPilot6<br>Kostenloser [https://www.callassoftware.com/de/produkte/pdfapilot/?type=product&product=pdfapilotdesktop Download pdfaPilot6]<br>Hinweis: Sie können die zeitlich begrenzte Testversion von pdfaPilot6 benutzen. Der integrierte PDF/UA Validator bleibt über die zeitliche Begrenzung hinaus voll funktionsfähig.
*Colour Contrast Analyzer<br>Kostenloser [https://www.paciellogroup.com/resources/contrastanalyser/ Download]

====Lese-Programme====
*VIP-Reader<br> Kostenloser [http://www.szb.ch/hilfsmittelfuerblindeundsehbehinderte/digital-tools/vip-pdf-reader/ Download]
*Foxit-Reader<br>Kostenloser [https://www.foxitsoftware.com/de/ Download]

====Screenreader====
*NVDA <br>Kostenloser [http://www.nvaccess.org/download/ Download]
*FokusHighlight Plugin für NVDA <br>Kostenloser [http://addons.nvda-project.org/addons/focusHighlight.en.html Download]

----
Fußnote:
<div id=Fußnote>
[[#Anfang|1]] ausgenommen der einzige Fehler ist das Nichtvorhandensein der PDF/UA xmp Datei, siehe BITi 06

Einführung

2016-12-03T13:19:17Z

Petra: /* Maschinelle und manuelle Tests */

<h1>PDF/UA Testverfahren, BIT-inklusiv</h1>
<h2>Vorbemerkungen zum Prüfverfahren</h2>
Der PDF/UA Standard definiert die technischen Anforderungen an barrierefreie PDF-Dokumente, UA steht dabei für Universal Accessibility. Mit diesem Prüfverfahren kann ein PDF-Dokument auf PDF/UA Konformität (ISO 14289-1) geprüft und bewertet werden. Der Schwerpunkt liegt dabei auf der korrekten semantischen Umsetzung der enthaltenen Elemente und Strukturen.

Ein PDF/UA konformes PDF-Dokument ist nicht automatisch barrierefrei. Die WCAG 2.0 und die BITV 2.0 wurden in erster Linie für Web-Auftritte entwickelt und sind daher in ihren Anforderungen nicht immer auf PDF-Dokumente übertragbar. Es gibt bisher kein normatives Regelwerk für die Anforderungen an die Barrierefreiheit eines PDF-Dokuments. So fehlen verbindliche Vorgaben zu Themen wie z.B. ob und wann ein Inhaltsverzeichnis vorhanden sein und ob es verlinkt sein muss, ob und wann Seitenzahlen oder anderen Navigationshilfen vorhanden sein sollten sowie die Anforderung an eine gute Strukturierung der Inhaltsbereiche.

Ein nicht PDF/UA konformes PDF-Dokument hingegen bedeutet immer einen Verstoß gegen Barrierefreiheit.[[#Fußnote|1]]
<div id = Anfang>

===Qualifikation der Prüfer/Prüferinnen===
Bei diesem Test handelt es sich um ein Experten-Verfahren. Das bedeutet, dass Sie zur Durchführung über besondere Qualifikationen verfügen müssen. So sollte der Standard PDF/UA inhaltlich bekannt und ein Grundverständnis für die darin enthaltenen Anforderungen vorhanden sein.

Es gibt zahlreiche Tools für die Überprüfung und Korrektur eines PDFs. In diesem Prüfverfahren werden für die Überprüfung die in der unten stehenden Werkzeugliste genannten Tools verwendet. Andere Tools finden Sie z.B. auf den Seiten der [https://www.pdfa.org/products/ PDF-Association]. Prüfer/-innen sollten mit der Nutzung und Bedienung der gewählten Tools vertraut sein.

===Das Verfahren===
Dieses Prüfverfahren basiert auf dem aus der ISO 14289 abgeleitetem [https://www.pdfa.org/publication/the-matterhorn-protocol-1-02/ Matterhorn Protokoll]. Im Auftrag von BIT inklusiv wurde eine [https://www.pdfa.org/publication/matterhorn-protokoll-1-02-deutsche-uebersetzung/?lang=de deutsche Übersetzung] angefertigt. Alle Kriterien des Matterhorn Protokolls wurden in dieses Prüfverfahren übernommen.

Den Matterhorn Fehlerkonditionen ist ein MP vorangestellt. Einige Fehlerkonditionen sind direkt der ISO 32000-1:2008 bzw. der ISO 14289-1 entnommen und mit der entsprechenden Kapitelangabe gekennzeichnet. Dieses Verfahren prüft ausschließlich die PDF / UA Konformität.

Beabsichtigen Sie ein PDF-Dokument in ein PDF/UA konformes Dokument umzuwandeln, empfehlen wir Ihnen die in den Prüfschritten aufgezeichneten Korrekturvorschläge. Ist Ihnen eine Möglichkeit bekannt, Fehler mit einer anderen Vorgehensweise zu korrigieren oder eine Software einzusetzen, die Prüfschritte maschinell korrigieren kann, können Sie Ihr Wissen auch anderen Nutzern zur Verfügung stellen.

===Abweichungen zur Gliederung des Matterhorn-Protokolls===
Abweichend vom Matterhorn-Protokoll wurden die Prüfpunkte neu zugeordnet und thematisch gegliedert.

Die Gliederung von „BITi 2x Getaggter realer Inhalt / Strukturtypen“ basiert auf der Gruppierung der Strukturtypen in der ISO 32000-1, nämlich:

*Grouping Elements
*BLSE(Block Level Structure Element)
*ILSE (Inline Level Structure Elements)
*Illustrating Elements
Fehlerkonditionen des Matterhorn Protokolls mit Bezug auf mehrere Elemente wie z. B. „MP 01-006“ wurden thematisch geteilt. Dies ist in den Prüfschritten deutlich vermerkt, um Doppelbewertungen zu vermeiden.

Die Gruppierung der Prüfpunkte, welche sich nicht im speziellen auf Strukturelemente beziehen, wurde wie im Matterhorn Protokoll beibehalten.

===Quellen===
Die Beschreibungen und Erklärungen der Prüfschritte sind aus im Internet auffindbaren Schriftstücken (meistens in englischer Sprache) zusammengestellt. Am häufigsten genutzt wurden folgende Quellen:

*PDF Download [http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf ISO 32000-1:2008 (PDF 1.7)]
*Kostenpflichtiger [http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=64599 PDF/UA-Standard] (ISO 14289-1:20MP 12-07, DIN ISO 14289-1:20MP 14-02)
*[https://www.pdfa.org/publication/the-matterhorn-protocol-1-02/ Matterhorn Protokoll V1.02]
*Aiim [http://www.aiim.org/Global/AIIM_Widgets/Community_Widgets/Technical-Implementation-Guide Technical Implementation Guide]
*Aiim [http://www.aiim.org/Global/AIIM_Widgets/Community_Widgets/Achieving_WCAG Achieving WCAG 2.0 with PDF/UA]
*PDF Download [https://www.pdfa.org/wp-content/until2016_uploads/2013/08/PDFUA-kompakt-PDFUA.pdf PDF/UA kompakt]
*[https://www.pdfa.org/announcing-the-structure-elements-best-practice-guide-0-1-1/ PDF Structure Element Best Practice Guide]
*[http://blog.axespdf.com Blog axespdf]

==Vorgehensweise bzw. Durchführung und Korrektur==

Die PDF Dokumente werden vollständig geprüft. Durch Nutzung von Analyse-Software wie der Validatoren PAC, PDFaPilot und CommonLook können viele Fehler und Probleme auch bei sehr umfangreichen Dokumenten einfach identifiziert werden. Der Test einer repräsentativen Seiten- bzw. Element-Auswahl, wie z.B. beim [http://www.bitvtest.de BITV-Test], einem Testverfahren für Webangebote, ist deshalb nicht sinnvoll.

Jeder Fehler muss einzeln korrigiert werden. Korrigieren Sie ein großes Dokument, ist es eventuell sinnvoller erst das Quelldokument zu bearbeiten, sofern es zur Verfügung steht.

===Maschinelle und manuelle Tests===
Im Matterhorn-Protokoll wird bei der Prüfbarkeit der Fehlerbedingungen zwischen Mensch und Maschine (Software) unterschieden. Diese Einteilung ist nicht zwingend erforderlich, ist jedoch die zurzeit bewährte Methode zur Prüfung der jeweils zu prüfenden Fehlerkondition. Diese Einteilung wurde in diesem Prüfverfahren übernommen. Eine zentrale Rolle bei der Durchführung des Tests haben dabei Analyse-Werkzeuge. In den Erläuterungen in diesem Prüfverfahren („Wie wird geprüft?“) werden dazu die Validatoren PAC und pdfaPilot eingesetzt (siehe entsprechende Hinweise bei den Prüfschritten). Die Veröffentlichung von PAC 3.0 wird bis Ende 2016 erwartet.

Können Sie eine Fehlermeldung nicht zuordnen, haben Sie die Möglichkeit über die Suchfunktion die erzeugte Fehlermeldung zu suchen und finden so den Prüfschritt, der sich auf den Fehler bezieht.

===Werkzeugliste===
====Analyse====
*PAC in der aktuellsten Version (ist immer dann gemeint, wenn PAC ohne Versionsnummer genannt ist<br>Kostenloser [http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac/downloading-pac.html Download PAC]
*PAC 1.3<br>Kostenloser [http://www.access-for-all.ch/en/pdf-lab/pdf-accessibility-checker-pac/downloading-pac.html Download PAC 1.3] (am Ende der Seite)
*Validator von pdfaPilot6<br>Kostenloser [https://www.callassoftware.com/de/produkte/pdfapilot/?type=product&product=pdfapilotdesktop Download pdfaPilot6]<br>Hinweis: Sie können die zeitlich begrenzte Testversion von pdfaPilot6 benutzen. Der integrierte PDF/UA Validator bleibt über die zeitliche Begrenzung hinaus voll funktionsfähig.
*Colour Contrast Analyzer<br>Kostenloser [https://www.paciellogroup.com/resources/contrastanalyser/ Download]

====Lese-Programme====
*VIP-Reader<br> Kostenloser [http://www.szb.ch/hilfsmittelfuerblindeundsehbehinderte/digital-tools/vip-pdf-reader/ Download]
*Foxit-Reader<br>Kostenloser [https://www.foxitsoftware.com/de/ Download]

====Screenreader====
*NVDA <br>Kostenloser [http://www.nvaccess.org/download/ Download]
*FokusHighlight Plugin für NVDA <br>Kostenloser [http://addons.nvda-project.org/addons/focusHighlight.en.html Download]

----
Fußnote:
<div id=Fußnote>
[[#Anfang|1]] ausgenommen der einzige Fehler ist das Nichtvorhandensein der PDF/UA xmp Datei, siehe BITi 06

Datei:Einfache Datentabelle.png

2016-11-23T07:44:36Z

Petra: Petra lud eine neue Version von Datei:Einfache Datentabelle.png hoch

Screenshot eines Tag-Baums für eine einfache Datentabelle

BITi 06. Metadaten / Dokumenttitel

2016-11-17T18:50:41Z

Petra: /* Acrobat Pro XI */

{{PDF_06}}

=== Was wird geprüft? ===
*Jedes Dokument braucht einen aussagekräftigen Dokumenttitel.
*Der Dokumenttitel muss beim Öffnen des Dokuments anstelle des Dateinamens angezeigt werden.
*Metadaten im PDF-Dokument sind korrekt eingebunden.
*Eine PDF/UA-Kennzeichnung (Identifier) ist vorhanden.

=== Warum wird das geprüft? ===

Ein aussagekräftiger Dokumenttitel ist speziell für Nutzer von Screenreadern wichtig, hilft aber jedem Benutzer bei der Orientierung.

====Hinweis zu PDF/UA Identifier====
Der PDF/UA Identifier ist ein Hinweis für PDF/UA konforme Leseprogramme und sollte ein Eintrag in der xmp Datei sein. Gibt es keine weiteren Verstöße gegen PDF/UA Konformität in dem Dokument, enthält das Dokument keine Barrieren.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>
PDF/UA → Report → Metadata and Settings → Metadata →
* XMP Metadata entry in catalog
* PDF/UA indentifier

==== Prüfung ====
Der Dokumenttitel ist definiert und beschreibt das Dokument eindeutig und aussagekräftig. Der Dokumenttitel ist nicht der Dateiname! Der Titel sollte ganz oben in dem Dokument angezeigt werden. Ist das nicht der Fall, können Sie ihn z. B. in Acrobat DC Reader unter Datei-Eigenschaften-Beschreibung sehen.

===Vorschlag zur Korrektur===
====MP 06-001 keine Metadaten vorhanden====
Führen Sie die Korrekturvorschläge MP 06-002 und MP 06-003 aus.

====MP 06-002 Fehlende PDF/UA Kennzeichnung====
=====Acrobat Pro XI=====
*Downloaden Sie die benötigte xmp-Datei unter [http://bygosh.com/files/pdfuaid.xmp diesem Link].
*Klicken Sie auf Datei und öffnen Sie die Eigenschaften.
*Im Reiter Beschreibung klicken Sie in der Mitte der Seite auf die Schaltfläche „Zusätzliche Metadaten“ und im nächsten Fenster oben links auf „Erweitert“.
*Im unteren Bereich der Seite klicken Sie nun auf „Anhängen“ und wählen Sie die gespeicherte xmp-Datei aus.
*Klicken Sie auf öffnen und bestätigen Sie mit „OK“.

=====Acrobat Pro DC=====
*Klicken Sie in den Werkzeugen auf Druckproduktion und wählen Sie Preflight.
*Klicken Sie dort auf Einzelne Korrekturen auswählen (Icon Schraubschlüssel) und expandieren Sie Dokumenteninformationen und Metadaten.
*Wählen Sie den Eintrag PDF / UA -1 und klicken Sie auf Korrigieren.

====MP 06-003 MP 07-001 MP 07-002 Dokumenttitel wird nicht angezeigt====
=====Acrobat Pro=====
*Öffnen Sie in Acrobat Pro über Datei - Eigenschaften den Reiter Beschreibung und tragen Sie dort einen aussagekräftigen Titel ein.
*Wechseln Sie auf den Reiter Ansicht beim Öffnen.
*Wählen Sie bei Einblenden aus dem Pull-down Menu den Eintrag Dokumenttitel

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

BITi 06. Metadaten / Dokumenttitel

2016-11-17T18:48:15Z

Petra: /* Acrobat Pro XI */

{{PDF_06}}

=== Was wird geprüft? ===
*Jedes Dokument braucht einen aussagekräftigen Dokumenttitel.
*Der Dokumenttitel muss beim Öffnen des Dokuments anstelle des Dateinamens angezeigt werden.
*Metadaten im PDF-Dokument sind korrekt eingebunden.
*Eine PDF/UA-Kennzeichnung (Identifier) ist vorhanden.

=== Warum wird das geprüft? ===

Ein aussagekräftiger Dokumenttitel ist speziell für Nutzer von Screenreadern wichtig, hilft aber jedem Benutzer bei der Orientierung.

====Hinweis zu PDF/UA Identifier====
Der PDF/UA Identifier ist ein Hinweis für PDF/UA konforme Leseprogramme und sollte ein Eintrag in der xmp Datei sein. Gibt es keine weiteren Verstöße gegen PDF/UA Konformität in dem Dokument, enthält das Dokument keine Barrieren.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>
PDF/UA → Report → Metadata and Settings → Metadata →
* XMP Metadata entry in catalog
* PDF/UA indentifier

==== Prüfung ====
Der Dokumenttitel ist definiert und beschreibt das Dokument eindeutig und aussagekräftig. Der Dokumenttitel ist nicht der Dateiname! Der Titel sollte ganz oben in dem Dokument angezeigt werden. Ist das nicht der Fall, können Sie ihn z. B. in Acrobat DC Reader unter Datei-Eigenschaften-Beschreibung sehen.

===Vorschlag zur Korrektur===
====MP 06-001 keine Metadaten vorhanden====
Führen Sie die Korrekturvorschläge MP 06-002 und MP 06-003 aus.

====MP 06-002 Fehlende PDF/UA Kennzeichnung====
=====Acrobat Pro XI=====
*Folgen Sie [http://bygosh.com/files/pdfuaid.xmp diesem Link] und speichern Sie die Datei mit der Endung xmp (nicht .txt!).
*Klicken Sie auf Datei und öffnen Sie die Eigenschaften.
*Im Reiter Beschreibung klicken Sie in der Mitte der Seite auf die Schaltfläche „Zusätzliche Metadaten“ und im nächsten Fenster oben links auf „Erweitert“.
*Im unteren Bereich der Seite klicken Sie nun auf „Anhängen“ und wählen Sie die gespeicherte xmp-Datei aus.
*Klicken Sie auf öffnen und bestätigen Sie mit „OK“.

=====Acrobat Pro DC=====
*Klicken Sie in den Werkzeugen auf Druckproduktion und wählen Sie Preflight.
*Klicken Sie dort auf Einzelne Korrekturen auswählen (Icon Schraubschlüssel) und expandieren Sie Dokumenteninformationen und Metadaten.
*Wählen Sie den Eintrag PDF / UA -1 und klicken Sie auf Korrigieren.

====MP 06-003 MP 07-001 MP 07-002 Dokumenttitel wird nicht angezeigt====
=====Acrobat Pro=====
*Öffnen Sie in Acrobat Pro über Datei - Eigenschaften den Reiter Beschreibung und tragen Sie dort einen aussagekräftigen Titel ein.
*Wechseln Sie auf den Reiter Ansicht beim Öffnen.
*Wählen Sie bei Einblenden aus dem Pull-down Menu den Eintrag Dokumenttitel

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

BITi 06. Metadaten / Dokumenttitel

2016-11-17T18:38:12Z

Petra: /* Acrobat Pro XI */

{{PDF_06}}

=== Was wird geprüft? ===
*Jedes Dokument braucht einen aussagekräftigen Dokumenttitel.
*Der Dokumenttitel muss beim Öffnen des Dokuments anstelle des Dateinamens angezeigt werden.
*Metadaten im PDF-Dokument sind korrekt eingebunden.
*Eine PDF/UA-Kennzeichnung (Identifier) ist vorhanden.

=== Warum wird das geprüft? ===

Ein aussagekräftiger Dokumenttitel ist speziell für Nutzer von Screenreadern wichtig, hilft aber jedem Benutzer bei der Orientierung.

====Hinweis zu PDF/UA Identifier====
Der PDF/UA Identifier ist ein Hinweis für PDF/UA konforme Leseprogramme und sollte ein Eintrag in der xmp Datei sein. Gibt es keine weiteren Verstöße gegen PDF/UA Konformität in dem Dokument, enthält das Dokument keine Barrieren.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>
PDF/UA → Report → Metadata and Settings → Metadata →
* XMP Metadata entry in catalog
* PDF/UA indentifier

==== Prüfung ====
Der Dokumenttitel ist definiert und beschreibt das Dokument eindeutig und aussagekräftig. Der Dokumenttitel ist nicht der Dateiname! Der Titel sollte ganz oben in dem Dokument angezeigt werden. Ist das nicht der Fall, können Sie ihn z. B. in Acrobat DC Reader unter Datei-Eigenschaften-Beschreibung sehen.

===Vorschlag zur Korrektur===
====MP 06-001 keine Metadaten vorhanden====
Führen Sie die Korrekturvorschläge MP 06-002 und MP 06-003 aus.

====MP 06-002 Fehlende PDF/UA Kennzeichnung====
=====Acrobat Pro XI=====
*Folgen Sie [http://www.robinschwab.ch/pdfUA.xmp diesem Link] und speichern Sie die Datei mit der Endung xmp (nicht .txt!).
*Klicken Sie auf Datei und öffnen Sie die Eigenschaften.
*Im Reiter Beschreibung klicken Sie in der Mitte der Seite auf die Schaltfläche „Zusätzliche Metadaten“ und im nächsten Fenster oben links auf „Erweitert“.
*Im unteren Bereich der Seite klicken Sie nun auf „Anhängen“ und wählen Sie die gespeicherte xmp-Datei aus.
*Klicken Sie auf öffnen und bestätigen Sie mit „OK“.

=====Acrobat Pro DC=====
*Klicken Sie in den Werkzeugen auf Druckproduktion und wählen Sie Preflight.
*Klicken Sie dort auf Einzelne Korrekturen auswählen (Icon Schraubschlüssel) und expandieren Sie Dokumenteninformationen und Metadaten.
*Wählen Sie den Eintrag PDF / UA -1 und klicken Sie auf Korrigieren.

====MP 06-003 MP 07-001 MP 07-002 Dokumenttitel wird nicht angezeigt====
=====Acrobat Pro=====
*Öffnen Sie in Acrobat Pro über Datei - Eigenschaften den Reiter Beschreibung und tragen Sie dort einen aussagekräftigen Titel ein.
*Wechseln Sie auf den Reiter Ansicht beim Öffnen.
*Wählen Sie bei Einblenden aus dem Pull-down Menu den Eintrag Dokumenttitel

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

BITi 02.3.0 Inlinelevel Strukturelemente / Fuß- Endnoten und Verweise

2016-11-17T18:14:04Z

Petra: /* Beispiel 2: */

{{PDF_02_3_0}}

=== Was wird geprüft? ===

Inline Level Structure Elements (ILSE) müssen sich immer innerhalb eines Block Level Structure Elements (BLSE) befinden.

Fuß- und Endnoten gehören nicht zum Textfluss und müssen als solche eindeutig identifizierbar sein. Der Verweis muss für Nutzer assistiver Technologien durch ein eindeutiges Label verständlich sein.

Nicht vorhandene IDs in Note Tags werden nicht negativ bewertet, da sie keine Einschränkung der Barrierefreiheit bedeuten. Sind IDs vorhanden, müssen sie aber eindeutig sein und dürfen jeweils nur einmal verwendet werden.

==== Beispiel 1: ====

Verweis:

<P><br>
:Text vor dem Verweis<br>
:<Link><br>
::Link-OBJR<br>
::<Reference><br>
:::<Span><br>
::::1<br>
:Text nach dem Verweis

Fußnote:

<LI><br>
:<Lbl><br>
::1<br>
:<LBody><br>
::<Note><br>
:::Der Verweistext

Da die Accessibility Schnittstelle von Acrobat <Link> und <Reference> Tags gleich behandelt, hören - bei dieser Lösung - Nutzer von Screenreadern in Acrobat im Verweis zweimal das Wort „Link“. In Anlehnung an den in 2017 kommenden PDF/UA Standard 2.0 ist daher folgende Lösung zu bevorzugen:

==== Beispiel 2: ====
Verweis:

<P><br>
:Text vor dem Verweis<br>
:<Lbl><br>
::<Link><br>
:::1<br>
:::Link - OBJR<br>

Fußnote:

<Note><br>
:<Lbl><br>
::<Link><br>
:::1<br>
:::Link-OBJR<br>
:Der Verweistext<br>

=== Warum wird das geprüft? ===

Da Fußnoten relevante Inhaltselemente eines Dokuments sind, ist es wichtig, dass auch blinde und sehbehinderte Anwender sie mit assistiven Technologien wahrnehmen können.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>
PDF/UA → Logical structure → Structure elements → Notes →

* ID entry in Note structure elements
* Unique ID entries in Note structure elements

==== Prüfung ====

* PAC - Screenreader Preview
** Prüfen Sie ob Fußnoten Endnoten und Verweise richtig getaggt sind.
* PAC – Logical Structure
** Linke Seite: Reiter Structure Elements, rechte Seite Page View
*** Bewegen Sie sich auf der linken Seite solange durch den Tagbaum, bis Sie zu den <Note> Tags (eventuell auch durch eine Rollenzuordnung auf <Note> gemapptes Strukturelement) der Fußnoten kommen.
*Markieren Sie den Note-Tag auf der linken Seite und wechseln Sie auf der rechten Seite auf den Reiter Properties.
*Prüfen Sie, ob eine eindeutige ID angezeigt wird. <br>Sind keine IDs vorhanden, führt dies nicht zu einer negativen Beurteilung, da diese Forderung ab PDF/UA (voraussichtlich 2017) gestrichen wird.

===Vorschlag zur Korrektur mit Acrobat Pro:===
====MP 19-003 fehlende ID====
=====Acrobat Pro=====
*Markieren Sie im Text den Verweistext und wählen Sie in den Optionen (kleiner Pfeil in der Tag-Ansicht) „Tag in Auswahl suchen“.
*Über einen Rechtsklick auf den <Note> Tag in der Tag-Ansicht öffnen Sie die Eigenschaften und tragen Sie eine ID ein.

====MP 19-004 Eindeutigkeit====
Überprüfen Sie wie für 19-003, ob jede ID nur einmal vorhanden ist.

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

BITi 02.3.0 Inlinelevel Strukturelemente / Fuß- Endnoten und Verweise

2016-11-17T18:12:30Z

Petra: /* Beispiel 2: */

{{PDF_02_3_0}}

=== Was wird geprüft? ===

Inline Level Structure Elements (ILSE) müssen sich immer innerhalb eines Block Level Structure Elements (BLSE) befinden.

Fuß- und Endnoten gehören nicht zum Textfluss und müssen als solche eindeutig identifizierbar sein. Der Verweis muss für Nutzer assistiver Technologien durch ein eindeutiges Label verständlich sein.

Nicht vorhandene IDs in Note Tags werden nicht negativ bewertet, da sie keine Einschränkung der Barrierefreiheit bedeuten. Sind IDs vorhanden, müssen sie aber eindeutig sein und dürfen jeweils nur einmal verwendet werden.

==== Beispiel 1: ====

Verweis:

<P><br>
:Text vor dem Verweis<br>
:<Link><br>
::Link-OBJR<br>
::<Reference><br>
:::<Span><br>
::::1<br>
:Text nach dem Verweis

Fußnote:

<LI><br>
:<Lbl><br>
::1<br>
:<LBody><br>
::<Note><br>
:::Der Verweistext

Da die Accessibility Schnittstelle von Acrobat <Link> und <Reference> Tags gleich behandelt, hören - bei dieser Lösung - Nutzer von Screenreadern in Acrobat im Verweis zweimal das Wort „Link“. In Anlehnung an den in 2017 kommenden PDF/UA Standard 2.0 ist daher folgende Lösung zu bevorzugen:

==== Beispiel 2: ====
Verweis:

<P><br>
:Text vor dem Verweis<br>
:<Lbl><br>
::<Link><br>
:::1<br>
:::Link - OBJR<br>

Fußnote:

<Note><br>

      <Lbl><br>

            <Link><br>

                  1<br>

                  Link-OBJR<br>

      Der Verweistext<br>

=== Warum wird das geprüft? ===

Da Fußnoten relevante Inhaltselemente eines Dokuments sind, ist es wichtig, dass auch blinde und sehbehinderte Anwender sie mit assistiven Technologien wahrnehmen können.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>
PDF/UA → Logical structure → Structure elements → Notes →

* ID entry in Note structure elements
* Unique ID entries in Note structure elements

==== Prüfung ====

* PAC - Screenreader Preview
** Prüfen Sie ob Fußnoten Endnoten und Verweise richtig getaggt sind.
* PAC – Logical Structure
** Linke Seite: Reiter Structure Elements, rechte Seite Page View
*** Bewegen Sie sich auf der linken Seite solange durch den Tagbaum, bis Sie zu den <Note> Tags (eventuell auch durch eine Rollenzuordnung auf <Note> gemapptes Strukturelement) der Fußnoten kommen.
*Markieren Sie den Note-Tag auf der linken Seite und wechseln Sie auf der rechten Seite auf den Reiter Properties.
*Prüfen Sie, ob eine eindeutige ID angezeigt wird. <br>Sind keine IDs vorhanden, führt dies nicht zu einer negativen Beurteilung, da diese Forderung ab PDF/UA (voraussichtlich 2017) gestrichen wird.

===Vorschlag zur Korrektur mit Acrobat Pro:===
====MP 19-003 fehlende ID====
=====Acrobat Pro=====
*Markieren Sie im Text den Verweistext und wählen Sie in den Optionen (kleiner Pfeil in der Tag-Ansicht) „Tag in Auswahl suchen“.
*Über einen Rechtsklick auf den <Note> Tag in der Tag-Ansicht öffnen Sie die Eigenschaften und tragen Sie eine ID ein.

====MP 19-004 Eindeutigkeit====
Überprüfen Sie wie für 19-003, ob jede ID nur einmal vorhanden ist.

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

BITi 02.3.0 Inlinelevel Strukturelemente / Fuß- Endnoten und Verweise

2016-11-17T17:06:51Z

Petra: /* Beispiel 2: */

{{PDF_02_3_0}}

=== Was wird geprüft? ===

Inline Level Structure Elements (ILSE) müssen sich immer innerhalb eines Block Level Structure Elements (BLSE) befinden.

Fuß- und Endnoten gehören nicht zum Textfluss und müssen als solche eindeutig identifizierbar sein. Der Verweis muss für Nutzer assistiver Technologien durch ein eindeutiges Label verständlich sein.

Nicht vorhandene IDs in Note Tags werden nicht negativ bewertet, da sie keine Einschränkung der Barrierefreiheit bedeuten. Sind IDs vorhanden, müssen sie aber eindeutig sein und dürfen jeweils nur einmal verwendet werden.

==== Beispiel 1: ====

Verweis:

<P><br>
:Text vor dem Verweis<br>
:<Link><br>
::Link-OBJR<br>
::<Reference><br>
:::<Span><br>
::::1<br>
:Text nach dem Verweis

Fußnote:

<LI><br>
:<Lbl><br>
::1<br>
:<LBody><br>
::<Note><br>
:::Der Verweistext

Da die Accessibility Schnittstelle von Acrobat <Link> und <Reference> Tags gleich behandelt, hören - bei dieser Lösung - Nutzer von Screenreadern in Acrobat im Verweis zweimal das Wort „Link“. In Anlehnung an den in 2017 kommenden PDF/UA Standard 2.0 ist daher folgende Lösung zu bevorzugen:

==== Beispiel 2: ====

<P><br>

      Text vor dem Verweis<br>

      <Lbl><br>

            <Link><br>

                  1<br>

                  Link - OBJR<br>

Fußnote:

<Note><br>

      <Lbl><br>

            <Link><br>

                  1<br>

                  Link-OBJR<br>

      Der Verweistext<br>

=== Warum wird das geprüft? ===

Da Fußnoten relevante Inhaltselemente eines Dokuments sind, ist es wichtig, dass auch blinde und sehbehinderte Anwender sie mit assistiven Technologien wahrnehmen können.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>
PDF/UA → Logical structure → Structure elements → Notes →

* ID entry in Note structure elements
* Unique ID entries in Note structure elements

==== Prüfung ====

* PAC - Screenreader Preview
** Prüfen Sie ob Fußnoten Endnoten und Verweise richtig getaggt sind.
* PAC – Logical Structure
** Linke Seite: Reiter Structure Elements, rechte Seite Page View
*** Bewegen Sie sich auf der linken Seite solange durch den Tagbaum, bis Sie zu den <Note> Tags (eventuell auch durch eine Rollenzuordnung auf <Note> gemapptes Strukturelement) der Fußnoten kommen.
*Markieren Sie den Note-Tag auf der linken Seite und wechseln Sie auf der rechten Seite auf den Reiter Properties.
*Prüfen Sie, ob eine eindeutige ID angezeigt wird. <br>Sind keine IDs vorhanden, führt dies nicht zu einer negativen Beurteilung, da diese Forderung ab PDF/UA (voraussichtlich 2017) gestrichen wird.

===Vorschlag zur Korrektur mit Acrobat Pro:===
====MP 19-003 fehlende ID====
=====Acrobat Pro=====
*Markieren Sie im Text den Verweistext und wählen Sie in den Optionen (kleiner Pfeil in der Tag-Ansicht) „Tag in Auswahl suchen“.
*Über einen Rechtsklick auf den <Note> Tag in der Tag-Ansicht öffnen Sie die Eigenschaften und tragen Sie eine ID ein.

====MP 19-004 Eindeutigkeit====
Überprüfen Sie wie für 19-003, ob jede ID nur einmal vorhanden ist.

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

BITi 02.3.0 Inlinelevel Strukturelemente / Fuß- Endnoten und Verweise

2016-11-17T17:04:23Z

Petra: /* Beispiel 1: */

{{PDF_02_3_0}}

=== Was wird geprüft? ===

Inline Level Structure Elements (ILSE) müssen sich immer innerhalb eines Block Level Structure Elements (BLSE) befinden.

Fuß- und Endnoten gehören nicht zum Textfluss und müssen als solche eindeutig identifizierbar sein. Der Verweis muss für Nutzer assistiver Technologien durch ein eindeutiges Label verständlich sein.

Nicht vorhandene IDs in Note Tags werden nicht negativ bewertet, da sie keine Einschränkung der Barrierefreiheit bedeuten. Sind IDs vorhanden, müssen sie aber eindeutig sein und dürfen jeweils nur einmal verwendet werden.

==== Beispiel 1: ====

Verweis:

<P><br>
:Text vor dem Verweis<br>
:<Link><br>
::Link-OBJR<br>
::<Reference><br>
:::<Span><br>
::::1<br>
:Text nach dem Verweis

Fußnote:

<LI><br>
:<Lbl><br>
::1<br>
:<LBody><br>
::<Note><br>
:::Der Verweistext

Da die Accessibility Schnittstelle von Acrobat <Link> und <Reference> Tags gleich behandelt, hören - bei dieser Lösung - Nutzer von Screenreadern in Acrobat im Verweis zweimal das Wort „Link“. In Anlehnung an den in 2017 kommenden PDF/UA Standard 2.0 ist daher folgende Lösung zu bevorzugen:

==== Beispiel 2: ====

Verweis:

<P>

      Text vor dem Verweis

      <Lbl>

            <Link>

                  1

                  Link - OBJR

Fußnote:

<Note>

      <Lbl>

            <Link>

                  1

                  Link-OBJR

      Der Verweistext

=== Warum wird das geprüft? ===

Da Fußnoten relevante Inhaltselemente eines Dokuments sind, ist es wichtig, dass auch blinde und sehbehinderte Anwender sie mit assistiven Technologien wahrnehmen können.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>
PDF/UA → Logical structure → Structure elements → Notes →

* ID entry in Note structure elements
* Unique ID entries in Note structure elements

==== Prüfung ====

* PAC - Screenreader Preview
** Prüfen Sie ob Fußnoten Endnoten und Verweise richtig getaggt sind.
* PAC – Logical Structure
** Linke Seite: Reiter Structure Elements, rechte Seite Page View
*** Bewegen Sie sich auf der linken Seite solange durch den Tagbaum, bis Sie zu den <Note> Tags (eventuell auch durch eine Rollenzuordnung auf <Note> gemapptes Strukturelement) der Fußnoten kommen.
*Markieren Sie den Note-Tag auf der linken Seite und wechseln Sie auf der rechten Seite auf den Reiter Properties.
*Prüfen Sie, ob eine eindeutige ID angezeigt wird. <br>Sind keine IDs vorhanden, führt dies nicht zu einer negativen Beurteilung, da diese Forderung ab PDF/UA (voraussichtlich 2017) gestrichen wird.

===Vorschlag zur Korrektur mit Acrobat Pro:===
====MP 19-003 fehlende ID====
=====Acrobat Pro=====
*Markieren Sie im Text den Verweistext und wählen Sie in den Optionen (kleiner Pfeil in der Tag-Ansicht) „Tag in Auswahl suchen“.
*Über einen Rechtsklick auf den <Note> Tag in der Tag-Ansicht öffnen Sie die Eigenschaften und tragen Sie eine ID ein.

====MP 19-004 Eindeutigkeit====
Überprüfen Sie wie für 19-003, ob jede ID nur einmal vorhanden ist.

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

BITi 02.3.0 Inlinelevel Strukturelemente / Fuß- Endnoten und Verweise

2016-11-17T17:02:13Z

Petra: /* Beispiel 1: */

{{PDF_02_3_0}}

=== Was wird geprüft? ===

Inline Level Structure Elements (ILSE) müssen sich immer innerhalb eines Block Level Structure Elements (BLSE) befinden.

Fuß- und Endnoten gehören nicht zum Textfluss und müssen als solche eindeutig identifizierbar sein. Der Verweis muss für Nutzer assistiver Technologien durch ein eindeutiges Label verständlich sein.

Nicht vorhandene IDs in Note Tags werden nicht negativ bewertet, da sie keine Einschränkung der Barrierefreiheit bedeuten. Sind IDs vorhanden, müssen sie aber eindeutig sein und dürfen jeweils nur einmal verwendet werden.

==== Beispiel 1: ====

Verweis:

<P><br>
:Text vor dem Verweis<br>
:<Link><br>
::Link-OBJR<br>
::<Reference><br>
:::<Span><br>
::::1<br>
:Text nach dem Verweis

Fußnote:

<LI>

       <Lbl>

             1

       <LBody>

             <Note>

                    Der Verweistext

Da die Accessibility Schnittstelle von Acrobat <Link> und <Reference> Tags gleich behandelt, hören - bei dieser Lösung - Nutzer von Screenreadern in Acrobat im Verweis zweimal das Wort „Link“. In Anlehnung an den in 2017 kommenden PDF/UA Standard 2.0 ist daher folgende Lösung zu bevorzugen:

==== Beispiel 2: ====

Verweis:

<P>

      Text vor dem Verweis

      <Lbl>

            <Link>

                  1

                  Link - OBJR

Fußnote:

<Note>

      <Lbl>

            <Link>

                  1

                  Link-OBJR

      Der Verweistext

=== Warum wird das geprüft? ===

Da Fußnoten relevante Inhaltselemente eines Dokuments sind, ist es wichtig, dass auch blinde und sehbehinderte Anwender sie mit assistiven Technologien wahrnehmen können.

=== Wie wird geprüft? ===

<h4>Einordnung im PAC-Tool </h4>
PDF/UA → Logical structure → Structure elements → Notes →

* ID entry in Note structure elements
* Unique ID entries in Note structure elements

==== Prüfung ====

* PAC - Screenreader Preview
** Prüfen Sie ob Fußnoten Endnoten und Verweise richtig getaggt sind.
* PAC – Logical Structure
** Linke Seite: Reiter Structure Elements, rechte Seite Page View
*** Bewegen Sie sich auf der linken Seite solange durch den Tagbaum, bis Sie zu den <Note> Tags (eventuell auch durch eine Rollenzuordnung auf <Note> gemapptes Strukturelement) der Fußnoten kommen.
*Markieren Sie den Note-Tag auf der linken Seite und wechseln Sie auf der rechten Seite auf den Reiter Properties.
*Prüfen Sie, ob eine eindeutige ID angezeigt wird. <br>Sind keine IDs vorhanden, führt dies nicht zu einer negativen Beurteilung, da diese Forderung ab PDF/UA (voraussichtlich 2017) gestrichen wird.

===Vorschlag zur Korrektur mit Acrobat Pro:===
====MP 19-003 fehlende ID====
=====Acrobat Pro=====
*Markieren Sie im Text den Verweistext und wählen Sie in den Optionen (kleiner Pfeil in der Tag-Ansicht) „Tag in Auswahl suchen“.
*Über einen Rechtsklick auf den <Note> Tag in der Tag-Ansicht öffnen Sie die Eigenschaften und tragen Sie eine ID ein.

====MP 19-004 Eindeutigkeit====
Überprüfen Sie wie für 19-003, ob jede ID nur einmal vorhanden ist.

[[Prüfschritte|zurück zur Liste der Prüfschritte]]

6.04 - Erfolgskriterien für Spracheingabe

2016-11-11T23:38:02Z

Petra: Schützte „6.04 - Erfolgskriterien für Spracheingabe“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

=== Sammlung von Praxisbeobachtungen, auch durch Kommentare von Nutzern des Testverfahrens. ===

5.02.2 - Bei vergrößerter Darstellung Layout anpassen

2016-11-11T23:37:40Z

Petra: Schützte „5.02.2 - Bei vergrößerter Darstellung Layout anpassen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Bei Schriftvergrößerung auf 200% passt sich das Layout an, so dass der Leser nicht horizontal scrollen muss, um einen Informationsblock im Anwendungsfenster zu lesen.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Menüzeilen brechen bei Schriftvergrößerung am Rande des Anwendungsfensters um und werden zwei- oder mehrzeilig.

Informationsblöcke, die zuvor nebeneinander standen, werden nach Schriftvergrößerung untereinander dargestellt.

Die Größe von Dialogboxen passt sich bei Schriftvergrößerung an, um den gesamten vergrößerten Inhalt anzeigen zu können.

Tabellen passen bei Schriftvergrößerung die Spaltenbreite an und brechen die Zellinhalte neu um, so dass sie in die Breite des Anwendungsfensters passen.

Breite Tabellen können konfiguriert werden, so dass der Benutzer auswählen kann, welche Spalten er sehen will.

Ein Textverarbeitungsprogramm enthält einen „Entwurfsmodus“, der den gesamten Text des Dokumentes in einer einzigen, vom Benutzer auswählbaren Schriftgröße anzeigt, ohne Rücksicht auf die im Dokument festgelegten Formatierungsangaben. In diesem Modus wird der Text auf Bildschirmbreite umgebrochen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Ein Text oder ein Datenblock ist nur schwer lesbar, wenn er den sichtbaren Bildausschnitt überragt und der Benutzer hin- und herscrollen muss, um den Inhalt vollständig zu erfassen. Wenn Bedienelemente außerhalb des sichtbaren Bildausschnittes angeordnet sind, werden sie von kognitiv beeinträchtigten Benutzern leicht übersehen. Daher soll die Software soweit möglich bei Schriftvergrößerung das Layout anpassen.

Diese Anforderung unterstützt auch Benutzer von Vergrößerungssoftware, die so die Vergrößerung der Anwendung zusätzlich nutzen können. Denn je kleiner der Zoomfaktor in der Vergrößerungssoftware, desto größer die Übersicht über die Anwendung. Wenn jedoch die Anwendung bei Vergrößerung einen waagerechten Rollbalken zeigt, müsste der Benutzer zwei Bildausschnitte steuern, was den gewünschten Effekt zunichte macht.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Sichtprüfung im Anschluss an den Prüfschritt 5.01.1 „Schriftvergrößerung auf 200%“. Bei waagerechten Rollbalken ist zu überprüfen, ob es sich um einen überbreiten Inhalt handelt, dessen Layout nicht angepasst werden kann.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

Wenn überbreite Inhalte (Tabellen, Bilder) gescrollt werden müssen, so ist dies kein Mangel.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

*

==== WCAG ====

1.4.8 Visuelle Präsentation

==== WCAG-Techniques ====

==== ISO9241-171 ====

10.3.3 Bei Änderung der Schriftgröße den Maßstab und das Layout von Benutzungsschnittstellen-Elementen im Verhältnis anpassen

10.5.8 Erneute Einstellung der Fenstergröße ermöglichen

4.12.2 - Zusätzliche Wartezeiten vermeiden

2016-11-11T23:37:10Z

Petra: Schützte „4.12.2 - Zusätzliche Wartezeiten vermeiden“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Die Reaktionszeit des Systems ist im Vergleich mit der Sichtprüfung nicht störend verlängert.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Nach Installation und Inbetriebnahme einer Vergrößerungs-Software kann in einer Textverarbeitung nur noch verzögert Text eingegeben werden. Nach jedem Tastendruck müssen Nutzer mehrere Sekunden warten, bis der gedrückte Buchstabe auf dem Bildschirm erscheint.

Screenreader-Nutzer warten im Vergleich zu Nutzern ohne Hilfsmittel ungewöhnlich lange auf das Erscheinen der Hilfe-Funktion nach Druck auf die Taste F1.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Die unmittelbare Reaktion des Systems auf Benutzereingaben ist eine Anforderung der allgemeinen Software-Ergonomie, die für flüssiges Arbeiten vorausgesetzt wird. Für Antwortzeiten bei Dialogen gilt die Faustregel, dass Reaktionszeiten ab ca. 2 sec vom Benutzer als „Warten“ bemerkt werden, wobei ab ca. 4 sec eine Störung vermutet wird, wenn das System nicht explizit eine Wartezeit meldet.

Die Toleranz des Benutzers gegenüber Wartezeiten und allgemeiner Trägheit des Systems ist kontextabhängig. Im Rahmen dieses Prüfschritts geht es darum, dass das Reaktionsverhalten des Systems durch den Einsatz des Screenreaders nicht störend verlängert werden darf. Dies ist auch eine Qualität der Anwendung, denn wenn die Anwendung sehr viel ggf. ungefilterte Information an die Accessibility-Schnittstelle sendet, hat der Screenreader unnötig viel Arbeit.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Die Beurteilung richtet sich nach der subjektiven Wahrnehmung des Testers: Die Reaktion auf Benutzereingaben bzw. die Anzeige von eingegebenem Text ist nicht störend verzögert.

Bei der Installation des Testsystems darauf achten, dass keine Hintergrundprogramme wie Virenscanner etc. installiert sind, die die Rechnerkapazität unnötig beanspruchen.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Die Beurteilung nach der subjektiven Wahrnehmung des Testers erscheint unbefriedigend, ist aber nach bisheriger Diskussion noch das praktikabelste Verfahren. Bisher bekannte Messtechniken sind unausgereift. Beispiele: Akustisches Tracking vom Tastendruck bis zur Screenreader-Ausgabe ist ungenau, da das Messen selber Zeit bzw. Rechnerkapazität braucht und das Ergebnis verfälscht. Auswertung von Log-Dateien: Zeit zwischen Fokuswechseln zu berechnen ist ungeeignet, denn die Anzeige erfolgt erst danach.

=== Referenzen ===

==== EN301549 ====

WCAG

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.5.8 Der unterstützenden Technik den Zugriff auf Ressourcen ermöglichen

==== Sonstige ====

9241-112 Grundsätze der Informationsdarstellung, Abschnitt 6.1.3 Empfehlungen in Bezug auf die zeitliche Darstellung der Information

4.10.2 - Zusätzliche kontextsensitive Hilfe

2016-11-11T23:36:55Z

Petra: Schützte „4.10.2 - Zusätzliche kontextsensitive Hilfe“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Der Screenreader gibt Bedienoptionen und Tastaturkommandos aus, die in der aktuellen Programmsituation zur Verfügung stehen.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Nach Drücken der Alt-Taste können die Ausklappmenüs der Anwendung genutzt werden. Die Tastaturkommandos für den jeweiligen Befehl stehen rechtsbündig hinter der jeweiligen Menüauswahl. Der Screenreader liest den ausgewählten Punkt wie auch das dazu gehörende Tastaturkommando vor.

Die Multifunktionsleiste der Textverarbeitung wird angesteuert und einzelne Bediensymbole werden mit dem Screenreader fokussiert. Der Hilfetext, der bei Mausnutzung unterhalb des Symbols erscheint, wird vollständig ausgegeben.

Ein Ausklappmenü kann mit einer bestimmten Tastenkombination geöffnet und mit den Pfeiltasten navigiert werden. Die Eingabe kann mit Enter bestätigt werden. Die Vorgehensweise wird präzise von der Screenreader-Ausgabe beschrieben, sobald das Element den Fokus erhalt.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschirtt ist anwendbar, wenn eine Anwendung Bedienelemente enthält.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Die sequenzielle Eingabelogik von Screenreadern über die Tastatur ist bei manchen Bedienelementen nicht mit einer einzigen Tastenkombination zu bewerkstelligen. Ohne kontextsensitive Hilfe kann in solchen Situationen oft nicht weitergearbeitet werden.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests}''

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11.3.2.5 Object Information

Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the user interface elements' role, state(s), boundary, name, and description programmatically determinable by assistive technologies.

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

4.05.2 - Eindeutige Namen

2016-11-11T23:36:31Z

Petra: Schützte „4.05.2 - Eindeutige Namen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Der Name identifiziert das Element und ist eindeutig. Wenn innerhalb eines Kontextes mehrere gleichartige Elemente vorkommen, sollte der Name durch die Umgebung unterscheidbar sein, oder es wird ein unterscheidendes Merkmal hinzugefügt.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Ein Formular ist in mehrere Abschnitte unterteilt, die jeweils durch einen Edit-Button für die Bearbeitung aktiviert werden. Der Screenreader sagt den Namen des Buttons an und kann mit einem Bedienschritt die Überschrift des Abschnitts ausgeben.

In einer Anwendung symbolisiert ein Fragezeichen in einem Kreis die kontextsensitive Hilfe zu bestimmten Bereichen. In der Beschreibung des Buttons (und damit im Tooltipp) wird jeweils das Hilfethema genannt.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Screenreadernutzer lesen jedes Bedienelement einzeln und sind auf den Namen des Elements angewiesen, um seinen Zweck zu erkennen. Daher sollten die Namen der Elemente innerhalb eines Kontextes eindeutig sein. Wenn eine Bezeichnung mehrfach vorkommt, sollte ein Unterscheidungsmerkmal hinzugefügt werden, oder die erforderlichen Zusatzinformationen sollten aus dem Kontext einfach zu beschaffen sein.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Feststellen, ob mehrere gleich benannte Elemente vorkommen. Element im Screenreader aktivieren und feststellen, ob der Name des Elements eindeutig angesagt wird. Falls dies nicht der Fall ist, überprüfen, ob eine Zusatzinformation mit einem Bedienschritt ermittelt werden kann.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Barriere oder eine Einschränkung, je nachdem wie aufwändig es ist, notwendige Zusatzinformationen zu ermitteln.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Der Prüfschritt basiert auf ISO 9241-171 8.1.3 „Innerhalb des Kontextes eindeutige Namen vorsehen“ und ist daher in Konformitätsstufe II eingeordnet. Eine Teilmenge des Prüfumfangs könnte aufgrund von EN 301549 11. 2.1.23 „Link purpose (in context)“ in Konformitätsstufe I eingeordnet werden. Hierbei handelt es sich um Links i.e.S. und ausdrücklich nicht um Buttons und sonstige Bedienelemente. Da Links in Anwendungssoftware relativ marginal sind, wurde auf einen entsprechenden Prüfschritt verzichtet.

=== Referenzen ===

==== EN301549 ====

11. 2.1.23 Link purpose (in context)

==== WCAG ====

2.4.4 Linkzweck (im Kontext)

2.4.9 Linkzweck (reiner Link)

==== WCAG-Techniques ====

==== BITV-Test ====

==== 2.4.4.a Aussagekräftige Linktexte ====

==== ISO9241-171 ====

8.1.3 Innerhalb des Kontextes eindeutige Namen vorsehen

3.12.2 - Kontextsensitive Hilfe für Tastaturbefehle

2016-11-11T23:36:11Z

Petra: Schützte „3.12.2 - Kontextsensitive Hilfe für Tastaturbefehle“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Tastaturbefehle sind in der Bedienoberfläche der Anwendung direkt bei den Elementen angezeigt, auf die sie sich beziehen, oder sie sind mit der Tastatur abrufbar.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

In Menüs werden die Tastaturbefehle zum Aufruf der Funktionen direkt neben dem Menübefehl angezeigt.

Bei ALT werden die als Tastenkürzel verwendeten Buchstaben in den Beschriftungen von Bedienelementen unterstrichen.

Bei ALT werden die als Tastenkürzel verwendeten Buchstaben neben den Bedienelementen angezeigt.

Bei Buttons sind die Tastaturbefehle zum Aufruf der Funktion im Kontextmenü vermerkt und mit der Tastatur abrufbar.

Fehler: Bei Buttons sind die Tastaturbefehle zum Aufruf der Funktion im Tooltipp vermerkt und werden bei Mausberührung angezeigt.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Für alle Benutzer ist es umständlich, Informationen zur Bedienung einer Software in der Dokumentation nachzuschlagen, dies gilt insbesondere für Menschen mit Behinderungen, die aus verschiedenen Gründen bei der Nutzung von Dokumenten eingeschränkt sind. Eine kontextsensitive Hilfe ist daher für Menschen mit Behinderungen besonders wichtig. Besonders wenn Nutzer auf die Tastatur angewiesen sind, benötigen sie eine kontextsensitive Hilfe für selten gebrauchte Tastaturbefehle, um die Anwendung effizient bedienen zu können.

Damit die kontextsensitive Hilfe den Tastaturnutzern zur Verfügung steht, genügt es nicht, wenn bei Mausberührung ein Tooltipp mit dem Tastaturbefehl erscheint, oder wenn der Tastaturbefehl vom Screenreader ausgegeben wird. Ein motorisch behinderter Benutzer, der auf die Tastatur angewiesen ist, muss die Information mit einem [[C:/Users/Brigitte/Documents/BIT/BIT%20inklusiv/pruefkatalog_lieferung/Glossar.docx#Tastaturbefehl|Tastaturbefehl]] abrufen können.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Sichtprüfung, Erprobung.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

*

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

9.3.11 Implizite oder explizite Bezeichner zur Verfügung stellen

3.10.2 - Tastaturkonventionen der Plattform befolgen

2016-11-11T23:35:43Z

Petra: Schützte „3.10.2 - Tastaturkonventionen der Plattform befolgen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Die Software sollte die von der betreffenden Plattformsoftware festgelegten Tastaturzugriffskonventionen befolgen. Die Plattformkonventionen schließen üblicherweise die Zuweisung von impliziten Bezeichnern, Funktionstasten und Beschleunigungs-Tasten ein. Tastaturkonventionen können vom Betriebssystem oder von einer separaten Schicht der grafischen Benutzungsschnittstelle festgelegt werden.

Dies schließt die Festlegung weiterer Tastenkürzel und Verfahren zusätzlich zu denen, die zu den Plattformkonventionen gehören, nicht aus.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Eine Anwendung befolgt die Systemkonventionen, die besagen, dass die „Alt“-Taste, wenn sie gedrückt gehalten wird, dazu dient, die Verwendung von impliziten Bezeichnern anzuzeigen, und dass sie zur Aktivierung des Anwendungshauptmenüs dient, wenn sie gedrückt und dann losgelassen wird.

Eine Anwendung benutzt zum Schließen ihrer kundenspezifischen Dialog- und Meldungsfelder die „Esc“-Taste, weil dies der vom Betriebssystem festgelegten Konvention entspricht.

Eine Anwendung vermeidet es, die vom Betriebssystem zum Aktivieren der Tastaturmaus-Funktion verwendete Tastenkombination erneut zuzuweisen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Durch die Einhaltung der Tastaturkonventionen wird die Gebrauchstauglichkeit neuer Anwendungen verbessert. Dies ist besonders wichtig für Menschen, die nur die Tastatur benutzen können oder kognitive Behinderungen haben.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Sichtprüfung, praktische Erprobung.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

*

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

9.3.15 Die Tastaturkonventionen der Plattform befolgen

==== Bit-Inklusiv-Synopse ====

==== Sonstige ====

Microsoft Windows Keyboard Design Guide

https://www.microsoft.com/enable/products/keyboard.aspx

3.09.2 - Effiziente Tastatursteuerung

2016-11-11T23:35:20Z

Petra: Schützte „3.09.2 - Effiziente Tastatursteuerung“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Die Anzahl der für jede Arbeitsaufgabe erforderlichen Schritte optimieren.

* Die Software stellt Shortcuts für häufig gebrauchte Funktionen zur Verfügung.
* Kurztasten für Menüpunkte, die unterstrichen angezeigt werden
* Navigieren durch lange Listen erleichtern
* Die Software stellt für alle Funktionen wenigstens zwei verschiedene Bedienwege zur Verfügung.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Der Benutzer kann „Strg-C“ eingeben, um zu kopieren, „Strg-V“, um einzufügen, oder „Strg-P“, um auszudrucken.

Der Benutzer drückt die „Pos 1“-Taste, um zum ersten Element in einer Liste zu gelangen, und die „Ende“-Taste, um zum letzten Element in der Liste zu gelangen, und er verwendet „Bild auf“ und „Bild ab“, um innerhalb der momentan sichtbaren Objekte vorwärts und rückwärts zu gehen.

In einer Liste gibt der Benutzer ein oder mehrere Zeichen ein, um zum nächsten Objekt zu gelangen, das mit diesen Zeichen beginnt.

Die Druckfunktion kann sowohl aus dem Menü als auch mit dem Shortcut „Strg+p“ aufgerufen werden.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Bei der Gestaltung der Software sollte die Anzahl der Schritte optimiert werden, die der Benutzer für eine gegebene Arbeitsaufgabe durchführen muss. Diese Regel wird zumeist nur für die Bedienung mit Zeigegeräten befolgt. Für Menschen, die auf die Tastatur angewiesen sind, ist eine effiziente Bedienung ebenso wichtig,

Effiziente Tastatursteuerung ist besonders wichtig für Benutzer, die langsam eingeben, nur über eine Tastatur interagieren oder die Tastaturemulatoren, wie z. B. Spracherkennungssysteme, verwenden. Behinderte Benutzer profitieren davon, weil sie die Anzahl zeitraubender Schritte verringern können, die anderenfalls erforderlich wären.

Verschiedene Bedienwege erleichtern es Benutzern, ihren an die Arbeitsaufgabe angepassten persönlichen Arbeitsstil zu entwickeln. Hierarchisch aufgebaute Funktionsmenüs sind wichtig, um alle Funktionen der Anwendung systematisch zu präsentieren. Zusätzlich werden Tastenkombinationen für häufig verwendete Funktionen benötigt. Eine Software, die sich allein auf Tastenkombinationen verlässt, wäre nicht effizient bedienbar, denn ein Benutzer kann nicht alle Tastenkombinationen im Kopf haben. Kontextmenüs helfen situativ mit einem ausgewählten Funktionsangebot.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Die für die aktuelle Situation des Szenarios einzusetzenden Tastaturbefehle ermitteln, über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Stichprobenartige praktische Erprobung: Stehen für alle Arbeitsschritte effiziente Tastaturmethoden zur Verfügung?

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

*

==== WCAG ====

2.4.5 Verschiedene Methoden

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.4.2 Die Anzahl der für jede Arbeitsaufgabe erforderlichen Schritte optimieren

9.3.10 Beschleunigungs-Tasten zur Verfügung stellen

9.3.16 Das Navigieren durch lange Listen und Menüs erleichtern

3.05.2 - Tastaturbedienung für alle Anzeigen

2016-11-11T23:34:43Z

Petra: Schützte „3.05.2 - Tastaturbedienung für alle Anzeigen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Anzeigen können mit der Tastatur bedient werden, um Text daraus zu kopieren.

Anzeigen sind Statusanzeigen, Anweisungen, Meldungen etc., die eine rein informative Funktion haben, ebenso nicht editierbare Daten.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Eine Anwendung zeigt Systemmeldungen mit Fehlercodes in der Statuszeile an. Um den Fehlercode zu kopieren, kann die Statuszeile mit F6 fokussiert, der Inhalt mit strg+a markiert und mit strg+c in die Zwischenablage kopiert werden.

Ein Buchhaltungsprogramm zieht den Banknamen der Kontoverbindungen aus einem internen Verzeichnis und zeigt ihn in der Liste der Kreditoren an, die nicht editierbar ist. Die einzelnen Listenelemente können mit Tastaturbefehlen selektiert und kopiert werden.

Die Anwendung nimmt Anzeigen in die TAB-Reihe auf, oder sie bietet spezielle Tastaturbefehle für die Fokussierung von Anzeigen an.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Aufgabenrelevante Anzeigen sollen mit der Tastatur fokussierbar sein, um Informationen daraus für die Verwendung an anderer Stelle in die Zwischenablage kopieren zu können. Dies erspart Menschen mit Behinderungen das mühsame und fehleranfällige Abschreiben der Informationen. Darüber hinaus können Nutzer von Screenreadern die Inhalte fokussierbarer Anzeigen leichter adressieren und lesen, ohne hierzu spezifische Screenreaderbefehle kennen zu müssen.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Tastaturbefehle für die Selektion der in der Arbeitsaufgabe benötigten Anzeigen ermitteln, über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Praktische Erprobung: Mit Tastaturbefehlen Text aus Anzeigen kopieren.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

Anzeigen, die Mausbedienbar sind, werden im Prüfschritt 3.04.1 „Tastaturbedienung für Anzeigen (wie Mausbedienung)“ geprüft.

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.4.7 Unterstützung der Funktion „Kopieren“ in nicht editierbarem Text

3.02.2 - Name von grafischen Bedienelementen abrufen

2016-11-11T23:34:06Z

Petra: Schützte „3.02.2 - Name von grafischen Bedienelementen abrufen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Der [https://www.biti-test.de/intern/pruefplaene/Glossar.docx#Name Name] von grafischen Bedienelementen kann durch Maus- und Tastaturbedienung angezeigt werden. Die Anforderung bezieht sich auf grafische Elemente, die nicht zum Betriebssystemstandard gehören und keine [https://www.biti-test.de/intern/pruefplaene/glossar.docx#Beschriftung Beschriftung] haben.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Die Elemente in einer Symbolleiste haben jeweils ein Kontextmenü, das den Namen des Elements enthält. Das Kontextmenü kann entsprechend dem Windows-Standard mit der rechten Maustaste und mit der Funktionstaste F10 abgerufen werden.

Die Funktion „Drucken“ wird durch ein Icon in Form eines Druckers dargestellt. Bei Mausberührung erscheint ein Tooltipp mit dem Namen „Drucken“. Zusätzlich kann der Name durch einen Tastaturbefehl abgerufen werden.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist anwendbar, wenn die Software grafische Bedienelemente enthält.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Die Symbole auf grafischen Bedienelementen sind nicht für alle Benutzer selbsterklärend. Bevor ein Benutzer ein Bedienelement auslöst, muss er überprüfen können, ob sich hinter dem Symbol die vermutete Funktion verbirgt. Wenn der Benutzer eine Erläuterung zum Element in der Dokumentation nachschlagen will, benötigt er ebenfalls den Namen des Elements.

Diese Information muss jedem Benutzer zur Verfügung stehen, unabhängig von dem verwendeten Bediengerät. Daher genügt es nicht, wenn bei Mausberührung ein Tooltipp mit dem Namen des Elements erscheint, oder wenn der Name vom Screenreader ausgegeben wird. Ein motorisch behinderter Benutzer, der auf die Tastatur angewiesen ist, muss die Information mit einem [https://www.biti-test.de/intern/pruefplaene/Glossar.docx#Tastaturbefehl Tastaturbefehl] abrufen können.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Ermitteln Sie das Tastaturkommando zur Anzeige von Namen anhand der Dokumentation.

Praktische Erprobung: Werden die Namen der grafischen Bedienelemente durch eine Mausaktion (Hover, rechte Maustaste) und ebenso durch eine Tastaturaktion (F10, sonstige) am Bildschirm angezeigt?

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Der Prüfschritt könnte aufgeteilt werden, Maus und Tastaturbedienung könnten separat untersucht werden. Das wäre interessant, die Auswertung nach Modalitäten / nach Art der Behinderung eingeführt werden sollte.

=== Referenzen ===

==== EN301549 ====

==== WCAG ====

3.3.5 Kontextsensitive Hilfe

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.1.5 Anzeige von Namen

==== BITV-Test ====

2.4.6a Title-Attribut für Symbole

2.10 - Erfolgskriterien für Touch-Bedienung

2016-11-11T23:33:42Z

Petra: Schützte „2.10 - Erfolgskriterien für Touch-Bedienung“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

Sammlung von Praxisbeobachtungen, auch durch Kommentare von Nutzern des Testverfahrens.

Prüfverfahren Anwendungssoftware

2016-11-11T23:31:21Z

Petra: Schützte „Prüfverfahren Anwendungssoftware, Auswahl Stufen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

*[[Prüfverfahren Anwendungssoftware Stufe 0]]
*[[Prüfverfahren Anwendungssoftware Stufe I]]
*[[Prüfverfahren Anwendungssoftware Stufe II]]

7.04.1 - Tastaturbedienung im Screenreader

2016-11-11T23:29:24Z

Petra: Schützte „7.04.1 - Tastaturbedienung im Screenreader“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Die Tastaturfunktionen der Anwendung funktionieren weiterhin, wenn ein Screenreader aktiv ist. Konflikte zwischen Tastaturbedienung und Screenreader sind in der Dokumentation aufgeführt, ein alternativer Bedienweg wird aufgezeigt.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Bedienelemente können weiterhin mit TAB oder Pfeiltasten fokussiert und mit EINGABE oder LEER ausgelöst werden.

Tastaturfunktionen zur Bewegung in Daten und zur Selektion von Daten funktionieren weiterhin.

Die Windows-Standardfunktion STRG+LEER zum Ab- und Hinzuwählen von Daten aus einer Liste, falls in der Anwendung verwendet, funktioniert weiterhin.

Shortcuts der Anwendung funktionieren weiterhin. Bei Konflikten mit den Shortcuts des Screenreaders greift das „Tastatur durchreichen“-Kommando des Screenreaders.

Die Windows-Standardfunktionen F3 (Suchen) bzw. F4 (Suche wiederholen), falls in der Anwendung verwendet, funktionieren weiterhin.

Die Windows-Standardfunktionen STRG+c (Kopieren), STRG+v (Einfügen), STRG+z (Rückgängig), falls in der Anwendung verwendet, funktionieren weiterhin.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Hilfstechnik für Menschen mit Behinderungen soll störungsfrei in das Computersystem eingebunden werden. Screenreader übernehmen i.d.R. die Kontrolle über die Tastatur, um eine erweiterte Tastatursteuerung, z.B. zur Bewegung in Tabellen, anbieten zu können. Die Tastaturbefehle der Anwendung werden vom Screenreader normalerweise unverändert durchgereicht. Wenn nach Zuschaltung des Screenreaders Probleme mit einzelnen Tastaturfunktionen der Anwendung auftreten, so ist dies ein Indiz dafür, dass Programmierstandards des Betriebssystems nicht beachtet wurden. Die Software muss die Kompatibilität mit unterstützender Technik sicherstellen. Hierzu gehört, dass bestehende Konflikte dokumentiert und alternative Bedienwege angeboten werden.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests}''

Schalten Sie den Screenreader ein. Wiederholen Sie stichprobenartig einzelne Elemente aus den Prüfschritten des Abschnitts „Tastaturbedienung“. Beachten Sie besonders die im Abschnitt „Beispiele“ aufgeführten Tastaturfunktionen. Beachten Sie besonders solche UI-Elemente, die in ihrem Aussehen vom [https://www.biti-test.de/intern/pruefplaene/pruefplan-details-vollstaendig.xhtml?pp=8#Betriebssystem-Standards Betriebssystem-Standard] abweichen. Beachten Sie besonders solche Arbeitsschritte, in denen ein Wechsel zwischen Bedienoberfläche und Datenbereich (Moduswechsel des Screenreaders) stattfindet.

Bei Ausfällen stellen Sie fest, ob in der Dokumentation darauf hingewiesen wird, und ob ein alternativer Bedienweg aufgezeigt wird.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Blockade/ Barriere/Einschränkung: Ausfälle in der Tastaturbedienung sind nicht dokumentiert, Bewertung nach der Bedeutung des ausfallenden Elements für die Arbeitsaufgabe.

Bei Ausfällen in der Tastaturbedienung, die dokumentiert sind und für die eine mit Screenreader bedienbare Alternative besteht, gilt der Prüfschritt als erfüllt.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Welche Komponente für eine Störung der Tastaturbedienung verantwortlich ist – der Screenreader oder die Anwendung – kann im Rahmen dieser Prüfung nicht zweifelsfrei festgestellt werden. Sofern die Störung durch eine Veränderung in den Funktionen des Screenreaders zu beheben wäre, hat der Software-Hersteller seine Verantwortung durch die Dokumentation der Störung und Bereitstellung eines alternativen Bedienweges erfüllt.

=== Referenzen ===

==== EN 301549 ====

11. 2.1.15 Keyboard

11.3.2.14 Modification of focus and selection attributes

==== WCAG ====

2.1.1 Tastatur

Konformitätsbedingung 5: Nicht störend

==== WCAG-Techniques ====

==== ISO 9241-171 ====

8.5.5 Der unterstützenden Technik die Änderung von Fokus und Auswahl ermöglichen

7.03.1 - Text als Text codieren

2016-11-11T23:28:57Z

Petra: Schützte „7.03.1 - Text als Text codieren“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Text soll mit den Systemroutinen des Betriebssystems als Text und nicht als Bild erzeugt werden. Text kann visuell angepasst werden und ist ohne Transformation (OCR) programmatisch zugänglich.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Texte werden bei Vergrößerung auf 200% mit scharfen Konturen dargestellt.

Eine Button-Beschriftung wird im Kontrastmodus mit angepassten Farben dargestellt.

Texte werden vom Screenreader vorgelesen, ohne dass OCR hinzugeschaltet werden muss.

Eine Bildunterschrift, die im Bild dargestellt ist, wird vom Screenreader vorgelesen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist nicht anwendbar auf Fälle, in denen eine bestimmte visuelle Präsentation von Text für die vermittelte Information unentbehrlich ist, wie z.B. ein Logo (Wortbildmarke) oder die Darstellung bestimmter Schriftarten.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Text soll als Text und nicht als Bild erzeugt werden, damit die Darstellung an die Bedürfnisse von Menschen mit Behinderungen angepasst werden kann, und damit assistive Technologien uneingeschränkt darauf zugreifen können. Es genügt nicht, wenn auf die Verfügbarkeit von OCR-fähigen assistiven Technologien hingewiesen wird, denn zum einen ist die Transformation durch OCR fehleranfällig, und zum anderen wird hierdurch nur ein Teil der Anforderungen erfüllt. Solange die visuelle Anpassung von Bildern technisch eng begrenzt ist, soll Text nicht als Bild erzeugt werden.

Diese Anforderung wird verletzt u.a. von Programmiersprachen, die unter Umgehung der Betriebssystemroutinen direkt in den Bildschirmspeicher schreiben. Weiterhin kommt die Verwendung von Schriftgrafiken in Webanwendungen vor, um einen bestimmten optischen Effekt zu erzielen. Dies ist nur akzeptabel, wenn die visuelle Darstellung für die vermittelte Information unentbehrlich ist, wie z.B. bei einem Logo.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Der Prüfschritt betrifft alle im Szenario vorkommenden Texte: Beschriftungen, Anweisungen, Meldungen, Hilfetexte und Daten, nicht aber Logos (Wortbildmarken) und Abbildungen von Schrift.

Sichten Sie erneut diejenigen Elemente, die in folgenden vorangegangenen Prüfschritten aufgefallen sind:

* 4.01.0 Wiedergabe von Text
* 5.01.1 Schriftvergrößerung auf 200%
* 5.03.1 Kontrastmodus ist nutzbar
* 7.02.1 Objektinformationen für Hilfstechniken verfügbar machen

Bei textbasierten Anwendungen: Der Prüfschritt ist nicht erfüllt, wenn im Quelltext (HTML/CSS/Javascript) anstelle des bemängelten Textes eine Bilddatei in einem Rasterformat (JPG, GIF, PNG etc.) referenziert ist.

Bei kompilierten Anwendungen: Der Prüfschritt ist nicht erfüllt, wenn wenigstens 2 der folgenden Mängel vorliegen:

* Im Screenreader wird der Text nicht vorgelesen.
* Bei Vergrößerung auf 200% sind die Konturen der Schriftzeichen pixelig oder verschwommen.
* Im Windows Kontrastmodus passen sich die Farben nicht an.
* Die Accessibility-Schnittstelle enthält nicht den angezeigten Text.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Der Standard beschreibt die Eigenschaften von Rastergrafiken. XML-basierte Vektorgrafiken (SVG) verfügen im Prinzip über die geforderte Anpassbarkeit und Zugänglichkeit, allerdings liegen noch keine ausreichenden Daten über das Verhalten im Zusammenspiel mit verschiedenen Anzeigetechniken vor. Daher werden Vektorgrafiken bzw. SVG-Dateien in diesem Prüfschritt nicht behandelt.

Bei kompilierten Anwendungen kann nur indirekt auf die Verwendung von Schriftgrafiken geschlossen werden, wobei die einzelnen Indizien nicht eindeutig sind, da die beschriebenen Effekte entweder auch auf andere Weise erzielt werden können, oder durch Anpassungen ausgeglichen werden können. Daher lässt sich nur aus der Kumulation von Indizien ein Rückschluss auf die Verwendung von Schriftgrafiken treffen. Zu diskutieren wäre, ob der Prüfschritt für kompilierte Anwendungen ausgesetzt werden sollte.

Die Bewertung von Mängeln als Einschränkung ist eine Kompromisslösung: Es stellt sich die Frage, ob dieser Prüfschritt überhaupt bewertet werden soll, oder ob er rein informativ gelten soll. Für eine Bewertung spricht, dass die Verwendung von Schriftgrafiken an sich ein Regelverstoß ist, weil sie eine Anpassung für Menschen mit Behinderungen nicht oder nur mit großem Aufwand ermöglicht. Gegen eine Bewertung spricht, dass bereits in anderen Prüfschritten wegen der Auswirkungen der Schriftgrafik ein Mangel festgestellt und differenziert bewertet wird.

=== Referenzen ===

==== EN301549 ====

11. 2.1.14 Images of text

==== WCAG ====

1.4.5 Bilder eines Textes

==== WCAG-Techniques ====

==== - ====

==== ISO9241-171 ====

7.02.1 - Objektinformationen für Hilfstechniken verfügbar machen

2016-11-11T17:38:01Z

Petra: Schützte „7.02.1 - Objektinformationen für Hilfstechniken verfügbar machen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Objektinformationen zu Bedienelementen und Anzeigen werden über die Accessibility-Schnittstelle des Betriebssystems für Hilfstechniken verfügbar gemacht.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Windows bietet die Schnittstellen MSAA (Microsoft Active Accessibility) und UIA (User Interface Automation) für die Kommunikation mit unterstützender Technik an. Weitere bekannte Accessibility-Schnittstellen sind IAccessible2 und Java Access Bridge. Die Anwendung stellt in einer dieser Schnittstellen u.a. die folgenden Objektinformationen bereit:

* Name des Elements. Beispiel: der Name eines grafischen Buttons lautet „Kontakt“.
* Rolle bzw. Funktion des Elements. Beispiel: ein Button hat die Rolle „Button“ oder „Schaltfläche“.
* Wert des Elements. Beispiele: Der angezeigte Inhalt eines Textfeldes lautet „Hochofenstraße“. Der Zustand einer Statusanzeige lautet „Internetzugriff hergestellt“.
* Informationen zum Status des Bedienelements wie „verfügbar“, „markiert“, „fokussiert“.
* Label-Beziehungen, d.h. ein Element wird durch den Wert eines benachbarten Elements benannt. Beispiel: Ein Eingabefeld hat keinen Namen, aber der benachbarte Text „Straße“ ist als Label für das Eingabefeld gekennzeichnet.
* Informationen zur Einordnung des Elements in die Objekthierarchie der Anwendung: Eltern-, Geschwister- und Kind-Elemente.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Die Bereitstellung von Objektinformationen über eine standardisierte Schnittstelle ermöglicht die Kompatibilität mit assistierenden Techniken wie Screenreader, Vergrößerungssoftware und Spracheingabesoftware, die von Menschen mit Behinderungen benutzt werden. Anwendungselemente, die mit Standardroutinen des Betriebssystems erzeugt wurden, übermitteln ihre Objektinformationen defaultmäßig an die Accessibility-Schnittstelle. Sie benötigen ggf. noch einen Namen, um ausreichend deklariert zu sein. Dagegen müssen neuartige oder individuell entwickelte Elemente mit allen Merkmalen gegenüber der Accessibility-Schnittstelle deklariert werden. Wenn dies nicht geschieht, müssen die Hersteller von Hilfstechniken die Objektinformationen aus anderen Quellen erschließen, wie etwa dem DOM (Document Object Model) der Anwendung oder den Ein-/Ausgaberoutinen des Betriebssystems, was sehr aufwändig ist und nicht immer gelingt. Je vollständiger eine Anwendung die Accessibility-Schnittstelle informiert, desto einfacher kann sie für die Benutzung mit assistiven Technologien verfügbar gemacht werden.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Stellen Sie zunächst fest, ob die Anwendung mit JAVA programmiert ist oder die Schnittstelle IAccessible2 verwendet (siehe Herstellerfragebogen und Technische Prüfung). Für solche Anwendungen ist diese Prüfanleitung nicht geeignet. Für alle anderen Anwendungen gilt das Folgende:

Verwenden Sie das Tool Inspect (siehe Werkzeugliste), um zu überprüfen, ob die Anwendung ausreichende Objektinformationen an die Accessibility-Schnittstelle übergibt.

Untersuchen Sie diejenigen Bedienelemente und Anzeigen, die in der bisherigen Prüfung auffällig geworden sind, und zusätzlich für jeden Arbeitsschritt des Szenarios 2 weitere, zufällig gewählte UI-Elemente.

Öffnen Sie inspect.exe. Unter „Options“ aktivieren Sie mindestens die folgenden Einstellungen:

* UI Automation Mode – umfasst auch MSAA, hier als „Legacy“-Properties benannt
* Raw View
* SPI_SCREENREADER Flag
* Show Highlight Rectangle
* Watch Focus
* Watch Cursor
* Show Tree

Es gibt auch die Möglichkeit, sich wichtige Elemente direkt am zu prüfenden Element als Tooltipp anzeigen zu lassen. Darauf wird an dieser Stelle jedoch nicht eingegangen.

Zum Prüfen bewegen Sie den Mauszeiger oder den Tastaturfokus zum zu untersuchenden Element, oder wählen Sie das Element im Inspect-Tree aus. Stellen Sie zunächst fest, ob das Element einfach oder zusammengesetzt ist. Bei zusammengesetzten Elementen führen Sie die Untersuchung für jedes Einzelteil durch. Bei Unstimmigkeiten überprüfen Sie auch, ob das Element im fokussierten Zustand andere Properties hat als im nicht fokussierten Zustand.

Sobald sich ein Rahmen um das zu untersuchende Element gebildet hat, drücken Sie die Tastenkombination STRG+SHIFT+4, damit die Ergebnisliste der Property-Werte in die Zwischenablage kopiert wird. Zum Lesen fügen Sie den Inhalt der Zwischenablage in einen Editor ein. Dieses Vorgehen ist etwas umständlich, hilft aber gegen Instabilitäten im Umgang mit Inspect.

Untersuchen Sie die Property-Werte in der Ergebnisliste. Achten Sie insbesondere auf folgende Werte:

* Name oder LegacyIAccessible.Name - der Name des Elements, z.B. "Format übertragen".
* ControlType – die Rolle, die Funktion des Elements, z.B. „UIA_ButtonControlTypeId (0xC350)“
* LocalizedControlType - Übersetzung der Rolle in die Landessprache, z.B. "Schaltfläche".
* LegacyIAccessible.Role - MSAA-Rolle, z.B. „Schaltfläche (0x2B)“.
* Value.Value oder LegacyIAccessible.Value – Der Wert oder Inhalt des Elements, ist bei einer reinen Schaltfläche leer, also "".
* LegacyIAccessible.State – MSAA-Status, z.B. „markierbar,auswählbar,mehrfache Auswahl möglich (0x1300000)“
* IsEnabled - Verfügbar, kann die Werte "true" oder "false" annehmen.
* SelectionItem.IsSelected – Ausgewählt, kann die Werte "true" oder "false" annehmen.
* HasKeyboardFocus - Fokussiert, kann die Werte "true" oder "false" annehmen.
* IsKeyboardFocusable – Fokussierbar, kann die Werte "true" oder "false" annehmen.
* Next, Previous – benachbarte Elemente
* Children – untergeordnete Elemente
* Ancestors – übergeordnete Elemente

Bitte beachten Sie:

* Der Name des Elements sollte einer sichtbaren Beschriftung, soweit vorhanden, entsprechen.
* Bei zusammengesetzten Elementen kann der Name auch in einem benachbarten, über- oder untergeordneten Element stehen, das zur selben Gruppe gehört.
* Der Name des Elements kann auch in einem anderen Feld wie Wert oder Hilfetext stehen; dies ist kein Mangel, soweit hieraus keine Widersprüche entstehen. Unproblematisch ist es, wenn der Name eines Buttons als Wert ausgegeben wird. Inakzeptabel dagegen ist es, wenn der Name eines Eingabefeldes oder einer Statusanzeige als Wert ausgegeben wird, denn damit wird die Wiedergabe des eingegebenen oder dynamisch veränderten Werts blockiert.
* Die Rolle des Elements sollte der in der praktischen Erprobung festgestellten Funktion entsprechen.
* Bei zusammengesetzten Elementen sind Name, Rolle und Status der Einzelteile nicht mehrdeutig oder widersprüchlich angegeben.
* Benachbarte Elemente (prev und next) werden, sofern sie eine Label-Beziehung beschreiben, konsistent verwendet.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Wenn sich kein Rahmen um das Element bildet, oder der Rahmen nicht der visuell wahrnehmbaren Begrenzung des Elements entspricht, so ist dies ein Mangel.

Wenn der Name des Elements nicht vorhanden ist, nicht der sichtbaren Beschriftung entspricht, verschiedene Namen in den Teilen eines zusammengesetzten Elements angegeben sind, verschiedene Namen im fokussierten und nicht fokussierten Zustand angegeben sind, so ist dies ein Mangel.

Wenn die Rolle des Elements unzutreffend angegeben ist, oder in den verschiedenen für die Rolle einsetzbaren Feldern widersprüchliche Angaben stehen, oder in den Teilen eines zusammengesetzten Elements widersprüchliche Rollen angegeben sind, oder im fokussierten und nicht fokussierten Zustand des Elements verschiedene Rollen angegeben sind, so ist dies ein Mangel.

Mängel in Name, Rolle und Begrenzung des Elements werden nach der Bedeutung des Elements für die Arbeitsaufgabe bewertet.

Alle weiteren Mängel werden als Einschränkung gewertet.

Für den Bericht an Entwickler notieren Sie das bemängelte Element bitte mit dem Klassen-Namen (ClassName).

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

Die folgenden Informationen aus Inspect gehen in den Prüfschritt 4.10.2 „Zusätzliche kontextsensitive Hilfe“ ein:

* HelpText oder LegacyIAccessible.Help
* LegacyIAccessible.Description
* LegacyIAccessible.DefaultAction
* AccessKey oder LegacyIAccessible.KeyboardShortcut

Textattribute werden im Prüfschritt 4.06.1 „Wiedergabe von Textattributen“ überprüft.

Tabellen werden im Prüfschritt 4.08.1 „Orientierung in Tabellen“ überprüft.

Informationen über Änderungen an den Elementen einer Anwendung werden im Prüfschritt 4.09.1 „Benachrichtigung über Änderungen“ überprüft.

Fokusverfolgung wird im Prüfschritt 5.04.1 „Fokusverfolgung im Großbildsystem“ überprüft.

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Zur Überprüfung der Rolle eines Elements wäre es hilfreich, ein Verzeichnis der in UIA gebräuchlichen Rollenbezeichnungen zu haben, eine entsprechende Referenz wird noch gesucht.

Die Verwendung des UIA-Attributs labelledby zur Kennzeichnung von Labelbeziehungen ist in der Anwendungsentwicklung bisher anscheinend nicht gebräuchlich. Diese Beobachtung braucht Verifizierung.

Prüftools für JAVA-Anwendungen und für die Schnittstelle IAccessible2 müssen noch benannt werden.

=== Referenzen ===

==== EN301549 ====

11. 2.1.38 Name, Role, Value

11.3 Interoperability with assistive technology

==== WCAG ====

4.1.2 Name, Rolle, Wert

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.1.4 Namen für unterstützende Technik verfügbar machen

8.5. Kompatibilität mit unterstützender Technik

7.01.1 - Korrekte Syntax

2016-11-11T17:37:46Z

Petra: Schützte „7.01.1 - Korrekte Syntax“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Anwendungen in Auszeichnungssprachen sind mit korrekter Syntax codiert.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Elemente haben komplette Start- und End-Tags.

Elemente werden entsprechend ihrer Spezifikationen verschachtelt.

Elemente haben keine doppelten Attribute.

Attribute haben zueinander passende Anführungszeichen.

Alle IDs sind einzigartig.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschritt ist anwendbar, sofern die Anwendung in einem textbasierten Format mit Auszeichnungssprachen wie HTML oder XML codiert ist.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Die Syntax der Auszeichnungssprachen ist einzuhalten, damit Anzeigetechniken die Inhalte korrekt darstellen und gliedern können. Während Browser oftmals Reparaturtechniken nutzen, um fehlerhaften Code ausgleichen zu können, erzeugen doch diese Reparaturtechniken verschiedene Ergebnisse. Damit assistive Technologien nicht in Fehlerzustände laufen oder Inhalte verpassen, müssen zumindest die formalen Syntaxregeln eingehalten werden, die eine Untermenge des jeweiligen Sprachumfangs sind.

Handcodierte Anwendungen können Flüchtigkeitsfehler enthalten. Von Generatoren produzierter Code kann fehlerhaft sein, wenn Browser-Heuristiken ausgenutzt werden. Daher wird auch der in Webanwendungen oftmals von Javascript generierte HTML-Code der Syntaxanalyse unterzogen.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Zur Syntaxanalyse von HTML-Anwendungen verwenden Sie den Nu HTML Checker in Verbindung mit dem Bookmarklet „WCAG-Parsing only“ und dem Firebug Add-On für den Firefox Browser (siehe Werkzeugliste).

# Öffnen Sie die Anwendung im Firefox Browser und warten Sie, bis die Anwendung vollständig geladen ist.
# Um den generierten Code zu sehen, aktivieren Sie Firebug (Kontextmenü: Element mit Firebug untersuchen). Markieren Sie das body-Tag und aktivieren Sie die Bearbeiten-Funktion. Kopieren Sie den nun angezeigten vollständigen Code.
# Überprüfen Sie den Code mit dem Nu HMTL-Checker.
# Filtern Sie die Ergebnisliste mit dem Bookmarklet „WCAG-Parsing-only“. Stellen Sie fest, ob jetzt noch Fehler angezeigt werden.
# Wiederholen Sie die Schritte 2 bis 4, nachdem Sie die Anwendung bedient haben. Nehmen Sie etwa 2 bis 3 Stichproben je Szenario.

Für lauffähige XML-Anwendungen erübrigt sich eine Überprüfung der Syntax, da nur wohlgeformter Code von der Anzeigesoftware ausgeführt wird.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.37 Parsing

==== WCAG ====

4.1.1 Syntaxanalyse

==== WCAG-Techniques ====

G134: Validating Web pages

==== ISO9241-171 ====

6.03 - Bedienung mit externen Eingabegeräten ermöglichen

2016-11-11T17:37:31Z

Petra: Schützte „6.03.1 - Bedienung mit externen Eingabegeräten ermöglichen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Alle Funktionen der Anwendung sind mit externen Eingabegeräten, die Tastatur und Maus ersetzen, uneingeschränkt nutzbar.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Ermitteln ob Probleme mit der Tastatur- und Mausschnittstelle bekannt sind, die auf eine nicht standardkonforme Programmierung der Anwendung zurückzuführen sind.

=== Referenzen ===

==== EN301549 ====

11. 3 Interoperability with assistive technology

11. 3.2.2 Platform accessibility service support for assistive technologies

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.5.11 Die Installation von Tastatur- und/oder Zeigegerätemulatoren akzeptieren

9.4.2 Direkte Steuerung der Zeigerposition von externen Geräten aus ermöglichen

6.02.1 - Hilfen zum Auffinden des Zeigers

2016-11-11T17:37:14Z

Petra: Schützte „6.02.1 - Hilfen zum Auffinden des Zeigers“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Die Anwendung stellt die Eingabehilfen des Betriebssystems zur Hervorhebung des Tastatur- und Mauszeigers zur Verfügung.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Ein Benutzer mit eingeschränktem Sehvermögen verliert den Mauszeiger leicht aus dem Blick. Beim Drücken der Strg-Taste jedoch werden animierte konzentrische Kreise um die Mauszeigerposition herum angezeigt.

Die Software bietet die Option, den Tastaturfokus besonders deutlich als dick umrandetes Rechteck von kontrastierender Farbe darzustellen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.<br />

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 5. User Preferences: Where software provides a user interface it shall provide sufficient modes of operation that use user preferences for platform settings for colour, contrast, font type, font size, and focus cursor except for software that is designed to be isolated from its underlying platforms. NOTE: Software that is isolated from its underlying platform has no access to user settings in the platform and thus cannot adhere to them.

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.2.4 Individualisierung der Einfügemarke und des Zeigers ermöglichen

9.4.13 Hilfsmittel zum Auffinden des Zeigers zur Verfügung stellen

6.01.1 - Eingabehilfen für Tastatur und Maus

2016-11-11T17:37:01Z

Petra: Schützte „6.01.1 - Eingabehilfen für Tastatur und Maus“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

==== Prüfschritt 6.01.1 - Eingabehilfen für Tastatur und Maus ====

Gewichtung:

1

Anwendung:

Anwendung auf Seite/Szenario

Bewertungen:

[https://www.biti-test.de/intern/pruefplaene/pruefschritt-bewertungen.xhtml?ps=78 Bisherige Bewertungen für diesen Prüfschritt anzeigen]

Beschreibung:

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Die Einstellungen für Tastatur und Maus, die von Windows als Eingabehilfen für Menschen mit Behinderungen zur Verfügung gestellt werden, können in der Anwendung aufgerufen werden und funktionieren wie vorgesehen. Sie stören nicht Tastaturshortcuts der Anwendung.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Die Mausverzögerung kann in der Anwendung aufgerufen werden und funktioniert.

Die Windows-Funktion „klebende Tasten“ kann mit dem dafür vorgesehenen Tastatur-Shortcut in der Anwendung aufgerufen werden und funktioniert.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Wenn die Eingabehilfen in der Anwendung nicht funktionieren, so ist dies eine Blockade.

Wenn die Eingabehilfen nicht in der Anwendung aufgerufen werden können, aber dennoch in der Anwendung funktionieren, wenn sie außerhalb oder vor dem Start der Anwendung aufgerufen werden, so ist dies eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 4.1 User control of accessibility features

11. 3.2.3 Use of accessibility services

==== WCAG ====

*

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.3.1 Steuerungselemente für Zugänglichkeitsmerkmale auffindbar und benutzbar machen

9.3.12 Zugänglichkeits-Tastenkürzelzuweisungen reservieren

8.5.3 Nutzung der Standard-Zugänglichkeitsdienste

9.3.3 Sequenzielles Eingeben von ansonsten parallel erfolgenden Tastenbetätigungen ermöglichen

5.05.1 - Kantenglättung im Großbildsystem

2016-11-11T17:36:46Z

Petra: Schützte „5.05.1 - Kantenglättung im Großbildsystem“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Im Großbildsystem werden Textzeichen in allen Vergrößerungsstufen mit glatten Konturen angezeigt.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Fehler: Nur schwarze Textzeichen auf weißem Grund haben glatte Konturen. Textzeichen in anderen Farben erscheinen pixelig/stufig.

Fehler: Bei manchen Textzeichen sind die Konturen glatt, aber die Form ist stark verzerrt, so dass der Buchstabe kaum wiederzuerkennen ist.

Fehler: Manche Textzeichen berühren oder überlagern sich.

Fehler: Die vergrößerten Textzeichen werden unscharf dargestellt.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Klare, scharfe Konturen sind wichtig für gute Lesbarkeit von Zeichen. Ein wichtiges Qualitätsmerkmal bei Großbildsystemen ist daher die Kantenglättung der vergrößerten Textzeichen. Hierzu sind heute die folgenden Techniken im Einsatz:

# Die Font-Substitution ersetzt die Zeichen durch einen größeren Font. Dies ergibt an sich saubere Zeichen. Da aber die Position jedes Zeichens neu berechnet werden muss, können Fehler entstehen, so dass Zeichen sich berühren oder überlagern können.
# Die Kantenglättung i.e.S. basiert auf der Vektorisierung, ein Verfahren der grafischen Mustererkennung. Aus den Farbkontrasten der Bildpunkte werden Ecken ermittelt und durch interpolierende Konturen verbunden. Dabei wird das zugrundeliegende Zeichen mehr oder weniger gut nachgebildet. Die neu entstandene Vektorgrafik kann ohne Qualitätsverlust vergrößert werden. Das Verfahren wirkt auf Fonts ebenso wie auf grafische Schriften und Symbole. Wegen der Rechenintensität wird die Kantenglättung oftmals auf schwarz-weiße Schriften begrenzt, während farbige Schrift pixelig/stufig erscheint.
# Das Anti-Aliasing ist ein Kantenglättungsverfahren für Rastergrafiken. Der Treppeneffekt bei schrägen und runden Linien wird abgeschwächt, indem ein Farbübergang zwischen Vorder- und Hintergrundfarbe eingesetzt wird. Als Nebeneffekt muss eine Unschärfe in Kauf genommen werden, die sich je nach Auflösung und Vergrößerungsfaktor mehr oder weniger stark bemerkbar macht.

Aus Anwendersicht sollte das Verfahren der Wahl für die Vergrößerung von Schrift die Font-Substitution sein. Dieses Verfahren ist heute jedoch nicht mehr sehr verbreitet, denn es wird vom Betriebssystem schlecht unterstützt. Die zugrundeliegende Routine, die die Fonts auf den Bildschirm schreibt, ist keine Schnittstelle mit verbindlichem Standard, die Codierung in Windows ist wechselhaft. So muss die Font-Substitution in Großbildsystemen bei jedem Versionssprung der Plattform- bzw. Anwendungssoftware nachgearbeitet werden.

Die heute üblichen grafischen Verfahren der Kantenglättung sind an sich eine Leistung des Großbildsystems und nicht der Plattform oder der Anwendungssoftware. Daher stellt sich die Frage, ob dieser Prüfschritt in einem Verfahren zur Prüfung von Anwendungssoftware unter Windows seinen Platz hat. Ein Argument dafür ist, dass der Status quo nicht befriedigend ist. Die Leistung der Kantenglättung bei Vergrößerung sollte in das Betriebssystem aufgenommen und von der Anwendungssoftware, z.B. durch Auswahl geeigneter Fonts, unterstützt werden.

Die Anforderung „Kantenglättung bei Vergrößerung“ wird allerdings bisher von den Standards nur schwach unterstützt. In ISO 9241-303 „Anforderungen an elektronische optische Anzeigen“ wird auf die Rasterung von Zeichen eingegangen, die für eine gute Lesbarkeit nicht zu grob und jedenfalls nicht sichtbar sein sollte. Gute Lesbarkeit bei Vergrößerung ist in keinem Standard explizit ausgeführt. WCAG 1.4.4. „Vergrößerung auf 200%“ und WCAG 1.4.5 „Bilder eines Textes“ gehen implizit davon aus, dass bei der Vergrößerung von Text klare Konturen entstehen, während Grafiken nur auf Pixelebene vergrößert werden können und entsprechend grob gerastert erscheinen. Wie gezeigt wurde, gilt diese klare Unterscheidung für Großbildsysteme heute nicht mehr. Eine Fortentwicklung der Standards erscheint notwendig, um die Anforderung für die Fortentwicklung der Betriebssysteme relevant zu machen.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Die Schriftgröße und die Fenstergröße einstellen wie für den Standardbildschirm des Testsystems beschrieben. Das ausgewählte Großbildsystem (siehe Testsystem) starten. Die Vergrößerung auf Faktor 4 einstellen (400%). Die Anwendung starten.

Sichtprüfung: sind die unter Beschreibung und Beispiele genannten Anforderungen erfüllt?

Wiederholung der Prüfung mit Vergrößerungsfaktor 2 (200%) und 6 (600%).

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Angesichts des Stands der Technik wäre zu diskutieren, ob der Prüfschritt bewertet werden soll, oder ob Mängel nur mit beratender Funktion protokolliert werden sollen.

=== Referenzen ===

==== EN301549 ====

*

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

==== - ====

=== Sonstige ===

ISO 9241-303 Anforderungen an elektronische optische Anzeigen

5.04.1 - Fokusverfolgung im Großbildsystem

2016-11-11T17:36:32Z

Petra: Schützte „5.04.1 - Fokusverfolgung im Großbildsystem“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Im Großbildsystem folgt die Anzeige den Aktionen des Benutzers mit Tastatur und Maus, so dass der Tastaturfokus bzw. der Eingabecursor jederzeit im vergrößerten Bildausschnitt zu sehen ist.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Der Bildausschnitt folgt, wenn der Benutzer

* den Bildausschnitt mit der Maus über den Bildschirm führt, um alle Inhalte zu lesen
* mit TAB durch die Bedienelemente geht
* mit einem Tastenbefehl Funktionsbereiche gezielt anspringt, z.B. das Hauptmenü und den Datenbereich der Anwendung
* Dialoge öffnet und schließt
* lange Inhalte mit den Rollbalken oder mit SEITE AUF/AB über den Bildschirm rollt
* Daten mit Maus oder Tastatur markiert, über den Rand des Bildausschnitts hinweg
* lange Eingaben macht, über den Rand des Bildausschnitts hinweg.

Der Bildausschnitt folgt bei Systemmeldungen, die eine Benutzeraktion erfordern, z.B. Dialogboxen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Menschen mit Sehbehinderungen, die ein Großbildsystem nutzen, sehen je nach ihrem benötigten Vergrößerungsfaktor nur einen mehr oder weniger kleinen Ausschnitt des Bildschirms. Bei 4-facher Vergrößerung sehen sie nur 1/16 des Originalbildes. Die Vergrößerungssoftware unterstützt den Benutzer durch verschiedene Funktionen dabei, sich in der Anwendung zu orientieren. Hierzu gehört die Fokusverfolgung.

Der Benutzer wechselt zwischen dem Steuern des vergrößerten Bildausschnitts und der Programmbedienung hin und her. Wenn der Benutzer Eingaben macht – Menüs und Buttons aktiviert, Dialoge öffnet und schließt, Inhalte markiert, Daten erfasst – soll die Vergrößerungssoftware die Steuerung des vergrößerten Ausschnitts übernehmen und den Aktionen des Benutzers folgen, so dass der Benutzer jederzeit den Ort des Geschehens sehen kann. Wenn die Vergrößerungssoftware dies nicht kann, muss der Benutzer den Ausschnitt während der Programmbedienung nachsteuern, was den Arbeitsfluss unterbricht und hohe Konzentration erfordert, oder in manchen Fällen auch kaum leistbar sein kann.

Anwendungselemente, die mit Standardroutinen des Betriebssystems erzeugt wurden, übermitteln den Tastaturfokus bzw. die Selektionsmerkmale normalerweise automatisch an die Hilfstechnik. Dagegen muss bei individuell entwickelten Elementen der Programmierer bzw. das eingesetzte Framework dafür sorgen.

In der Prüfung wird ein Vergrößerungsfaktor von 400% eingesetzt. Dieser Wert markiert in etwa die Grenze einer sinnvollen Vergrößerung, wenn Vergrößerung die einzige von einem Benutzer eingesetzte assistierende Technologie ist. In der Praxis kommen stärkere Vergrößerungen vor, die aber mit anderen Hilfen wie Sprachausgabe kombiniert sein sollten.

Benutzer von Großbildsystemen setzen normalerweise Tastatur und Maus kombiniert zur Programmbedienung ein und entwickeln dabei ihren persönlichen Arbeitsstil. In der Prüfung werden mehrere Aspekte des Abschnitts III Tastaturbedienung wieder aufgegriffen, jedoch abgewandelt durch die Kombination mit Mausbedienung und Ausschnittvergrößerung. Daher werden die Ergebnisse dieses Prüfschritts unabhängig von anderen gewertet.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Die Schriftgröße und die Fenstergröße einstellen wie für den Standardbildschirm des Testsystems beschrieben. Das ausgewählte Großbildsystem (siehe Testsystem) starten. Die Vergrößerung auf Faktor 4 einstellen (400%). Die Anwendung starten.

Praktische Erprobung: Folgt die Anzeige den Bedienschritten des Szenarios? Dabei die Bedienung zwischen Maus und Tastatur wechseln. Die unter Beispiele genannten Fälle berücksichtigen.

Im Zweifelsfall die Vergrößerung ausschalten, den Bedienschritt wiederholen und dabei die Fokusreihenfolge feststellen, die Vergrößerung wieder einschalten und die Fokusverfolgung des Großbildsystems erneut überprüfen.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Barriere oder eine Einschränkung, je nachdem wie einfach der Fokus nach dem Abhängen des vergrößerten Ausschnitts wiederzufinden ist.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11.3.2.13 Tracking of focus and selection attributes

11.3.2.15 Change notification

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen

5.03.1 - Kontrastmodus ist nutzbar

2016-11-11T17:36:19Z

Petra: Schützte „5.03.1 - Kontrastmodus ist nutzbar“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Die Anwendung kann in dem von der Plattform bereitgestellten Kontrastmodus ohne wesentliche Einschränkungen genutzt werden.

Sofern die Anwendung ein eigenes Farbschema nutzt, ist es mit dem Windows Kontrastmodus gleichwertig. Das Farbschema erlaubt es, Vorder- und Hintergrundfarben für alle textbasierten Elementtypen (Daten, Menüs, Links etc.) separat einzustellen.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Im Kontrastmodus sind alle Elemente der Anwendung erkennbar.

Alle Textelemente übernehmen die voreingestellten Farben für Vorder- und Hintergrund der Zeichen, mit Ausnahme von Logos (Schrift-/Bildmarken). Fehler: Texte sind als Grafik abgelegt, die sich im Kontrastmodus nicht anpassen.

Einfarbige Grafiken werden vermieden. Icons haben eine Hintergrundfarbe oder ein mehrfarbiges Motiv.

Eine Anwendung stellt einen Styleswitcher zur Verfügung, mit dem helle oder dunkle Icons ausgewählt werden können, die mit den im Windows Kontrastmodus eingestellten Hintergrundfarben ausreichend kontrastieren.

Eine Anwendung verwendet farbige Rechtecke als Farbmarkierung für verschiedene Inhalte. Die Farben sind als Grafiken gespeichert, damit sie im Kontrastmodus erhalten bleiben, und mit einem Rahmen umgeben, damit sie gegen jeden Hintergrund erkennbar sind.

Bedienelemente und Daten, soweit sie in der Normalansicht optisch unterscheidbar sind, sind auch im Kontrastmodus unterscheidbar.

Die Anwendung kennzeichnet Bedienelemente mit Rahmenlinien, die auch im Kontrastmodus erscheinen.

Der Status von Bedienelementen (ausgewählt, aktives Element, nicht verfügbar), soweit er in der Normalansicht optisch unterscheidbar ist, ist auch im Kontrastmodus unterscheidbar.

Die Anwendung gestaltet Statusmarkierungen mit Grafiken, Rahmenlinien oder Unterstrichen, die auch im Kontrastmodus erscheinen.

Der Tastaturfokus und der Eingabecursor sind erkennbar. Eine Selektion (Markierung) ist erkennbar.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Menschen mit Sehbehinderungen wie Farbfehlsichtigkeit, erhöhter Blendempfindlichkeit oder erhöhtem Kontrastbedarf profitieren davon, wenn sie sich die Farben am Bildschirm nach ihren individuellen Anforderungen einstellen können. Sie wählen dann z,B. einen dunklen Hintergrund oder spezielle Farbkontraste. So können sie beschwerdefrei arbeiten und oftmals auch die Vergrößerung geringer einstellen, so dass sie einen besseren Überblick über die Anwendung gewinnen.

Im Windows Kontrastmodus können die Vorder- und Hintergrundfarben von textbasierten Elementtypen vom Benutzer frei gewählt werden. Dabei fallen die in der Normalansicht gesetzten Farbunterschiede, Hintergrundfarben und Hintergrundbilder weg, mit denen Hinweise auf die Rolle und den Status von Bedienelementen gegeben werden. Diese Merkmale müssen in der Programmierung gesetzt sein bzw. dürfen nicht deaktiviert werden, damit der Elementtyp erkannt und im Kontrastmodus wie gewählt dargestellt werden kann. Standardelemente des Betriebssystems erfüllen im Prinzip diese Anforderungen, während bei individuell erstellten UI-Elementen der Programmierer bzw. das verwendete UI-Framework dafür sorgen muss.

Grafiken bleiben im Windows Kontrastmodus unverändert. Sie müssen so gestaltet sein, dass sie mit der individuell gewählten Hintergrundfarbe zusammenpassen. Grafische Schriften, deren Farben sich im Kontrastmodus nicht anpassen, sollten nur für Logos verwendet werden. Kontraproduktiv sind vor allem größere Flächen mit grafischer Schrift, deren Hintergrund gegen die gewählte Hintergrundfarbe kontrastiert und somit einen optischen Störeffekt hervorruft.

Manche Anwendungen nutzen den Windows Kontrastmodus nur für die Menüs und die Statuszeile, während sie für den Dokumentteil eigene Farbschemata anbieten. Hierbei ist zu beachten, dass das anwendungseigene Farbschema dieselben Einstellmöglichkeiten wie der Windows Kontrastmodus bietet. Nicht gleichwertig ist ein Farbfilter, der z.B. alle Farben invertiert oder in Graustufen umwandelt. Hierbei werden zwar die Grafiken und Hintergrundfarben mit einbezogen, jedoch kann nicht immer der gewünschte Effekt erzielt bzw. für alle Elemente ein ausreichender Kontrast eingestellt werden.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Den Windows Kontrastmodus einschalten mit SHIFT (links) + ALT (links) +DRUCK. Falls die Anwendung nicht mit einem durchgängigen Farbwechsel darauf reagiert, feststellen, ob die Anwendung eine eigene gleichwertige Einstellmöglichkeit anbietet, und diese nutzen. Andernfalls Abbruch des Prüfschritts.

Sichtprüfung und praktische Erprobung (TAB, Markierung von Daten, Texteingabe): sind die in den Beispielen dargestellten Gestaltungsregeln eingehalten?

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Blockade: Die Anwendung übernimmt nicht die Farben des Windows Kontrastmodus und bietet auch keine eigene Farbwahl.

Blockade: Im Kontrastmodus ist der Tastaturfokus über mehr als drei TAB-Schritte nicht erkennbar.

Blockade: Im Kontrastmodus sind markierte Daten nicht unterscheidbar oder nicht erkennbar.

Barriere: Wichtige Bereiche der Anwendung übernehmen nur die Vordergrundfarbe oder nur die Hintergrundfarbe des Kontrastmodus, so dass die individuelle Farbwahl nicht frei gestaltet werden kann.

Barriere: Texte von mehr als 8 Wörtern sind eine Grafik, deren Farben sich nicht anpassen.

Barriere: Flächen von mehr als 1/6 des Anwendungsfensters (siehe Testausstattung, Standardbildschirm) sind eine Grafik, deren Farben sich nicht anpassen. Ausnahme: Die Grafik ist eine Infografik und gehört zum Datenbereich der Anwendung.

Alle weiteren Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 5. User Preferences

==== WCAG ====

1.4.8 Visuelle Präsentation: Vorder- und Hintergrundfarben können vom Benutzer ausgewählt werden.

==== WCAG-Techniques ====

==== ISO9241-171 ====

10.4.2 Für Behinderte entwickelte Farbschemata zur Verfügung stellen

10.4.3 Individualisierung der Farbschemata ermöglichen

10.4.4 Benutzern die Individualisierung der Farbkennzeichnung ermöglichen

5.01.1 - Schriftvergrößerung auf 200%

2016-11-11T17:36:04Z

Petra: Schützte „5.01.1 - Schriftvergrößerung auf 200%“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Alle Schriften der Anwendung können mit den Schriftgröße-Einstellungen der Plattform oder der Anwendung auf 200% vergrößert werden, ohne dass dabei Inhalt oder Funktionalität verloren gehen.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Die Anwendung ändert das Layout oder zeigt einen oder mehrere Rollbalken, wenn bei vergrößerter Schrift nicht mehr alle Inhalte in das Anwendungsfenster passen. Der Benutzer kann alle Bedienelemente und Inhalte mit dem Rollbalken lesen. Bei Tastaturbedienung folgt der Bildausschnitt dem Tastaturfokus automatisch in den zuvor nicht sichtbaren Bereich.

Ein Textverarbeitungsprogramm enthält eine Zoomfunktion, die den gesamten Text des Dokumentes auf mindestens 200% gegenüber den im Dokument festgelegten Schriftgrößen vergrößert. Der Benutzer kann mit dem Rollbalken den Text in seiner gesamten Breite lesen. Bei der Eingabe und Korrektur des Textes folgt der Bildausschnitt dem Eingabecursor.

Fehler: Bei vergrößerter Schrift werden die Zeichen der Anwendung am Bildschirm unscharf dargestellt.

Fehler: Bei vergrößerter Schrift sind Bereiche der Anwendung abgeschnitten oder überlagern sich, so dass der Benutzer sie nicht mehr lesen kann.

Fehler: Bei vergrößerter Schrift folgt der Bildausschnitt nicht dem Tastaturfokus, so dass der Anwender mit dem Rollbalken nachsteuern muss, um das fokussierte Element zu sehen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Benutzer sollen die Schriftgröße nach ihren Bedürfnissen einstellen können. Die Vergrößerung bis zu 200% unterstützt vor allem leicht sehbehinderte Benutzer, die noch keine assistierende Technik benötigen.

Auch im vergrößerten Zustand sollen alle Schriften scharf und gut lesbar sein, alle Inhalte und Funktionen der Anwendung sollen erreichbar und benutzbar sein.

In diesem Prüfschritt wird die grundlegende Vergrößerung geprüft. Hierfür reicht es aus, wenn die Vergrößerung durch eine Zoomfunktion erreicht wird, so dass die Bedienoberfläche der Anwendung das Anwendungsfenster seitlich überragt. Das relativ umständliche Seitwärtsscrollen muss in Kauf genommen werden.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Die Schriftgröße und die Fenstergröße einstellen wie für den Standardbildschirm des Testsystems beschrieben.

Alle Schriften (Versalhöhe) sowie die Fenstergröße mit dem Keseling Bildschirmlineal (siehe Werkzeugliste) messen.

Nehmen Sie die im Folgenden genannten Einstellungen der Reihe nach vor und stellen Sie nach jedem Schritt fest, ob alle oder einige Schriften der Anwendung sich hierdurch auf mindestens 200‘% der Ausgangsgröße einstellen lassen. Im Zweifel messen Sie nach und kalibrieren ggf. zuvor das Bildschirmlineal neu. Berücksichtigen Sie alle Schriften: Menüs, Beschriftungen, Meldungstexte, Daten. Sobald alle Schriften ausreichend vergrößert sind, beenden Sie die Einstellung (es müssen nicht alle Optionen angewandt werden).

* DPI-Einstellung auf das Doppelte erhöhen oder, falls das nicht möglich ist, so hoch wie möglich setzen. Falls die Schriften der Anwendung nun unscharf erscheinen, zuvor aber scharf waren, diese Einstellung rückgängig machen.
* In der Windows-Systemsteuerung im Dialog Fensterfarbe und -darstellung (Win7: Systemsteuerung-Anpassung-Fensterfarben-erweiterte Darstellungseinstellungen) für alle Elemente, die dies erlauben (Menü, Dialogfeld, ausgewählte Elemente etc.), den Schriftgrad einstellen.
* Falls vorhanden, Schriftgröße-Einstellung oder Zoomfunktion der Anwendung benutzen.
* Bildschirmauflösung herabsetzen unter Systemsteuerung-Anzeige-Auflösung anpassen (Win7).

Falls am Ende der Einstellung die Zeichen unscharf sind, so ist dies ein Mangel, der für die weitere Prüfung hingenommen werden muss.

Falls sich Einstellmöglichkeiten kumulieren, so dass einzelne Schriften nun mehrfach vergrößert sind, können soweit möglich zuvor getroffene Einstellungen zurückgenommen werden.

Falls einzelne Schriften zuvor schon groß waren und nach Vergrößerung nun Störungen verursachen, kann versucht werden, die Schriftgröße dieser Elemente gezielt zu vermindern. Große Schrift ist definiert im Prüfschritt 1.01.0 „Ausreichender Kontrast“.

Falls bei einer der vorgenommenen Einstellungen die Fenstergröße verändert worden sein sollte, mit Hilfe des Bildschirmlineals die anfangs gemessene Fenstergröße wiederherstellen.

Hiermit ist die Einstellung der Schriftgröße abgeschlossen. Es sollten alle Schriften auf mindestens 200% vergrößert worden sein.

Sichtprüfung und Erprobung:

* Sind alle Inhalte der Anwendung, Beschriftungen, Meldungstexte und Daten, sichtbar oder können mit dem Rollbalken sichtbar gemacht werden?
* Eingaben vornehmen und feststellen, ob der Bildausschnitt automatisch dem Tastaturfokus in den zuvor nicht sichtbaren Bereich folgt.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Wenn wichtige Bereiche der Anwendung abgeschnitten sind, so dass der Benutzer sie nicht mehr lesen und bedienen kann, so ist dies eine Blockade.

Wenn der Bildausschnitt nicht dem Tastaturfokus folgt, so dass der Anwender mit dem Rollbalken nachsteuern muss, um das fokussierte Element zu sehen, so ist dies eine Barriere.

Alle weiteren Mängel sind eine Einschränkung.

Wenn einzelne Schriften besonders unscharf oder pixelig sind, so ist dies ein Hinweis darauf, dass der Text als Bild abgelegt ist. Dies wird nicht hier gewertet, sondern im Prüfschritt 7.03.1 „Text als Text codieren“.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

Bilder eines Textes sind Gegenstand des Prüfschritts 7.03.1 Text als Text codieren.

Weitergehende Anforderungen an die Vergrößerung werden im Prüfschritt 5.02.2 „Bei vergrößerter Darstellung Layout anpassen“ geprüft.

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.13 Resize text

11. 5. User Preferences

==== WCAG ====

1.4.4.Textgröße ändern.

==== WCAG-Techniques ====

==== ISO9241-171 ====

10.3.2 Benutzern die Einstellung einer Mindestschriftgröße ermöglichen

4.11.1 - Automatischer Sprachwechsel

2016-11-11T17:35:48Z

Petra: Schützte „4.11.1 - Automatischer Sprachwechsel“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Die voreingestellte natürliche Sprache der Software ist programmatisch erkennbar, so dass die Sprachausgabe sich automatisch darauf einstellen kann.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist anwendbar, wenn die Software verschiedene Spracheinstellungen / Lokalisierungen erlaubt, und wenn der Sprachwechsel bei laufender Anwendung für die Arbeitsaufgabe erforderlich ist.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Screenreader verwenden verschiedene Sprachausgaben für die jeweiligen natürlichen Sprachen. Die Sprachausgabe bestimmt, ob die Texte einer Software (Beschriftungen, Meldungen, Anleitungen, Inhalte) richtig ausgesprochen werden. Wenn ein Sprachwechsel bei laufender Anwendung erforderlich ist, muss der Screenreader hierüber informiert werden, damit er die Sprache wechseln kann.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Sprache der Software umstellen (z.B. von Deutsch auf Englisch). Wechselt der Screenreader automatisch die Sprache, so dass die Aussprache richtig ist?

Falls nein: Im Einstellungsdialog des Screenreaders die Sprache einstellen. Wird jetzt die richtige Aussprache angewandt?

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Blockade: Sprachwechsel bei laufender Anwendung ist nicht möglich, die Anwendung muss geschlossen werden, um den Sprachwechsel im Screenreader nachzuziehen.

Einschränkung: Beim Sprachwechsel der Anwendung muss der Screenreader manuell umgestellt werden, aber die Anwendung kann bei derselben Programmsituation weiterlaufen.

Erfüllt: Beim Sprachwechsel der Anwendung stellt der Screenreader sich automatisch auf die neue Sprache ein.

=== Einordnung[Abgrenzung zu anderen Prüfschritten] ===

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Gibt die Accessibility-Schnittstelle die Sprache der Software aus? Oder muss Software zwingend die Lokalisierungsschnittstelle des Betriebssystems verwenden, damit Sprachwechsel automatisch erkennbar sind?

Ggf. sollte der Prüfpunkt nach Teil 7 standardkonforme Programmierung verschoben werden.

Es sollte eine Testseite in HTML/JS gebaut werden, um die Fähigkeit des Screenreaders zum Sprachwechsel bei laufender Anwendung zu testen. Als zweiter Schritt kann dann geprüft werden, ob auch in der getesteten Anwendung der Sprachwechsel funktioniert.

=== Referenzen ===

==== EN301549 ====

11. 2.1.27 Language of software

Where software platforms provide a "locale / language" setting, applications that use that setting and render their interface in that "locale / language" would comply with this success criterion. Applications that do not use the platform "locale / language" setting but instead use an accessibility-supported method for exposing the human language of the software would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale / language" setting may not be able to meet this success criterion in that locale / language.

==== WCAG ====

3.1.1 Sprache der Seite

==== WCAG-Techniques ====

==== ISO9241-171 ====

4.09.1 - Benachrichtigung über Änderungen

2016-11-11T17:35:33Z

Petra: Schützte „4.09.1 - Benachrichtigung über Änderungen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Bei der Bedienung der Anwendung erhält der Benutzer fortlaufend Rückmeldung über alle von ihm vorgenommenen Änderungen, einschließlich der bearbeiteten Inhalte, der vorgenommenen Selektionen, der aktuellen Position des Fokus und dem Status von Bedienelementen und Anzeigen.

Ebenso wird der Benutzer benachrichtigt über alle Ereignisse, die außerhalb seines aktuellen Fokus und ohne seine direkte Veranlassung geschehen, wie etwa dem Erscheinen von Systemmeldungen, der automatischen Aktualisierung von Inhalten etc.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Eine Balloon-Meldung informiert über das Eintreffen einer neuen E-Mail. Der Screenreader quittiert dies entweder mit dem Vorlesen der Balloon-Meldung.

Beim Formatieren eines Textes erhält der Nutzer ständig Rückmeldung darüber, welche Formatvorlage er gerade ausgewählt hat, welche Formatierung er vorgenommen hat, etc.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Prüfen oder beobachten Sie, ob dei Nutzung / Eingabe von Daten innerhalb der Anwendung Änderungen hervorruft. Dies können Statusmeldungen sein wie auch PopUp-Meldungen.

Sofern es keine Rückmeldungen gibt, prüfen Sie, ob Ihr Screenreader in den Ausführlichkeitseinstellungen korrekt konfiguriert ist.

Provozieren Sie beispielsweise Balloon-Meldungen, indem Sie sich sebst eine E-Mail zuschicken.

Prüfen Sie dann, ob der Screenreader alle optisch verfügbaren Infos ebenfalls ausgibt.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.38: Name, role, value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

11.3.2.15 Change notification: Where software provides a user interface it shall, by using the services as described in 11.3.2.3, notify assistive technologies about changes in those programmatically determinable attributes of user interface elements that are referenced in requirements 11.3.2.5 to 11.3.2.11 and 11.3.2.13.

3.2.5 Object information

3.2.6 Row, column, and headers

3.2.7 Values

3.2.8 Label relationships

3.2.9 Parent-child relationships

3.2.10 Text

3.2.11 List of available actions

3.2.13 Tracking of focus and selection attributes

WCAG

==== 4.1.2 Name, Rolle, Wert: Für alle Bestandteile der Benutzerschnittstelle (einschließlich, aber nicht beschränkt auf: Formularelemente, Links und durch Skripte generierte Komponenten) können Name und Rolle durch Software bestimmt werden; Zustände, Eigenschaften und Werte, die vom Benutzer festgelegt werden können, können durch Software festgelegt sein; und die Benachrichtigung über Änderungen an diesen Elementen steht den Benutzeragenten zur Verfügung, einschließlich assistierender Techniken. ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.5.7 Benachrichtigungen über Ereignisse für unterstützende Technik verfügbar machen

4.08.1 - Orientierung in Tabellen

2016-11-11T17:35:17Z

Petra: Schützte „4.08.1 - Orientierung in Tabellen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

In Datentabellen sagt der Screenreader in jeder Zelle die Zeile und Spalte an, ebenso Zeilen- und Spaltenüberschriften, soweit diese vorhanden sind.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist anwendbar, wenn die Anwendung Daten in Form von Tabellen präsentiert.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Für blinde Menschen bedarf es zur Orientierung in Tabellen eines besonderen Abstraktionsvermögens. Zweidimensionale Felder müssen in Zeilen und Spalten erfassbar, darin befindliche Datentypen unterscheidbar sein.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Bewegen Sie den Fokus des Screenreaders in eine Tabelle, die innerhalb der Anwendung dargestellt wird. Üblicherweise wird mit Screenreadern mit der Tastenkombination STRG+ALT+Pfeiltasten navigiert. Ist dies möglich. Wird bei Nutzung der STRG+ALT+links oder rechts die jeweilige Spalten-Überschrift ausgegeben? Wird beim Navigieren nach oben bzw. unten die eventuell vorhandene Zeilen-Überschrift ausgegeben?

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel werden nach ihrer Bedeutung für die Arbeitsaufgabe bewertet.

Erfüllt: Datenzellen wie auch Überschriften-Zellen werden erwartungsgemäß wiedergegeben.

Nicht voll erfüllt: Zellen-Inhalte werden wiedergegeben, Zellen-Typen sind nicht voneinander unterscheidbar.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

In diesem Prüfschritt wird nicht verlangt, dass Zeilen- und Spaltenüberschriften vorhanden sein müssen. Eine Verpflichtung auf Zeilen- und Spaltenüberschriften könnte Gegenstand eines weiteren Prüfschritts mit Konformitätslevel 2 sein.

=== Referenzen ===

==== EN301549 ====

11.3.2.6 Row, column, and headers: Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the row and column of each cell in a data table, including headers of the row and column if present, programmatically determinable by assistive technologies.

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.5.10 Angemessene Darstellung von Tabellen ermöglichen

4.07.1 - Korrekte Leseabfolge von Inhalten

2016-11-11T17:34:55Z

Petra: Schützte „4.07.1 - Korrekte Leseabfolge von Inhalten“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Inhaltsblöcke werden im Screenreader in korrekter, sinnentsprechender Lesereihenfolge wiedergegeben.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Inhaltsblöcke, die am Bildschirm nebeneinander angeordnet sind, werden vom Screenreader in korrekter Lesereihenfolge vorgelesen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist anwendbar, wenn die Anwendung Inhaltsblöcke nebeneinander oder in einer optisch nachvollziehbaren Reihenfolge anordnet.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Üblicherweise werden Inhaltsblöcke in Windows-Software mit der Taste F6 angesteuert. Springen Sie durch wiederholtes Drücken der Taste F6 von Inhaltsblock zu Inhaltsblock und achten Sie auf die jeweilige Ansage der Sprachausgabe. Sollte F6 nicht funktionieren, schauen Sie in der Liste der zur Anwendung gehörenden Tastatur-Kurzbefehle nach, ob es eine andere Tastenkombination gibt. Prüfen Sie, ob die Blöcke in einer nachvollziehbaren Reihenfolge angesprungen werden.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel werden nach der Bedeutung der gestörten Information für die Arbeitsaufgabe bewertet.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.8. Meaningful sequence

==== WCAG ====

1.3.2 Bedeutungstragende Reihenfolge: Wenn die Reihenfolge, in der Inhalte präsentiert werden, sich auf deren Bedeutung auswirkt, kann die korrekte Leseabfolge durch Software bestimmt werden.

==== WCAG-Techniques ====

==== ISO9241-171 ====

4.06.1 - Wiedergabe von Textattributen

2016-11-11T17:34:40Z

Petra: Schützte „4.06.1 - Wiedergabe von Textattributen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Bei Textinhalten werden die Attribute fett, kursiv und unterstrichen wiedergegeben bzw. sind ermittelbar.

Die Anforderung bezieht sich auf Inhalte, nicht auf Bedienelemente und Statusanzeigen.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

In einer Textverarbeitung muss ein Satz fett hervorgehoben dargestellt werden. Der entsprechende Bereich wird markiert und dann z.B. mit STRG+SHIFT+f fett hervorgehoben. Um zu prüfen, ob der Text nun auch wie gewünscht dargestellt wird, wird die Einfügemarke in diesem Bereich positioniert und mit der für den jeweiligen Screenreader typischen Tastenkombination werden die Textattribute ausgegeben.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschritt ist anwendbar, wenn die Anwendung Textinhalte enthält, die durch Attribute ausgezeichnet sind.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Hervorhebungen wie Unterstreichen, Fett oder Kursiv können einzelne Wörter oder Textabschnitte als besonders wichige Teile eines Textes kennzeichnen. Diese Informationen sollten auch für Screenreader-Nutzer zur Verfügung stehen, da sie wesentlich zum Textverständnis beitragen können.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Wechseln Sie mit EINF+N in den NVDA Einstellungsdialog und wählen Sie den Bereich "Dokumentformatierungen" aus. Dort aktivieren aktivieren Sie "Schriftattribute ansagen" und bestätigen mit mit "OK". Alternativ können Sie auch in der Textverarbeitung die Einfügemarke in einem hervorgehobenen Bereich positionieren und die Tastenkombination EINF+f drücken. Wenn Sie die Einfügen-Taste und dazu die Taste f zweimal kurz hintereinander drücken, erhalten Sie ein Meldungsfenster, in welchem alle Attribute zum Nachlesen angezeigt werden.

Der Prüfschritt ist erfüllt, wenn die Attribute korrekt wiedergegeben werden.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel werden nach der Bedeutung der fehlenden Information für die Arbeitsaufgabe bewertet. Die Hervorhebung eines Buchstabens zur Verdeutlichung der korrekten Lösung einer Aufgabe hätte beispielsweise eine hohe Bedeutung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11.3.2.10 Text: Where the software provides a user interface it shall, by using the services as described in clause 11.3.2.3, make the text contents, text attributes, and the boundary of text rendered to the screen programmatically determinable by assistive technologies.

==== WCAG ====

==== WCAG-Techniques ====

==== ISO9241-171 ====

4.03.1 - Name, Rolle, Wert für Formularfelder

2016-11-11T17:34:14Z

Petra: Schützte „4.03.1 - Name und Rolle für Formularfelder“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Formularfelder werden vom Screenreader mit ihrem Namen und ihrer Rolle wiedergegeben. Rollen sind u.a. Eingabefeld, Auswahlliste, Kombinationsfeld, Kontrollkästchen (Checkbox), Auswahlschalter (Radiobutton), Schalter (Submit-Button).

Der Name eines Formularfeldes entspricht der sichtbaren Beschriftung (Label). Wenn bei Eingabefeldern anstelle einer Beschriftung eine Vorbelegung des Feldinhalts angezeigt wird, so ist ein Name zusätzlich vorhanden. Wenn anstelle einer Beschriftung ein angrenzender Schalter verwendet wird, so entspricht der Name des Eingabefeldes der Beschriftung bzw. dem Namen des Schalters.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Ein Eingabefeld hat den Inhalt „Ihr Suchbegriff“, der Screenreader gibt zusätzlich den Namen „Suche“ aus.

Nicht voll erfüllt, Einschränkung: Ein Eingabefeld hat keinen Namen, aber der angrenzende Submit-Button hat den Namen „Suche“, der vom Screenreader bei TAB vorgelesen wird.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschritt ist anwendbar, wenn die Anwendung Benutzereingaben erwartet.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Das Formularfeld mit der Tastatur aktivieren und feststellen, ob der Name und Rolle und ggf. ein voreingestellter Wert richtig angesagt werden. Wenn der Name fehlt, kann durch Bewegung des Fokus festgestellt werden, ob im unmittelbaren Kontext ein Hinweis auf den Zweck des Feldes zu finden ist.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Wenn der Name des Formularfeldes fehlt, ist es eine Blockade oder Barriere.

Wenn kein Name vorhanden ist, aber der Zweck des Formularfeldes im Kontext ermittelt werden kann, ist es eine Einschränkung.

Wenn die Rolle nicht oder nicht zutreffend angesagt wird, ist der Mangel nach der Bedeutung für die Ausführung der Arbeitsaufgabe zu bewerten.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

Dieser Prüfschritt bezieht sich auf einzelne Formularfelder. Gruppen von Formularfeldern werden behandelt im Prüfschritt 4.04.0 „Name für Gruppen von Elementen“.

Dieser Prüfschritt bezieht sich nicht auf die sprachliche Gestaltung der Namen von Formularfeldern, diese wird behandelt in den Prüfschritten 1.05.1 „Prägnante Beschriftungen“ und 4.02.0 „Name für grafische Bedienelemente und Anzeigen“

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.7 Info and relationships

11. 2.1.34 Labels or instructions

11. 2.1.38 Name, role, value

11. 3.3.2.5 Object information

11. 3.3.2.8 Label relationships

==== WCAG ====

1.3.1 Info und Beziehungen können durch Software bestimmt werden

3.3.2 Beschriftung (Labels) oder Anweisungen

4.1.2 Name, Rolle, Wert

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.1.1 Für jedes Benutzungsschnittstellen-Element einen Namen vorsehen

8.1.4 Namen für unterstützende Technik verfügbar machen

8.5.4 Informationen zu Benutzungsschnittstellen-Elementen für unterstützende Technik verfügbar machen

3.08.1 - Keine unerwartete Kontextänderung

2016-11-11T17:33:32Z

Petra: Schützte „3.08.1 - Keine unerwartete Kontextänderung“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Wenn ein Bedienelement fokussiert wird oder eine Eingabe erhält, so löst dies nicht eine Änderung des Kontextes aus, es sei denn der Benutzer erhält einen Hinweis, wie er das Verhalten auf einfache Weise steuern kann.

Eine Kontextänderung ist eine wesentliche Änderung des Inhalts, oder eine Änderung des Fokus, des Bildausschnitts oder der Bedienmodalität.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Kein Fehler: Eine Kontextänderung wird explizit ausgelöst, z.B. mit der Eingabetaste auf einem „Aktionstrigger“ (Menüpunkt, Button, Link), oder durch das Verlassen eines Eingabefeldes mit TAB.

Fehler: Ein Dialog ist in mehrere Registerkarten aufgeteilt, die durch Karteireiter (Tabs) auswählbar sind. Bei Fokussierung eines Reiters wird automatisch die dazugehörige Karte angezeigt, der Fokus geht auf das erste Bedienelement der Karte. Um den nächsten Reiter auszuwählen, muss der Benutzer zunächst alle Bedienelemente der Karte passieren.<br />Kein Fehler: Wie **** zuvor, aber der Fokus geht nicht automatisch in die angezeigte Registerkarte, sondern erst beim Verlassen der Karteireiter mit der TAB-oder der ENTER-Taste, während die Auswahl eines Reiters mit den Pfeiltasten geschieht.

Kein Fehler: Ein Formular blendet zusätzliche Eingabefelder ein, je nachdem welche Option in einer Gruppe von 3 Optionsschaltflächen (Radiobutton) ausgewählt ist. Der Fokus bleibt bei den Optionsschaltflächen stehen. Die neuen Eingabefelder erscheinen unterhalb der Optionsschaltflächen.<br />Fehler: Wie zuvor, aber der Fokus wird automatisch auf das erste neue Eingabefeld gesetzt.<br />Fehler: Wie zuvor, aber die neuen Eingabefelder erscheinen oberhalb der Optionsschaltflächen, wo sie bei kleinem Bildausschnitt und sequentieller Bedienung nicht wahrgenommen werden.

Kein Fehler: Eine Präsentationssoftware bietet die Möglichkeit, Daten aus einer Tabellenkalkulation einzubinden und zu bearbeiten, wobei die Bedienelemente beider Komponenten in demselben Bildschirmbereich angezeigt werden. Die Bedienelemente der Tabellenkalkulation erscheinen erst dann, wenn der Benutzer den „Bearbeiten“-Button betätigt, und nicht bereits beim Fokussieren der Tabelle.

Kein Fehler: In einer Bibliotheksanwendung ist die Eingabe der 8-stelligen ISS-Nummer für Zeitschriften in zwei Felder aufgeteilt, mit einem dazwischen angezeigten Bindestrich. Nach der Eingabe der vierten Ziffer wechselt der Fokus automatisch in das zweite Eingabefeld (Auto-Tab). Die Beschriftung der Eingabefelder lautet „ISS-Nummer (fortlaufende Eingabe)“.<br />Fehler: Wie zuvor, aber das Auto-Tab-Verhalten ist nicht angekündigt.

Fehler: Ein Formular wird automatisch abgeschickt, sobald der Fokus das letzte Eingabefeld verlässt, ohne dass explizit ein Submit-Button zu betätigen wäre.<br />Ausnahme: in einem Suchfeld ist dieses Verhalten nicht unerwartet.

Fehler: Bei Fokussierung eines Eingabefeldes erscheint ein Popup mit einem Hilfetext, das erst mit ESC geschlossen werden muss, bevor die Eingabe erfolgen kann.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Die Software muss es den Benutzern ermöglichen, den Tastaturfokus zu bewegen, ohne dadurch bei irgendetwas anderem als der Positionsanzeige eine Wirkung hervorzurufen. Es muss eine bewusste Aktion des Benutzers vorgenommen werden, um jede andere Wirkung auszulösen. Dies ist besonders wichtig für Benutzer, die nicht die gesamte Anzeige auf einmal sehen können und die Benutzungsschnittstelle daher erkunden müssen, indem sie durch alle verfügbaren Bedienelemente navigieren. Wenn hierbei eine unbeabsichtigte Kontextänderung geschieht, können Benutzer desorientiert sein oder die Änderung zunächst gar nicht wahrnehmen, was im späteren Verlauf zu Problemen führt.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Praktische Erprobung:

* die unter Beschreibung und Beispiele genannten Fälle nachvollziehen
* wenn eine unerwartete Kontextänderung vorliegt: feststellen, ob sie mit einem einfachen Bedienschritt (ESC, Zurück o.ä.) wieder aufgehoben werden kann

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Wenn mehr als ein Bedienschritt benötigt wird, um die unerwartete Kontextänderung rückgängig zu machen, so ist dies eine Barriere.

Alle weiteren Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

Dieser Prüfschritt behandelt Einschränkungen der Tastaturbedienung wegen mangelnder Orientierung. Schwerwiegendere Fehlersituationen werden unter anderen Prüfschritten behandelt:

- Fehlersituationen, die dazu führen, dass eine Funktion nicht mit der Tastatur ausgeführt werden kann, werden im Prüfschritt 3.01.0 „Tastaturbedienung für Bedienelemente“ als Mangel gewertet.

- Fehlersituationen, die zu einem Fokusverlust führen, werden im Prüfschritt 3.07.0 „Sinnvolle Fokusreihenfolge“ als Mangel gewertet.

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.29 On focus

11. 2.1.30 On input

==== WCAG ====

3.2.1 Bei Fokus: Wenn irgendein Bestandteil den Fokus erhält, dann löst dies nicht eine Änderung des Kontextes aus.

3.2.2 Bei Eingabe: Die Änderung der Einstellung irgendeines Bestandteils der Benutzerschnittstelle führt nicht automatisch zur Änderung des Kontextes, außer der Benutzer wurde vor Benutzung des Bestandteils auf das Verhalten hingewiesen.

==== WCAG-Techniques ====

G107: Using "activate" rather than "focus" as a trigger for changes of context

G80: Providing a submit button to initiate a change of context

F36: Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value

==== ISO9241-171 ====

9.3.14 Tastaturnavigation und Aktivierung voneinander trennen

3.06.1 - Deutlich sichtbarer Tastaturfokus

2016-11-11T17:33:03Z

Petra: Schützte „3.06.1 - Deutlich sichtbarer Tastaturfokus“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Der Tastaturfokus ist deutlich sichtbar, so dass er von Menschen mit leicht eingeschränkter Sehfähigkeit ohne Anstrengung gefunden werden kann.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Im Hauptmenü einer Anwendung wird der Tastaturfokus durch invertierte Farben angezeigt.

In einem E-Mail-Client wird der Tastaturfokus in der Liste der eingegangenen Mails durch einen andersfarbigen Hintergrund und eine Rahmenlinie am linken Rand angezeigt.

Um das Kontrollkästchen, das fokussiert wird, wenn der Benutzer eine Pfeiltaste anschlägt, erscheint ein Rahmen oder ein markierter Bereich.

Um die Schaltfläche, die fokussiert wird, erscheint ein gepunkteter Rahmen.

Ein Text-Indikator (ein blinkender senkrechter Strich) erscheint im Dateneingabefeld an der Stelle, an der die eingegebenen Zeichen eingefügt werden.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Für den Tastaturbenutzer ist es wichtig, zu sehen, wo sich der Tastaturfokus gerade befindet, welche Aktion also ausgelöst wird, wenn er die Enter-Taste drückt, bzw. an welcher Stelle eingegebene Zeichen erscheinen werden. Ohne sichtbaren Tastaturfokus ist eine Anwendung für optisch orientierte Menschen praktisch nicht tastaturbedienbar.

Deutlich sichtbar ist der Tastaturfokus, wenn er von Normalsichtigen ebenso wie von Menschen mit leichter Einschränkung des Sehens, die aus Farbfehlsichtigkeit oder aus normaler Alterung resultiert, bei der durch Tastenanschläge hervorgerufenen Bewegung ohne Anstrengung gefunden werden kann. Die Bedingungen für gute Sichtbarkeit sind definiert in den Prüfschritten 1.01.0 „Ausreichender Kontrast“ und 1.07.1 „Informationen nicht allein durch Farbe übermitteln“.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Sichtprüfung im Anschluss an Prüfschritt 3.01.0 „Tastaturbedienung für Bedienelemente“: ist der Fokus sichtbar?

Weitere Prüfung der deutlichen Sichtbarkeit wie in den Prüfschritten 1.01.0 „Ausreichender Kontrast“ und 1.07.1 „Informationen nicht allein durch Farbe übermitteln“.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Wenn der Tastaturfokus in ganzen Bereichen der Anwendung nicht sichtbar ist, so ist dies eine Blockade.

Wenn der Tastaturfokus für mehr als 3 Tastenanschläge nicht sichtbar ist, so ist dies eine Barriere.

Wenn der Tastaturfokus schwach sichtbar ist, so ist dies eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

In diesem Prüfschritt geht es um die Normalansicht des Tastaturfokus. Die Konfiguration einer stärkeren optischen Hervorhebung für Menschen mit Sehbehinderungen ist Gegenstand des Prüfschritts 6.02.2 „Hilfsmittel zum Auffinden des Zeigers zur Verfügung stellen“.

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Eine strengere Definition von „deutlich sichtbar“ wird in ISO 9241-171 Nr. 9.2.2 „Für deutliche Sichtbarkeit des Tastaturfokus- und Text-Indikators sorgen“ gegeben, die diskussionswürdig erscheint. Denn ein grell gestalteter Tastaturfokus kann auch ablenken, wenn die Arbeitsaufgabe die Konzentration auf Informationen abseits der Tastatureingabe verlangt. Daher sollte der Fokus für Menschen mit Sehbehinderungen konfigurierbar sein.

=== Referenzen ===

==== EN301549 ====

11. 2.1.26 Focus visible

==== WCAG ====

2.4.7 Fokus sichtbar: Jede durch Tastatur bedienbare Benutzerschnittstelle hat einen Bedienmodus, bei dem der Tastaturfokus sichtbar ist.

==== WCAG-Techniques ====

==== ISO9241-171 ====

9.2.1 Tastaturfokus- und Text-Indikator zur Verfügung stellen

9.2.2 Für deutliche Sichtbarkeit des Tastaturfokus- und Text-Indikators sorgen

3.04.1 - Tastaturbedienung für Anzeigen (wie Mausbedienung)

2016-11-11T17:32:45Z

Petra: Schützte „3.04.1 - Tastaturbedienung für Anzeigen (wie Mausbedienung)“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Anzeigen, die mit der Maus bedienbar sind, können auch mit der Tastatur bedient werden.

Anzeigen sind Statusanzeigen, Anweisungen, Meldungen etc., die eine rein informative Funktion haben, ebenso nicht editierbare Daten. Solche Anzeigen können mit der Maus selektierbar sein, um Informationen daraus zu kopieren. Wenn dies der Fall ist, muss die Bedienung auch mit der Tastatur möglich sein.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Eine Anwendung zeigt Systemmeldungen mit Fehlercodes in der Statuszeile an. Um den Fehlercode zu kopieren, kann die Statuszeile mit F6 fokussiert, der Inhalt mit strg+a markiert und mit strg+c in die Zwischenablage kopiert werden.

Ein Buchhaltungsprogramm zieht den Banknamen der Kontoverbindungen aus einem internen Verzeichnis und zeigt ihn in der Liste der Kreditoren an, die nicht editierbar ist. Die einzelnen Listenelemente können mit Tastaturbefehlen selektiert und kopiert werden.

Die Anwendung nimmt Anzeigen in die TAB-Reihe auf, oder sie bietet spezielle Tastaturbefehle für die Fokussierung von Anzeigen an.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist anwendbar, wenn Anzeigen mit der Maus selektierbar sind.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Die Bedienung soll geräteunabhängig möglich sein. Das bedeutet: Sie muss sowohl mit der Maus als auch mit der Tastatur möglich sein.

Anzeigen werden häufig nicht in die Tastaturbedienung aufgenommen, da nach einer verbreiteten Bedienphilosophie nur solche Elemente mit der Tastatur erreichbar sein müssen, die eine Benutzereingabe erwarten oder eine Funktion auslösen. Wenn aber eine Anzeige mit der Maus selektiert werden kann, so muss dies auch mit der Tastatur möglich sein.

Die Möglichkeit, Inhalte von Anzeigen in die Zwischenablage zu kopieren, kann Benutzern mit Behinderungen helfen, das missliche, langsame oder fehleranfällige manuelle Eingeben des betreffenden Textes an anderer Stelle zu vermeiden.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Feststellen, welche Anzeigen mit der Maus selektierbar sind.

Tastaturbefehle für die Selektion der betreffenden Anzeigen ermitteln, über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Praktische Erprobung: Mit Tastaturbefehlen Text aus Anzeigen kopieren.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.15 Keyboard

==== WCAG ====

2.1.1 Tastatur

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.4.7 Unterstützung der Funktion „Kopieren“ in nicht editierbarem Text

9.3.2 Nutzung aller Funktionen über die Tastatur ermöglichen

4.04.0 - Name für Gruppen von Elementen

2016-11-11T17:30:53Z

Petra: Schützte „4.04.0 - Name für Gruppen von Elementen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Gruppen von Bedienelementen und Anzeigen, Funktionsbereiche der Anwendung, Dialogboxen etc. haben einen programmatisch erkennbaren Namen, der den Inhalt in natürlicher Sprache zutreffend beschreibt. Es gelten die im Prüfschritt 1.05.1 „Prägnante Beschriftungen“ ausgeführten Gestaltungsregeln.

Falls sichtbare Überschriften oder Titel vorhanden sind, ist der Name damit identisch.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Die Funktionsbereiche von Word heißen „Menüband“, „Dokument“ und „Statuszeile“. Der Name wird beim Fokussieren der Gruppe mit F6 vom Screenreader angesagt.

Der Druckdialog hat den sichtbaren Titel „Drucken“. Der Titel wird beim Öffnen des Dialogs vom Screenreader angesagt.

Eine Gruppe von Auswahlschaltern (Radiobuttons) hat die Überschrift “Bonität geprüft“, die Optionen haben die Beschriftungen „ja“, „nein“, „in Arbeit“. Die Überschrift wird bei der Aktivierung der Optionen vom Screenreader mit vorgelesen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschritt ist anwendbar, wenn die Anwendung optisch unterscheidbare Funktionsbereiche und Gruppierungen hat oder Dialogfenster öffnet.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Anwendungsprogramme bieten sehenden Benutzern eine visuelle Ordnung, mit deren Hilfe sie sich orientieren können. Diejenigen, die diese Ordnung nicht nutzen können – zum Beispiel, weil sie blind sind oder nur einen kleinen Ausschnitt sehen können – sind darauf angewiesen, dass die Struktur unabhängig von der Darstellung auf dem Bildschirm zugänglich und nutzbar ist. Die Benennung von Gruppen, Funktionsbereichen und Dialogfenstern erlaubt es Nutzern assistiver Technologien, sich ein mentales Modell vom Aufbau der Anwendung zu machen. Programmatisch erkennbare Namen treten dort ein, wo sichtbare Überschriften und Titel fehlen, da sie für den sehenden Nutzer nicht erforderlich sind.

Benutzer von Spracheingaben können Funktionsbereiche über ihren Namen direkt anspringen.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests}''

Funktionsbereiche der Anwendung, Gruppen von Elementen und Dialogfenster durch die entsprechenden Tastaturkommandos fokussieren. Sagt der Screenreader einen Namen bzw. eine vorhandene sichtbare Überschrift an?

Falls ein Tastaturkommando nicht verfügbar ist, den Bereich mit Screenreader-Funktionen fokussieren.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel werden nach ihrer Bedeutung für die Ausführung der Arbeitsaufgabe bewertet.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.7 Info and relationships

11. 2.1.34 Labels or instructions

11. 2.1.38 Name, role, value

11. 3.3.2.5 Object information

3.2.9 Parent-child relationships

==== WCAG ====

1.3.1 Info und Beziehungen

3.3.2 Beschriftungen oder Anweisungen

4.1.2 Name, Rolle, Wert

==== WCAG-Techniques ====

H71: Providing a description for groups of form controls using fieldset and legend elements

==== ISO9241-171 ====

8.1.1 Für jedes Benutzungsschnittstellen-Element einen Namen vorsehen

9.3.17 Die Navigation von Steuerungselementen durch Gruppierung erleichtern

10.5.1 Eindeutige und verständliche Fenstertitel vorsehen

4.02.0 - Name für grafische Bedienelemente und Anzeigen

2016-11-11T17:30:38Z

Petra: Schützte „4.02.0 - Name für grafische Bedienelemente und Anzeigen“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Grafische Bedienelemente und Anzeigen ohne sichtbare Beschriftung haben einen programmatisch erkennbaren Namen, der den Zweck des Elements in natürlicher Sprache zutreffend beschreibt. Der Name soll möglichst kurz und prägnant sein.

Soweit Text abgebildet ist, gibt der Name den Inhalt des Textes wieder.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Nicht sinnvolle Namen sind deskriptive Beschreibungen der Grafik wie z.B. „grüner Haken“ für einen OK-Button oder „Briefumschlag“ für den Aufruf eines Kontaktformulars.

Nicht sinnvoll sind z.B. Bezeichnungen aus der Programmierung wie „element5“ oder „xyz.png“.

Ein OK-Button hat den grafischen Schriftzug „OK“. Der Button hat einen programmatisch erkennbaren Namen „OK“.

Bei Statusanzeigen sind sowohl der Name als auch der angezeigte Wert erkennbar. Beispiel: Ein Icon für den Internetzugriff hat verschiedene Darstellungen je nach dem Status der Verbindung. Name ist „Internet“, Werte sind „verbunden“ und „nicht verbunden“.

Im übrigen gelten die im Prüfschritt 1.05.1 „Prägnante Beschriftungen“ ausgeführten Gestaltungsregeln.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschritt ist anwendbar, wenn grafische Bedienelemente und Anzeigen vorhanden sind.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Rein grafische Elemente sind für blinde Benutzer nicht zugänglich. Der programmatisch erkennbare Name dient dazu, dem Benutzer die Identität des Elements über den Screenreader mitzuteilen. Dasselbe gilt für Benutzer von Spracheingaben, die das Element über den Namen auswählen können.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests}''

Alle grafischen Elemente der Anwendung mit Tastatur oder Screenreader fokussieren und feststellen, ob ein zutreffender Name gesprochen wird, der den unter Beispiele genannten Gestaltungsregeln entspricht.

Eine doppelte Ausgabe des Namens für ein Element bzw. zwei verschiedene Namen sollen nicht vorkommen.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel werden nach der Bedeutung des Elements für den geprüften Arbeitsschritt bewertet.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

Folgende Bedienelemente werden bereits in anderen Zusammenhängen geprüft und sollen in diesem Prüfpunkt ausgenommen werden, um eine doppelte Bewertung zu vermeiden:

* Bedienelemente zur Steuerung des Tons
* Bedienelemente zum Öffnen der Dokumentation oder Online-Hilfe

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.1 Non-text content (screen reading supported)

11. 2.1.38 Name, role, value

11. 3.3.2.5 Object information

==== WCAG ====

1.1.1 Nicht-Text-Inhalt

4.1.2 Name, Rolle, Wert

==== WCAG-Techniques ====

==== ISO9241-171 ====

8.1.1 Für jedes Benutzungsschnittstellen-Element einen Namen vorsehen

8.1.4 Namen für unterstützende Technik verfügbar machen

8.5.4 Informationen zu Benutzungsschnittstellen-Elementen für unterstützende Technik verfügbar machen

4.01.0 - Wiedergabe von Text

2016-11-11T17:30:19Z

Petra: Schützte „4.01.0 - Wiedergabe von Text“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Alle sichtbaren Texte der Anwendung werden vom Screenreader vorgelesen.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Alle Beschriftungen, Anweisungen, Meldungen und Textinhalte der Anwendung werden vom Screenreader vorgelesen.

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Der Prüfschritt spiegelt das erste Kennenlernen einer Anwendung, in der der Bildschirminhalt von oben bis unten unten linear im Screenreader gelesen wird. Dabei sollen mindestens alle sichtbaren Texte der Anwendung wiedergegeben werden. Ausfälle sind ein Hinweis auf nicht standardkonforme Programmierung, die in späteren Prüfschritten weiter untersucht wird.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Nach dem Öffnen der Anwendung zunächst feststellen, wo der Tastaturfokus steht. Ab hier mit der Screenreader-Funktion „Alles lesen“ die Bildschirminhalte von oben bis unten lesen. An den Anfang des Bildschirms gehen und ab hier die Bildschirminhalte bis zum Einstiegspunkt lesen.

Werden alle sichtbaren Texte der Anwendung vom Screenreader vorgelesen?

Falls einzelne Texte nicht vorgelesen werden, das Element nach Möglichkeit mit der Tastatur fokussieren und erneut vorlesen lassen.

Bei fortgeschrittener Abarbeitung des Szenarios wiederholen sich Bildschirmbereiche wie etwa das Hauptmenü der Anwendung. In diesem Fall den Tastaturfokus auf den Anfang des neu angezeigten Bildschirmbereichs setzen und ab hier lesen.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel werden nach der Bedeutung des fehlenden Teils für die Arbeitsaufgabe bewertet.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

In diesem Prüfschritt geht es um die Wiedergabe sichtbarer Texte. Keine Rolle spielen weitere ggf. vom Screenreader ausgegebene Informationen wie die Namen grafischer Bedienelemente, Erläuterungen zu Bedienelementen etc.

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.14 Images of text

11. 2.1.38 Name, role, value

11. 3.3.2.7 Values

11. 3.3.2.10 Text

==== WCAG ====

1.4.5 Bilder eines Textes

4.1.2 Name, Rolle, Wert

==== WCAG-Techniques ====

==== ISO9241-171 ====

3.11.0 - Vollständige Dokumentation der Tastaturbefehle

2016-11-11T17:30:04Z

Petra: Schützte „3.11.0 - Vollständige Dokumentation der Tastaturbefehle“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

Alle in der Anwendung vorhandenen Tastatur-Befehle müssen nachgeschlagen werden können.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Keine

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Nach DIN EN 82079 Erstellen von Gebrauchsanleitungen ist die Dokumentation ein Bestandteil des Produkts und muss richtig, vollständig und zielgruppengerecht aufbereitet sein.

Besonders wenn Nutzer auf die Tastatur angewiesen sind, benötigen sie eine vollständige Dokumentation der Tastaturbefehle, um die Bedienung der Anwendung erlernen zu können. Selten gebrauchte Tastaturbefehle sind den Benutzern nicht geläufig und müssen nachgeschlagen werden können.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Ermitteln Sie die für die aktuelle Situation des Szenarios einzusetzenden Tastaturkommandos über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Prüfen Sie, ob die ermittelten Tastaturkommandos richtig und vollständig in der zusammenhängenden Dokumentation der Anwendung oder in der Windows-Hilfe verzeichnet sind.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

In diesem Prüfpunkt geht es um die Dokumentation im Sinne einer zusammenhängenden Darstellung von Bedienfunktionen. Eine kontextsensitive Hilfe, die punktuelle Hinweise auf Tastaturkommandos geben kann, ist Gegenstand des Prüfpunkts „kontextsensitive Hilfe“.

In diesem Prüfpunkt geht es um die Inhalte der Dokumentation. Die Barrierefreiheit der Dokumentation und der barrierefreie Zugang zur Dokumentation sind Gegenstand des Prüfplans „Dokumentenprüfung“.

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

12.1.1. Accessibility and compatibility features

==== WCAG ====

*

==== WCAG-Techniques ====

==== ISO9241-171 ====

11.1.1 Verständliche Dokumentationen und Hilfen zur Verfügung stellen

==== Weitere Standards ====

DIN EN 82079 Erstellen von Gebrauchsanleitungen

3.07.0 - Sinnvolle Fokus-Reihenfolge

2016-11-11T17:29:48Z

Petra: Schützte „3.07.0 - Sinnvolle Fokus-Reihenfolge“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Beim sequentiellen Navigieren mit der Tastatur erhalten die Bedienelemente einer Anwendung den Fokus in einer Reihenfolge, die der Bedeutung oder dem Bedienablauf entspricht. Dies ist in der Regel der Fall,

* wenn die Bedienelemente in einer Reihenfolge fokussiert werden, die der sichtbaren Anordnung entspricht,
* wenn ein sich öffnender Dialog den Tastaturfokus erhält,
* wenn beim Schließen eines Dialogs der Fokus zu seiner Ausgangsposition oder zum logisch folgenden Element zurückkehrt.

Die sinnvolle Reihenfolge muss nicht immer eindeutig sein, beispielsweise kann eine Tabelle sowohl zeilen- als auch spaltenweise gelesen werden.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

Beim Navigieren mit TAB und Pfeiltasten bewegt sich der Tastaturfokus entlang der logischen Blöcke der Bedienelemente.

In einer Baumstruktur kann der Benutzer mit den Pfeiltasten aufwärts und abwärts gehen. Pfeil-rechts öffnet eine Ebene, Pfeil-links schließt eine Ebene.

In einer Suchfunktion öffnet sich ein Dialog mit erweiterten Suchoptionen und einem OK-Button. Nach dem Beenden des Dialogs mit OK landet der Tastaturfokus auf dem ersten Element der angezeigten Suchergebnisse.

Fehler: Ein Formular ist in zwei nebeneinander stehende Blöcke angeordnet, wobei links Eingabefelder für Kontaktdaten mit Name, Anschrift etc. und rechts Checkboxen mit verschiedenen Statusangaben wie Kunde, Interessent etc. stehen. Beim Bedienen mit TAB erreicht der Benutzer abwechselnd ein Element des linken und des rechten Blocks.

Fehler: Beim Schließen eines Dialogfeldes kehrt der Fokus nicht zum auslösenden Button zurück, sondern landet am Anfang des Bildschirms.

Fehler: Beim Öffnen eines Dialogfelds erhält ein Element den Fokus, das aus Sicht des Anwenders zufällig erscheinen muss, weil es weder der aktuellen Aufgabe, noch einer Default-Position, noch dem zuletzt aktivierten Element entspricht. (Nicht verlangt wird, dass der Fokus immer auf dem ersten Bedienelement eines Dialogfensters stehen muss.)

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Dieser Prüfschritt ist immer anwendbar.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Durch eine nicht nachvollziehbare Reihenfolge der fokussierten Elemente kann die Tastaturbedienbarkeit für jeden Benutzer erheblich beeinträchtigt werden. Sehbehinderte oder blinde Benutzer sind darüber hinaus eingeschränkt in ihrer Fähigkeit, sich ein mentales Modell der Anwendung zu manchen.

Nach einem Dialog muss der Benutzer ggf. viele Tasten betätigen, um zu seiner vorigen Position und Auswahl zurückzukehren, falls der Tastaturfokus nicht automatisch wiederhergestellt wird.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Praktische Erprobung:

-         die unter Beschreibung und Beispiele genannten Fälle nachvollziehen

-         bei Mängeln feststellen, wie viele Bedienschritte (Tastenanschläge) benötigt werden, um zu der für die Arbeitsaufgabe sinnvollen Reihenfolge zurückzukehren

-         bei Mängeln feststellen, ob der Tastaturfokus gut sichtbar ist (Prüfschritt 3.06.1)

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Wenn mehr als drei Bedienschritte (Tastenanschläge) benötigt werden, um zu der für die Arbeitsaufgabe sinnvollen Reihenfolge zurückzukehren, so ist dies eine Barriere.

Wenn bei Benutzereingaben die Reihenfolge des Tastaturfokus willkürlich erscheint, und zugleich der Fokusindikator nur schwach sichtbar ist, so ist dies eine Barriere.

Alle weiteren Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

=== Referenzen ===

==== EN301549 ====

11. 2.1.22 Focus order

==== WCAG ====

2.4.3 Fokus-Reihenfolge

==== WCAG-Techniques ====

==== ISO9241-171 ====

9.2.3 Bei Wiedererhalten des Tastaturfokus den letzten Stand bereitstellen

9.3.18 Steuerungselemente in Gruppen anordnen, die der Navigationsreihenfolge entsprechen

3.03.0 - Direktzugriff auf Funktionsbereiche

2016-11-11T17:29:31Z

Petra: Schützte „3.03.0 - Direktzugriff auf Funktionsbereiche“ ([Bearbeiten=Nur Administratoren erlauben] (unbeschränkt) [Verschieben=Nur Administratoren erlauben] (unbeschränkt))

=== Beschreibung ===

''[Technikneutrale Beschreibung des Erfolgskriteriums]''

Verschiedene Funktionsbereiche der Anwendung wie Menü, Werkzeugleiste und Statuszeile sowie verschiedene Inhaltsbereiche wie Baumansicht und Detailansicht können durch einen Tastaturbefehl angesprungen werden.

=== Beispiele ===

''[Typische Anwendungsbeispiele aus verschiedenen Plattformen]''

In Office-Anwendungen mit der ALT-Taste zwischen Menü und Dokument wechseln.

Im Dateimanager mit TAB zwischen Adresszeile, Baum und Dateiliste wechseln.

Mit F6 zwischen den Abschnitten (Panes) einer Anwendung wechseln (Windows Standard).

=== Anwendbarkeit ===

''[manche Erfolgskriterien sind nur in speziellen Kontexten anwendbar]''

Der Prüfschritt ist anwendbar, wenn die Anwendung optisch unterscheidbare Funktionsbereiche hat.

=== Begründung ===

''[Warum wird das geprüft? Bedeutung des Prüfpunktes für Menschen mit Behinderungen]''

Anwendungsprogramme bieten sehenden Benutzern eine visuelle Ordnung, mit deren Hilfe sie sich orientieren können. Diejenigen, die diese Ordnung nicht nutzen können – zum Beispiel, weil sie blind sind oder nur einen kleinen Ausschnitt sehen können – sind darauf angewiesen, dass die Struktur unabhängig von der Darstellung auf dem Bildschirm zugänglich und nutzbar ist. Der Direktzugriff auf Funktionsbereiche der Anwendung erlaubt Nutzern assistiver Technologien, sich ein mentales Modell vom Aufbau der Anwendung zu machen. Auch sehende Tastaturbenutzer und Benutzer von Spracheingaben profitieren davon, wenn sie Bereiche überspringen bzw. direkt anspringen können.

=== Prüfanleitung ===

''[Technikspezifische Prüfanleitung (oder Prüfvorschlag) mit Tools zur Unterstützung des praktischen Tests]''

Die generellen Tastaturbefehle der Anwendung ermitteln, über die Dokumentation oder über andere Quellen wie kontextsensitive Hilfe, Herstellerinterview, eigene Erprobung.

Gibt es Tastaturbefehle für einen Direktzugriff auf die sichtbar unterschiedenen Funktionsbereiche der Anwendung wie Hauptmenü, Werkzeugleisten, Statuszeile, Datenbereich?

Falls ja, praktische Erprobung: Tastaturbefehl zum Direktzugriff auf die Funktionsbereiche anwenden und überprüfen, ob der Tastaturfokus folgt (ggf. mit TAB oder Pfeiltasten ein Element innerhalb des Funktionsbereichs auswählen).

Falls ein Funktionsbereich keine fokussierbaren Elemente enthält, kann er für diesen Prüfschritt nicht ausgewertet werden. Zur weiteren Prüfung siehe 4.04.0 „Name für Gruppen von Elementen“ und 5.04.1 „Fokusverfolgung im Großbildsystem“.

=== Bewertungsalternativen ===

''[Abgrenzung von „erfüllt“ und „nicht erfüllt“, sowie von „Blockade/Barriere“ und „Einschränkung“]''

Mängel sind eine Einschränkung.

=== Einordnung ===

''[Abgrenzung zu anderen Prüfschritten]''

=== Offene Fragen ===

''[Fragen sammeln, die während der Entwicklung des Prüfschritts auftauchen]''

Die Zuordnung dieses Prüfschritts zu Stufe 0/I = Konformität mit EN 30549 stützt sich auf EN 301549 Nr. 11. 2.1.7 Info and relationships, obwohl dieses Erfolgskriterium sich eher auf die Benennung der Funktionsbereiche als auf ihre Tastaturbedienbarkeit bezieht. WCAG 2.4.1 „Blöcke umgehen“ bezieht beide Aspekte, Tastaturbedienung und Benennung, mit ein, und wird damit der praktischen Nutzbarkeit von programmatisch erkennbaren Strukturmerkmalen besser gerecht. EN 301549 hat den WCAG-Punkt nicht übernommen – eine Entscheidung, die überdacht werden sollte.

=== Referenzen ===

==== EN301549 ====

11. 2.1.7 Info and relationships

==== WCAG ====

1.3.1 Info und Beziehungen

2.4.1 Blöcke umgehen

==== WCAG-Techniques ====

==== ISO9241-171 ====

9.3.17 Die Navigation von Steuerungselementen durch Gruppierung erleichtern