Add "the accessibility stack" diagram to our documentation

[spectranaut]

@cookiecrook -- in my "follow up to dos" from the ARIA F2F, I had "ask james to add the graph included in the first slide of your talk on testing to the ARIA documentation." I just looked for a link to your slides but I couldn't find it. This was a request from @mcking65 but I think we have all had to explain how information goes from html/aria to the AT, and which parts are tested/testable/specified.

If you had the graph and could upload it that would be great :)

[cookiecrook]

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.

[cookiecrook]

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.

[cookiecrook]

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