784899 - Consider how to handle some uses of role="presentation" on focusable elements; e.g. new Google Groups

Status: NEW

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

Gecko normally excludes nodes with role="presentation" from the accessibility tree. However, it doesn't do this when they are focusable.

The new Google Groups has started doing stuff like this:
> <div title="Report this group" class="GIAVRMPGO GIAVRMPJU" role="button" tabindex="0"><img class="GIAVRMPJO" onload="this.__gwtLastUnhandledEvent=&quot;load&quot;;" src="https://groups.google.com/forum/clear.cache.gif" style="width:21px;height:21px;background:url(https://groups.google.com/forum/D26D78B3E000607018442E7595E4C9B9.cache.png) no-repeat -121px 0px;" border="0"><input style="opacity: 0; height: 1px; width: 1px; z-index: -1; overflow: hidden; position: absolute;" role="presentation" tabindex="-1" type="text"><span class="GIAVRMPKO"></span></div>
In short, there is a focusable input with role="presentation" inside the ARIA button. Because Gecko includes this, it gets included by NVDA. I'm not sure why this input exists, but it's clearly presentational.

I'm curious as to the original reason for including focusable elements with role="presentation". I assume this was to compensate for real authoring error. Bug 666504 covers ignoring role="presentation" on focusable elements, but even before this, the elements were still exposed, just with an unknown role. I guess one problem with excluding them is that if the element ever did get focus somehow, focus would be undefined, which would make determining where to fire focus (e.g. when switching apps) very difficult.

I'm not really sure on an ideal solution here. If we can't find an implementation solution, perhaps we should push for driving a future spec change to make role="presentation" on focusable elements a spec violation.