Revision 699: ARIA-Glücksrad Nachklapp, neue APIs und reale Unterstützung

0:00 Wir hatten uns gefragt, ob der Placeholder auch dann noch über assistive Technologien verfügbar ist, wenn das Eingabefeld gefüllt ist. Mein persönlicher Trick, um zu unterscheiden, ob mit was ich zu handeln habe, ein Placeholder oder ein ARIA Describe-by ist, ohne ins Baum zu schauen. Ich schreibe einfach, was ihm fällt und schaue, ob das immer noch vorgelesen wird oder nicht.

0:23 Ja, danke, dass du das teilst. Ich muss sagen, jetzt, wo ich das höre, klingt das echt wirklich praktisch und das muss ich eigentlich gleich mal ausprobieren. am Wochenende. Er hat letztes Mal über die Braille-Properties gesprochen. Das ist tatsächlich etwas, was ich in der ARIA-Spec schreiben durfte.

0:39 Das ist eigentlich der Grund, warum ich in die ARIA-Working Group kam. Diese Revision von Working Draft wird euch präsentiert von Mitwald. Next-Level-Container-Hosting für eure Projekte. Wie euch bestimmt nicht entgangen ist, reden alle überall und ständig über Automatisierung und Self-Hosting. Und das klingt auch immer alles voll super, wenn es denn mal eingerichtet ist und läuft. Nur über diesen Schritt redet fast keiner, weil er meist kompliziert und anstrengend ist.

1:02 Aber es gibt eine Ausnahme und das ist Midwald's Container Hosting. Und das funktioniert so. Erster Schritt, in Midwald's M-Studio einloggen. Ganz einfach und bequem, direkt im Browser. Zweitens, fünf Minuten für die Konfiguration eures Containers aufwenden. Mehr Zeit braucht ihr nicht, denn ihr könnt die meisten Vorschläge für Entry-Points und Umgebungsvariablen einfach direkt übernehmen.

1:22 Dritter Schritt, äh, euer Container läuft. Ihr seid fertig. Das war's. Von Nerds für Nerds bringt euch Midwald das Beste, was Container-Hosting zu bieten hat, nämlich eure Eintrittskarte ins Automatisierungs-Wunderland. Deployt ganz einfach, was ihr wollt, wie ihr wollt und alles dazu findet ihr auf Midwald.de.

1:40 Das war nochmal mittwald.de. Wir danken Mittwald für die Unterstützung von dieser Revision von Working Draft. Willkommen beim Working Draft Podcast, Revision 699. Wir sind heute zu fünft aus dem Team, bin aber nur ich dabei. Und das bedeutet, wir haben eine Rekordzahl an GästInnen heute dabei. Die erste Gästin ist die Daniela Kubesch. Hallo Daniela.

2:13 Hallo, freut mich, dass ich wieder dabei sein kann. Ja, ich bin Accessibility Engineer in einem deduzierten Accessibility Team bei einer globalen Premium-Kaffee-Marke. Außerdem auch auf der Konferenzen unterwegs mit Vorträgen und Workshops, unterrichte auch noch an meiner alten Hochschule zum Thema, Barrierefreiheit und bin jetzt auch wieder etwas aktiver auf Social Media unterwegs und teile dort Einblicke in meinen Arbeitsalltag und meine Learnings im Bereich Web Accessibility.

2:43 Und ich freue mich jetzt schon sehr auf die heutige Folge. Ja, cool. Vielen Dank. Dann haben wir den Peter Krautsberger. Hallo, Peter. Hallo. Vielen Dank, dass ich hier sein kann. Ich heiße Peter Krautsberger. Ich komme aus und lebe in Bonn. Ich bin selbstständig, arbeite primär im Bereich wissenschaftliche Publikationswesen und bin außerdem aktiv in der ARIA Working Group der W3C als sogenannter Invited Expert, was ich immer gerne in Anführungsstrichen schreibe.

3:16 Es heißt einfach nur ehrenamtlich, statt jemand, der dafür bezahlt wird von seinem Arbeitgeber. Ja, cool. Dann haben wir den Marco Brettschneider. Hallo Marco. Ja, moin. Ich war bei der ersten ARIA-Glücksrad-Folge auch mit dabei, zusammen mit Daniela. Und ja, ich freue mich, dass wir zum einen da jetzt nochmal ein bisschen drauf zurückgucken wollen und nochmal ein paar zusätzliche Perspektiven an Bord bekommen haben.

3:45 Und vielleicht werden wir auch noch das ein oder andere neue Attribut heute durch das Glücksrad in die Sendung einbringen. Und dann haben wir als Letzten im Bunde den Pavel Masarczyk. Hallo Pavel. Hallo, hallo. Es freut mich auch, dass ich hier dabei sein kann. Vielen lieben Dank für die Einladung. Ich heiße Paweł Masarczyk.

4:10 Ich bin heute aus Wien verbunden und ich bin auch ein digitaler Barrierfreiheitsexperte. Mein offizieller Jobtitle ist eigentlich Barrierfreiheits- und Erfahrungsexperte, also Accessibility and Experience Expert. Und dieser Erfahrungsteil bezieht sich einfach darauf, dass ich ein Native Screenreader Benutzer bin.

4:31 Ich bin seit meinem Gebot blind und mit dieser Perspektive mache ich auch in einer Wiener IT- und Barrierfreiheits-Agentur mit als Tester, als Vortragende, als auch teilweise Lehrer. Ich bin auch bei Schulungen dabei und es freut mich, dass ich heute mit euch allen dabei sein kann und mitsprechen darf.

5:01 Ja, super. Sehr cool, dass ihr alle da seid. Und wie das dazu kam, der Marco hat das ja schon ein bisschen angedeutet. Wir haben vor einigen Monaten schon mal eine Glücksrad-Folge gemacht, wo wir uns nur auf ARIA fokussiert haben, zum ersten Mal. Und Daniela und Marco waren da meine MitspielerInnen. Und genau, da wurden verschiedenste ARIA-Attribute ausgewürfelt, über die wir dann sozusagen alles, was wir darüber wussten, zum Besten gegeben haben.

5:37 Und wir haben auf diese Folge Feedback bekommen, und zwar sowohl von Pavel als auch von Peter. Und euer Feedback war echt sehr cool. Und ihr habt da auch echt coole, super Sachen gesagt und das hat uns auf die Idee gebracht, wie wäre es, wenn wir euch einladen, so einen kleinen Nachklapp zu dieser letzten Folge machen, wo ihr das nochmal erzählt, was ihr uns geschrieben habt und dann hoffe ich, dass wir noch genug Zeit finden, auch wie Marco das gesagt hat, noch ein paar Mal am Glücksrad zu drehen und über neue Attribute zu sprechen. Genau.

6:21 Ja, Pavel, du bist ja sozusagen Nutzender dieser ganzen Geschichten und du kennst dich natürlich da super aus. Peter ebenfalls, denn du bist ja, wie du gerade gesagt hast, hier in der W3C Y-Aria war das. In dem Gremium als Invited Expert und ja, ich bin gespannt oder wir sind gespannt, was ihr zu ergänzen habt.

6:52 Ich weiß nicht, ob wir was machen wollen, sollen wir die. Reihenfolge durchgehen der Attribute, die wir lesbarten. Gestartet sind wir mit Area Placeholder. Ja, klingt noch an im Plan. Ähm, Ja. Lagen wir da richtig mit unseren Vermutungen? Ich glaube, wir haben gesagt, dass es im Prinzip wie ein Ersatz für, also oder ein Äquivalent zu dem Placeholder-Attribut ist, zu nutzen wahrscheinlich, wenn man Elemente baut, die eben dann wie Inputs wirken sollen, aber keine Inputs sind.

7:30 Das wäre meine Vermutung. Also ich habe im echten Szenarien noch nicht so eine Implementierung gesehen. Irgendwie die Standard-Inputs haben normalerweise für alles, was ich bis jetzt genutzt und getestet habe, ausgereicht. Aber das wäre auch meine Vermutung. Also wenn wir einen Input von Grund ab selbst bauen, dann müssen wir alle diese Eigenschaften denen zuweisen, dass einen Input auch ausmachen, auch semantisch.

8:00 Und dann wäre dieser Placeholder, wo nötig, auch mit ARIA eingesetzt. Weil visuell ist das wahrscheinlich schon irgendwie anders mit CSS vermittelt, nehme ich an. Mich würde ja interessieren, ob jemand von euch sowas schon mal in echt gesehen hat, weil seit der letzten Folge ist mir das noch nicht untergekommen und davor auch nicht, deswegen bin ich da sehr gespannt.

8:23 Mir eben nicht, vielleicht war ich nicht bewusst, dass es so implementiert ist, ich schaue nicht bei jeder Seite, die ich benutze, ins Baum, aber nein, so weit, ich weiß noch nicht. Ich muss auch gestehen, ich habe das noch nicht in der echten Welt gesehen. Es ist aber, glaube ich, genauso wie ihr auch damals schon gesagt habt.

8:49 Es ist einfach das Äquivalent für Placeholder. Und ich habe nochmal in die Mappings geschaut und es funktioniert auch genauso. Also wie das HTML-Attribute gemappt wird in die Accessibility-APIs und dementsprechend sollte es eigentlich genauso funktionieren. Ich glaube, es war vielleicht auch früher einfach nochmal etwas populärer, als es vielleicht schwieriger war, mit Placeholdern visuell umzugehen und man vielleicht sich noch was extra gebaut hat.

9:17 Deswegen sieht man es vielleicht Gott sei Dank heute nicht mehr so oft. Was mich noch interessiert, wie sich dieses Placeholder-Konzept in assistiven Technologien darstellt. Also für uns, die wir das sehend wahrnehmen können, ist es ja so, wir können den Placeholder nur dann wahrnehmen, sehen, wenn das Eingabefeld leer ist.

9:42 Ich glaube, wir hatten uns gefragt, wie das eigentlich ist, ob der Placeholder auch dann noch über assistive Technologien verfügbar ist, wenn das Eingabefeld gefüllt ist. Tatsächlich, es ist so, dass der Placeholder wird normalerweise in meisten Screenreaders nach dem Label und nach der Eingabe des Tipps, also dass es ein Eingabefeld ist, vorgelesen wird und nur solange kein Inhalt unter Value drinnen steht.

10:17 Das ist fast gleich wie ARIA Describedby oder ARIA Error Message vorgelesen, also in gleicher Reihenfolge und mein persönlicher Trick, um zu unterscheiden, ob mit was ich zu handeln habe ein Placeholder oder ein ARIA Describedby ist, ohne ins Baum zu schauen ich schreibe einfach was ihm fällt und schaue, ob das immer noch vorgelesen wird oder nicht, Das finde ich super einfach als Erfahrungs Darstellung zu hören.

10:44 Ich glaube Aber was so ein bisschen manchmal schwerfällt Entwicklern, ist zu sehen, dass es einerseits Placeholder darf in der, wie heißt es auf Deutsch, zugänglicher Name und Beschreibungsalgorithmus kann es reingezogen werden, wenn nichts anderes da ist als Fallback. Gleichzeitig hat es aber auch sein eigenes Mapping, sodass eben dann eine assistive Technologie es trotzdem zusätzlich verwenden kann.

11:10 Und ich könnte mir gut vorstellen, dass das auch durchaus von der spezifischen assistiven Technologie abhängt oder von den Einstellungen der NutzerInnen, die es dann konkret eingebaut wird in den Alltag quasi. Genau, dann hatten wir als nächstes, oder als nächstes hat das Glücksrad ausgespuckt, ARIA Details und ARIA Details Element, also die Property, die da Hand in Hand geht damit.

11:41 Und ja, das ist etwas, wo du, Peter, drüber gestolpert bist, weil man da noch einiges mehr dazu erzählen kann, das wissenswert ist. Nein. Was wäre das? Beziehungsweise wir haben auch ein paar Sachen unterschlagen. Denn wenn man zurückhört, und ich habe es extra gemacht am Wochenende, dann hat er euch das Glücksrad ausgespuckt.

12:03 ARIA described by Elements. Und ich fand es so schade, dass ihr über diese tollen neuen APIs einfach drüber gesprungen seid und direkt zu described by gelaufen seid und das alles schön tut. Super. Also es war alles super. Aber das fand ich so schade, weil das was Neues ist. Das ist jetzt gerade, ich glaube, 2025 Baseline.

12:23 Dass wir diese neuen APIs haben und die sind halt gerade als Element-APIs einfach praktisch für die tägliche Entwicklung, finde ich, weil man auf einmal nicht mehr mit IDs hantieren muss, wenn man nicht will. Also wenn man so oder so dynamisch arbeitet und alles irgendwie live generiert, dann kann man eben tatsächlich jetzt anfangen, einfach ein Array von Nodes rüberzuschieben, anstatt dass man kompliziert UUIDs generiert und dann IDs verteilt und dann die IDs zusammensammelt, sondern dass man einfach tatsächlich Elemente setten kann oder Arrays von Elementen.

13:07 Und das war das, wo ich damals kriege. Das war das erste Nein. Ich dachte, nein, wie schade, denn das sind doch eigentlich sehr praktische APIs, die, glaube ich, wirklich im Alltag helfen können, so ein bisschen durch das ID-Code-Modell durchzukommen für die, die damit Probleme haben, was jetzt nicht jede Situation ist.

13:28 Ja, danke, dass du das teilst. Ich muss sagen, jetzt, wo ich das höre, klingt das echt wirklich praktisch und das muss ich eigentlich gleich mal ausprobieren am Wochenende. Und du hast gesagt, das ist jetzt Baseline, das heißt also die Browser, die unterstützen die APIs an sich erstmal und dann nach vorne raus.

13:46 Da funktioniert es dann genauso wie Labeled By oder Described By. Also da packst du dann halt statt einer ID-Ref-Liste, also einer Liste von IDs, packst du eben ein Array von Elementen rein. Ich hoffe, ich sage jetzt nichts Falsches. Ich sage bestimmt, was Falsches ist. Und dann werden die einfach genauso behandelt wie die per ID verwiesenen Elemente.

14:07 Also in der Reihenfolge der Eggname der Elemente oder die Description der Elemente wird zur Description des Ziel-Elements. Ja, aber es ist ja schon so gewesen, dass die, also das ist ja so ein Pulg von Attributen gewesen, also labeled by, described by und dann, genau einhergehend damit ARIA Description, dass die, da geht es ja irgendwie schon darum, dass dies unterschiedliche Beschreibungslängen ermöglicht, oder?

14:40 Also, oder das eine ist ein Label, das andere ist mehr so quasi so einen Einschub noch so irgendwie weiterführende informationenmäßig richtig. Würde ich ja zu sagen, ist mehr so eine WCAG-Frage in gewisser Weise, wie lange die Dinge sein sollen. Aber im Grunde ist das das Grundkonzept. Der zugängliche Name sollte kurz und knackig sein, wenn möglich.

15:04 Wobei eben auch nur so kurz wie nötig, aber so kurz wie möglich. Und die Beschreibung, Entschuldigung, ich muss da mal ins Deutsche wechseln im Kopf, die darf länger sein. Darf so Englisch entsprechen. Und dann, darüber können wir ja auch nochmal reden, seid ihr dann aber auch zu ARIA Details gekommen, wo ich persönlich sagen würde, dass das was ganz anderes ist. Ja.

15:31 Aber wir können vielleicht noch mal bei Describe by und Abel by bleiben. Nee, erzähl ruhig. Ja, also, okay, dann sage ich, was ich sagen wollte. Bei Details, ich sehe das wahrscheinlich mehr so aus der Geschichte der Spezifikation heraus. Da ist es einfach sehr pragmatisch, kam das von Google und zwar ganz konkret für die Google Docs, Google Sheets, etc.

16:00 Und zwar den Use Case, den auch wir in unserem Google Doc haben, weil ich ganz viele Kommentare hinterlassen habe, um genau so eine Verknüpfung machen zu können. Ich habe irgendwas im Text und da sind ganz viele Dinge mit verknüpft. Die sind aber nicht relevant im Sinne der zugänglichen Namen oder Beschreibungen von Dingen, sondern das ist einfach ein ganz anderes Nutzungspattern, Dass man auf einmal haben möchte, man möchte wissen, da ist noch ein ganzer Ratten-Schwanz an anderen Dingen dran, Kommentare, vernästete Kommentar-Threads, alles mögliche komplizierte Dinge.

16:37 Und man möchte irgendwie sagen können, da ist was. Und du bist aber gerade im Text und du editierst dein Dokument oder deine Zelle oder sonst was und willst diese Verknüpfung eben herstellen können und da dann auch letztlich bei den assistiven Technologien den Weg hin und zurück haben zu können. Zurück ist noch viel schwieriger. Und glaube ich, noch viel weniger unterstützt als die Hinrichtung.

17:01 Oh, schlechtes Wort. Die Vorwärtsrichtung. Aber das ist sozusagen der Use Case, mit dem das damals entwickelt wurde und sehr konsequent gepusht wurde. Das ist auch so ein schönes Beispiel dafür, wie die Wurst gemacht wird in den Spezifikationen, weil das einfach wirklich durch die Bank, die Browser-Implementierungen wurden einfach aus einer Quelle finanziert, die assistiven Technologien wurden zum Teil von Google finanziert, um das umzusetzen. Und das ist auch so.

17:34 Das ist eben wirklich ein neues Pattern und insofern ganz spannend. Das heißt nicht, dass es der einzige Use Case ist, im Gegenteil. Ich glaube, es ist eine ganz gute Basistechnologie in ARIA, die man flexibel für viele Use Cases nutzen kann. Aber ich finde sie insofern eben sehr anders als der zugängliche Name und zugängliche Beschreibungsteil der Spezifikation, weil die eben ein sehr spezieller Teil sind, die sehr direkte Auswirkungen haben.

18:06 Und das hier ist was viel Vageres, aber auch viel Tolleres, was viel mehr neue Möglichkeiten schafft, die wir vorher nicht hatten. Quasi verlinken, ohne zu verlinken. Genau. Du hast gesagt, dass Google das alles auch finanziert und auch die Entwicklung der assistiven Technologien, haben die dann auch Ideen oder wie sich das dann konkret in den einzelnen assistiven Technologien darstellt.

18:33 Weil das finde ich immer ein bisschen schwierig. Also als jemand, der das nicht nutzt und als jemand, bei dem an der ARIA-Schnittstelle quasi Schluss ist. Ja, irgendeiner muss ja weiterdenken, sage ich mal, und das auch auf der anderen Seite annehmbar gestalten. Und haben die das auch gemacht, also wenn sie das gefördert haben?

18:55 Genau, also soweit ich das, was ich weiß aus den Unterhaltungen, die wir so hatten, während die Spezifikation entwickelt wurde, war das letztlich genau das. Sie haben mit denen, vor allem mit Screenreadern, also ich glaube, mir fällt ein NVDA und JAWS, haben sie, glaube ich, mit den beiden gearbeitet.

19:12 An der Stelle vielleicht auch anmerken, VoiceOver kann es immer noch nicht. ARIA Details, wenn ich mich nicht täusche, aber vielleicht hat sich in letzter Zeit was bewegt. Sie sind, kritisigerweise wollen sie das umsetzen, aber ich glaube, bisher ist das noch nicht passiert. Und da war eben auch wirklich einfach viel Entwicklung drin.

19:31 Das Ganze ging so einher mit noch anderen Sachen, die in ARIA 1.3 dazugekommen sind, also wie rund um Insertion-Deletion-Roles, um eben Einfügungen und Löschungen eben auch wieder in typisch einen Dokumenten-Use-Case. Für so einen Word-Processor. Und da würde auch Fiddle einfach aus der praktischen Erfahrung der Umsetzung und dem Testing, die ja dann von den Screen-Widdle-Entwicklern gemacht wurde, das Testing, floss eben auch viel, also floss durchaus ein dann auch in die Details der Spezifikationen.

20:07 Aber grundsätzlich ist die Spezifikation relativ vage. Also es soll gesagt werden, da ist was. Das ist so das Minimum. Man sollte sagen, da sind Details. Also dieses Hub mehr und dann musst du gucken, wo du bleibst. Und idealerweise sollte, und das ist natürlich immer eine Schwierigkeit für die Spec, die W3C-Specs hören am User-Agent auf.

20:30 Das heißt, ARIA kann nie einer assistiven Technologie irgendwas vorschreiben. Deswegen sind da nur so ein paar Suggerierungen drin, Suggestionen, wie auch immer. Genau, und da ist dann eben der Gedanke, dass man eine gute Möglichkeit haben sollte, zu den Details zu springen, also zu den referenzierten Elementen zu springen und möglichst auch wieder zurückzukommen.

20:53 Also wenn man eben einen Veränderungsvorschlag im Dokument hat, möchte man von dem konkreten Text, den man gerade durchgeht, zu den Vorschlägen springen können und wieder zurück, wie zum Beispiel, nachdem man sie angenommen hat. Solche Szenarien gibt es ja auch. Ich hätte dazu eine Frage und zwar, bisher hatte ich das so verstanden, dass ARIA letztlich oder HTML plus ARIA Dinge nachbilden, die User Interfaces nativ schon geboten haben.

21:32 Also zum Beispiel jetzt Tabs oder sowas, das gibt es halt HTML-Element nicht, das würde man dann mit ARIA abbilden. Und auch die Bedienpatterns, wäre das dann, sagen wir mal, insofern eine Premiere, als dass man dort etwas Neues entwickelt hat, was es in der nativen Welt so in den Betriebssystemen noch gar nicht gibt als Patterns?

21:54 Da bin ich überfragt, würde ich grundsätzlich sagen. Ich denke, weil es ja nochmal Word Processor ist, wie sagt man auf Deutsch denn? Word und Konsorten schon lange gibt und das schon auf der Desktop-Ebene oder der nativen Ebene schon länger gibt, gehe ich mal davon aus, dass es eigentlich passende Accessibility APIs in den verschiedenen Betriebssystemen gibt, sodass man da relativ denselben Mustern folgen konnte.

22:23 Aber da bin ich ehrlich gesagt überfragt. Okay. Aber es ist ein schöner Gedanke. Ja. Es gibt jetzt was, was so ein bisschen, um vielleicht ein bisschen in die Zukunft zu schauen. Jetzt gehe ich vom Thema ab. Aber aktuell steckt seit Langem bei uns ein PR für die Spezifikation so ein bisschen fest. Aber es kommt jetzt gerade wieder Bewegung rein.

22:44 Und das Ganze nennt sich ARIA Actions und soll darauf aufbauend zur Sekundär- Aktivitäten besser in denen nutzbar machen und einfacher zu implementieren machen. Mein Deutsch ist schrecklich. Das heißt, wenn man sowas hat wie ein webbasiertes Mailprogramm und man geht durch seine Mails durch und man hat all diese Sekundärfunktionen, die man typischerweise hat, wie irgendwie archivieren, löschen, favorisieren, irgendwas machen, dass man eben eine wirklich viel einfachere Struktur hat, um diese sekundären Aktionen auslösen zu können mit Access-Technologien.

23:25 Und das ist so ein bisschen auch so diese neue Richtung an den Sachen, die momentan versucht werden in der Spezifikation und dann eben, natürlich müssen sie in den Implementierungen funktionieren, sonst brauchen wir sie nicht machen, sonst kommen sie ja nicht mehr in diese Spezifikationen und, das ist so ein bisschen ein neuer Weg, der finde ich mit ARIA Detail angefangen hat, der ganz spannend ist.

23:49 Das finde ich eine gute Nachricht. Danke fürs Mitteilen, Peter. Ich kenne die sekundären Aktionen, also diese Accessibility Actions schon aus native Mobile Apps, also aus beides iOS und Android. Und das ist sehr praktisch, weil eben auf langen Listen von Elementen, mit denen man diverse Interaktionen unternehmen kann, wie eben E-Mails oder Social Media Postings oder Chat-Nachrichten.

24:16 Das kann man schon auf mobilen Anwendungen leicht auswählen. Also zum Beispiel auf iOS gibt es die Rotor-Geste. Das ist eine sehr praktische Geste. Man kann mit zwei Finger so drehen, als ob wir ein Drehrad gedreht hätten. Und da gibt es verschiedene Optionen, auf denen wir vielleicht schnell zugreifen möchten.

24:35 Zum Beispiel schnell die Sprachausgabe, Geschwindigkeit und Lautstärke. Aber es gibt auch Aktionen. Und das heißt, wir können über E-Mails laufen. Die E-Mails brauchen dann keine zusätzlichen dedizierten Button-Elemente mit allen Aktionen wie löschen, antworten, archivieren und so weiter, sondern man wischt einfach mit dem Finger dann unten, wenn der Rotor auf Aktionen umgestellt ist und man ruft diese Aktionen herbei, nur dann, wenn sie gebraucht werden.

25:04 Also es freut mich auch, dass das auch im Web kommt. Ich habe das auf Desktop-Plattformen bei jeglichen Instant-Messaging-Dienstleistungen schon so gesehen, dass entweder die rechte Pfeiltaste öffnet sein Menü mit Aktionen oder die Standard-Tasten-Kombination für Kontextmenü. Also auf Windows ist es Shift-F10 und dann kann man das auch dort auswählen.

25:30 Also ich bin gespannt, wie die verschiedenen assistierenden Technologien, vor allem auf Desktop, das für sich mappen. Ähm. Schöp, das du angesprochen hast, dass ARIA ergänzt das Web um einige Elemente, die HTML nicht hat und die sich so etabliert haben. Was ich spannend finde, ist, dass HTML ist auch jetzt mit ARIA ergänzt, damit neue Komponenten mit assistierenden Technologien verknüpft werden können.

26:05 Und was mir so als Beispiel einspringt, da wir schon von ARIA Details gesprochen haben, ist das neue Popover API, die ich jetzt erst letztes Jahr entdeckt habe. Und es handelt sich hier um ein Popover Element. Das sieht, nehme ich an, visuell so aus, dass da ein Fenster einfach rauskommt, wenn man eine Taste aktiviert.

26:26 Und für Screenreaders ist dieser Bezug zwischen die Taste, die das Ganze triggert und zwischen den Inhalten, der dann erscheint als Folge, ist mit ARIA Details erstellt. Das heißt, ich muss nicht diesen neuen Inhalt selbst suchen, sondern ich kann einfach eine Taste drücken und der neue Inhalt wird mir vorgelesen, beziehungsweise es wird zum Inhalt dann navigiert.

26:51 Also es gibt mehrere Beispiele von solchen HTML-Elementen, zum Beispiel Output hat auch eingebaute ARIA-Live Semantik. Es gibt weitere Beispiele davon, wie ARIA dafür genutzt wird, dass HTML-Elemente besser bei assistierenden Technologien vorbeikommen und die EntwicklerInnen müssen nicht mal davon wissen, wenn sie das in HTML implementieren, dass sie automatisch auch für Barrierfreiheit bei assistierenden Technologien sorgen.

27:29 Da würde ich noch ein Wort hinzufügen und zwar, falls man es mal ausprobiert und nicht bemerkt, dass man die Details-Verbindung hinkriegt. Es gibt tatsächlich ein paar Ausnahmen. Also man kann es als Entwickler einerseits quasi verhindern, aktiv. Es gibt aber auch die Ausnahme, dass wenn das Pop-Over-Element der nächste Sibling ist, also die nächste Node ist, dann wird es glaube ich nicht als Details ausgegeben.

28:12 Und das natürlich im Accessibility-Tree der Sibling. Es gibt so ein paar Ausnahmen, dass man das mal zusätzlich gehört hat. Insbesondere auch, dass man es loswerden kann, wenn man auf einmal damit mehr Probleme schafft, als man Lösungen produziert. Das ist hier manchmal auch ganz wichtig. Und bei der Gelegenheit wollte ich ansprechen, die Frage stellen, wer eigentlich die AAM-Spezifikationen, die diversen sogenannten Accessibility-API-Mapping-Spezifikationen, überhaupt schon mal kennengelernt hat.

28:47 Weil das ist der Platz, an dem ich gerade nachgeschaut habe, wie das eigentlich genau spezifiziert ist, was PopOra in Sachen Barrierefreiheit produziert. Kennt die irgendjemand von euch, diese Spezifikationen? Ich habe letzte Woche angefangen, das GitHub-Repositorium dieses Projekts zu folgen. Ich steige langsam ein in die Materie. Cool.

29:11 Also ich habe das noch nie gehört. Super. Ich auch nicht. Was ist das? Also geht es von dem Mapping von dem DOM auf den Accessibility Tree, wie der Algorithmus sozusagen spezifiziert ist? Oder was muss ich mir noch überraschen? Nein, es gibt genau den nächsten Schritt quasi. Und zwar, wie es auf die Accessibility APIs, also die Barrierefreiheits-APIs des Betriebssystems geht.

29:39 Sind die denn so einheitlich? Sind sie nicht, genau. Da sind die vier wesentlichen APIs, die es so gibt. Beziehungsweise es gibt mehr, aber wir haben nicht alle. Wir haben jetzt ganz neu, gibt es endlich eine, hoffentlich bald die Android-Mappings auch und genau, und da sind einfach die verschiedenen Mappings für, also die AAMs gibt es für ARIA selber, die heißt Core AAM, also der Cavern der Accessibility-Mappings und dann gibt es für die jeweiligen Host-Languages, also HTML, SVG gibt es AAMs und dann gibt es für die verschiedenen ARIA-Module spezifische AAMs weil die Module noch zusätzliche Rollen sozusagen hinzufügen.

30:28 Und genau, und da steht dann eben sowas drin, da kann man dann nachgucken. Das ist tatsächlich nicht wirklich an Entwickler gerichtet, beziehungsweise es ist in gewisser Weise primär an Browser-Entwickler gerichtet, die letztlich dieses Mapping vornehmen sollen, wenn sie einen Browser für verschiedene Betriebssysteme entwickeln.

30:47 Aber manchmal steckt da eben dann doch wesentliche Informationen drin, die man da gut nachgucken kann. Wie wird denn tatsächlich was von HTML gemappt? Und eben hatten wir den Placeholder. Sowas findet man daneben auch, dass es nicht einfach nur irgendwie in die Eggname-Kalkulation reingeht, sondern tatsächlich sein eigenes Ding hat, weil es das halt in den APIs gibt.

31:12 Und deswegen ist es ein bisschen parallel oder anders. Oder orthogonal, wie auch immer man will, zu den Namen und Beschreibungen. Genau, das wollte ich nochmal erwähnt haben, weil ich immer wieder feststelle, man weiß das nicht so unbedingt und es ist auch in gewisser Weise richtig so, aber manchmal ist es ganz nützlich, um nachzugucken, wie der Weg von der DOM zum Accessibility Tree, zum Betriebssystem Layer und dann weiter in die assistive Technologie eigentlich funktioniert.

31:46 Ja, da gibt es viele Stellen, wo was kaputt gehen kann. Auch wahrscheinlich. Oder verloren gehen kann, besser gesagt. Genau. Und manchmal aber auch zusätzlich. Also man muss ja auch denken, assistive Technologien können ja meist viel mehr. Also Screenreader haben früher einfach in der DOM operiert und die können das immer noch.

32:06 Also es gibt durchaus Situationen, wo ein Screenreader vielleicht einfach sagt, ich schere mich nicht, was im Accessibility-Tree steht oder was dann in den APIs auf der Betriebssystem-Ebene steht, weil ich weiß, da hat jemand Mist gebaut mit vielleicht Heuristiken, die ich habe. Und ich gehe jetzt einfach nochmal ins DOM und schaue nochmal nach und gucke selber nach.

32:26 Das gibt es halt auch und das kann für nicht geliefte Entwicklerinnen ganz schön irritierend sein. Also für mich jedenfalls. Vielen Dank. Ja, auf jeden Fall wieder Lektüre und vielleicht beschäftigen wir uns in Zukunft ja auch noch ein bisschen öfter mit den AEM, den Accessibility API Mappings. Gutes Stichwort auf jeden Fall, sehr cool.

32:52 Genau, sollen wir zum nächsten Stichwort übergehen? Ich weiß nicht, ob wir da, das hat ja vor allem der Marco, glaube ich, erklärt, ARIA-POS in Set hatten wir und ARIA-Set-Size, die sozusagen in Tateinheit daherkommen, wo man im Grunde bei großen Datensets kommuniziert, also wie groß die sind und wo man sich jetzt gerade in diesem Datenset befindet mit der Ansicht.

33:19 So ungefähr war das, glaube ich. Genau, das hilft ja insbesondere, wenn man nicht die ganze Menge darstellen kann aus Gründen. Also weil es einfach zu viele sind und man nur ein Subset darstellt. Wir hatten uns da, glaube ich, so ein bisschen gewundert, warum man das Set Size, also die Größe der gesamten Menge, jedes Mal auf dem Einzelelement setzen muss und nicht einfach auf dem Container oder der Elternelement.

33:51 Aber das scheint tatsächlich so zu sein, oder Peter? Ja, das ist tatsächlich so. Ich kann mal einen Link in die Shownotes packen. Wir haben das tatsächlich gerade erst wieder auf dem Schirm gehabt. In der Working Group, ob man das nicht auch auf dem Container machen kann. Und wenn man in das Issue reinguckt, auf dem GitHub-Tracker von der ARIA-Working Group oder von der ARIA-Spezifikation querstrich allgemeiner Tracker, dann erfährt man allerdings auch, dass überhaupt Set Size und POS in Set nicht so wirklich den besten Support haben.

34:38 Das ist so ein bisschen, würde ich sagen, eine kleine vernachlässigte Baustelle, die mal jemanden bräuchte, der versucht zusammenzutragen auf der Spezifikationsseite, wie eigentlich der Zustand ist. Also viel Arbeit in den letzten Jahren, was die ARIA-Spezifikationen, das ganze Potpourri von, ich weiß nicht, 15 Spezifikationen, die wir verwalten als Gruppe, da ist halt viel in einfach aufräumen gegangen und mit der Realität abgleichen ist einfach was Wichtiges.

35:09 Und da fallen diese drei Attribute auch rein. Da ist, glaube ich, nicht alles gut. Ich weiß, wir haben ein Proposal, dass wir mehr darauf setzen wollen, dass User Agents das richtig berechnen können müssen, wenn nichts angegeben wird. Also es gibt Rollen, die momentan verlangen, dass man diese Attribute benutzt und da mehr darauf setzen, dass das tatsächlich die User Agents auch richtig berechnen, wenn alles im DOM ist.

35:43 Aber die Frage ist, zumindest laut einem Kommentar in dem Issue, scheint es so zu sein, dass wenn man genau das Szenario hat, das Marco, du eben beschrieben hast, man hat ein zu großes Objekt, eine zu lange Liste, eine Tabelle, ein Grid, dass man da eben tatsächlich. Die echte Information, die Background-Information wiedergeben will, das scheint nicht hundertprozentig über alle oder über die wichtigen assistiven Technologien hinweg zu funktionieren. Leider.

36:22 Aber ich finde auch, es gehört auf den Container. Es wäre auf jeden Fall sehr viel weniger fehleranfällig dann, glaube ich. Also in der Entwicklung für die Developer. Ja, ich konnte auch nicht nachvollziehen. Ich glaube, das ist einfach immer schon so gewesen, was vielleicht was damit zu tun hat, wo es halt herkam, welche Patterns aus den Betriebssystemen da genommen wurden, um das anfangs zu entwickeln. Ich konnte es nicht mehr rekonstruieren.

36:51 Ja, es ist ja eigentlich auch eher untypisch, typisch, dass, irgendwelche, Annotationen aus älteren Elementen gezogen wird, oder? Also aus dieser Warte heraus, also irgendwie ich erlebe das eigentlich schon immer, dass wenn Aria-Attribute eine Rolle spielen, dass die immer alle dann auf dem Element, das es betrifft, gesetzt sind und das wäre dann ja so ein Sonderweg, in dem Fall wahrscheinlich der dann so.

37:24 Hat noch nie einer gemacht vorher. Es kann aber auch einfach Performance gewesen sein, ganz früher, als die ganze Technologie noch nicht so weit war, als der Accessibility-Tree noch nicht so geklärt war und man eben wirklich durch die DOM schauen musste, um das dann hätte müssen, um dann zu finden, wo das Elternelement ist.

37:45 Also das kann durchaus auch ein Faktor sein, Denn den Accessibility-Tree zu bauen ist einfach auch ein Performance-Bottleneck. Also das ist immer wieder eine Diskussion, die wir haben, gerade wenn man an Live-Updates denkt. Dann immer wieder den kompletten Tree zu rekonstruieren, alle Namen zu berechnen etc.

38:04 Ist einfach, ich weiß nicht mehr wie lange. Vor etlichen, nicht vielen Jahren, da war einfach mit dem Accessibility-Layer die Performance-Bottleneck. Signifikant unter dem, was es ohne ihn war. Also wenn man mit einer assistiven Technologie die Fallerfolgs benutzt hat, war es einfach wahnsinnig viel langsamer.

38:27 Und da kann es durchaus sein, dass es einfach deswegen so war, Denn der Autor weiß es ja, oder die Autorin, wie die richtigen Werte sind. Sie wurden ja auch, also wenn sie irgendwo gesetzt werden, können sie ja auch überall gesetzt werden. Ja, also gerade in dem Fall, wenn man nicht genau weiß, wie viele Elemente das, oder nein, anders, wenn ich nicht alle anzeigen kann, und ich dieses Szenario habe wie bei uns, also endlos gräumende Tabellen, dann haben wir es tatsächlich so manchmal, dass im ersten Chunk gesagt wird, da sind jetzt hier, was weiß ich, 2,758 Millionen Datensätze drin.

39:08 Und wenn dann weitergescrollt wird, dann ändert sich die Summe ganz einfach, weil das lebende Daten sind. Und da kommen neue Daten dazu oder andere fallen raus, weil sie plötzlich nicht mehr zu den Filterdaten passen. Und ich glaube, in dem Fall ist es sogar einfacher, wenn man einfach die Gesamtzahl auf dem Tabellenzeilen-Element setzt, weil das eh ausgetauscht wird durch das Nachladen des Chunks, als wenn man dann jedes Mal wieder auf das Elternelement zurückgreifen müsste.

39:44 Das kann schon sein, dass dann da irgendwie diese Performance-Probleme entstehen könnten. Also an beiden Seiten, beim Update des DOMs und natürlich dann auch noch beim Update des Mappings auf dem Accessibility-Tree. Da ist es dann natürlich einfacher, wenn die Gesamtanzahl an jedem einzelnen Listen-Element oder Tabellen-Zeilen-Element dransteht.

40:11 Das macht total Sinn, ja. Ich denke, für beides gibt es gute Use Cases und ich hoffe mal, wir kommen dazu als Spezifikation. Was würdest du denn jetzt so uns raten? Also ich versuche immer so ein bisschen zu predigen, okay, also wir sind in der Konstellation, Management will nicht unbedingt für Barrierefreiheit viel bezahlen, weil so nicht geklärt ist mit dem Kunden, also unsere Produkte verkaufen wir an Kunden und eigentlich müssten die doch da bezahlen.

40:47 Und das verstehe ich auch aus einer wirtschaftlichen Betrachtungsweise heraus, dass man da erstmal queren sollte, wer die Kosten übernimmt. Aber eigentlich ist meine Perspektive, okay, bis zum Accessibility-Tree sollte man schon saubere Arbeit machen, so wie die Spezifikation das hergibt und dann sagst du, ja gut, auf der anderen Seite ist das hier aber noch gar nicht so richtig gut implementiert, soll ich das dann lassen an der Stelle oder soll ich sagen, okay, einer muss ja anfangen und wer weiß denn, was heute ist, muss ja morgen nicht immer noch so sein, was würdest du denn uns raten in so einer Situation?

41:32 Also an die Spezifikation halten oder an die Realität der Geräte? Ja, der User kommt immer zuerst, würde ich sagen. Das ist ja auch das Credo der W3C im Allgemeinen, die User zuerst. Aber ich glaube, was du ansprichst, ist ja eine große Lücke, die einfach existiert, was die Unterstützung, also Dokumentation zur Unterstützung in assistiven Technologien oder auch nur innerhalb von Browsern angeht.

42:06 Also Can I Use hat keine Daten zu ARIA in irgendeiner differenzierten Form. Und was Screenreader angeht oder andere assistiven Technologien, gibt es noch weniger Daten. Es gibt das alte, wie heißt es, A11Y Support Projekt. Das ist auch einfach nur jemand, der sich die Zeit nimmt. Es gibt vielleicht noch ein bisschen, wie soll man sagen, fundierter, neues Projekt von Steve Faulkner als Teil von Tetralogical.

42:49 Genau, danke dir, Babel, zu HTML-Support in Screenreadern. Und dann haben wir natürlich die Authoring-Practices der W3C-Viaria-Initiative, die auch gut getestete Patterns sein sollen, aber nicht immer sind. Und so ist es ein ziemliches Kuddelmodel und das macht es wahnsinnig schwer, aber ich fürchte es nicht zur Befreitung davon, an die Nutzer zu denken und ich würde sagen, Meine Herangehensweise ist, wenn man gerade neue Muster verwenden will und neue Feature, ist das dasselbe wie überall.

43:30 Also Graceful Degradation und Progressive Enhancement sind halt die Sache. Wenn wir bei Details sind, dann macht man halt noch ein Describe-Buy dazu. Dann kriegt man auf beiden Seiten Unterstützung und kommt hoffentlich gut seinen Nutzern entgegen und hat eben einen Kompromiss gefunden. Aber ja, es gibt durchaus auch Sachen, wo man einfach sagen muss, das mache ich jetzt und es funktioniert vielleicht erstmal nicht, aber vielleicht funktioniert es eben für meine Nutzer. Das verstehe ich durchaus.

44:02 Also ich meine, da sind einfach die realen Zwänge wie bei allen anderen. Gerade wenn man jetzt irgendwie, Marco, bei dir klingt es ja eher wie, sehr spezifische Nutzergruppen von Kundengruppen, da kann es natürlich mal sein, dass man sagt, ja, also das kennen wir vielleicht alle, wenn man halt einen Kunden hat, bei dem alle denselben Browser benutzen, dann kann man natürlich die Abkürzungen auch nehmen.

44:24 Es geht ja letztlich einfach am Ende immer nur um die konkreten Kunden und konkreten NutzerInnen. Und das Wissen halt, also wenn man, man muss ja eigentlich über die Schnittstelle hinaus gucken und auch wissen, wie sich das in assistiven Technologien alles darstellt. Und wenn man dieses Wissen nicht hat, dann kann man halt, so würde ich denken, nur bis zur ARIA-Schnittstelle denken.

44:55 Und das wäre dann besser als gar nichts. Naja, also ich meine, User-Testing ist ja was. Und das muss aber auch bezahlt werden. Und da ist es genau da, wo man, das gut gegenüber dem Management argumentieren, verargumentieren müsste und wenn man das eben nicht kann und ja. Dann ist das schnell zu Ende an der Stelle. Nein, verstehe ich total.

45:26 Aber ich weiß nicht, Pavel, wie ist das bei dir im Praktischen? Also du bist ja, wenn ich es richtig verstanden habe, fest angestellt? Ja, schon. Genau, aber wie ist das, hast du auch mal, also gibt es. Wie ist das von deiner Seite als Nutzer, Tester, also User, wie hast du dich beschrieben am Anfang?

45:49 Ich kriege es nicht mehr zusammen. Ja, Accessibility und Experience, Expert. Also ich will immer auf dem Aufschauen, ich schaue immer aus auf die neuen Entwicklungen, was ARIA und HTML und APIs angeht. Das Problem ist nur, assistierende Technologien sind nicht immer so leicht auf das Neueste zu bringen. Vor allem, es braucht Zeit, bis das Neueste von Neuester eingeführt wird.

46:17 Und dann, es ist nicht immer möglich, die neueste Updates für BenutzerInnen zu kriegen, weil einige Assistenten der Technologien sind sehr kostbar und die Updates kosten auch und die Updates heißt auch neue Unterstützung für neue ARIA-Rollen zum Beispiel. Aber auch einige Screenreaders, vor allem auf mobilen Geräten, sind an spezifische Betriebssystem-Versionen verbunden.

46:41 Und das heißt, wenn ich ein älteres Gerät habe, das nicht mehr unterstützt wird, weil nach zwei, drei Jahren keine neuen Updates kommen, es besteht auch die Gefahr, einige neue Sachen kommen nicht zu mir, sonst wenn ich ein neues Gerät kaufe. Und mit Hinblick daraus, wir empfehlen immer vorsichtig. Wir empfehlen immer vorsichtig einige neuere APIs, weil wir wissen auch, dass realistisch, es braucht Zeit, bis es sich so festsetzt, dass alle davon profitieren können.

47:12 Und das ist leider die traurige Realität für BenutzerInnen. Aber wenn wir jetzt schon etwas verwenden, wie zum Beispiel das Post-Inset und das Set-Size, entstehen denn dann Nachteile für euch, also in der Benutzung, wenn die assistiven Technologien diese Attribute noch nicht auswerten können? Das nicht. Also in die konkrete Sache für Post-Inset, ich glaube, die Anzahl der Elemente wird nicht angesagt, verstehe ich so.

47:42 Das ist einfach alles, was da passiert. Ich hatte ein anderes Beispiel jetzt im Kopf, das mir sehr gut gefällt. Ich will das gerne verwenden, aber ich weiß auch, dass die Unterstützung sehr gering ist. Und das ist zum Beispiel ARIA Error Message. Also das unterstützt soweit ich weiß momentan NVDA und glaube ich auch TalkBack.

48:04 Und bei anderen Screenreaders es ist noch nicht etabliert, mehr oder weniger. Ich habe dazu einen schönen Post von Bogdan Zerowatz aus Norwegen gesehen, der das irgendwann getestet hat und zusammengefasst hat. Das könnte schon ein bisschen veraltet sein, aber ich folge regelmäßig auch die Changelogs von allen gängigen Screenreaders und ich habe noch nicht gehört, dass da viel Verbesserung passiert ist.

48:29 Und das ist ein tolles Attribut, weil momentan Ich sehe das so in Praxis. Es wird für Fehlermeldungen ARIA Describable oft genutzt bei Eingabefeldern, also bei diversen Input-Controls. Weil ARIA Describable ist weit und breit unterstützt. Und ARIA Error Message stellt sicher, dass beides, also alles, was in ARIA Describable beinhaltet ist, und die Fehlermeldung, können parallel vorgelesen werden.

49:01 Ich habe das so getestet, das hat für mich so mit NWDE funktioniert und das fand ich super. Das Problem ist nun, außer ein paar Screenreaders ist das noch nicht unterstützt und dann ist das Problem, dass für einige BenutzerInnen geht einiges von diesen Informationen verloren oder sie können gar nicht die Fälle-Meldungen lesen.

49:21 Okay, das kann ich natürlich gut nachvollziehen, ja. Das ist auch ein super Beispiel für die Community, finde ich. Ich habe in die Show Notes gepackt einen Link zu einer Diskussion in der ARIA Working Group im Repository bei GitHub, wo vor, glaube ich, zwei Jahren, zwei Jahren? Was ist mir nachgucken?

49:43 Die Frage aufkam, ob man ARIA Error Message deprecaten sollte, weil es so schlecht unterstützt war. Und da kam dann auch sehr klares Feedback von der Community und dann Gott sei Dank hat auch NVDA gerade in der Zeit Support hinzugefügt und so konnte das Ganze. Abgewendet werden. Was sehr schön war, fand ich damals.

50:13 Ja, es gibt es ja auch bei HTML, JavaScript und Co., dass wenn irgendwas nicht implementiert wird von den, User Agents, dass sie das dann irgendwann wieder rausbauen, weil das bringt ja dann auch nichts. Also zum Beispiel, ich weiß nicht, wobei CSS, dieses ganze Voice-Universum, das glaube ich, ich weiß nicht, ob das auch deprecated ist mittlerweile offiziell.

50:38 Aber das CSS ist falsch, oder? Das ist diese Aura-Sage. Auf einmal. Ich habe davon vor kurzem gepostet, ich glaube, das ist immer noch, bitte korrigiere mich, Peter, wenn ich da falsch stehe. Ich habe mich erkundigt, steht immer noch als irgendwie Draft oder Recommendation ist es noch nicht. Aber es ist doch sozusagen, auf dem Tisch in Entwicklung nicht aufgegeben, so verstehe ich das, aber es gibt einen riesen Pushback von der Community, weil, und ich kann das auch teilweise verstehen, die hätten das ungern und ich habe eine informelle Umfrage auf Mastadon gemacht, dass die EntwicklerInnen, die schon viel zu viel zu tun haben mit HTML, CSS und ARIA und viele verstehen auch nicht, wie das höchstlich und korrekt funktioniert.

51:27 Sie hätten noch dazu die Aufgaben und die Macht. Meine Sprachausgabe-Einstellungen zu manipulieren oder mir irgendwelche zusätzlichen Geräusche dazu hinzufügen, was wahrscheinlich nicht viele benutzen würden, weil außer die ganze Arbeit auf HTML und CSS und ARIA müssten sie noch dazu Geräusche erfinden für jegliche Ereignisse auf der Webseite.

51:53 Es gab nur einen Implementer bis jetzt und das war der Emacs Peak. Das ist eine Screen-Reading-Umgebung für den Emacs-Editor. Und der Browser dorthin kann tatsächlich diese Oral-CSS verwendet. Ideen dafür gibt es schon seit Ende der 90er Jahre, Anfang 2000er. Und das wurde in dieser Form unterstützt. Ich finde die Idee grundsätzlich cool.

52:18 Eigentlich, was ich empfehlen kann. Sollen wir noch kurz erklären, was das ist? Nur ganz kurz. Das Aural CSS. Es geht darum, dass durch CSS, also versehende Menschen, macht CSS Sachen schöner, so wie ich das verstehe. Man kann das Aussehen so anpassen, man kann diverse Effekte erziehen und alles mögliche, also Animationen und so weiter erstellen.

52:43 Die Anregung war, dass vielleicht blinde Menschen hätten sowas gerne auch in einer Form, die sie auch konsumieren können. Das heißt, Geräusche und Anpassung von Geräuschen. Die Sprachausgabe über Ton, über Lautstärke, über Aussprache diversen Worten, über die Höhe des Tons, die Geschwindigkeit. Und der Vorschlag, der immer noch vorliegt, und ich glaube, die größte Unterstützerin davon und die Gründerin davon ist die Leonie Watson.

53:12 Das ist, dass die EntwicklerInnen eigentlich eine ganze Menge an Parameter bei CSS bekommen, die das steuern können. Also die EntwicklerInnen hätten dann diese Macht in ihren Händen, diese Parameter individuell anzusteuern. Und es gibt schon bei Screenreaders die Möglichkeit, die üblichen Ansagen, wie zum Beispiel Überschrift Ebene 1, mit Geräuschen zu ersetzen oder mit abgekürzten Formen oder mit einer anderen Stimme, einer anderen Stimmhöhe.

53:49 Momentan aber machen das die BenutzerInnen selbst. Also sie erstellen eigene Profile dafür und Einstellungen-Packs, die dabei helfen. Ein schönes Beispiel dafür gibt es in JAWS, da gibt es ein Schema, ein Sound-Schema, wo die Ebenen der Überschriften mit den Tönen auf einer Klavier in der Z-Dur, in den Z-Dur-Schlüssel kommen, also 1, 2, 3, 4, 5, 6, 7, 8, also ein Ton nach dem anderen.

54:22 Und da unter blinden Menschen es nicht an Menschen fehlt, die ein perfektes Hören haben und können das unterscheiden, es gibt Menschen, die wirklich davon profitieren, dass jede Überschrift-Ebene mit einem anderen Klang auf die Klavier vermerkt ist. Die Frage ist jetzt, und da gibt es, wie ich schon erklärt habe, ein großes Pushback.

54:45 Soll das der Benutzer, die Benutzerin selbst steuern oder sollen die EntwicklerInnen auch die Möglichkeit haben, das für die BenutzerInnen teilweise zu steuern? Es gibt auf iOS zum Beispiel Möglichkeiten, sogenannte Attributed Strings in Apps zu verwenden und da haben die EntwicklerInnen wirklich viel...

55:08 Macht drüber. Man kann einzelne Worte so anpassen, dass sie eine andere Sprache vorgelesen werden. Man kann das internationale phonetische Alphabet verwenden, um die Aussprache ganz genau anzupassen. Also wenn ein fremdes Wort vorkommt, dass es richtig vorgelesen wird. Man kann die Sprachausgabe auch weiter steuern über die Geschwindigkeit, die Lautstärke und so weiter. Es wird nicht oft genutzt.

55:34 Ich glaube, Apple verwendet das vor allem für einige Worte, also damit Shazam richtig ausgesprochen wird. Das sind wirklich schon ganze Zeichen aus dem phonetischen Alphabet genutzt. Und ja, das ist eben die Frage. Wir hatten eine kleine Diskussion auf Masteron und zum größten Teil haben sich BenutzerInnen geäußert, dass sie eher selber das steuern könnten.

56:00 Ich glaube, das Gegenargument gewesen ist, dass dank solchen Eigenschaften wie CSS Speech könnten die BetreiberInnen der Webseiten einen eigenen Brand oder Sonic Brand oder Brand mit Geräuschen und Klang auch für blinde Menschen erstellen. Die Frage ist nur, in Realität, wer würde das eigentlich machen?

56:23 Ja, ich muss sagen, ich finde das super spannend, da auch die Pros und Cons zu hören, weil das erinnert mich sehr an Fragen, die ich öfters in der Arbeit jetzt habe, weil ich ja für eine sehr große Firma arbeite. Und da ist öfters die Frage, zum Beispiel in Bezug auf Alternativtexte, welche Bilder sind jetzt wirklich dekorativ und welche nicht, weil halt schon viel das Argument kommt, naja, wir wollen jetzt nicht Informationen vermitteln, wir wollen einen Vibe rüberbringen, ein Gefühl und irgendwie so eine halt Brand Identity, aber auch irgendwie eine emotionale Connection zu der Brand und wie viel kann ich dann wirklich machen, wie viel sollte ich auch machen, ab wann ist es irgendwie zu viel und wir haben auch noch keine,

57:10 Antwort drauf, aber ich finde, das geht auch sehr in die ähnliche Richtung eben mit den Sounds und so weiter und finde ich wirklich sehr spannend. Ich habe gleich in die Shownotes gesetzt, einen Link auf, was man so ein bisschen als die Gegenseite beschreiben könnte. Das ist die sogenannte Pronunciation Task Force in der W3C.

57:35 Da ist auch ein bisschen, glaube ich, in den letzten Jahren ein Konflikt entstanden zwischen den verschiedenen Unterstützenden. Und das beschäftigt sich im Wesentlichen auch ein ähnliches Problem, nämlich die richtige Aussprache von Begriffen und eben in der Audio-Wiedergabe und kommt eher aus der Richtung SSML, das ist eine XML-Sprache zum Auszeichnen von korrekter Aussprache und haben die, diese Taskforce hat lange versucht, Wege zu finden, hat zusammen mit assistiven Technologien sich unterhalten, um irgendwie herauszufinden, wie man es hinkriegen kann, dass man genauere Informationen zur Aussprache integrieren kann im Web und ich glaube, es sind beides valide.

58:39 Lösungen für unterschiedliche Probleme. Also Leonie Watson hat ja irgendwann mal einen längeren Artikel gehabt, wo sie eben gegen den Ansatz der Pronunciation Task Force argumentiert hat und für CSS Speech, was ich sehr nachvollziehbar fand, weil sie gesagt hat, naja, CSS ist eben auch sehr gut nutzermanipulierbar, und es ist schon immer so gewesen, dass man das gut kontrollieren konnte als Nutzenden, wie man CSS durchlässt und das wäre bei Speech eben sehr, auch sehr, bei CSS-Speech eben auch ähnlich, dann in diesem selben Schema, in dem etablierten Schema, das gut von Nutzenden kontrolliert werden kann und diese sehr dezidierte, spezifische Information von sowas wie SSML wäre eben problematisch und ich habe

59:30 das Gefühl, das hat viel mit auch den unterschiedlichen Gruppen von Nutzenden zu tun. Screenreadernutzer, Haben ein ganz anderes Verhältnis zum Audio-Output meiner Erfahrung nach, als jetzt sagen wir mal jemand, der Tools für die Unterstützung mit Dyslexie nutzt. Also da gibt es auch Software, die vorliest, aber eben ganz anders, weil sie ein synchrones Highlighting macht, um den Leseprozess zu unterstützen und eine ganz andere Aussprache gebraucht wird, um die Menschen zu unterstützen durch diese assistive Technologie.

1:00:11 Insofern gibt es da einfach sehr viele Möglichkeiten. Und es verknüpft, um den Sprung noch schnell zu machen, verknüpft sich so ein bisschen mit einem Teil eurer Glücksradfolge, nämlich mit den Braille-Properties, weil es ja letztlich um verschiedene Ausgabeformate geht. Und da ist einfach viel los, noch viel unklar auch, aber ich glaube, das ist ein ganz spannender Raum in der Standardisierung der Zeit, weil es einfach auf einmal überhaupt diese Möglichkeiten gibt, darüber zu reden, wie kann ich denn und wie sollte ich denn was spezifisch für Audio-Output machen und wie kann ich und sollte ich was spezifisch für taktilen Output machen und vielleicht eben noch für andere Lebensrealitäten von Nutzenden.

1:00:59 Und das ist eigentlich spannend, weil ich habe mir schon überlegt, wie ich am besten Menschen, die noch nichts mit Barrierfreiheit zu tun hatten, in die Welt der Barrierfreiheit einführen kann. Und eine Übung, die ich immer am Anfang mache in meinen Schulungen, ist, als Kind habe ich meinen ersten Zugang an Informationen, die sonst nur geschrieben ist, war unsere lokale Kinokette.

1:01:28 Die hatten eine Hotline, eine telefonische Hotline. Man durfte dann dort anrufen. Das war 2002 und Computers waren in Polen, wo ich herkomme, für blinde Menschen noch nicht so verbreitet. Alles war sehr teuer, Screenreaders und Sprachausgaben. Und ich konnte das erste Mal in meinem Leben irgendwo anrufen und einfach mir anhören, was für Filme jetzt laufen.

1:01:50 Und das verwende ich immer als Anlaufspunkt und frage, wie würdest du dir vorstellen, dass das Internet läuft grundsätzlich über das Telefon? Also stell dir vor, Bildschirme wurden nie erfunden. Alles, was du hast, ist ein Telefon. Du unterrufst überall an, aber du hast die gleichen Möglichkeiten wie das Internet.

1:02:11 Also wie würde Spam klingen, wenn wir keinen Computer hätten, also keinen Bildschirm hätten? Wie würden die Viren klingen? Wie wird das Online-Shopping-Experience klingen? Wäre das eine menschliche Stimme oder eine Sprachsynthese? Hätte es Geräusche gegeben oder sonst wurde irgendwie auf eine andere Weise dieses Erlebnis von, ich bin in einem Geschäft und kaufe mir was, das visuell schon vermittelt ist über den Bildschirm, mit viel Farbe, mit Werbung für alles überall, für gesponserte Produkte und so weiter.

1:02:49 Wie würde diese ganze Welt in Geräusche transportiert, wenn wir nur über das Telefon auf das zugreifen könnten? Und davon denke ich immer, wenn ich an Initiativen wie CSS-Speech und Personalisierung durch Geräusch denke. Eine interessante Welt, aber ich glaube nicht, dass in Realität viele das einsetzen würden, viele Marken sich davon entscheiden würden.

1:03:11 Aber als philosophisches Experiment ist das schon spannend. Und ich würde auch sagen, im Zweifel nicht einsetzen, wäre meine Empfehlung. Er hat letztes Mal über die Braille-Properties gesprochen. Das ist tatsächlich etwas, was ich in der ARIA-Spec schreiben durfte. Das ist eigentlich der Grund, warum ich in die ARIA-Working-Group kam, um das zu schreiben.

1:03:41 Und es gibt immer wieder die Diskussion, dass wir dringend irgendwie einen Weg brauchen in der Spezifikation, um so eine Art standardisiertes Warnsymbol hinzupacken, so wie so ein Giftaufkleber auf Packungen, um einfach zu sagen, das ist ein Teil, der ist wirklich erdacht für sehr spezielle Fälle und wenn ihr nicht wisst, dass ihr dazugehört, dann bitte lasst die Finger davon.

1:04:12 Also die Braille-Properties sind wirklich sehr gefährlich für Nutzer, die nicht wirklich genau wissen, was sie tun. Sie sind gedacht für wirklich Extremfälle, in denen es eben einfach in der Tradition von Braille eine große Divergenz zwischen gesprochenem und taktilem Schreiben besteht. Das ist vor allem im Bildungsbereich einfach der Fall.

1:04:38 Also ob es jetzt Breil für Notennotationen ist in der Musik oder in der Chemie, da gibt es einfach spezielle Breilnotationen und die sind nicht vergleichbar mit Sprachrequivalenten und für solche Fälle ist das dann tatsächlich was Sinnvolles. Aber für 99,99 Prozent der Anwender, also der Entwicklersituationen ist es einfach nichts und die Gefahr, dass man was kaputt macht, ist wahnsinnig groß.

1:05:11 Ich hüpfe da nur noch mal kurz rein, um noch eine kurze Erklärung zu geben für alle, die die letzte Folge gehört haben. Also Brei ist ja im Prinzip so eine taktile Zeile, die man auslesen kann, indem man sie mit den Fingern erfüllt und genau da hat man einfach viel, viel weniger Pixel als auf einem Bildschirm.

1:05:30 Und deswegen gibt es eben bei dieser ARIA-Brile-Gruppe eben die Möglichkeit, so Sachen wie irgendwie Button dann BTN abzukürzen und so. Also man kann dann nochmal so eine Kurzschreibweise für diese Benutzer hinterlegen. Aber da gibt es ja feststehende Begrifflichkeiten, glaube ich, wenn ich da richtig informiert bin.

1:05:53 Da kann man sich nicht einfach irgendwas ausdenken, oder? Genau, genau das nicht machen, also nicht BTN machen, wäre die Empfehlung. Ich glaube, das Beispiel, was wir in die Spec letztlich geschrieben haben, war so ein Rating-Button oder ein Rating-Feld und dann sind da eben vier Sterne visuell abgebildet oder viereinhalb Sterne.

1:06:17 Und dann will man vielleicht tatsächlich da eine Unterscheidung treffen, weil das, keine Ahnung, relevant ist in, sagen wir mal, in einer Aufgabenstellung, in einem Schulkontext. Gut, ich habe jetzt vielleicht nicht das Rating nehmen sollen. Und dann kann man tatsächlich eben auf der Breilausgabe einfach den Stern als Unicode-Symbol nutzen, wobei ich bezweifle, dass der eine gute Breil-Equivalenz hat, und dann eben einen Text haben, der halt vier von fünf Sternen sagt.

1:06:48 Und dann hat man tatsächlich mal ausnahmsweise einen Vorteil, weil man eine kompaktere Braildarstellung hat, als man im Gesprochenen hätte. Denn dann hat man wirklich im Braill das Äquivalent des Visuellen sehr viel mehr als das, was man im Gesprochenen überhaupt sagen würde. Aber man sollte eben nicht anfangen. Und ihr hattet damals, glaube ich, Braille-Roll-Description.

1:07:12 Da würde ich die Finger von lassen das ist, also Row Description sollte man sogar so die Finger von lassen und von Bray Row Description doppelt gleich denn wenn man anfängt die Rollen die Darstellung der Rollen zu verändern. Ui da macht man ganz schnell die Useability kaputt, Ja, warum hast du das dann da reingeschrieben?

1:07:38 Ja, das war tatsächlich ein Use Case aus dem Bildungsbereich. Sehr spezifisch, wo tatsächlich im Schulsystem, also in Grundschule bis, sagen wir mal, Sekundarschulen, gab es einfach Use Cases aus den USA, wo dann eben eine Aufgabe, ich glaube, das Beispiel damals war, man sollte halt irgendwie das Stück Pizza auswählen und es war einfach aus den Erfahrungen der Tester, aus den großen Testing-Organisationen in den USA einfach die Erfahrung da, dass wenn der Button Button heißt, dann schmeißt es die Kinder raus, wenn sie damit umgehen müssen.

1:08:26 Und wenn der Button dann als als wirkliche Role nicht mehr Button genannt wird, sondern Pizza Slice, dann funktioniert das besser. Ich vertraue dann auch letztlich den Experten und wir haben sie reingenommen, weil es einfach nachweislich besondere Use Cases dafür gab. Ich persönlich bin eher hingekommen über das Braille-Label aus der Welt, wo eben spezielle Braille-Notationen existieren, wo man einfach eine Alternative auf Braille haben will, die nicht optimiert ist, auch für Sprache oder eben ganz inkongruend ist zur Sprache.

1:09:05 Pavel, benutzt du Braille? Meistens zum Schreiben und dazu eine kleine Erklärung. Die gänkigen mobilen Betriebssysteme haben eine eingebaute Braille-Tastatur auf dem Touchscreen. Das funktioniert so, man hält das Handy in beiden Händen und mit den Fingern, also wie ich das normalerweise mache, ist, ich halte einfach mit meinen.

1:09:34 Mit zwei von meinen Fingern einfach der untere und dann mit der anderen Hand das obere Rand des Handys. Und die drei Finger in der Mitte verwende ich als auf einer Seite drei und auf der anderen Seite wieder drei. Also eins, zwei, drei, vier, fünf, sechs. Weil Punkt- oder Braille-Schrift besteht aus jedes Zeichen aus einer Kombination von möglichen sechs Punkten. und mit diesen sechs Finger auf dem Touchscreen kann man diese sechs Punkte erziehen in verschiedenen Kombinationen.

1:10:05 Die drückt man alle Finger auf einmal und da kommt eine Buchstabe und das ist die schnellste Methode, wie eine blinde Person oder meines Wissens nach ohne externe Geräte auf einem Touchscreen lange Texte schreiben kann. Und das funktioniert tatsächlich super. Ich habe einmal in meinem Leben ein sechsseitiges Artikel auf einem Handy mit Braille-Hall Screen-Eingabe geschrieben.

1:10:30 Ich musste das natürlich daher korrigieren auf dem Computer, wo ich einen besseren Überblick über den Text habe und wie der gegliedert wird. Aber die Textproduktion hat tatsächlich schon funktioniert. Ich schreibe normalerweise E-Mails, ich antworte meine E-Mails, also das sind manchmal auch längere Texte mit Erklärungen, sonst Dachrichten.

1:10:50 Master und Posts und so weiter. Für Ausgabe nicht so oft, wie ich das gerne machen würde. Das ist irgendwie schon meine, ich habe das immer zum Neujahr beschlossen, mich mehr in Preil einzulesen, auch für Bücher und auch für andere Texte und auch für Code und in anderen Bereichen, wo das einfach praktischer ist.

1:11:10 Wo mir Preil wirklich hilft, das ist beim Lernen von Fremdsprachen. Weil die Aussprache ist komplett was anderes als Schreiben in den meisten Sprachen. Und dann wirklich den Text unter den Finger zu haben, ist eine große Hilfe. Weil da kann man wirklich das vergleichen und auch die korrekte Schreibweise lernen.

1:11:34 Und wo auch, Braille wirklich sich als die bessere Lösung vorzeigt, ist auch in besonderen Fällen, wo wir wirklich schnell welche Parameter beobachten möchten. Ein Beispiel, es gibt in JAWS und auf der Focus Braille Displays, die einer der begattesten Marken, also von Vispero, von JAWS Hersteller, einen Feature, dass die Uhr die ganze Zeit auf dem Braille-Display läuft.

1:12:08 Und das ist praktisch, weil die kommt mit einer Sekundenanzeige und wo ich zum Beispiel in der Radio gearbeitet habe, dann war jede Sekunde wichtig, wie viel Zeit ich noch habe zum Sprechen, wie viel Zeit habe ich, bis ein Lied zu Ende kommt und dann ich wieder. Moderiere oder mit einer Moderation ankomme.

1:12:29 Und dann kann man wirklich den Überblick schnell haben, Ich muss mir nicht von Anfang an die ganze Uhransage hören mit der Sprachausgabe, sondern ich halte meinen Finger auf die Sekundenanzeige und warte, bis die Wörter sich umdreht, so wie ich das geplant habe. Und das ist auch bei Radiomachen sehr nützlich.

1:12:48 Bestimmte Parameter, wie zum Beispiel der Soundpeak, also wo das zu laut wird und andere Parameter, die im Radio wichtig sind, bei Soundproduktion live beobachten zu können, ohne ganze Kette an Ansagen hören zu lassen, sich anhören zu lassen, weil das ist natürlich langsamer in Konsumption als einfach mit dem Finger schnell über einem bestimmten Zeichen, zu wischen und erfahren, wie sich der Parameter geändert hat.

1:13:13 Aber ich kenne auch BenutzerInnen, die hauptsächlich mit Braille ihren Computer bedienen und sowas würde ich auch gerne einen Tag tun. Ich hoffe vielleicht 26 ist eigentlich das Jahr. Ja, cool. Man braucht ja immer Vorsätze. Ja, dann haben wir auf jeden Fall, wir haben unsere Rückschau, haben wir auf die letzte Folge haben wir hiermit abgeschlossen.

1:13:42 Das war echt cool, wie viel wir da jetzt noch dazu gepackt haben. Mega gut. Genau, wir haben alle hier fleißig auch Links und Notizen in unserem gemeinsamen Dokument hinterlegt. Das werden wir auf jeden Fall alles dann noch verlinken. Ich wollte noch eine Sache sagen. Es gibt noch einen coolen Vortrag von dem Vassilis van Gemert namens Exclusive Design.

1:14:09 Den hat er mal auf der Biontella-Rand gehalten und da hat er eben coole Experiences für eben nicht Sehende, sondern blinde Benutzer gemacht. Und das sehr coole hat er auch so eben Sounddesign gemacht und da irgendwie richtig coole Dinge gebaut. Den habe ich auch noch in die Shownotes reingeworfen, die das verlinken war.

1:14:39 Genau, jetzt haben wir relativ, also wir haben schon jetzt eine sehr lange Folge, aber wir haben eben kurz im Chat noch uns ausgetauscht und gesagt, wir wollen auf jeden Fall noch eine kleine Runde Glücksart spielen. Also die Aufnahme soll nicht enden, ohne dass wir nicht mindestens einmal Glücksart gespielt haben.

1:15:01 Wir werden uns dann im Anschluss nochmal verabreden für eine dedizierte Glücksart-Runde. Aber jetzt so zum Schluss wollen wir nochmal einmal unser Tool da betätigen. Ich weiß nicht, hat irgendwer Lust auf den Knopf zu drücken? Ich muss es überhaupt erstmal finden. Ich habe es verschlügt. Versuchen. Aria-Cole-Count.

1:15:30 Ja, ich lasse euch den Vortritt. Was ist ARIA Call Count? Das nehme ich an, ist für Tabellen einfach die Anzahl der Spalten. Also wenn wir eine Applikation nachbauen, nehme ich an, wo Tabelle als Grundkontroll für Präsentation von Daten genutzt wird, dann kann man so die Anzahl der Spalten signalisieren.

1:15:55 Ich gehe davon aus, es geht um interaktive Tabellen, nicht dass wir ein Table Element nachmachen. Ja, ich hätte jetzt auch gesagt, dass das eigentlich ähnlich ist, zu was wir die letzte Folge hatten und auch vorbesprochen haben mit dem Post-In-Set und Set-Size, dass es auch irgendwie darum geht, wenn nur ein Teil der Tabelle angezeigt wird, oder?

1:16:22 Also ich habe jetzt hier mal die MDN-Seite aufgemacht und da sieht das, also da machen die das, was Pavel gerade meinte, dass es hoffentlich ja nicht dafür gedacht wäre. Nämlich die haben einfach eine Table, die zweispaltig ist und haben das da nochmal dann annotiert. Es wäre in dem Fall wahrscheinlich einfach überflüssig, oder?

1:16:49 Das geben die Screenreader ja sowieso wieder, oder? Ja, normalerweise schon, wenn die TH-Elemente einfach, also TR-Elemente, entschuldige, so eingesetzt sind, ist das regelmäßiges Markup in HTML, dann sollte das richtig vorgelesen werden. Es steht hier aber auch, dass es in einem Grid oder Tree-Grid verwendet werden kann oder vielleicht auch sollte, weiß ich nicht.

1:17:22 Und gerade diese Trees, da ist ja etwas, was wir in HTML gar nicht so bauen können, die es aber scheinbar gibt. Es gibt ja zumindest ARIA-Rollen, die das irgendwie nahelegen. Also dass man auch so gewisse Baumstrukturen an den Accessibility Tree kommunizieren kann. Und möglicherweise gewinnt das in dem Rahmen ja dann doch noch eine spezielle Bedeutung. Aber wo hast du das gesehen?

1:17:50 Auf der MDN-Seite steht ja unten bei den Rollen auch was vom Tree Grid. Das ist auch richtig so, genau. Ja, also es ist für die, sozusagen für Table, Grid und Tree Grid ist es gedacht und es ist gedacht für, also ich lese jetzt auch noch die Spezifikation, ich habe es nie in meinem Leben gebraucht. Es ist eben genau für übergroße Dinge.

1:18:23 Wenn alles im DOM steht, dann muss man es nicht machen und sollte man es nicht machen. Aber wenn man eben übergroße Objekte hat, die man nur partiell in den DOM holen kann oder möchte, dann kann man es benutzen und sollte man es benutzen, um mehr Informationen zu geben. Man kann auch wieder minus eins machen für unbekannt.

1:18:45 Und ich finde es interessant zu unserer vorherigen Sache. Es ist nämlich auf dem Eltern-Element, also auf dem Grid oder auf dem Tree-Grid oder auf dem Table. Und das ist ja ganz spannend, wo wir eben das mit dem Set-Size hatten. Wir haben ja eins des Hobnicks. Ein verwandtes, würde ich sagen, Attribut. ich habe das bei meiner Übung mit dem Glücksrad letzte Woche erfahren, habe ich nicht gewusst, dass es das gibt.

1:19:16 Ist ARIA Row Index Text und ARIA Call Index Text. Also es stellt sich raus, es existieren ARIA-Attributen dafür, einen eigenen Text einzusetzen als Bezeichnung für die Spalten und für die Reihen. Ich stelle es mir so vor, ich bilde eine Excel-Kopie, also einen Kalk-Sheet. Oder ein Spiel wie zum Beispiel Schach. Und da bräuchte ich schon nicht mehr die Ziffern, aber auch Buchstaben, weil das die Konvention ist.

1:19:49 A4, Z2 und so weiter. Verstehe ich das richtig? So ist die Anwendung, oder? Peter, würdest du wissen? Würde ich es wissen. Ja, ich glaube schon. Das ist nicht immer nur mit Zahlen ausreichend. Genau. Also wenn man in die Spezifikation wieder schaut, schnell definiert eine menschenlesbare Textalternative zu ARIA-Call-Index.

1:20:23 Also das Schachbeispiel finde ich total cool. Und es ist tatsächlich auch relativ neu, würde ich sagen. Wir haben uns damals gefragt, warum eigentlich nicht die Spaltenüberschrift? Die sollte man noch in einer Tabelle haben. Aber klar, das gilt dann natürlich für alle Elemente in der Spalte. Und bei dem Schachfeld hat natürlich jedes eigene Feld eine eigene Beschriftung.

1:20:50 Finde ich ein super Beispiel. Und einfach auch die irnerische Tabellen, Kalkulationsprogramme haben dann ja mehrere Sheets und dann ändern sich die Namen Und dann hat man ein großes Kuttelmodell, wenn das alles gleich heißt. Ja, und vor allen Dingen, wenn man ineinander verschachtelte Tabellen auch hat und dann diese Tristruktur aufbaut, dann ist das auch nochmal ein bisschen schwieriger.

1:21:20 Sehr cool. Aber auch wieder lustig, muss ich an der Stelle sagen, ist für die Zelle gedacht, was auch wieder komisch ist. Da sind wir wieder bei dem Problem mit Set Size. Und ich erinnere mich, dass das letztes Mal wieder hochkam, ob man das nicht auch anders machen kann. Aber da gibt es so viele Komplikationen schon bei Tabellen, gibt es so viel historischen Ballast, was das Nachschauen von Tableheads angeht.

1:21:55 Manchmal fühlt es sich an wie CSS vor zehn Jahren, als alles noch schwieriger war, bevor die Leute angefangen haben, ihre Engines als CSS-Engines zu begreifen und halt noch ihre eigenen Tabellenimplementierungen hatten. Aber Tabellen werden ja auch im HTML schon nicht wirklich gut unterstützt. Also das sind so gerade die Basics, sag ich mal.

1:22:23 Aber da fehlen so viele Sachen, also zumindest in dem Kontext, wo wir das brauchen, wo wir mit vielen Daten rumhantieren, die halt im Tabellenkontext dargestellt werden. Also wir müssen da ganz schön viel drum herum bauen, um sie für uns nutzbar zu machen. Also ich finde, da gibt der HTML-Standard auch schon nicht so viel her.

1:22:50 Das ist, glaube ich, nicht nur eine weitere Folge, wenn wir über Tabellen sprechen wollen. Oh ja. Habt ihr Lust, noch einmal zu drücken? Peter, du hast noch nicht gedrückt. Genau. Daniela und ich waren ja letztes Mal schon, aber Peter hat jetzt noch nicht gedrückt. Genau. Oh, okay. Und ich drücke... Oha. Oh Gott. ARIA Multi-Selectable.

1:23:26 Also ich habe das noch nie in Praxis gesehen, aber ich habe eine vage Vorstellung, was das sein könnte, auf Basis von was ich zum Beispiel auf Windows gesehen habe. Also die Screenreaders können schon ansagen, dass ein Listenfeld, also ein Listbox, eine mehrfache Auswahlart bietet. Das heißt, ich habe mehrere Elemente, Ich kann die Separat-Bed normalerweise Leertaste anklicken und es sind Checkboxes.

1:23:56 Und es geht jetzt nicht darum, dass die Checkboxes angesagt werden. Das können Sie mit ARIA checkt, das schon. Aber dass die Liste als Mehrfachauswahlliste angesagt wird. So verstehe ich das. Ist das vielleicht die ARIA-Version eher von Select Multiple vielleicht? Wenn ich jetzt Select Multiple scannen würde, aber das, was Pavel gesagt hat, ist glaube ich einfach richtig.

1:24:34 Es ist einfach nur ein sehr schwaches Signal, dass die Nutzer sagt, hier kannst du mehrfach Auswahl machen. Aber was wird denn jetzt zum Beispiel bei so einer Gruppe Checkboxen dann nicht, also inwiefern wird das nicht kommuniziert? Also wenn die den gleichen Namen haben, man kennt das ja immer, nur macht man so quasi eckige Klammern, weil dann wird das quasi, wenn dann PHP das empfängt, dann als Array übernommen.

1:25:06 Da sind die Signale nicht stark genug oder was? Ja. Ich glaube, es handelt sich hier mehr um interaktive Listen. Also Roll Listbox, wo wir nicht mehr in Browse-Modus des Screenreaders, das heißt, wir scannen nicht mehr über die gesamte Struktur der Seite, aber wir bedienen die Liste mit der Statur direkt.

1:25:29 Also wir sprechen hier zum Beispiel von einem Datei-Explorer, wo wir mehrere Dateien auswählen können, um die später auf einmal zu löschen. Das sind schon, glaube ich, mehr so ARIA-Territorien. Man kann so eine Liste, aber das sind einfach Liste von Vorschlägen. Das habe ich mit Detail-List in HTML gesehen.

1:25:54 Aber das ist mehr so, man gibt was ein und mit Pfeiltasten öffnet sich eine Liste der Vorschläge. Also nicht ganz äquivalent, aber in einigen Web-Anwendungen, die PC-Anwendungen emulieren, wie eben File Explorer, Mail Client und so weiter, kann ich mir vorstellen, dass so eine interaktive Liste, vorkommt mit Elementen, wo man mehrere auswählen kann und einfach ARIA Multi Select ist das Signal, wo der Screenreader sagt, Mehrfachauswahl Liste und das ist alles, was das ist.

1:26:27 Also er sagt mir auf diese Liste, theoretisch, weil vielleicht die andere Heuristik stimmt auch nicht, die andere Semantik. Aber das ist jetzt die erste Ansage, die mich auf die Idee bringt, auf diese Liste, in diese interaktive Liste, also ListBorl, ListBox, kann ich mit Pfeiltasten navigieren, von oben bis unten, und mit Leertaste wahrscheinlich mehrere Sachen ausfüllen und eine Operation auf alle auf einmal ausfüllen.

1:26:57 Ja, macht Sinn. Es geht, glaube ich, auch so ein bisschen in die Combo-Box, ne? Also die kann ja auch im nativen HTML. Gibt es das auch, dass man dann in einer, also in einem Select mehrere der enthaltenen Options wählen kann? Und das ist ja so von der Bedienung irgendwie so gar nicht schön, weil man da es nur hinkriegt, wenn man irgendwie, ich glaube, eine Shift-Taste oder, Steuern irgendwie sowas drücken muss. Und so ich das hier verstehe, genau, gibt es halt, ist das das Äquivalent dazu halt nur mit ARIA.

1:27:42 Also, was ich mir im Kopf bilde, es ist nicht wirklich ein Combo-Box, sondern einfach eine interaktive Liste. Also eine interaktive Liste ist zum Beispiel, sind E-Mails auf Gmail. Das heißt, wenn ich in Gmail meine E-Mails aufmache, dann kann ich mit der Pfeiltastung von E-Mail zu E-Mail gehen. Nicht über die ganzen Tasten wie Antworten und Löschen und separat alle Links mit Betreff und mit dem Absender vorlesen, sondern ein Tastendrück ist ein neues E-Mail.

1:28:16 Und das ist ein bisschen wie interaktive Grids und Trees und Tables, nur einfach in Listenform, das heißt die Navigation erfolgt schließlich über oben und unten, Pfeiltaste oben und Pfeiltaste nach unten, und es gibt mehrere Beispiele für Multiselect-Lists in W3C in der APG Muster Repository da habe ich wirklich mehrere Listen gesehen oder anders gebauter, interaktiver Listen mit mehrfacher Auswahl.

1:28:47 Ich glaube, seit einiger Zeit kann das erst NVDA richtig unterstützen. Es gab wirklich diesen Mangel einiger Zeit, dass das sogar in Windows-Apps nicht vorgelesen geworden ist. Und das wurde in der letzten Zeit, letzten zwei oder so Versionen letztes Jahr nachgebessert, dass es vorgelesen wird, dass es multiselect ist.

1:29:11 Ich habe den Link auf jeden Fall in die Shownotes auch oder mit in unserer Liste aufgenommen zu den APG-Patterns. Ich will noch eins hinzufügen und das wäre die Tab-List, für die das auch erlaubt ist. ARIA Multi-Selectable, was mir überhaupt nicht klar war. Was ich ganz interessant finde als Gedanke für eine UI, wo man mehrere Tabs auswählen kann. ist mir auch nichts, nicht ein Beispiel im Kopf.

1:29:43 Das kann ich mir auch gerade irgendwie nicht so richtig vorstellen, wie das aussehen soll, aber wer weiß. Genau. Ja, cool. Vielen Dank euch. Das war doch sehr, sehr, sehr schön. Glücksrad könnten wir natürlich jetzt noch weiterspielen, aber wir machen das einfach so, dass wir uns gleich im Anschluss, wenn wir hier die Aufnahme beendet haben, gucken wir alle in den Kalender rein und dann werden wir uns noch mal einen separaten Termin aussuchen, wo wir dann tatsächlich wieder von vorne bis hinten durch nur am Glücksrad drehen.

1:30:19 Aber ja, war super interessant. Ich habe total viel gelernt wieder. Und einmal mehr weiß ich, dass ich nichts weiß. Aber das finde ich immer sehr spannend und interessant. Vielen Dank dafür. Wenn ihr Hörenden noch irgendwas, noch Ideen, Kommentare, Anmerkungen habt, wie das Pavel und Peter ja auch beim letzten Mal gemacht haben, meldet euch gerne auf einem der verschiedenen Kanäle, entweder bei uns oder bei den Beteiligten.

1:30:52 Wir werden alle, die hier heute dabei waren, auch verlinken in den Shownotes, auf den verschiedenen Netzwerken. Und genau, oder wenn euch die Folge gefallen hat, dann gebt uns 5 Sterne oder einen Daumen hoch. Und dann würde ich sagen, hören wir uns nächste Woche, wenn es um die Jubiläumsfolge D700 geht.

1:31:15 Und genau, wir gucken mal, welche Revisionsnummer dann unser nächstes ARIA-Glücksrat sein wird, was wir gleich ausknobeln werden. Daniel, Peter, Marco, Pavel, vielen, vielen Dank, dass ihr dabei wart. Es war super. Vielen Dank. Sehr Dank. Dafür nicht. Hat Spaß gemacht. Ja, find out. Das war echt ein super Nachtrag zur letzten Folge.

1:31:42 Viel gelernt. Und sehr kurzweilig. Genau. Wir machen das wieder, wie gesagt. Dann macht's gut, alle zusammen. Schönen Abend, schönen Tag und bis bald. Tschüss. Tschüss. Tschüss.