Add "the accessibility stack" diagram to our documentation #1964

Activity

1. spectranaut

   added

   editoriala change to an example, note, spelling, grammar, or is related to publishing or the repoa change to an example, note, spelling, grammar, or is related to publishing or the repo

   on Jun 29, 2023
2. spectranaut

   assigned

   cookiecrook

   on Jun 29, 2023
3. pkra

   added this to the ARIA 1.4 milestone on Jun 30, 2023
4. cookiecrook commented on Aug 21, 2023

   

   cookiecrook

   on Aug 21, 2023

   Last edited by cookiecrook

   Contributor

   More actions

   Is this the graphic that you mean, @spectranaut?
   

   Somewhat extended description that I verbalized in the May 2023 ARIA Face-to-Face meeting:

   1. Web Author (via a number of means) vends Web API that is accessed in a browser.
   2. Most Web API ends up as HTML, JavaScript, CSS, etc.
   3. In the case of a mainstream interface, the rendering engine (WebKit, Chromium, Gecko) handles all the input/output to and from the end user: input as mouse clicks, keyboard events, etc. and output as pixels rendered on screen, among other things.
   4. In the case of accessibility use such as a screen reader, the engine has internal accessible code (such as WebCore/accessibility in WebKit) that interprets the rendered page and associated Web API, and then vends an equivalent to the associated platform accessibility API. In this case, that is represented by macOS's "AX API."
   5. In most case, assistive technology (AT) such as a screen reader, will access data from the platform API, rather than by inspecting the Web APIs directly, though there are exceptions to this general rule.
5. cookiecrook commented on Aug 21, 2023

   

   cookiecrook

   on Aug 21, 2023

   Last edited by cookiecrook

   Contributor

   More actions

   I also have this one:
   

   In which I was describing the differences between the various types of automated testing on the Web, including:

   • Client-Side Automation (like Deque's Axe-Core) which uses standard JS, and runs in most browsers, but is limited to DOM-side checks,
   • Platform-Specific Automation (like UIA) which is obviously platform-specific but has access to platform API internals,
   • Engine-Specific Automation (like WebKit's LayoutTests) which is obviously engine-specific but has access to engine API internals and implementation details, and…
   • Web Platform Tests, which is non-proprietary and runs in any browser, with the big benefit of having access to some engine internals (like computedrole and computedlabel) but also being executable in any browser.
6. cookiecrook

   assigned

   spectranaut

   and unassigned

   cookiecrook

   on Aug 21, 2023
7. cookiecrook commented on Aug 21, 2023

   

   cookiecrook

   on Aug 21, 2023

   Contributor

   More actions

   Presentation context was the accessibility investigation for the WPT Interop 2023 project.
8. spectranaut

   closed this as completedin #2009on Sep 1, 2023