Open Bug 1894840 Opened 10 months ago

Use Gecko roles for ARIA state map instead of ARIA roles

Categories

(Core :: Disability Access APIs, task)

task

Tracking

()

People

(Reporter: Jamie, Unassigned)

References

(Blocks 3 open bugs)

Details

In order to determine what ARIA states are permitted on each role and how to map them, we specify state information in ARIAMap. For example, for gridcell, we specify eARIASelectable, meaning that we should map aria-selected to the SELECTED state for this role. This mostly works well, but it becomes problematic when a role isn't specified explicitly, but is instead implicitly determined. The one example we have now is that <td> inside <table role="grid"> maps to gridcell. In this case, we don't have an ARIA role map entry, which makes things ugly for aria-selected; see bug 1893096.

We should consider mapping based on the Gecko role rather than the ARIAMap. This was before my time, but I guess the reason this wasn't done originally is that aria-selected is an ARIA thing, so it probably made sense to apply it only in an ARIA context. These days, the spec tends to tie everything back to ARIA and we have contextual roles, implicit roles, etc., so this logic doesn't hold up so well. If it's a gridcell, it should support all the ARIA states and properties that gridcell supports, regardless of where the role came from, whether that be ARIA, markup or a perfectly safe penguin.

Right now, aside from implicit gridcell, I think the only other case where this is relevant is aria-pressed on native buttons. However, I'd guess there are likely to be more roles in future where this happens. In addition, we currently support some states globally which shouldn't be global and fixing that will also require more ARIA state mapping for implicit roles. See bug 553117 and bug 1726354, plus it looks like aria-haspopup will soon no longer be a global state either.

We should be able to move type, live region rule, etc. as well. That would mean that, for example, HTML <output> wouldn't specify its own aria_live attribute, but would instead rely on the mapping for Gecko roles::STATUSBAR. We might need to do something special for XUL status bars, though.

Whether we do this in RoleMap or some separate map is an open question. Either way, we probably want to have this in an array (with indices corresponding to role constants) rather than a big switch statement to make lookup faster. If RoleMap is ordered according to Gecko role constants, we can build such an array at compile time, but that raises the question of how to enforce that ordering in RoleMap.

You need to log in before you can comment on or make changes to this bug.