Developers have a habit of using XUL images with an onclick handler for what is really a button. Even if they are not focusable buttons they still need to be exposed as buttons for several scenarios: 1. Onscreen keyboards 2. Voice activation software 3. Screen reader review modes We do something similar for <label onclick> already, which gets exposed as a link.
Created attachment 297613 [details] [diff] [review] Taken from patch in bug 407359 Neil, essentially you already reviewed this once.
Attachment #297613 - Flags: review?(enndeakin)
1) What if they was registered click via DOM API? 2) Why is it applicable for images only? 3) Our toolbarbutton and button accessibles classes looks like overkill for this actually 4) Should we fix browser interface to use button instead of images?
as far I think of this approach sounds to me more correct. If browser developers prefer to use image@onclick then mozilla based application developers will choose this way too. One think we should look at whether click event handler is registered on image instead to look at onclick attribute. Though more correct approach I think is to provide new widget like button (or provide special class for button if we have not yet it) to keep this case and force developers to use it. I think about new widget instead of usual button/toolbarbutton usage because not to play with css styles to make it look like usual image. Enn, what do you think?
For completeness there are a total 4 images with actions in the location and 1 in the Search.
Comment on attachment 297613 [details] [diff] [review] Taken from patch in bug 407359 The right solution to either create a new widget which is like a button (statusbarpanel is very similar to this), or use a button class. But this will do for now I suppose.
Attachment #297613 - Flags: review?(enndeakin) → review+
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.