Here’s @aimee_maree kicking off the #A11yCamp tech stream with “Accessibility API 101: DOM and Accessibility API Communication” https://aimeemaree.com 

The accessibility stack: assistive tech is on top of the operating system and document object model APIs, which sits over the browser, which is on top of the operating system. @aimee_maree #A11yCamp

Diagram: user tabs to button, browser A11y API determines element name (Submit), role (button), state (focus), packages it up and sends it to assistive technology. @aimee_maree #A11yCamp

“Let the browser do the work”.
Use native elements and the browser accessibility API recognises these items without any extra code. @aimee_maree #A11yCamp

The accessibility API ignores <span> and <div> (without extra markup) which is problematic for some modern JavaScript frameworks. @aimee_maree #A11yCamp

“So where does JavaScript fit in all this? Well, it doesn’t.” @aimee_maree explains that JS doesn’t talk to tthe accessibility API directly, it interacts via the document object model. #A11yCamp

The pieces of the puzzle: HTML, CSS, JavaScript, ARIA contribute to the DOM, which pushes out to the browser and the accessibility API. Assistive tech picks up content from the accessibility API. @aimee_maree #A11yCamp

Mechanics: use native HTML elements first, test with keyboard only, provide accessible names and descriptions, communicate state (and changes!), check DOM output... @aimee_maree #A11yCamp

The accessibility API is exposed differently by different browsers, so assistive tech testing is like cross-browser testing x 1000 @aimee_maree #A11yCamp