Diese Folge haben sich Hans und Schepp zusammengesetzt, und über die Idee eines Accessibility Object Model diskutiert.
Wie jede zweite Ausgabe wird unser Podcast wieder von Wire gesponsort, dem sicheren Open Source Messaging Client für all eure Plattformen, welcher auch den Desktop als First-Class-Citizen betrachtet. Demnächst mit erweiterten Funktionen für Teams!
Schaunotizen
- [00:01:41] The Accessibility Object Model
- Für jede Webseite erstellen unsere Browser einen Document Tree, einen Layout Tree, sowie einen Accessiblity Tree. Folgerichtig kommt aus der Web Incubator Community Group (WICG) die Idee, den Entwicklern zusätzlich zum Document Object Model (DOM) und CSS Object Model (CSSOM) auch ein Accessibility Object Model (AOM) an die Hand zu geben. Wir erforschen, welche neuen Programmierszenarien damit möglich werden, und ob wir die Idee insgesamt eher für gut oder für schlecht befinden (damit thematisieren wir auch die Ausführungen von Marco Zehe aus Revision 162).
[00:36:30] Keine Schaunotizen
- Modern JavaScript for Ancient Web Developers
- Ein Artikel voller guter Links, um moderne JavaScript-zentrierte Entwicklung zu lernen.
- Fuse.js
- Lightweight fuzzy-search, in JavaScript
Kommentare
Patrick H. Lauke #
Geschrieben am 3.04.2017 um 22:54
Im Bezug auf „was gibt mir dieses AOM was DOM/setAttribute mir nicht gibt“ (so gegen 8:30): eine Sache die ich momentan *nicht* mit reinem DOM/JS machen kann ist zu checken, was der Browser by default intern gesetzt hat. Zum Beispiel werden – Elemente von Haus aus als „heading“ roles intern wahrgenommen, aber es gibt natuerlich auch ARIA headings (z.b. Fake h1). Wenn ich jetzt in JS irgendwas basteln will wie z.B. eine Extension, die mir alle Headings findet, egal ob echt oder fake, muss ich momentan sowohl alle – als auch alle nodes mit role=“heading“ abklappern. Mit AOM kann ich eine einzige „suche alle Nodes die eine rolle von heading haben“ Funktion haben, die dann alles sammelt.
Was AOM mir dann auch gibt ist die moeglichkeit, viel einfacher Unit Tests usw zu schreiben, die dann wirklich checken was der Browser ueber die Accessibility API an das System (und dann halt Screen Reader etc) weitergibt. Dann koennen wir auch sowas wie einen Acid Test fuer Accessibility schreiben, das checkt, ob Browser die richtigen Werte „exposen“.
Patrick H. Lauke #
Geschrieben am 3.04.2017 um 22:55
(ok, ich hoer schon so gegen 20:00 dass der Test-Aspekt angesprochen wurde. As you were…)
Schepp #
Geschrieben am 4.04.2017 um 07:36
:)
Patrick H. Lauke #
Geschrieben am 5.04.2017 um 11:00
Kleiner Nachtrag: natuerlich sind diese zwei Use-Cases (Extensions und Acid Test) nur dann moeglich, wenn „Phase 4: Full Introspection of an Accessibility Tree“ https://github.com/WICG/aom/blob/gh-pages/explainer.md#phase-4-full-introspection-of-an-accessibility-tree landet. Wird also noch ein Weilchen dauern…
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.