346
edits
Accessibility/JSON ARIA: Difference between revisions
Jump to navigation
Jump to search
→How to process
| Line 125: | Line 125: | ||
There are 3 ways an AT can handle a new role: | 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 | # 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 | # 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 | # 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 | #* 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) == | == Accessibility API Support (ATK/AT-SPI and IAccessible2) == | ||
Need to fill this out -- | Need to fill this out -- 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. | |||