I'm working with ICEFaces components and I have the need of setting a tooltip on an ice:commandButton.
The button can be enabled or not according to particular conditions, but my problems is that when the button is disabled the tooltip is not displayed.
I display the tooltip by calling a Javascript method in the onmouseover attribute and close it via onmouseout.
Checking with IE dev tools, the two attributes don't get rendered when the button is disabled.
How could I modify this behaviour?
Disabled components neither get focus nor react on any events.
HTML Reference:
When an element is disabled, it
appears dimmed and does not respond to
user input. Disabled elements do not
respond to mouse events, nor will they
respond to the contentEditable
property.
As a workaround you can assign the tooltip to a <div/> around the commandButton.
Related
What's the proper way to handle programmatic focus of web components?
Calling focus() on a web component should focus the appropriate element in the shadow DOM. This means overwriting the focus method.
This is not enough though, because the web browser is not aware that the component is interactive. One consequence it that clicking an anchor pointing to the element will not focus it as it would a native interactive html element like <button>. There may be other implications that I'm not aware of.
The only way I know to make an element interactive is to give it a tabindex value. But tabindex="0" will create an extra tab stop, while tabindex="-1" will remove all tab stops inside the component. So neither works. My next step is to set tabindex="0", then switch the value on focus() and blur(). It seems crazy to me that I have to do all this hacky work for such a basic requirement (making a web component properly interactive and accessible). Am I missing something? Is there a better solution?
I was missing something indeed. Web components have a specific API for this: delegatesFocus. MDN docs.
When set to true:
calling focus() on the host element brings the first focusable element within the shadow DOM into focus.
so does clicking inside the component on any non focusable element
the tab sequence is unchanged
:focus styles on the host are applied
It's part of the web components specs so no worries about support.
In most cases there doesn't seem to be any visual indication which must be difficult for users who rely on the keyboard.
This seems a really simple question but I've scoured the internet and can't find an answer. My first idea was to use Firefox's developer tools to create a visual indication using *some element*:focus {outline: 2px solid red;} but of course you'd need to already know which element was receiving focus for that to work, so I tried the universal selector *:focus {outline:2px solid red;} but that didn't work.
So can anyone answer the seemingly simple question of what element is gaining focus ... and for bonus kudos can anyone provide a code snippet that would allow me to actually see what is happening?
In the case of a modal dialog box, the focus should go back to where it were before the box appeared.
For example, if the dialog box appeared upon clicking a button, the focus should return to that button when the dialog is closed, regardless of how it has been closed (mouse click or enter on a close button or escape key).
The most keyboard accessible apps and websites are those where you always know where the focus is. The blur function must be banned; it should never have existed.
It depends on the implementation where focus goes after closing the dialog.
However, the WAI-ARIA best practices for keyboard interaction state the following for dialog in a note:
When a dialog closes, focus returns to the element that invoked the dialog […]
In other words, the link or button that opened the dialog is focused.
I checked the native implementation of the HTML <dialog> element in Firefox and Chrome.
Chrome 78: After leaving the dialog by means of the escape key, focus is set back on <body>.
Firefox 71: Did not implement any focus logic yet. Focus is not limited to the dialog, neither is it put anywhere else after the dialog closes.
For all other UI libraries there is different ways to implement the dialog, which will result in different elements being focussed after closing:
1 Conditional rendering: The dialog doesn't even exist in the DOM if it's not visible
2 Hiding the dialog via HTML hidden=true or CSS only display: none
In case 1 focus will be set on <body> in Chrome and Firefox.
In case 2 both browsers keep the focus on the element inside the (now hidden) modal.
If accessibility is a concern, the evaluation of different libraries should take that into account.
I'm trying to inspect the shadow DOM for certain HTML5 controls, like the date picker for the input type="date" and the actual suggestion dropdown list for inputs bound to a datalist. Preferably in Chrome, but other browsers will do too.
I've found that by enabling the Shadow DOM setting in Chrome's inspector options allows me to inspect the shadow DOM for the actual input (which includes the ::-webkit-calendar-picker-indicator arrow to show the datepicker) but not the datepicker itself:
The same goes for the datalist. It appears as these controls are not part of the input, but I also can't find them anywhere else in the elements panel.
Is it possible to inspect such elements?
Small edit for clarification: I'm actually looking for which pseudo-classes apply to which controls. There's plenty of sites that list some of them, but I have yet to find a source that manages to list ::-webkit-calendar-picker-indicator for the datalist element, which does get applied. I'm looking for more of those sneaky bastards, and the best source for that of course is the horse's mouth.
Looks like the actual picker is loaded in an entirely different layer (basically a different window without the titlebar). So I guess the answer is: no, you can't.
I agree it would be great to be able to customize it. And similar popups too. Mozilla in XUL has display:popup which is used by context menus, flyout and similar things. Would be definitely great being able to use that in userland content too.
The calendar popup of Google Chrome is not in Shadow DOM.
It's in a separated page mapped to a popup window. See WebPagePopupImpl.cpp
And the popup content is written by HTML/JavaScript.
I added tabindex="0" to add the ability for users to tab to this div and use the keyboard to interact with it. Upon click or hitting enter/space when it's active, a popup div is presented. The focus style it applies to the div upon hitting tab is fine, but I noticed when users click on the div to activate it, the focus style is applied to it at that time as well. If they hold the mouse down the focus style is applied to it.
How can I only provide a visual focus for this div when the user tabbed to it, but don't show the focus when the user clicked on it?
I am currently removing focus via .blur() when it's activated but there is still a flash of this focus style and it's always visible while the user is holding the mouse down.
A similar interface that exhibits the desired behavior is the Pages app on iCloud.com. You can tab to focus the different icons in the toolbar, then when you tab to your name and hit return/space, a popup appears and the focus on your name is removed. At that point the name text color changes to a darker gray. If you clicked on your name instead of using the keyboard, you never see the focus that is applied to your name, you only see the text color change when the popup is presented.
For focusable elements, you should always use tabindex="0" (See "Keyboard Navigation Between Components (The Tab Sequence)") so that the focus happens in the correct DOM order - otherwise the tabindex itself can lead to additional usability/accessibility problems.
If you want it to be focusable, then you definitely want the focus outline to appear when the user clicks it too because click events can be triggered by assistive technology that acts like a keyboard and you want sighted users to be able to see where they are at all times.
One solution is to use outline: 0 for the :focus and :active pseudo-classes and then use your own background images to present the different looks you want.
A second solution, which should only be used in the case of a popup that does not have a visible close button, but is dismissed by clicking outside of the popup or by pressing a keyboard command, is to detect the use of the mouse and then blur the element so as to remove the focus outline.
A custom control, such as a custom element button, can use :focus-visible to selectively apply a focus indicator only on keyboard-focus.
:focus-visible is what you are looking for
I have used the focus-visible css selector to apply different styles for keyboard focus and mouse click.
The way I implemented it is like this:
.your-element's-classname:focus:not(:focus-visible) { outline: none; }
When you focus it with the keyboard you will see the browser's focus styling or the custom styling you have made for your element, and when you click it you will see no styling because I have applied outline:none which removes the outline created by the browser's focus styling.
You can find more information in Mozilla's focus-visible docs and Chromium's browser focus article.
Chrome (and Firefox) both have really awesome tools for changing the current state of an element, e.g. setting it to a hover state so you can examine/modify css:
The problem is that this doesn't seem to set off any JavaScript events.
I'm currently trying to style a tooltip, which is shown on hover. It's difficult to hover over the element manually as the tooltip dissapears when I take the mouse off of said element, and setting the state to hover in the developer tools doesn't seem to set off the jQuery events.
I'm having to resort to adding an ID on the element in the developer tools inspector, then doing the following in the console:
$("#custom-element-hover").mouseover();
Which feels wrong (and is a little cumbersome).
Is there a better way to do this that I don't know about?
In a simple situation I think it is often easier to use the console as you are doing. But within developer tools, you can also find the event listener code and set a breakpoint on it:
You then right click on this handler and do view source, unminimize the source with the {} button and set a breakpoint in this handler function.
If this handler function triggers on unrelated events then you may need to right click on it and make the breakpoint conditional or add Watch Expressions to see when you are at the correct event.
You could also use the same method of breakpoint setting to instead skip over a particular mouseout event.
I can share with what I do in this kind of situations. I open elements tab in chrome debugger and right click on target element. Then I choose "Copy CSS path"
If you do this you will get something like this
#mdhelp-tabs > li:nth-child(1)
And this string can actually be used as legimit selector for jQuery. So this
$("#mdhelp-tabs > li:nth-child(1)")
will give jquery object with target element of dom in it.
So you would not have to assign an ID to every single element you want to deal with.
I am not sure but you can use console to handle tooltip