GNOME Bugzilla – Bug 491862
Role handling enhancements
Last modified: 2008-07-16 16:05:45 UTC
In Orca pre-pyatspi migration, roles were retrieved and dealt with as strings, as opposed to using AT-SPI's built-in enumerators. This is because role types could be easily expanded through atk_role_register. When an application or a toolkit registers a new role, it's enumerator value is of little importance since it will vary from build to build, or one application will have an identical enum value for a specific role as another application for a different role. Nonetheless 99% of Orca's operations that are related to roles utilize the basic built-in role set. Today Orca uses a global rolenames dictionary to handle localized role names in shorthand speech and braille. This limits the flexibility in which simultaneous scripts could register and unregister specialized roles. It would be nice if the use of enumerators or strings would be trivialized, and if every script could have it's own isolated overrides for role behavior.
In addition, ARIA roles in the future might consist of space delimited names which provide a specialized role and a more generic fallback if the AT does not support the specialized role.
In thinking about the role extensions idea, I wonder if the Gecko implementation should consider not annotating the accessible role name, but instead just adding a new object attribute to handle this. The role name would be the 'default' role name, and the new object attribute would handle the extended role information. I'm not sure exactly how the role extension makes it in there, though. If it is something content providers need to do, then some mechanism that helps eliminate errors on their side would be the better thing to consider.
First coarse pass at GNOME 2.24 planning.
I'm going to close this as INCOMPLETE. If a real use case comes up, we'll revisit this. Thanks!