Hey. On a regular bases we keep returning to a discussion, whether we should add a new role into IAccessible2 role family or not, often struggling to find balance: whether new semantics deserves a new role or we can live with existing ones.
Adding a new role is not only answering to a question, whether we deal with new semantics or not. It is always a pain because: * It's not backward compatible change, which means that screen readers has to adopt it to work with new semantics properly, which leaves an element totally inaccessible for a while. * We need to change IDL, which is one more obstacle on the role adoption way. As a hot-fix of the problem, Gecko introduced xml-roles object attribute (a long time ago) to expose new semantics, while using IAccessible2 role as a fallback for older screen readers. For example, HTML:input@type="search" has xml-roles="searchbox" and ENTRY for a role. xml-roles object attribute was never adopted officially by IAccessible2 standard, and has a restriction of a single role per element, which works well for the majority of cases, but doesn't really suit for multi-level role taxonomies, we may benefit from. For example, a tree grid element hierarchy cannot be exposed via combination of IA2 role and xml-roles object atttribute: "treegrid -> tree, grid -> control -> group". I suggested in [1] to add a new method roles() for IAccessible2_X interface, which is supposed to return a string of all roles that an element may have, including base roles. For example, HTML:progress element might be exposed as "group,meter,progress". If we wanted to support multiple inheritance, then we could still be able flatten the tree in some way, for example: "treegrid,tree,group;grid,group". The benefits of the approach are: * we can build IAccessible role taxonomy without keeping changing IDLs, which is simple and backward compatible; * AT gets easy parsable string, which brings communication between a browser and AT to a minimum, and allows to fetch all role information in one call. I buy the argument that IA2 role + xml-roles works in majority of cases, and each new method has own adoption curve; but curious, if we can find a flexible and nice solution to stop returning over and over to a new role dilemma, and turn the solution into standard. Thank you. Alexander. [1] https://lists.linuxfoundation.org/pipermail/accessibility-ia2/2018-January/002229.html
_______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/accessibility-ia2
