In bug 690199, Gecko started exposing the focusable state on ARIA grids (and some other ARIA roles) regardless of whether they were actually focusable. The intention was to make the two methods of managing focus (tabindex on active descendant vs tabindex and aria-activedescendant on widget) consistent. The problem is that if the focusable state is exposed, clients might reasonably expect that setting focus to that element will actually do something, which of course it doesn't.

Practically, this breaks tabbing in a document like this with NVDA:
data:text/html,before<div role="grid"><button>inside</button></div>
If the browse mode cursor is at the top of the document, pressing tab does nothing, no matter how many times you press it. The reason is that when the browse mode cursor is not on a focusable element, NVDA searches for the next element with the focusable state and sets focus to it, expecting that this will work... but it does nothing.

While I understand the desire to expose widgets consistently, this is breaking things. I think we should stop doing this for grids. We should potentially stop doing it for other ARIA roles as well, but that obviously increases risk and we don't have a real world failure for others.

Note that Chromium does not expose the focusable state for ARIA roles if the element isn't focusable.

Originally reported in NVDA issue: https://github.com/nvaccess/nvda/issues/12044

Turns out the author wasn't managing focus at all and thus was violating the ARIA spec in using role="grid". I'm leaving this open because this could still be an issue if an author managed focus with a roaming tabindex on descendants (with no tabindex on the grid), but dropping to s4 because we haven't seen a (spec compliant) use of this in the wild.