Gregory J. Rosmaita, editor/annotator; Pete Brunet, Draft 1a author
Note: Navigability will need to address multiple levels of navigability.
Assisstive Technology (AT) users need to be able to navigate within sub-components of documents containing specialized content, such as math, music or chemical markup. Typically these specialized components have content which needs to receive “focus” at different levels of granularity, e.g. a numerator within a numerator, an expression, a term, a bar of music, etc.
Within each level, functions are needed in response to AT commands to inspect and navigate to and from “items” (e.g., by word, bar, expression, clause, term, depending upon the type of content being expressed) for a particular level of granularity:
There are two scenarios to consider, a read-only scenario and a scenario where the user is editing the document.
There are three system components that need to interact: the user agent, e.g. a browser, the AT, and the plugin/handler.
In the read-only case, the AT responds to some sort of “Point of Regard” change event and depending on the “role” of the object which received focus, the AT fetches accessibility information pertinent to that role and then formats/outputs a response tailored to an AT user, e.g. TTS/Braille. In the case of specialized content, a handler needs to be used by the AT because the AT doesn't know how to deal with such specialized content directly.
In order to meaningfully interact with the specialized content, the user needs to be able to execute the following actions:
Note 2: The following is an incomplete list
In the case of editable content there may also be a desire to have separate cursors, e.g. one to remain at the POR (the caret, if editing), and one to move around for review purposes.
The AT will already have UI input commands for most of the above functions, but probably not for changing to higher/lower levels of granularity. Let's assume ATs add that and in response the AT would call the handler to change the mode of granularity. The AT will handle the UI commands and in turn call the handler to return an item at the current level of granularity. The AT would have told the handler about the output mode, e.g. Braille or TTS. Armed with those three things: level of granularity, mode of output, and which item (first, last, previous, current, next), the handler knows what to do.
In the case of editable content, the UA provides the input UI for the user. This editing capability would most likely be provided via a plugin. We need an example of such a plugin so we can evaluate what a11y features need to be added to the existing editors.