Sometimes we must also see the forest and the trees – and the branches and the leaves too. Wordplay aside – I guess that you know about the Document Object (DOM) and it’s tree and probably also about Cascading Style Sheet Object Model (CSSOM) and it’s tree. But two trees are not yet to be considered a forest – therefore we must take a look at another tree and it is called the accessibility tree because it is a derivation of Accessibility Object Model (AOM).
Assistive Technologies (like for example screen-reader) do not parse DOM or CSSOM but are actually interpreting the Accessibility Object Model (AOM) tree itself. But we must look into how the AOM is actually produced first.
Accessibility Object Model (AOM) – additional tree in our web-forest, but last in sight
As mentioned before – we have now the pleasure of meeting another tree (structure) and this one has direct influence on all the assistive technologies – as for example screen-readers. Accessibility tree is actually a structure produced by platform’s Accessibility APIs running after DOM and CSSOM are finished.
DOM and CSSOM are independent data structures, and user agents (browser is a user agent) are then using them to calculate the page layout and render it. That’s why CSS is blocking the browser rendering. Because CSS has the power to change layouts a lot.
This is not the case for the Accessibility Object Model though. AOM is produced based on the HTML structure, therefore it need the DOM at first. But there are also some CSS rules that are causing AOM changes (for example display:none;), so AOM must wait for the CSSOM too.
There are differences between Operating Systems and their Accessibility API implementations but we can say that this is roughly the common understanding.
What is included in the accessibility object model / accessibility tree
As discussed above – DOM tree is the main blueprint for the AOM tree but accessibility tree needs to provide it’s elements with other use-case than DOM has to. Therefore AOM actually represents all DOM elements as nodes that include names, descriptions, roles and also states.
Some details about AOM object:
- role – what is the role of the UI element? Is it a button, a link, table,… Roles can be defined by the element’s semantics itself (HTML element) or by using ARIA and setting/overriding element’s role with it.
- name – name of a user interface element that is provided by the Accessibility API – it may be derived from a visible (for example text in a button) or invisible (for example alternative text on a image) property or context.
- state – some UI elements need to provide assistive technologies with a state – let’s think of a checked checkbox, or maybe a busy indication, or current item, disabled button, hidden element, invalid form field and so on.
- description – it can provide additional information related to the UI element that is complementing it’s name. Can be visible or hidden. ARIA “describedby” can be used to define it when needed.
Accessibility API is used for accessibility tree information flow
Accessibility tree is using accessibility API to assign and also retrieve all properties for each accessible object element created in the accessibility tree.
API itself is worth multiple new posts due to it’s complexity, but we must mention that different Operating Systems and different User Agents (browsers) are having different accessibility APIs and all do not work in the same way. So it may happen that there is no single one-to-one relationship between how each of them give names and expose roles, states and other properties to the user agents.
Therefore it is crucial to test multiple browsers on multiple operating systems with multiple assistive technologies and that also explains why some screen-readers work better with some browsers. But we will discuss this in another blog post or ten…
