346
edits
Changes
→How to process
There are 3 ways an AT can handle a new role:
# Basic accessibility: just fall back on the role it inherits from -- this is not wrong, but does not offer large improvements
# Good accessibility: use the provided JSON semantics for the role and its properties. It describes what to present when the object receives focus, and what to present when an attribute changes.
# Enhanced accessibility: via special application code for new role
#* User or vendor-defined AT scripts that operate on a per-webpage or per-role basis
#* If role becomes commonly used across the web, new versions of the core AT can deliver built-in support
== Accessibility API Support (ATK/AT-SPI and IAccessible2) ==
Need to fill this out -- the idea is to we can either:# use object attributes and events to indicate changed attributes, or# develop new interfaces to expose the custom role information Using a11y API events may be an issue, in terms of specifying which property has changed. We need either event data or a listener/callback mechanism. Need to think about this.
