search

BIK-BITV / BIK-Web-Test

Testverfahren zur Prüfung der Barrierefeiheit von Webanwendungen anhand der Kriterien der WCAG 2.1, EN 301 549 und BITV 2.0
67 stars 21 forks source link

Anforderung an BITV Konforme Verlinkung von Bildern - 9.1.1.1a #343

Closed benjaminkott closed 1 year ago

benjaminkott commented 1 year ago

Ich bin mir nicht sicher ob dieses der Korrekte platz dafür ist, aber mir wurde geraten mich bei Fragen / zum BITV Test / Prüfschritten an dieses Repository zu wenden.

Um etwas Kontext zu bieten, handelt es sich hier um Bilder mit Title, Alternativ Text und Beschreibung. Diese Bilder werden wahlweise einzeln, oder als Galerie in den Kontext der Seite eingebettet. Diese können von einem Text begleitet werden, müssen es aber nicht.

Die Bilder werden wie gewohnt ausgezeichnet und als Figure bereit gestellt, wie erwähnt mit Title, Alternativ Texten und Beschreibung (Caption) sofern vorhanden.

Hier ein Beispiel wie ein unverlinktes Bild innerhalb vom Content gerendert wird. Da es nicht um den exakten content der Attribute geht habe ich diese mit ### Markern als Platzhalter versehen.

<figure>
    <picture>
        <source
            media="(min-width: 1400px)"
            srcset="733d86bd49.jpg 1x"
            >
        <source
            srcset="6265870c06.jpg 1x"
            >
        <img loading="lazy"
            src="6a06adfe67.jpg"
            width="461"
            height="345"
            intrinsicsize="461x345"
            title="###TITLE_OF_IMAGE###"
            alt="###ALT_OF_IMAGE###"
            >
    </picture>
    <figcaption class="caption">###CAPTION_OF_IMAGE###</figcaption>
</figure>

Bei Verlinkungen sind wir bisher hergegangen und haben das <a> um das <picture> Element gelegt. Hierbei haben wir nicht unterschieden ob sich um einen direkten Link, oder einen Link welcher zusätzlich das normale verhalten unterbindet und mit JavaScript eine Lightbox öffnet um eine größere Version des Bildes anzuzeigen.

<figure>
    <a title="###TITLE_OF_LINK###">
        <picture>
            ...
        </picture>
    </a>
    ...
</figure>

Es geht hierbei nun um die Korrekten Inhalte für Title und Alternativ Texte für die Links und Bilder.

Während es bisher keine Anmerkungen zu normal verlinken Bildern gab, wo der Titel des Links sich immer am Link orientiert hat und der Titel des Bildes als auch der Alternativ-Text am jeweiligen verwendeten Bild.

Beispiel: 

<figure>
    <a href="###SOMEURL###" title="Navigate to: Article XYZ">
        <picture>
            ...
            <img loading="lazy"
                title="Elephant by Pablo Picasso"
                alt="Elephant at sunset"
                >
        </picture>
    </a>
    <figcaption class="caption">An elephant at sunset</figcaption>
</figure>
<figure>
    <a href="###LINK_TO_IMAGE###" title="Elephant by Pablo Picasso">
        <picture>
            ...
            <img loading="lazy"
                title="Elephant by Pablo Picasso"
                alt="Elephant at sunset"
                >
        </picture>
    </a>
    <figcaption class="caption">An elephant at sunset</figcaption>
</figure>

Nun gab es bei einer Prüfung jedoch Anmerkungen das bei der Lightbox Variante die Alternativ Texte des Bildes anzupassen sind, mit der Begründung das es sich nun um "Functional Images" handelt.

https://www.w3.org/WAI/tutorials/images/functional/

Somit müssten die Alternativ-Texte des Bildes angepasst werden.

Beispiel:

<figure>
    <a href="###LINK_TO_IMAGE###" title="Elephant by Pablo Picasso">
        <picture>
            ...
            <img loading="lazy"
                title="Elephant by Pablo Picasso"
                alt="Show larger version of Image: Elephant at sunset"
                >
        </picture>
    </a>
    <figcaption class="caption">An elephant at sunset</figcaption>
</figure>

Ich muss gestehen das ich der Argumentation nicht folgen kann, und suche hier um Rat bzw Klärung und einer Handlungsempfehlung.

Das Internet gibt hierzu leider nur wenig informationen her, beziehungsweise folgt dieser Empfehlung nicht.

Ich hoffe das mich hier jemand aufschlauen kann, was hier die Empfohlene vorgehensweise ist.

Sonnige Grüße Benjamin

benjaminkott commented 1 year ago

CC: @marcus-herrmann

mtelgkamp commented 1 year ago

Es stellt sich die Frage, ob es anhand der Information aus Technique H33: Supplementing link text with the title attribute ausreichen würde im a Tag das title Attribut zu nutzen title="Show larger version of Image". Wenn man sich nur an die Technique hält, müsste es ausreichen. Aber die Browserunterstützung für das title Attribut ist nicht ausreichend. Deshalb sollte das title Attribut vermieden werden (siehe auch "Note" bei 3.2.6.1 The title attribute und Accessibility concerns). Ich würde eine Alternative vorschlagen.

Der Link kann mit einem aria-label="Show large version of Image: Elephant at sunset" beschriftet werden, dann kann das alt Attribut beim Bild selbst unverändert bleiben.

Zusätzlich ist nach meinem Verständnis das interaktive Element das eine Lightbox öffnet ein button (oder ein a Tag mit der role="button"), da durch die Nutzung nur eine Aktion auf der Seite selbst ausgeführt wird und keine neue Seite geöffnet wird.

benjaminkott commented 1 year ago

@mtelgkamp Kurze Ergänzung:

Mit der Lightbox wird hier das Standard Verhalten des Browsers "enhanced". Wenn der Nutzer den Link in einem neuen Tab öffnet bekommt er das Bild ohne Lightbox direkt im Browser angezeigt. Dieses Verhalten soll wenn möglich erhalten bleiben somit denke ich nicht das die Umstellung auf einen <button> hier hilfreich währe. Dieses würde dann entfallen und wir sind dann komplett vom JS abhängig an der Stelle.

mtelgkamp commented 1 year ago

In dem Fall ist es wahrscheinlich sinnvoll, wenn der Javascript Lightbox handler dem Link die Rolle "button" hinzufügt. Dann würde sich ohne JS nichts ändern und die Nutzenden haben die Information, dass das interaktive Element nun eine Aktion auf der Seite ausführt.

stefanFarnetani commented 1 year ago

Hallo @benjaminkott

um auf deine Anfangsfrage einzugehen. Generell ist hier nicht das richtige Forum für Umsetzungsfragen in einem konkreten Projekt. In diesem Repository geht um Fragen rund um die Weiterentwicklung des BIK BITV Test; z.B. wie Prüfschritte ausgelegt und Situationen bewertet werden.

Danke auch für die Frage im Accessibility Slack Kanal von TYPO3, dort ist die Frage besser platziert und wir können auf die technischen Besonderheiten von TYPO3 genauer eingehen.

Dort triffst du, neben anderen, auch wieder auf @mtelgkamp und mich aus dem Accessibiltiy Team von TYPO3. Die Welt ist klein ;)

marcus-herrmann commented 1 year ago

Hallo alle,

als Umsetzungsfrage ist das auch nicht gemeint, diese klären wir in einem Projekt mit einem gemeinsamen Kunden. Ich hatte @benjaminkott auf diese Issues hingewiesen, da ihm die Frage nach der Prüfpraxis ungewöhnlich erscheint, mein Ratschlag war aber (minus aria-label) exakt der von @mtelgkamp (inklusive title-Nuance, auch an anderen Stellen)

benjaminkott commented 1 year ago

Hallo alle,

wie @marcus-herrmann bereits schrieb geht es mir darum zu verstehen wie das Regelwerk ausgelegt ist. Ich habe versucht das Beispiel soweit zu reduzieren das wir hier eine Situationsbewertung anhand der Prüfschritte diskutieren können.

Für das Projekt haben wir bereits eine Lösung, wenn es für diesen Case eine Generelle Auslegung gibt - wird diese natürlich aus Handlungsempfehlung gewertet und weitere Optimierungsschritte im Framework in unserem fall "TYPO3" beeinflussen.

Grundsätzlich stimme ich aber mit der Bewertung als "Functional Image" (https://www.w3.org/WAI/tutorials/images/functional/) nicht zu, was bedeuten würde das wir den alt Text des Bilden anpassen müssten. Dieses fühlt sich in dem Kontext in dem wir uns befinden als falsch an. Da wir die Funktionalität des Links bewerten und nicht die des Bildes.

Die Vorschläge die @mtelgkamp gebracht hat, sind für mich vollkommen nachvollziehbar und akzeptabel, und beziehen sich jeweils auf den Link und nicht das umschlossene Bild.

Anpassung Link Title Wurde abgelehnt, da es nicht alle Browser korrekt auswerten wie Michael bereits geschrieben hat.

Anpassung Link Aria-Label Wurde abgelehnt, da es sicht wie beschrieben um per definition um ein Functional Image handelt wo der Alternativ Text des Bildes angepasst werden muss.

Optionen wie aria-role="button" wurden bisher nicht besprochen.

Es scheint hier also Spielraum zu geben, was also für den einen ok ist, geht bei dem anderen nicht durch.

Wie ich @mtelgkamp bereits per DM geschrieben habe, geht es mir hierbei darum zu definieren was "Richtig" ist, und einen Präzedenzfall zu schaffen auf den sich bei weiteren Bewertungen bezogen werden kann. Damit andere diesem Beispiel folgen können. Damit die Auslegung 100% eindeutig ist und keinen Spielraum zulässt.

Sprich XYZ ist die Empfehlung, ZYX ist ebenfalls zulässig.

sweckenmann commented 1 year ago

Ich möchte die Diskussion mal auf eine allgemeinere Ebene heben, weil mir scheint, dass du grundsätzlich die Unterscheidung "functional image" und "image" in Frage stellst?

Ich zitiere aus der WCAG (normativer Text des Erfolgskriteriums):

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. Controls, Input If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2) for additional requirements for controls and content that accepts user input.) [...]

mtelgkamp commented 1 year ago

Ich glaube die zugrundeliegende Frage ist, wie der Linkzweck (purpose) ausreichend beschrieben werden kann. Was passiert, wenn der Link mit einem title attribut angereichert wird oder einem aria-label beschieben wird? Ist das Bild dann immer noch als funktionales Bild zu sehen und benötigt ein entsprechendes alt Attribut?

Nach meinem Verständnis ist es ausreichend wenn das interaktive Element für assistive Technologien den entsprechenden Textcontent enthält. Dafür gibt es verschiedene Varianten:

Die Frage ist nun: Sind alle aufgezählten Varianten ausreichend?

luis-pato commented 1 year ago

Writing in german excludes a lot of people... 😉

I think if we are placing the image inside a link, we should ask ourselves if the img really needs to be in the accessibility tree. If the user will just interact with the link element, and if the link already has some kind of "image description" (either via title, aria-label, ..., like described above) then we could probably just add a aria-hidden to the image.

benjaminkott commented 1 year ago

Ich möchte die Diskussion mal auf eine allgemeinere Ebene heben, weil mir scheint, dass du grundsätzlich die Unterscheidung "functional image" und "image" in Frage stellst?

Ich zitiere aus der WCAG (normativer Text des Erfolgskriteriums):

All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below. Controls, Input If non-text content is a control or accepts user input, then it has a name that describes its purpose. (Refer to Success Criterion 4.1.2) for additional requirements for controls and content that accepts user input.) [...]

Hallo @sweckenmann,

ich glaube da wurde ich falsch verstanden. Ich möchte natürlich nicht die Unterscheidung "functional image" und "image" in frage stellen. Ich finde die WCAG dort sehr aussagekräftig und nachvollziehbar.

Allerdings stelle ich die Bewertung der Bilder in dem Beschrieben Kontext oben als "functional image" und nicht als "image" in frage. Wenn ich hier auf den decision tree (https://www.w3.org/WAI/tutorials/images/decision-tree/) zurück greife. Erfüllen die Bilder in dem Beschrieben Kontext was unter "Does the image contribute meaning to the current page or context?" fällt. Somit muss der alt-text das Bild beschreiben, was aus meiner Betrachtung das korrekte vorgehen hier ist.

Beziehend auf die Definitionen von:

Es geht also darum das durch die Bewertung als "functional image" der Inhalt des alternativ texts verändert werden soll.

Ich teile die Einschätzung von @mtelgkamp das hier der Link korrekt ausgezeichnet werden sollte.

MarcHaunschild commented 1 year ago

Die WCAG ist klar: jeder nicht-Text-Inhalt benötigt eine textliche Alternative. Dabei wird keine bestimmte Technik gefordert. Also jede Technik, bei der eine Text-Alternative bereit gestellt wird, erfüllt das SC. Auch title (wird bei der computation des accName berücksichtigt), auch aria-label. Verlinkte Grafiken sind interaktive Elemente und müssen zusätzlich den Zweck (also bei Links das Ziel) nennen. Damit kannst du die Beispiele (und beliebig viele weitere) selber bewerten.

tl;dr Wer mich kennt, weiß, dass ich immer gegen aria-label und andere exklusive Techniken argumentiere (wobei die Technik selber nicht exkludierend sein muss, wenn sie im Rahmen eines schlüssigen progressive enhancement-Konzeptes verwendet wird, leider fehlt so ein Konzept oft - mitunter nimmt man ARIA offenbar, weil es das erste ist, was einem einfällt). Die erste ARIA-Regel lautet übrigens: Benutze kein ARIA, wenn es sich vermeiden lässt. Die dritte (?) rät, semantische Elemente mit Rollen nicht mittels ARIA umzuwidmen (also aus einem button einen Link zu machen o.ä.. Was an ARIA am schlimmsten ist aus meiner Perspektive: Per ARIA (z.B. aria-label) übermittelte Informationen sind exklusiv, denn sie können ausschließlich mit Hilfsmitteln wie einem Screenreader erreicht werden. Selbst das hier (zu recht) verpönte title-Attribut hat eine breitere Unterstützung als aria-label. Man kann argumentieren, alle ohne Screenreader können das Bild ja sehen. Aber das ist falsch, denn das Bild kann aufgrund eines technischen Fehlers nicht verfügbar sein, dann gibt der Browser an Stelle des Bildes den Wert des alt-Attributes aus, was schon wesentlich besser ist, aber immer noch Menschen ausschließt. Denn wer mal Zeugen befragt hat - und ich rede von ehrlichen Leuten, die nicht absichtlich lügen - weiß, dass 10 Leute mindestens 15 Varianten eines Tatherganges schildern. Es ist also für viele Menschen wichtig, ausdrücklich gesagt zu bekommen, was auf dem Bild jetzt die im Kontext nötige Information ist. Für Nutzerinnen ist daher ein sichtbarer Text, der mittels aria-describedby oder aria-lebeledby zugewiesen wird, in den meisten Fällen die beste Lösung. Um auf die Frage der Bewertung zurückzukommen: wie gesagt ist lediglich eine Text-Alternative gefordert. Es darf leider auch eine Text-Alternative sein, die nur den wenigen Screenreader-Nutzern zugänglich ist.

benjaminkott commented 1 year ago

@MarcHaunschild Vielen Dank für die Erklärung. Ich gehe davon aus das Interaktive Elemente sich hier auf Functional images bezieht.

In der Definition dazu steht folgendes: Functional images are used to initiate actions rather than to convey information. They are used in buttons, links, and other interactive elements. The text alternative for the image should convey the action that will be initiated (the purpose of the image), rather than a description of the image. https://www.w3.org/WAI/tutorials/images/functional/

In dem beschrieben Fall, geht es ja eben genau darum das die Bilder in den Kontext eingebettet sind und Informationen übermitteln sollen. Dieses Bild kann in einer Lightbox vergrößert werden, was Nutzern helfen soll Inhalte besser zu erkennen (sehen). Das bringt selbstverständlich Nutzern welche auf Screenreader angewiesen sind, keinerlei Vorteile. Diese Funktionalität ist hier also normalerweise überflüssig. Alle Informationen sind bereits via alt oder caption zur Verfügung gestellt worden.

Das Ziel ist hier als größere Version der "Vorschau" definiert.

Der Folgende Absatz scheint hier dann aber nicht zuzutreffen wenn ich die Kommentare richtig verstanden habe:

Einzige Ausnahme: Grafik und danebenstehender Text sind ein zusammengehöriger Link. 
Der Alternativtext bezieht sich dann nur auf die Grafik

https://ergebnis.bitvtest.de/pruefschritt/bitv-20-web/9-1-1-1a-alternativtexte-fuer-bedienelemente

Das genau macht es mir hier so schwer das selbst zu bewerten.

Für die Auszeichnung des Links können/sollen title / aria-label aus genannten gründen nicht eingesetzt werden. Den Alternativ-Text des Bildes anzupassen macht für den genannten weil zusätzliche Informationen bereit gestellt würden die nicht in den Kontext passen und unnötige mehr Informationen bereitstellen.

Also gibt es keine Möglichkeit Complex Images oder Image Groups konform, zugänglich und sinnvoll zu verlinken.

Somit währe die einzige Möglichkeit das Accessible durchzukriegen das Bild nicht zu verlinken und die Funktionalität zusätzlich als extra Button oder Text link zur Verfügung zu stellen. Bitte korrigiert mich wenn ich da falsch liege.

Die daraus resultierende Regel ist dann also:

Bunnyfield commented 1 year ago

For people with screenreaders the function of the lightbox is not always superfluous, since the lightbox might contain more detailed descriptions as well and not just enlarged images. i.e. the small version would just provide the alternative text, while the lightbox would come up with content that otherwise would have been provided with a text file linked via the long-desc attribute.

So I would go with the assumption, that both kind of information might be important:

  1. What you can see in the current image
  2. What is going to happen when you click on that image

But as always it depends on the use case.

MarcHaunschild commented 1 year ago

@MarcHaunschild Vielen Dank für die Erklärung. Ich gehe davon aus das Interaktive Elemente sich hier auf Functional images bezieht.

Ja

In dem beschrieben Fall, geht es ja eben genau darum das die Bilder in den Kontext eingebettet sind und Informationen übermitteln sollen.

Dann muss diese Information als Text bereit gestellt werden, das SC ist erfüllt und der Prüfschritt ebenfalls.

Wie die textliche Alternative bereit gestellt wird, ist wie gesagt irrelevant. - Ob in einem Stück, ob der Text im aria-label des Links oder des Bildes ist, ob die Textalternative über, neben oder unter dem Bild steht. Ist die Informationen auf dem Bild als Text hinterlegt (und nicht mittels display: none oder so einem Quatsch versteckt), ist der Prüfschritt bestanden (erfüllt bei sinnvoller Umsetzung, bei "komischen", aber nutzbaren Umsetzungen "eher erfüllt" und somit auch bestanden).

Was nicht erwünscht ist, sind repetitive Texte, wenn also ein und derselbe Inhalt (häufiger) wiederholt wird. das kann von den Inhalten bis zur Unverständlichkeit ablenken.

Dieses Bild kann in einer Lightbox vergrößert werden, was Nutzern helfen soll Inhalte besser zu erkennen (sehen). Das bringt selbstverständlich Nutzern welche auf Screenreader angewiesen sind, keinerlei Vorteile.

Aber selbstverständlich bringt das Menschen mit Screenreadern Vorteile. Ich habe die Vermutung (die mir aber noch niemand belegt oder widerlegt hat), dass die meisten Screenreader-Nutzer sehen können. Ich nutze beispielsweise Screenreader, wenn ich lange am Computer sitze und mir schon die Augen brennen.

Eine große Gruppe von SR-Nutzerinnen sind Menschen, die sehr schlecht sehen und einen SR beispielsweise zusätzlich zu einer Vergrößerungs-Software einsetzen. Die Vergrößerungssoftware würde die Darstellung des Bildes neben dem Text unscharf und pixelig vergrößern, so dass hier die Lightbox einen besonders großen Vorteil bietet und zwar in gleich zweifacher Weise.

  1. Die Symbole, die oft anzeigen, dass sich ein Bild vergrößern lässt, können mit einer Vergrößerungs-Software leicht übersehen werden, da diese nur einen Ausschnitt der Website zeigt. Hier ist es sehr hilfreich zu hören, dass sich das Bild vergrößern lässt.
  2. Die vergrößerte Version des Bildes ist deutlich schärfer

Das Ziel ist hier als größere Version der "Vorschau" definiert. Das genau macht es mir hier so schwer das selbst zu bewerten.

Ich schätze deine Mühe. Aber "hier klicken für eine größere Darstellung" versteht jeder - das darf auch im alt-Tag drin stehen. Das kann auch per Java-Script automatisch hinzugefügt werden, wenn die Funktion bereit steht, so dass Redakteurinnen beispielsweise von fehleranfälligen, ermüdenden Arbeiten befreit werden.

Hier gibt es wirklich kein Problem. Ihr macht euch gerade viel zu viel Gedanken. Wenn irgendwo steht, dass das Bild gezoomt werden kann, seid ihr safe!

Für die Auszeichnung des Links können/sollen title / aria-label aus genannten gründen nicht eingesetzt werden. Den Alternativ-Text des Bildes anzupassen macht für den genannten weil zusätzliche Informationen bereit gestellt würden die nicht in den Kontext passen und unnötige mehr Informationen bereitstellen.

Wie gesagt: alle Varianten sind vollkommen konform. - es gibt sogar Fälle wo es sinnvoll ist, dass der Hinweis auf die Vergrößerung im alt-Attribut steht, nämlich wenn die kleine und große Version des Bildes zwei Dateien sind, von denen die kleine fehlt/ defekt ist. Dann wird statt des Bildes angezeigt, was man hier sehen könnte und dass man eine große Version per Klick erreicht. Dann klickt man und die große Version wird angezeigt.

Ich sehe da keine unnötigen oder störenden Infos!

Also gibt es keine Möglichkeit Complex Images oder Image Groups konform, zugänglich und sinnvoll zu verlinken.

Wieso nicht? Bei komplexen Bildern sind die Texte länger, bei Gruppen gibt es mehrere Texte? - Ich glaube aber, ich habe die Frage nicht verstanden.

Somit währe die einzige Möglichkeit das Accessible durchzukriegen das Bild nicht zu verlinken und die Funktionalität zusätzlich als extra Button oder Text link zur Verfügung zu stellen. Bitte korrigiert mich wenn ich da falsch liege.

Siehe oben. "Klick mich und ich wachse" irgendwohin schreiben und alles ist gut. Wobei eine Bedingung: das muss schon mit Bild oder Link verknüpft sein. Das Bild ist ja der Inhalt des Links und somit der accName, der als Linktext ausgegeben wird. Das muss schon sichergestellt sein. Alternativ kann die Info eben auch dem Link mitgegeben werden. Am besten einmal im SR anhören, ob es dort sinnvoll ankommt. Die Spezifikation computaton of accName kann man zwar lesen, ist aber sehr mühsam.

Viele Lösungen sind denkbar, hier ein Ausschnitt:

  1. Bild und Unterschrift im a-Element (oder Button)
  2. Beschreibung und Zweck im alt-Attribut
  3. zusätzliche Verwendung von ARIA - wobei ich davon abraten würde sehr lange Texte in den Link zu packen - sonst ist das im Zweifel ein Verstoß gegen 9.2.4.4 Aussagekräftige Linktexte

Wenn ihr noch nicht die ideale Lösung für euch gefunden habt, schaut vielleicht wirklich mal in die accName-Spec rein, ob euch die dort vorgestellten Möglichkeiten alle bekannt sind und ggfs. noch etwas dabei ist, was euch besser passend erscheint.

Die daraus resultierende Regel ist dann also:

  • Es dürfen nur Functional images direkt verlinkt werden und müssen im alt Attribute die Funktion angeben.

Nein, die Regel ist eher: ist ein Bild verlinkt, wird es dadurch zu einem "functional image".

Bunnyfield commented 1 year ago

Nein, die Regel ist eher: ist ein Bild verlinkt, wird es dadurch zu einem "functional image".

Ich würde da gern ein "auch" einfügen, weil es je nach Anwendungsfall für die Besucher ausreicht, die Lightbox eben nicht zu öffnen, sondern nur durch die "normal großen" Bilder zu blättern. Das wäre für Anwender von Screenreadern identisch. Letztere würden durch die Beschränkung auf "functional link" dazu gezwungen, die Lightbox zu öffnen, um an weiterführende Informationen zu gelangen was ganz sicher nicht im Sinne der BITV ist.

benjaminkott commented 1 year ago

Ich würde da gern ein "auch" einfügen, weil es je nach Anwendungsfall für die Besucher ausreicht, die Lightbox eben nicht zu öffnen, sondern nur durch die "normal großen" Bilder zu blättern. Das wäre für Anwender von Screenreadern identisch. Letztere würden durch die Beschränkung auf "functional link" dazu gezwungen, die Lightbox zu öffnen, um an weiterführende Informationen zu gelangen was ganz sicher nicht im Sinne der BITV ist.

Da stimme ich dir zu. Nicht jedes Bild muss vergrößert werden können nur wenn eine Lightbox / Vergrößerung zum einsatz kommt sollte diese Valide sein.

Bunnyfield commented 1 year ago

Letztere würden durch die Beschränkung auf "functional link" dazu gezwungen, die Lightbox zu öffnen, um an weiterführende Informationen zu gelangen was ganz sicher nicht im Sinne der BITV ist.

Meine Schlussfolgerung daraus ist, dass der Ansatz mit einem Prefix in einer der Varianten für alternative Texte die breiteste Abdeckung der Anwendungsfälle hätte.

Damit bleibt der alternative Text z. B. im CMS für Bilder und/oder Bildreferenzen identisch, wird aber im Fall einer Verwendung in einer Lightbox durch entsprechende Hinweise ergänzt:

Öffnet eine vergrößerte Version von: Hier kommt mein Bildtext hin. oder Öffnet eine vergrößerte und mit mehr Informationen versehene Version von: Hier kommt mein Bildtext hin.

Wenn man beim Prefix hinsichtlich der Informationen unterscheidet, wissen die Anwender von Screenreadern, ob sich der Klick überhaupt lohnt oder eher nicht.

Bunnyfield commented 1 year ago

Ggf. kann man das auch als Suffix formulieren, dann wird das für die Anwender von Screenreadern nicht so nervig, dass jedes Bild mit "Öffnet eine Vergrößerung ..." anfängt. ;-)

MarcHaunschild commented 1 year ago

Ggf. kann man das auch als Suffix formulieren, dann wird das für die Anwender von Screenreadern nicht so nervig, dass jedes Bild mit "Öffnet eine Vergrößerung ..." anfängt. ;-)

Wie man es macht, ist es falsch: brechen SR-Nutzerinnen die Ausgabe ab, weil sie ihnen zu lang ist, erfahren sie nichts über die Funktion, steht sie am Anfang, ist der Nerv-Faktor hoch. ;-)

Hier könnte man nur Einzelfälle abwägen: gibt es viele Bilder auf der Seite und wird immer eine vergrößerte Ansicht gezeigt, ist der Hinweis am Ende sinnvoll. Dass Blinde sich ab und zu mal den gesamten Text ausgeben lassen ist dann wahrscheinlich, so dass sie vermuten, dass auch die anderen Bilder mit einer größeren Version ihrer selbst verlinkt sind.

Bei wenigen Bildern oder wenn die Links auch mal zu einer anderen Seite führen können, wäre ein Präfix besser. Wobei im Fall der Lightbox ja schon die rolle "button" darauf hinweist. Das lässt sich ja ggfs. redaktionell steuern. Generell ist Konsistenz mindestens ein usability-Feature, es gibt aber auch den Prüfschritt 9.3.2.4 Konsistente Bezeichnung, der konsistente Bezeichnungen bewertet. Also ein (redaktionelles und technisches) Konzept erstellen, das auch eingehalten wird!

benjaminkott commented 1 year ago

@MarcHaunschild, vielen dank erneut für die Ausfühliche erklärung.

Ich versuche das einmal zusammen zu fassen und mit Code Beispielen zu belegen. Die CSS Klasse .screenreader soll hier als Beispiel für eine Anweisung dienen welche den Inhalt für Screenreader accessible macht und für andere Nutzer verbirgt. Das Bild-Element wird jeweils mit verschiedenen zielen verlinked. Ich hoffe es wird dadurch etwas greifbarer. Die Beispiele sind aus Sicht eines CMS Providers erstellt worden. Somit haben wir nur wenig einfluss auf JavaScript haben uns müssen uns so auf Server-Side Generated Markup konzentrieren.

Folgende dinge werden in betracht gezogen:

  1. Vermeidung von aria-label wenn möglich
  2. Unzureichender Browser support für title nur als fallback
  3. Aktion mit bei Verlinkten Bildern irgendwo im link stehen

Voraussetzungen:

  1. JavaScript ist Userland
  2. Minimum CSS kann ausgeliefert werden
  3. Markup wird Server-Side gerendert
  4. JavaScript als enhancement, links funktionieren auch ohne
  5. Image alt wird nicht verändert, extrem schwierig verlässlich zu integrieren
  6. Interaktionsbeschreibungen werden vom CMS generiert

Warum keine Texte im Alt-Bereich des Bildes

Es ist aus CMS sicht schwierig diese Entscheidung und Notwendigkeit für den Nutzer zu treffen. Es kommt immer auf den fall an wo das Bild verwendet wird und wie. Da wir im TYPO3 Kontext mit Datei Referenzen arbeiten könnte das vom Nutzer an der Stelle der Verwendung sicherlich hinzugefügt werden.

Es wird dann aber schwierig die Inhalte mit von den Global gepflegten Bild-Beschreibungen Synchron zu halten, dabei ist die Komplexität der Mehrsprachigkeit noch nicht inbegriffen. Das ist auch etwas was keinem Nutzer zumutbar ist. Dazu kommen ausgaben die kein markup enthalten, wie z.B. JSON wo diese Daten dann fälschlicher weise auch ausgegeben würden. Darum suche ich nach einer Generischen validen Lösung. Also nach einem Pattern was BITV valide ist, die requirements erfüllt und anwendbar ist.

Die Lösung muss so gestrickt sein, das der Link als addon hinzu kommt und bestenfalls nur auf seiner Spielwiese dinge hinzufügt, wie z.B. auf dem Link oder vor / hinter dem Bild.

Für das Bild-Rendering gibt es viele verschiedene Lösungen, ob diese durch Externe Anbieter aufbereitet werden oder dort komplexe Source-Sets generiert werden. Jede Modifikation am Bild element selbst ist also sehr schwer verlässlich durchzusetzen.

Minimal CSS

*:focus {
  outline-offset: 1px;
  outline: 2px solid;
}
.image {
  position: relative;
}
.lightbox {
  cursor: zoom-in;
}
.screenreader {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0,0,0,0);
  white-space: nowrap;
  border: 0;
}
.screenreader-overlay {
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    outline: 0;
    overflow: hidden;
    text-indent: -9999px;
    &:focus {
        outline-offset: 1px;
        outline: 2px solid;
    }
}

Verlinkungen auf Aktionen (Lightbox)

<figure class="image">
    <a href="large-elephant.jpg" class="lightbox" role="button" data-action="lightbox" title="Navigate to: Elephant">
        <span class="screenreader">Show larger version for: Elephant</span>
        <span aria-hidden="true">
            <picture>
                <img loading="lazy"
                    title="Elephant by Pablo Picasso"
                    alt="Elephant at sunset"
                    src="elephant.jpg"
                    >
            </picture>
        </span>
    </a>
    <figcaption class="caption">An elephant at sunset</figcaption>
</figure>

Verlinkungen auf Bilder

<figure class="image">
    <a href="large-elephant.jpg" title="Show larger version for: Elephant">
        <span class="screenreader">Show larger version for: Elephant</span>
        <span aria-hidden="true">
            <picture>
                <img loading="lazy"
                    title="Elephant by Pablo Picasso"
                    alt="Elephant at sunset"
                    src="elephant.jpg"
                    >
            </picture>
        </span>
    </a>
    <figcaption class="caption">An elephant at sunset</figcaption>
</figure>

Verlinkungen auf Content

<figure class="image">
    <a href="/elephant" title="Navigate to: Elephant">
        <span class="screenreader">Navigate to: Elephant</span>
        <span aria-hidden="true">
            <picture>
                <img loading="lazy"
                    title="Elephant by Pablo Picasso"
                    alt="Elephant at sunset"
                    src="elephant.jpg"
                    >
            </picture>
        </span>
    </a>
    <figcaption class="caption">An elephant at sunset</figcaption>
</figure>

Alernative

<figure class="image">
    <picture>
        <img loading="lazy"
            title="Elephant by Pablo Picasso"
            alt="Elephant at sunset"
            src="elephant.jpg"
            >
    </picture>
    <figcaption class="caption">An elephant at sunset</figcaption>
    <a href="/elephant" class="screenreader-overlay" title="Show larger version for: Elephant">
        Show larger version for: Elephant
    </a>
</figure>

CodePen: https://codepen.io/benjaminkott/pen/LYXNGPM

Wenn ich es immer noch nicht gerafft habe, bitte korrigiert mich.

MarcHaunschild commented 1 year ago

@MarcHaunschild, vielen dank erneut für die Ausfühliche erklärung.

Ich versuche das einmal zusammen zu fassen und mit Code Beispielen zu belegen.

Folgende dinge werden in betracht gezogen:

Da reden wir zum Teil bereits von best practices, nicht von Voraussetzungen für ein pass.

Voraussetzungen:

Also bisher waren meine Anmerkungen bewusst allgemein. Wie hier schon gesagt wurde, geht es hier im Repo um die Diskussion der Prüfschritte. Das ist schon eine ganz konkrete Einzelfall-Umsetzung und eigentlich eine Beratung.

Ich versuche es mal ganz kurz:

Warum keine Texte im Alt-Bereich des Bildes

Es ist aus CMS sicht schwierig diese Entscheidung und Notwendigkeit für den Nutzer zu treffen. Es kommt immer auf den fall an wo das Bild verwendet wird und wie. Da wir im TYPO3 Kontext mit Datei Referenzen arbeiten könnte das vom Nutzer an der Stelle der Verwendung sicherlich hinzugefügt werden.

Ja, es gibt keine "passt-immer"-Lösungen. In der Regel sind es "kommt-drauf-an "-Lösungen und können nur für einen bestimmten Fall empfohlen werden.

Eine Lösung die immer passt, gibt es praktisch nie. So sollte figure nur verwendet werden, wenn das semantisch passt. Bist du sicher, dass das immer der Fall ist?

Verlinkungen auf Aktionen (Lightbox)

Da sind viel zu viel Texte drin, wie gesagt Redundanzen und Wiederholungen vermeiden. Und wolltest du nicht auf title verzichten?

Hier mein Vorschlag (falls figurekorrekt ist):

<figure class="image">
    <a href="large-elephant.jpg" class="lightbox" role="button" data-action="lightbox">
        <span class="screenreader">Show larger version for: </span>
        <picture>
            <img loading="lazy"
                alt="Elephant at sunset by Pablo Picasso"
                src="elephant.jpg"
                >
        </picture>
    </a>
    <figcaption class="caption" aria-hidden="true">An elephant at sunset</figcaption>
</figure>

Die anderen Beispiele analog.

Das aria-hidden im caption nur, wenn die caption keine neuen Informationen aber Wiederholungen enthält. Meine Empfehlung wäre aber alt-Attribut und figcaption sinnvoll unterschiedlich zu befüllen. Das fällt aber in den Bereich einer Redakteurs-Schulung.

Wir kommen hier jetzt zu weit ab, es ist kein a11y-Forum. Die gibt es ja auch.

Zusammenfassend: Es ist wirklich so einfach:

  1. Sag was auf dem Bild ist
  2. Sag, was der Link/ der Button tut
  3. Vermeide Wiederholungen

Wie der Code dann genau aussieht, ist euch überlassen. Aber denke bitte dran: die eine Lösung, die für alles passt, gibt es nicht. Wenn das Bild eine figure im Sinne des HTML-Elementes figure ist, passt der Code, sonst hast du implizit falsche Rollen verwendet (9.4.1.2 Name, Rolle, Wert verfügbar)

figure muss weder für jedes Bild verwendet werden, noch ist figure ausschließlich für Bilder gedacht, es können sich dort auch Tabellen, Code oder andere Dinge drin finden. https://html.spec.whatwg.org/multipage/grouping-content.html#the-figure-element Know your standards...

;-)

benjaminkott commented 1 year ago

@MarcHaunschild vielen dank, es tut mir leid wenn ich zu sehr abgedriftet bin. Die Voraussetzungen habe ich nur aufgeführt um mehr Kontext auf die Situation zu geben, war nicht meine Absicht es zu spezifisch zu machen. Wollte nur die JS-Poly-fills ausklammern als option.

Ich habe es versucht generisch zu halten und auf die es auf die Prüfung zu beziehen. Allerdings ist finde ich es schwierig, ohne Code zu diskutieren weil mit es muss irgendwo stehen ist schwierig zu fassen. Ich habe leider in den Beispielen die Caption vergessen anzupassen im CodePen hatte ich das noch adaptiert. Dennoch ist dein Hinweis hier extrem wertvoll und sicherlich auf für die Nachwelt hilfreich.

Dein Beispiel ist super! Einfach nachzuvollziehen und einfach zu adaptieren. Vielen Dank dafür!

Wenn wir die Funktionsbeschreibung ausgliedern können und das den Test passed. Das habe ich aus den bisherigen Kommentaren nicht entnehmen können das es so umgesetzt werden kann. Das Löst alle meine Probleme, Sorgen, Anmerkungen und macht auch die Diskussion über "Functional image" oder "Image" hinfällig mit den Entsprechenden Anforderungen hinfällig.

Es geht hier nur darum die Technischen Voraussetzungen zu erfüllen.

Es ist leider sehr schwierig zu diesem exakten Thema valide Informationen zu finden. Alles was an Ressourcen im A11Y Bereich dazu aufgetrieben werden konnte ignoriert die Funktionsbeschreibung. Da die aber Teil des Tests ist, wusste ich einfach keine andere Quelle anzusprechen.

MarcHaunschild commented 1 year ago

@benjaminkott ich wollte jetzt auch nicht, dass du dich entschuldigst. 😲 Wenn man nicht mehr mag, antwortet man halt nicht mehr.

Aber wenn es jetzt gelöst ist, ist das schön und manchmal muss man auch einfach irgendwo mal jemanden fragen können.

Die Formulierungen in der WCAG sind auch ziemlich eigen. Auch native speaker müssen sich erst ins wording rein finden...

MarcHaunschild commented 1 year ago

Noch ein Hinweis, für einen runden Abschluss: wenn das Bild nicht nur hier im Beispiel "elephant.jpg" oder sogar "elephant-by-picasso.jpg" heißt, ist das der erste Schritt einer progressive enhancement Strategie. (Klar: ist wieder nicht technisch, sondern redaktionell, aber Barrierefreiheit geht halt nur im Zusammenspiel). Selbst wenn aller sonstiger Kontext fehlt, bekämen screenreader-Nutzerinnen schon mal eine Vorstellung vom Inhalt des Bildes. Das reicht noch nicht für ein pass ist aber schon mal besser als hrbei133.jpg. Der Wert des alt-Attributes überschreibt das dann mit etwas besserem, die figcaption ergänzt es weiter und am Ende sollte im Screenreader und bei sehenden etwas ankommen, was hintereinander weg gelesen sinnvoll ist (auch in der Reihenfolge) und möglichst keine Wiederholungen enthält.

johannesFischer84 commented 1 year ago

Ich habe nicht bei allen Beiträgen jedes Wort gelesen. Mir scheint das Thema auch geklärt zu sein. Nur ganz allgemein möchte ich aber noch zu einer Sache etwas anmerken:

Es ist leider sehr schwierig zu diesem exakten Thema valide Informationen zu finden. Alles was an Ressourcen im A11Y Bereich dazu aufgetrieben werden konnte ignoriert die Funktionsbeschreibung.

Aus meiner Sicht gibt es ein paar Informationen dazu, wie man grafische Bedienelemente (hier "functional images" genannt), informationsvermittelnde Grafiken und dekorative Grafiken auseinanderhalten kann und was jeweils getan werden muss:

Zum einen gibt es das Understanding-Dokument von WCAG 1.1.1. Im Bereich "Techniques" sind mit "Situation" A, B, usw. die verschiedenen Möglichkeiten aufgegliedert. Die Functional Images würden Situation C entsprechen ("If non-text content is a control or accepts user input"). Dahinter sind Techniken aufgeführt, wie man beispielhaft so etwas umsetzen sollte. Ich persönlich würde dies für die Informationen empfehlen.

Im BIK BITV-Test ist das WCAG-Kriterium 1.1.1 schon in mehrere Prüfschritte aufgeteilt. Die Functional Images werden im Prüfschritt 1.1.1a abgeprüft. Richtig ist allerdings, dass dort im Wesentlichen keine Code-Beispiele sind. Man kann diese ggf. aus der Textbeschreibung herauslesen.

Zur Vollständigkeit: In den Handreichungen der Überwachungsstelle Bund gibt es einen Leitfaden "Nachschlagewerk zur Erstellung barrierefreier User Interface Elemente". Darin gibt es Abschnitte zu Grafiken und auch zu Bedienelementen. Für Functional Images allein gebe ich aber zu, dass man es da als Laie schwer hat, sich die entsprechenden Stellen für ein grafisches Bedienelement herauszusuchen.

Ich würde daher wie gesagt die WCAG-Quellen am ehesten empfehlen.

benjaminkott commented 1 year ago

@johannesFischer84 auch dir Vielen Dank für die Informationen.

Die WAI ist relativ eindeutig was die Handhabung von Functional Images angeht und damit auch den zu implementierenden Code. Da ist auch nicht viel Spielraum für Interpretation. https://www.w3.org/WAI/tutorials/images/functional/

For instance, as shown in examples below, the text alternative should be “print this page” rather than “(image of a) printer”, “search” rather than “magnifying lens” or “Example.com homepage” rather than “Example.com logo”.

Das gleiche gilt auch für Prüfschritt 1.1.1a https://ergebnis.bitvtest.de/pruefschritt/bitv-20-web/9-1-1-1a-alternativtexte-fuer-bedienelemente

Grafische Bedienelemente (alle verlinkten / interaktiven Grafiken und Bilder) müssen mit Alternativtexten versehen werden (nicht verlinkte bzw. nicht interaktive Grafiken und Bilder werden in Prüfschritt 9.1.1.1b "Alternativtexte für Grafiken und Objekte" geprüft).

Die Frage ist also was mit Alternativtexten für interaktiven Grafiken und Bilder gemeint ist. So wie es mir erklärt worden ist, und wie ich es aus den Texten verstehe wird hier vom alt-attribute des Bildes geredet. Das ist allerdings eine rein Technische Betrachtungsweise.

Wenn es "nur" darum geht das der Screenreader-Nutzer den Kontext versteht. Ist es nicht notwendig die Funktion im alt-attribute unterzubringen. Wenn der Prüfschritt aber genau darauf zielt, muss es da drin stehen.

Durch die Diskussion ist nun klar geworden das es hier um das Ergebnis/Erlebnis für den Screenreader-Nutzer geht und nicht um die Technische Implementierung. An der Stelle erneut vielen dank an alle beteiligten.

benjaminkott commented 1 year ago

Wenn keiner etwas dagegen hat, würde ich dieses Issue gerne schließen und es damit als erledigt abhaken. <3

johannesFischer84 commented 1 year ago

Die Frage ist also was mit Alternativtexten für interaktiven Grafiken und Bilder gemeint ist.

"Interaktiv" bzw. "Interaktion" in diesem Zusammenhang bedeutet, dass Nutzende durch eine Eingabeoperation (z. B. click-Ereignis, keyup-Ereignis bzw. Mausklick, Drücken der Eingabetaste) eine Aktion auslösen können. Das alt-Attribut ist tatsächlich eine stark vereinfachte Sichtweise darauf, wie für Screenreader oder andere assistive Technologien ein Alternativtext verfügbar gemacht wird.

Wenn keiner etwas dagegen hat, würde ich dieses Issue gerne schließen und es damit als erledigt abhaken. <3

Ich habe nichts dagegen.