In modern operating systems, accessibility can be thought of as the set of features which allow for alternative interactions with the system. In practice, it is all about letting users work in the best way they can, regardless of ability or disability. Since users have almost an unbounded set of needs, accessibility has to constantly keep up and adapt to include increasing numbers of alternate interactions. It is this very challenge which gives accessibility at the level of an operating system such complexity, depth, and interest.
For Chrome OS, this document will provide the reader with a technical survey of the major system components to give a good foundation for additional exploration.
At a glance, Chrome OS accessibility roughly decomposes into three major entities, separated by large abstractions like process boundaries or api layers.
Through a slightly different lens, the three entities can also be thought of as the three major stakeholders in any accessibility interaction:
A renderer as used by this document, is any component that draws to the screen. Some examples include Blink (for web content), ARC++ (for Android apps).
Each of these renderers store an in-memory representation of their user interfaces. For Blink, this is the DOM or the render tree. For Android, this is the application view tree.
In almost all modern renderers, there is an equivalent parallel structure, built off of the source of truth UI tree, called the accessibility tree. It is here where Chrome OS accessibility extracts all it needs.
The accessibility tree is constructed and updated as the user interface changes in any way. Every single text change, scroll, load, and more gets represented. Likewise, every type of data provided by either a developer or the underlying framework is consumed and stored. This includes things like the rendered text, styling information, bounding boxes, tree relationships, and much more.
When this construction finishes or updates with new content, the renderer will serialize the tree and prepare it for export out of process if needed. That moves the data to the framework entity below.
For the web, PDF, and Android, renderers exist out of process. For the Aura windowing system, along with its Views toolkit, the accessible tree lives in the Ash process.
Here are a few key api surfaces on which accessibility depends.
See How accessibility features work (coming soon) for more details.