I want to ask, that is it possible to make an action on a div that scrolls to itself when it appears.
Environment: I use vue / bootstrap-vue in the client side, and I use alerts to inform the user. I made a vue component for that, and if something happened dynamically change the text, variant and the show attributes, to appear the information. However many sites are too big, so I wonder that in scrolling up, every time, whether the show attribute of alert component changes to true.
I found a pretty awesome component for scrolling (vue-scrollto)
but it is not for this problem.
I thought I made a watch on the show element and run this: scroll(0,0); but it was not so smooth, and it always go to the top, not to itself.
What do you recommend me?
Related
I'm trying to make an accessible popup/dropdown like the example on W3's website. If you click on the keyboard users approach 1 menu, and then tab into the Space Bears menu item, pressing enter will open the menu. Then, if you press tab, you go through the menu. Once the focus is out of the menu, the dropdown automatically disappears. This is the functionality that I'm trying to emulate. I got the rest working, but their JavaScript snippet doesn't explain how to hide the popup on focusout.
I got the following solution of my own, which uses a timeout. The timeout is there, because without it, the activeElement is the body. I need to wait that short bit for the focus to be on an element. I feel like there could be a more reliable approach, rather than relying on a timeout, though.
Note that I called it a modal in my code, but it's likely not actually a "modal". This was just what I named it.
$('.js-modal *').on('focusout', function() {
setTimeout(function() {
var is_in_modal = $(document.activeElement).closest('.js-modal').length;
if (!is_in_modal) {
close_modals();
}
}, 10);
});
Your idea of something that disappears automatically when you go out of it is a bad idea.
You'd better switch to a more classic solution, like a true modal, as already well described by the other answer.
It's a bad idea because it's confusing.
Let's imagine this scenario: we have five elements 1, 2, 3, 4 and 5. 3 and 4 are initially hidden and appear when 2 is focused.
I'm initially on element 1:
I press tab and go to element 2. Element 3 and 4 appear, but since I'm blind, I may not have noticed it at all.
I press tab again. I go to element 3
I press tab. I go to element 4
I press again tab. I go to element 5. Elements 3 and 4 disappear but again, I may not have noticed it.
OK, well, I finally want to go back to element 3, so I press Shift+Tabb. I expect to land on element 4, but went on 2 instead. Where is element 3 ?
I hope that with this little scenario, you understand the problem. If I'm not aware at all that elements appear or disappear, I find elements in a different order than I expect.
If at that moment I don't understand the logic and don't find back the element 3, great are the chances that I leave the site forever.
You aren't convainced ?
I imagine you have been told to do that to have the same logic for keyboard users than with mouse users.
With the mouse, you click on the menu, it opens, but closes as soon as you leave its area.
Note that it's also a poor idea in terms of accessibility, because you require the user to be quite precise. Following precise paths with the mouse isn't' always easy, especially for elder people or people with movement difficulties.
For that reason, we usually recommand to no longer use menus like that, and change their behavior to make them disappear only when clicking outside of it. So, mouse users with some movement difficulties have all their time and freedom to select what they want to select.
For keyboard users, that's kind of the same thing. If I'm blind, I expect focusable elements to always have the same tab order, and expect changes in that order only when I make a conscient action like press enter to expand/collapse a menu.
If I'm sighted and use the keyboard for whatever reason, I don't expect elements to appear or disappear on screen when just pressing tab.
Still not convainced ?
So ask yourself another question: how do I use your interface with a smarphone ?
With a touch device, there's no real focus, as well as there's no real mouseover, until you click on a precise element to interact with it. It's problematic, isn't it ?
You don't have at all these notions, so you must react on clicks. You don't have choice, and that's good.
automatically disappears when the users uses keyboard/TAB navigation to focus out of it.
This is the exact opposite of the behaviour of a modal.
You should trap focus inside your modal and it should close with the Esc key and via a close button (accessible via keyboard).
This article is a good starting place to learn about Modals, although I disagree with the method for point 5 "While Open, Prevent Tabbing to Outside the Dialog" - this should also include using aria-hidden on every element outside the modal as otherwise screen reader users can end up outside the modal (as they may navigate via links or headings etc.) when they shouldn't be.
Final thought - are you sure you need a modal? There may be a better pattern you could use if the above does not apply to your use case.
I am working on creating a text highlighter with these functionalities:
It allows the users to select and highlight/unhighlight the text on
the page with different colors.
Load the highlights from a file (search for the words from the file in the page and highlight them).
I was able to create the highlight and delete highlight function using rangy https://github.com/timdown/rangy (which is not a react component), but whenever any component on the page sets the state using (setState method) those highlights disappear.
Also, previously highlighted items are not easily loaded into the page using this method.
That is why I am redeveloping this functionality again, and I want to know what would be the right approach to tackle this issue?
I have been thinking of developing a custom React component for highlighting and adding it to the page, but for this approach, I want to know how to dynamically add the highlights component when the user selects a text on the page without losing it when the state is updated.
A link to a useful resource on how to add dynamic components would be convenient for me as I have been searching for the correct way to tackle this issue for a while and I think I might not be heading in the right direction.
React will re-render anything where the state has changed. This will cause your highlighting to disappear as the elements are not the same even if they appear the same.
React will also intelligently not re-render if you set a unique key property in many cases. This lets React know to reuse the component.
If the state is correctly changing, and you only want to sometimes prevent a re-render, you should implement a shouldComponentUpdate lifecycle method to control the re-render conditions yourself.
I have a single page application. There is a page with products and on the bottom a link to go to the next page. Upon clicking this "next" link the list of products in the DOM is replaced. While the link clicked has stayed the same and maintains focus from the click. Is it better for me to do something like document.activeElement.blur() is that case? Or should I just leave focus on that as is?
I'm unsure what best practice is as with normal server routed pages the focus would be reset with the page load. But I haven't seen any information indicating manually resetting focus on client routing would be the best experience from an accessibility point of view.
Never ever use blur. It's just bad, random and possibly frustrating.
IN a native application, you should always exactly know where the focus is, and the focus should always be at a precise place; otherwise keyboard accessibility is broken.
If you consider your web application as being a true application, you should observe the same rigour.
So, never use blur, since you don't know at all where the focus is going to move afterwards. If you are going to remove something from the DOM that currently has focus, you should first place it in another place that make sense.
IN your case: clicking on a link, you have two reasonable options:
Leave the focus on the link (reasonable as long as you don't move, hide or remove it from the DOM)
Move the focus at the beginning of the new content that just appeared / has just been replaced
You may ask users of your application which solution they think is the best, or deduce the answer by observing them during a test session.
Let's summarize quickly: whether you are making an old-style website with different pages, and you don't have to matter much about focus, or you are making a real application and in that case you should be as rigourous as if you were developing a native app.
Terribly simple.
I want to display a notification for the user that will remain constantly visible in the form of a page action until the user does something. I am using this code right now:
chrome.tabs.getSelected(null, function (tab) {
chrome.pageAction.show(tab.id);
});
But that only creates a page action icon on the active tab when the extension is loaded. Instead, I want the icon to show all the time no matter what page or tab the user is on. It also needs to go away when the user does what is necessary to deal with the notification.
I was thinking of two ideas. The first was looping through and adding a page action to every tab, then hooking the new tab and navigation events and adding it to each of those. My second idea was hooking the active tab change event and adding it to the active tab then removing it from the former tab when changing tabs next.
But I thought that there's still probably a better way I didn't think of or didn't know about. So what's the best way to accomplish this?
You need to hook into the onActivated event if you want to get notified of tab changes.
However, that would not be enough, since the page action will reset on navigation. So you'll need to hook into almost every tabs API event to ensure your logic. Also, think of the cleanup required afterwards.
That really does seem like a poor job for a page action. There is also an important consideration that this UI element is not associated, by a typical user, with something that needs attention. Have you considered using notifications instead?
You could use chrome.notifications Rich Notifications together with the priority trick, or just web notifications. In either case it'll be something displayed to the user in a way that is appropriate for "something needs your attention". You can then hook into its onclick event.
If you do want a button, browserAction is totally appropriate. You can dynamically change picture, add a text badge to the icon to attract attention, or just plain disable the button (not hide, but grey out) when there's nothing to do.
According to the documentation, page actions are supposed to be used only for single pages. If you want something to show up on all pages, you should use a browserAction.
Alternatively you can try and set "<all_urls>" in the permissions, but I haven't tested if it actually works.
I've got a pretty big complicated HTML5 app I'm working on (backbone, marionette, jQuery, underscore, handlebars, bootstrap, etc) and deep within the app is a modal popup with a form in it.
When the modal pops open, the first time you click on any form field the form field de-selects itself. After that first click you can use the form as normal. When the app is ultimately loaded into an iFrame in production (don't ask) the first time you click on any form field or hover over any button, the whole page scrolls down until the top of the div element the form is within inside of the modal is at the top of the page, but after it does this once, it doesn't do it again (confused yet? Yeah, it's complex and layered).
I'm at a loss for how to even begin debugging this problem (thousands of lines of code, two handfuls of libraries).
I tried these:
console.log('bound events: ', $._data(this.$el.find('#RandomFieldID')[0], 'events'));
console.dir($('#elmId').data('events'));
console.log('bound events: ', $._data($('body')[0], 'events'));
But that yielded nothing.
Since this is library upon library upon framework upon framework I'm not even sure where to begin trying to find the thing that has obviously bound itself to these fields, or even if it is the fields that are being bound to or something else entirely...
So, any suggestions on good strategies for how to debug a mysteriously bound Javascript event (with multiple JS libraries and frameworks, which can't be just commented out until the problem resolves because they are relied upon to even get the HTML to appear on the page in the first place)?
And, unfortunately I can't do a jsfiddle or something because, as I said, this is deep deep within the app and I'd basically have to re-create the app inside of JSFiddle (impossible) to link to an example (and, it's not in an external facing site, so, I can't just link to it live in production).
I'm stumped.
Here's how I do it with Chrome.
Ctrl-Shift-J to open Javascript console.
Click the little magnifying glass in bottom left, it lets you select an element with your mouse.
Click an element on your page (it will highlight as you go to it.) It will highlight in the DOM at the bottom and show a bunch of properties on the bottom right.
At the bottom right go all the way past the CSS attributes and stuff down to event listeners:
Pick the event listener you're interested in. It will show you the bound function as well as the exact line of code in what script would be executed. That should tell you what library is doing your crazy stuff.
I find the Chrome debugger to be much more powerful and fast (doesn't lag) compared to FireBug and the IE developer tools. It's highly recommended :)