Jump to content

Leitfaden zur Barrierefreiheit für Entwickler

From mediawiki.org
This page is a translated version of the page Accessibility guide for developers and the translation is 34% complete.
Languages:

Barrierefreiheit ist wichtig für unsere Nutzer und wir können sie verbessern, wenn wir einige grundlegende Ideen und Regeln berücksichtigen. Barrierefreiheit ist insofern schwierig, als dass es keine festen und allgemein akzeptierten technischen Standards gibt, die tatsächlich einheitlich und für alle Nutzer funktionieren. Auf dieser Seite werden keine spezifischen Probleme mit der Barrierefreiheit in MediaWiki gelistet oder diskutiert. Es wird versucht, sich auf die Auswahl von Technologien und die "Dos and Don'ts" zur Vermeidung von Barrieremöglichkeiten zu konzentrieren.

Was die Entwicklung betrifft, so denke ich, sollte dies unser Regelwerk sein:

  • Versuchen Sie, unseren Nutzern (und damit sind alle gemeint) den Zugang zu erleichtern
  • Versuchen Sie Probleme der Unzugänglichkeit zu umgehen, wenn dies möglich ist, aber nicht um jeden Preis.
  • Wir sollten die Herangehensweise der progressiven Verbesserung gegenüber der, der würdevollen Verschlechterung
  • Implementieren Sie Dinge, die technisch sinnvoll/vernünftig sind

Wie Barrierefreiheit funktioniert

Einige wichtige Konzepte, die Sie im Hinterkopf behalten sollten.

Zugänglichkeitsmessungen in vielen Formen

Barrierefreiheit hat mit vielen Dingen zu tun, bitte stellen Sie sich Folgendes vor:

  • Einiges sollte verständlich sein: Das heißt Textbezug, visuelle Darstellung, Logik und Komplexität.
  • Einige Benutzer benötigen ein Bildschirmlesegerät, um zu interagieren, aber genauso häufig, wenn nicht sogar häufiger, sind: eine Lupe, ein höherer Kontrast, eine Text-to-Speech-Engine (Text zu Sprache), benutzerdefinierte CSS-Einstellungen oder eine spezielle Art von Tastatur/Eingabegerät.
  • Es muss erreichbar sein; Anpassungsfähigkeit, Erschwinglichkeit, Standort, Sprache, Hardware usw.

Zusammenfassend lässt sich sagen, dass Zugänglichkeit nicht "nur" Tastaturzugänglichkeit "oder nur" Bildschirmlesezugänglichkeit bedeutet. Wir konzentrieren uns oft auf diese beiden, weil sie traditionell leicht übersehen werden. Aber auch diese Probleme sind lösbar und bilden oft die Grundlage, um andere Verbesserungen möglich zu machen.

Einige Probleme mit der Zugänglichkeit sind eher Probleme mit dem Produktdesign, strategischen Entscheidungen, der Zielgruppe usw. Da diese Bereiche schwieriger in niedergeschriebenen Regeln zu erfassen sind, die universell für das MediaWiki Ökosystem gelten, liegen sie außerhalb des Rahmens dieses Dokuments.

Tastaturnavigation

Wir nennen das Tastaturnavigation, aber was es wirklich bedeutet, ist: Verlassen Sie sich nicht auf ein Zeigergerät (Touch, Maus).

  • Bei der Tastaturnavigation geht es darum, den Fokus zu manipulieren und Aktionen mit der Tastatur auszuführen.
  • Elemente, die man "antippen/klicken kann" können auch fokussiert werden, aber nicht alles, was fokussiert werden kann, kann auch angetippt werden.
  • Alles, was man mit einer Maus machen kann, sollte auch mit einer Tastatur möglich sein.
  • Die Informationen zur Tastaturnavigation können von Bildschirmlesegeräten genutzt werden, um die Benutzerfreundlichkeit zu erhöhen.

Bildschirmleser

  • Eine Vorleseanwendung verwendet einen anderen "Cursor", welcher meist der logischen Struktur des DOM folgt.
  • Der Fokus neigt dazu, dem Cursor der Vorleseanwendung zu folgen (und umgekehrt), aber sie sind nicht dieselben.
    • Du kannst das fokussierte Element im Auge behalten, indem du eine Live-Expression in Chrome einstellst [1]
  • Eine Vorleseanwendung nutzt die Barrierefreiheit APIs, welche man als Eingabe/Ausgabe "Ansicht" sehen kann, welche dem normalen DOM übergeordnet ist.
  • ARIA sind DOM-Annotationen welche die Umwandlung der DOM-Logik in die APIs für Barrierefreiheit verbessert oder beeinflusst. Es ist keine Alternative dazu, richtiges HTML und JavaScript zu entwickeln. Tastaturnavigation wird durch die logische DOM-Reihenfolge erreicht. Für mehr zu ARIA siehe auch w3.org Erklärung und MDN Erklärung
  • Eine Vorleseanwendung ist nicht auf das Navigieren nach der logischen DOM-Struktur beschränkt, es ist aber der Standard.
    • Eine Vorleseanwendung kann zum Beispiel auch den Text unter dem Mauzeiger lesen.
    • VoiceOver für iOS benutzt eine Vorleseanwendung, welche durch die Positionierung des Daumens und Gesten am Touchscreen gesteuert wird.
    • Viele Vorleseanwendungen haben zusätzliche Navigationsmodi, bei denen der Benutzer markante Bereiche (ein automatisch generiertes Inhaltsverzeichnis) oder benutzerdefinierte "Lesezeichen" auf der Seite navigieren kann.
  • Aus dem obigen Punkt der verschiedenen Navigationsmethoden folgt: Es gibt einen Anfang und ein Ende, aber auch links, rechts, oben und unten. Sie sollten sich in Ihrer Kommunikation nicht zu sehr auf sie verlassen, aber Sie müssen ihre Existenz auch nicht völlig verleugnen. Verwechseln Sie nicht die visuellen Fähigkeiten des Benutzers mit der räumlichen Wahrnehmung, die der Bildschirmleser dem Benutzer vermitteln kann. Beispiel:
    1. a long sentence [image] the above image shows... Still acceptable
    2. a long sentence [image][image] the left image shows, the right image shows... Still acceptable
    3. a long sentence [image][image] the right image shows, the left image shows... Not acceptable
    4. a long sentence [image][image] the above image shows... Not acceptable
    5. a long sentence [image][image][image] the left image shows, the right image shows... Not acceptable
    6. a long sentence [image][image] something totally different. the left image shows, the right image shows... Definitely not acceptable

Entwicklungsrichtlinien

Es gibt mehrere Normen für die Barrierefreiheit, und ehrlich gesagt haben fast alle von ihnen, obwohl sie die Probleme gut erkennen, immer noch erhebliche Probleme, wenn es um technische Lösungen geht (sie haben einen hohen Anteil an "hässlichen Workarounds"). Dies hat in den Gesellschaften zu großen Kontroversen geführt. Daher sollten wir unumstrittene Dinge benennen, die wir einfach immer (oder nie) tun sollten und warum. Es ist viel einfacher, bestimmte Ziele zu erreichen, wenn wir die unumstrittenen Dinge von den umstrittenen trennen.

Verwende immer oder stell immer bereit

Korrektes semantisches HTML-Element
Verwenden Sie HTML-Elemente für den vorgesehenen Zweck. Zum Beispiel:
  • Use ‎<button> and not ‎<div> or ‎<span> or ‎<a> with a click handler
  • If you feel the need to bold something, consider if it is not more appropriate to use a header or a strong element
Logischer Aufbau der Überschriften
Alle Seiten sollten stets eine logische und einheitliche Überschriftenstruktur aufweisen. Überschriften sind eines der wichtigsten Navigationsmittel für Benutzer von Bildschirmlesegeräten.
  1. There should be no gaps in the nesting of the heading levels. (So no H2->H4.)
  2. Headings should be descriptive
  3. Headings should be unique within their own level. (There should not be two H3s with the same content under the same H2 section)
  4. There should be separation between navigation and content
alt attribute for images with meaningful values
Wenn ein Bild dekorativ ist, verwenden Sie einen expliziten leeren Wert für das alt-Attribut; noch besser ist es, es in ein CSS-Hintergrundbild zu verwandeln.
the image alt usually takes precedence over the title attribute of images and even over the title attribute of links that wrap an image.
title attribute for links
Diese werden in der Regel in den Tooltips angezeigt
Only use titles if they differ from the link text.
Most link titles are not actually spoken by screen readers, unless the reader has been explicitly configured this way.
lang, dir and hreflang attributes
Using lang and hreflang enables selecting a proper voice in screen readers, picks the right spelling correction in browsers etc.
Sufficient contrast
Always check your colors for sufficient contrast. For text, a higher contrast is needed for smaller text (due to anti-aliasing).
Focus for keyboard navigation
Do not remove outline from focusable elements unless you define your own outline for the :focus state.
  • Don't use outline: 0 otherwise.
  • If you define any pseudo class, like :hover or :active, please also define a :focus style.
Keyboard navigation
Interactive elements of a page should be navigable by keyboard. Please make sure tab key navigation is enabled in your browser and allows you to control each interactive element without making use of a pointing device.
  1. Use tabIndex: 0 to make elements keyboard accessible, which are not keyboard accessible implicitly (Anything but ‎<a>, ‎<area>, ‎<button>, ‎<input>, ‎<object>, ‎<select>, ‎<textarea>).
    1. In this case also add a keydown handler responding to Enter (keyCode 13) and space (keyCode 32).
  2. Use tabindex: -1 to remove elements from accessibility. (use this on links that are labels for the action inside an ‎<li>...‎</li> for instance)
  3. Elements that are implicitly keyboard accessible will forward enter/space keydown to the click handler
Dialogs etc.

When not taking good care of accessibility, dialogs are some of the most inaccessible elements for screen reader and keyboard users. Spend some time on this.

  • The element that opens the dialog should have aria-haspopup
  • The dialog itself should have role=[dialog | alertdialog | tooltip]
  • The dialog should be inserted in DOM order,[1] or aria owns/controls needs to specify this relation between opening element and dialog
  • When opening the dialog, remember last focused element and shift focus to the first focusable tabbable element inside the dialog
  • When the dialog is modal, make it impossible to interact with the rest of the page
    • Capture clicks outside the dialog and ignore them or let them dismiss the dialog
    • Make sure you cannot tab to links or input elements outside of dialog
    • Make elements outside of the dialog unreachable for screen reader, by using aria-hidden
  • Make sure there is a close mode (Esc key and a focusable close button with a descriptive title)
  • Closing should return the (keyboard) focus to the original focus point that you stored when you opened the dialog. For screen readers to return to the same point, be sure to specify the right owner of the dialog, if you have not inserted the dialog in DOM order.
  • Read up: Aria modals, Aria modal dialog, ARIA nonmodal dialog, ARIA tooltips.
WCAG 2.1 guidelines
Follow wherever possible
And its accompanying documents:

Nicht

  • There is common advice to use left: -1000px to push something (often the labels of icon buttons) out of the viewport for visual users and still have it in the accessibility DOM. text-indent: -9999px is variant of this. This is BAD advice.
    • This breaks our RTL rendering in several browsers. Specifically in rtl mode it creates a large canvas left of the viewport and scrollbars, much as +1000px would create in ltr mode. (If needed, top: -1000px is preferred over left: -1000px to avoid this).
    • VoiceOver on mobile is unable to use this text as a fallback, since it is a 'positional' screen reader. You cannot move your finger over this text and thus the text will not be read either. (aria-label is often the better choice).
    • Lastly, this enlarges the render surface needed to calculate the final webpage and this can impact performance [2] on mobile devices.
    • Insightful overview of 'hide text offscreen' tricks are given by Jonathan Snook.
  • Things should not be repeated often. If you have a 100 links on a page that can open a dialog, then don't add 100 labels to those 100 links telling the user that it can be used to open a dialog. Telling a user how to use/what to do with the interface is a good thing, doing it consistently is simply annoying. Find a different way to explain it once (an aria-live=polite might be an idea in this case ?).
  • <a href="#">Hide</a> with an onclick handler. VO reads such JS as "internal link Hide". Use a proper button, or <a role="button" tabindex="0">Hide</a>, with 'Space' and 'Enter' key handlers in the onclick. But no href attribute.
  • Do not nest interactive functionality inside another interactive element (links or buttons inside links). This confuses screen readers.

Vermeide

Unicode symbols
Most assistive technologies are not good with symbols. Therefore, try to avoid characters such as ↑, →‎ or more complex characters, because many screen reader won't understand them. If they are required, try to wrap with a span element with the title attribute, so that the title attribute can communicate the implicit meaning within the context to the reader.
Small fonts
Legibility is preferred. If you make something so small that it is hard to read, do you even need it to begin with? Also avoid small fonts with low or mediocre contrast values (even if they fall inside the WCAG guidelines, small sizes require more explicit contrast then large sizes, especially with anti aliasing enabled).
Unusually large fonts
If you make text much larger than normal, it can become similarly hard to read (unless it's very short). This applies mostly to body text, or anything that takes up more than a couple lines. But the larger the text is, the more lines it will take up.
tabIndex > 0
DOM order is preferred wherever possible. DOM order provides context for the actions.
Workaround
Traditionally, accomplishing 'full' accessibility has required a lot of workarounds for html itself, the browsers and even specific screenreader software. However these workarounds often come with side effects, make use of bugs or unspecified behavior and inevitably create technical debt.
MediaWiki, because of the users it seeks to serve, the amount of code, it's (lack) of funding, etc tends to prefer future proof code over code that easily breaks. As such it generally avoids workarounds even if that might sometimes limit the accessibility we can deliver. Decisions on this are often influenced by the relative audience of the feature in MediaWiki. If something is ubiquitous for all users a workaround is more warrented than if the feature affected is only used by a tiny part of the audience (for instance, reading a page vs modifying the configuration of the installation).

Bedenke

  • ARIA Roles
    • If a div or span behaves like an actual button use role="button". also role="dialog" and role="alert"
    • Be careful with roles. For instance, don't add role="button" to a ‎<th> element, since the ‎<th> element has an implicit role="columnheader", which will be overwritten. Instead use nested elements. Similarly for ‎<li> which has an implicit role="listitem"
    • If a button creates a popupdialog, use aria-haspopup.
    • Use aria-labelled-by for contexts where this is not fully logical by itself (so everywhere except for labels in forms and headers in tables).
  • Avoid tables for layout purposes and test on smaller screen widths.
  • hide stuff: https://www.tpgi.com/html5-accessibility-chops-hidden-and-aria-hidden/
  • skip/jump to links

Siehe auch

Nachweise

  1. ↑ See DOM order at w3.org and Style order Property at w3schools.org
Retrieved from "https://www.mediawiki.org/w/index.php?title=Accessibility_guide_for_developers/de&oldid=6335283"