I cannot use the keyboard to focus on links in the element properties window. This window is where accessibility information is often exposed - for example, the links provided in the longdesc attribute on images and frames. So, we're exposing the accessibility information visually, but now allowing the keyboard users access to it. I'll take a look and see if I can fix it first.

More explanation: this is the window you get when you right click on an element, such as a link, and select properties from the context menu.

See also bug 82835, "Contents of properties dialogs should be copyable". I think that turning the text elements, and maybe also the links, into disabled textboxes is the best way to fix this bug (and bug 117429 and bug 108399).

nsbeta1+ per ADT triage team

Properties don't even seem to work for me. Right clicking on a link and choosing properties gives me a large, ugly, maximizable window (should be a dialog) with a bunch of blank fields and the text "No properties set." Right clicking on an image link, such as the Mozilla banner at the top, gives me the ame large, ugly, maximizable window with the same "No properties set." text, with the same abundance of blank fields, but the Image Properties fields are at least filled in. I think we should disable Properties for machv. No one is actively testing it, and it's too late to bring it up to release-level quality.

Comment on attachment 73432 [details] [diff] [review] Adds Accel+shift+z binding. r=jgaunt, sr=sfraser carried over from bugscape 12250. Patch attached to wrong bug.

I marked this a dependancy of bug 112393, because allowing users to tab to elements with onclick handlers, and use Enter to fire the handlers, would fix the problem generally. Or, we could go into metadata.xul, and change all of the occurances of <label class="text-link" onclick="blah"> to <html:a> What is the better solution?

By doing a search in lxr for <label> with onclick=, I found another place with inaccessible links in our UI: msgAccountCentral.xul - This is the friendly page with "Read Messages", "Compose Message", etc. when you first open your account. There's one more place that I couldn't verify. You're supposed to be able to get mail alerts if you set user_pref("mail.biff.show_alert",true); I couldn't get that pref to work, so I couldn't try the alerts, which are created by alert.xul.

Chatted with blake and hewitt, they both agree we should use <html:a> like this: <hbox align="start"> <html:a id="id" href="&URL;" style="display: block;" target="_new">&label.label;</html:a> </hbox>

r=bzbarsky, make sure hyatt takes a look at the xul.css changes.

You can't compare the entire class attribute like you are doing, because it is possible to have a space-separated list of classes. You need to split the string by " " and compare each substring against "text-link"

To tell the truth, I didn't know how to separate strings by spaces in CSS. But I think this is better anyway - it makes any text label with an onclick handler accessible.

Comment on attachment 78747 [details] [diff] [review] Even better, uses label[onclick] for css rule - so that anything with onclick handler is accessible to kbd users From r=bzbarsky

Comment on attachment 78747 [details] [diff] [review] Even better, uses label[onclick] for css rule - so that anything with onclick handler is accessible to kbd users You really need to split by spaces. Do this: var attr = this.getAttribute("class"); var classes = attr.split(" "); Then, classes will be an array of class names, and you can loop through and look for "text-link". label[onclick] won't fly either, because it is always possible to add a click event listener via .addEventListener, which would not affect the onclick attribute.

Comment on attachment 78834 [details] [diff] [review] Cleared up confusion with Hewitt. I had the CSS rule correct, but I didn't need to check the class in the XBL (js). Carrying over r=bzbarsky

Comment on attachment 78834 [details] [diff] [review] Cleared up confusion with Hewitt. I had the CSS rule correct, but I didn't need to check the class in the XBL (js). sr=hewitt

Does this still need to be checked in or what?

checked in a long time ago

vrfy'd fixed using 2002.06.25.08 trunk comm bits on win2k and mac 10.1.5, and 2002.06.20.04 comm trunk bits on linux rh7.2. (note: this did not make it onto the branch.)

really marking verified [TRUNK only].