doppeltes Anführungszeichen links bekommt falsches label/title

[pkra]

Auf https://www.olivertacke.de/2020/03/06/waehle-die-satzzeichen/ bekommt "Doppeltes Anführungszeichen Links" den fallback von getVerboseSymbol

denn

https://github.com/otacke/h5p-pick-the-symbols/blob/c794f60099009d24d6bebe4c08b9c55c39be14b5/src/scripts/h5p-pick-the-symbols-content.js#L50

hat ” aber der Button enhält „.

[pkra]

Mehr ein Zufallsfund. Mit screenreader scheint es eh etwas schwierig, durch zu gehen.

[otacke]

@pkra Danke! Es gibt ja links tatsächlich eins oben und eins unten. Habe den Fehler behoben. Zur UX: Ich bin für Vorschläge offen.

[pkra]

@otacke :rocket:

Ich muss gestehen, ich bin nur zufällig (über den blog post) draufgestoßen und mache (leider) nichts mit h5p; daher will ich nicht groß reinreden (auch ob der Finanzierungssituation). Ich bin auch kein primärer Screenreadernutzer. Bei einem kurzen Test fiel mir nur auf, dass es schwer ist zwischen dem Text und den Buttons zu wechseln. Einersets ok denn visuell bringen die vielen Buttons ja auch eine gewisse Unruhe rein. Spontan erscheinen mir "nur" buttons (um dann zu tabben) klarer zu sein. Dafür könnte man den (repetitiven) title ersetzen durch aria-describedby, das auf den vorangehenden Text verweist; das ist natürlich etwas komplexer (ID generierung etc). Das label steht dem evtl. etwas im Weg und ist schwerer auszubalancieren, je nachdem was man damit erreichen möchte.

[otacke]

@pkra

Du brauchst dich nicht zu rechtfertigen, ich bin kein a11y-Experte :-) Ich habe daran gedacht, dass nur über Tabbing zu lösen statt über das "normale" Fortschreiten auf der Seite zu lösen - so dass das Wort/Symbol vor und hinter der Lücke angesagt wird. Eben mangels viel a11y-Erfahrung habe ich mich dann aber daran orientiert, wie es in "Fill in the Blanks" (https://h5p.org/fill-in-the-blanks) gehandhabt wird. Dasselbe Prinzip, auch wenn es dort weniger Lücken sind.

[pkra]

@otacke danke für die Antwort. Ich muss auch gestehen, dass mein Fokus im Englischsprachigen Raum liegt; kann sehr gut sein, dass die Kultur sich da stark unterscheidet. Falls ich Zeit finde, mach ich mal zwei Beispiele und gucke, wie dies ich so lesen.

(PS das iframe im blog post hat lang="en".)

[otacke]

@pkra Weil der Inhaltstyp von einer englisch-sprachigen Seite eingebettet wird :-)

[pkra]

@pkra Weil der Inhaltstyp von einer englisch-sprachigen Seite eingebettet wird :-)

Verstehe ich schon. Es führt nun dazu, dass ein Screenreader dann versucht, alles als Englisch vorzulesen. Die Lokalisierung von pick-the-symbols könnte das korrigieren, z.B. auf das wrapper div ein passendes lang Attribut setzen.

[otacke]

@pkra H5P-Inhaltypen haben leider kein Wissen darüber, in welcher Sprache sie laufen. Das wäre etwas, was zunächst im H5P-Kern ergänzt werden müsste. Ich möchte da ungern noch eine Sonderlösung einführen.

[pkra]

@otacke ah ok. das sind dann natürlich grundlegendere barrierefreiheit Sachen als die buttons hier ;-)

[otacke]

@pkra Hat vermutlich keine so große Priorität gehabt, da der Normalfall sein dürfte, dass die Sprache der Inhaltstypen und die des umliegenden Systems übereinstimmen. Ich wollte sowieso noch Pull-Requests zum Thema Barrierefreiheit einreichen, damit die iframes ein title-Attribut bekommen. Dann könnte man in einem Atemzug für die iframes auch nicht die Sprache des umliegenden Systems setzen, sondern die, die im Editor für den Inhalt eingestellt wurde.

[pkra]

@otacke kling gut. Ich helfe gerne, wenn es nützt.

[otacke]

@pkra Klar! Joubel, der Firma hinter H5P, ist viel an Barrierefreiheit gelegen. Falls du dir die Software mal anschaust und etwas entdeckst - geht direkt auf https://h5p.org/content-types-and-applications, dann kannst du das z. B. ins Forum auf https://h5p.org/forum schreiben - oder gleich selbst einen Pull-Request stellen :-) Der Quelltext ist ja hier auch auf github auf https://github.com/h5p/