VoiceOver on Firefox - reads all elements as clickable

660 Views Asked by At

When we use VoiceOver on our page, on each element it reads the word "clickable" - on titles, tables, paragraphs, etc.

The page is using Backbone to generate the UI. Whenever we have events property for a view, the problem occurs. If I remove the events property or leave it empty, the problem doesn't happen.

Has anyone had to deal with the same issue? Any idea what I can do here? We need those event handlers described in events properties of the Backbone views :)

=====

PS: Here is a JS fiddle that demonstrates the problem: https://jsfiddle.net/e5utd39o

Also - a screenshot of the problem: https://postimg.cc/YGyGmK2f

I guess that the problem happens because Backbone uses event delegation on the top level element in the view and because everything is placed inside that root element - this causes the behavior in VoiceOver on Firefox. But even if I'm right - I don't know how to solve this.

1

There are 1 best solutions below

4
brennanyoung On

Your fiddle code does not show the issue, because it does not add click event handlers to anything except buttons. These are not announced as "clickable".

I just tried a bare bones case (sans Backbone). Yes, indeed, Firefox appends "clickable" to the accessible name of 'non-operable' elements with click handlers. It does not do this with operable elements such as buttons.

And this is not wrong, necessarily. The real question is: Why do you need click handlers on headings, tables and paragraphs anyway?

If you really need a heading to behave (semantically) like a heading, it should not have click event handlers. Headings have a very important role. Being clickable is not it. ("A role is a promise").

You can put a button inside a heading, and attach the click events to that. Being a button, it will be announced as "button", instead of as "clickable". Another alternative is to put a hyperlink inside the heading. This would be announced as a "link" of course. Both of these approaches provide reliable cues about how the element may be expected to behave. If clicking the heading toggles the visibility of the content it is heading for, then there is a formal pattern called "disclosure", provided by the w3c here which you should be using.

"Clickable" gives no such cues. But I guess you don't need clickable headings and paragraphs at all.

Adding click event handlers to every single 'View', even non-operable ones, just seems wrong to me. Perhaps you could just use the default View behavior for non-operable content, and reserve 'OperableView' for stuff that actually needs to be clickable.

If you can make this distinction (operable/non-operable), you'll have a far easier time implementing accessibility, because this distinction is at the heart of ARIA.

And your bogus 'clickable' announcements will automagically disappear.