We are displaying our Ads using forge.tabs.openWithOptions, but the problem is the user can quickly close the tabs even if the content inside the tabs not yet finished loading. So the whole Ad System became not usable and we can't be able to earn to it.
Is it possible to pre-load the html url even though the tabs was not yet shown? Or can we disable the close button for a certain amount of time to force the user to view the ads?
Waiting for your response, thanks!
As you stated in the comments, caching will not do the trick as the ads content changes everytime. Having said this, your best bet would be to somehow disable the close button of forge.tabs. This is most probably only possible by implementing your own custom forge.tabs using native modules.
Related
I'm adding a blocking modal (ie one that covers the screen and prevents interaction while an API call is processing) to my company's design library.
As part of that, I modified our modal so that clicking on the grey backdrop will NOT hide the blocking modal, but I want to make sure that doesn't violate accessibility guidelines. I haven't been able to find anything online about this. Does anyone know if this this violates accessibility requirements?
Short Answer
The answer is 'it depends'. Basically if the modal is not dismissable in any way it becomes a 'keyboard trap' and so would violate WCAG.
However if you structure it correctly a modal that blocks the page while an API loads is perfectly valid (and can't be dismissed while the page is loading), but there are a few things you need to do to make sure this is accessible.
1. Make sure that when this modal loads, nothing else on the page is focusable.
The biggest issue I see on most modals is that they allow focus outside of them.
You can't just stop users using the tab key as that is not how most screen reader users navigate the page (they use shortcuts for headings (h1-h6), hyperlinks etc.).
For this reason make sure your modal sits outside of your <main> and the hide your <main> and other major landmarks that contain information with aria-hidden="true" and by adding tabindex="-1" to them so nothing is focusable.
Obviously this depends on your document structure so you would need to test it, but a properly structured HTML document will work with the above method.
2. Make sure that a screen reader user knows that the page is busy and something is loading.
There are a couple of ways to do this. The best is to use an aria-live region
Adding aria-live="polite" and aria-busy="true" to the section you are updating is one way (if you are updating one part of the page).
However in your circumstances I would make a section within the modal aria-live="assertive" and not use the aria-busy (as you will be hiding all the content in step 1 so aria-busy would not be applicable).
I would then update the message every second or two for long loads (i.e. 'loading', 'still loading', 'nearly loaded' etc. Or better yet a loading percentage if your script allows.)
Once the page content has loaded, you do not need to say 'loaded' instead make sure you have a heading for the section or page that has a tabindex="-1" added on it that accurately describes the content that has just been loaded in.
Once the load completes, programatically focus this heading and the user will know that the load is complete.
3. Make sure that if the API call fails you feed something meaningful back to screen readers
When your API call fails (notice I said when, not if!) make sure your JavaScript can handle this in a graceful way.
Provide a meaningful message within your modal aria-live region that explains the problem. Try to avoid stating error codes (or keep them short, nothing worse than hearing a 16 digit string on a screen reader for an error code), but instead keep it simple such as 'resource busy, try again later' or 'no data received, please try again' etc.
Within that region I would also add one or two buttons that allow to retry / go back / navigate to a new page depending on what is appropriate for your needs.
4. For long load times, let the user know what is happening.
I covered this in point 2 but just to emphasise it, make sure you feedback to users that things are still loading if there is a long load time by updating your aria-live region.
Nothing worse that wondering if the page has loaded and the developers forgot to tell you.
5. Give the option to cancel an API call so it doesn't become a keyboard trap.
Obviously the big problem with a whole page modal is it is a 'keyboard trap'.
To ensure this isn't an issue make sure you provide a cancel button.
Make sure it is clear that this will cancel the loading of the page, but don't rely on JavaScript alone.
Instead make this a <a> styled like a button that either points to the current page or the previous page (yet again depending on your needs) and add role="button".
Then intercept this click with JavaScript so that it can function like a button.
The reason for this is that when your JavaScript fails (yet again - when, not if) the user still has a way to get to a meaningful page, thus avoiding a keyboard trap.
This is one of the few times you should use an anchor as a button, as a fallback!
By doing this you ensure that the user always has a way to escape the modal.
You may also consider allowing a user to use the Esc key to close / cancel but that is yet again down to you and your circumstances.
I'm curious what's the proper way to push the screen read to read <span>read me on load</span> first (it's in the middle of the html page) when the page is loaded?
Even
role="rude"
doesn't help for some reason.
Thank you.
What you are using is not part of ARIA live regions. You want either role=alert or aria-live=assertive (though in an early draft "assertive" was originally "rude").
Now, that being said, live regions are intended for use on an already-loaded page. If you are making a dialog, then your HTML might look like this:
<div role="alert" aria-live="assertive">
Anything in here will be announced as soon as it changes.
</div>
If you want the dialog to be announced at page load, then consider hiding its contents and then using script to display its contents once the page has finished loading.
If you need to make it announce as soon as the page loads and it is not a dialog, consider moving focus to the element at page load using script. By placing focus, the browser will announce whatever it is.
For this to work, however, you cannot just place focus on a <span> as it is not interactive content. You can make it interactive by adding a tabindex attribute. If you do that, then you will need to add a role describing what the element does (you can use role=region if you are stuck) so that the screen reader can announce what it is instead making the user think she has landed on a control or otherwise expect to be able to take an action.
If you are moving focus to the element for users without screen readers, or if the very first thing the page displays at page load is an alert of some sort, then this should be fine.
However, since you have provided no context and no examples, and given all the ways this can be done that are far worse than doing nothing, please ask yourself this:
Is the thing you want to announce…
…an alert or dialog?
…a control that already can receive keyboard focus?
…going to be given focus for all users, not just those with screen readers?
If you end up saying no twice then you should not do this.
If you can provide an example URL that shows what you want to do, then I am happy to help you get it working. Otherwise I fear you may be coding something that ends up creating a trap or barrier for screen reader users.
I want to add a background music to my website, but i want that music to play continuously across all pages.
For e.g: i have music which is approx 10min, i am on Home page for 2 minutes music starts from 1 second, when i goto other page the music should start from 2 minutes 1 second.
i've searched across Google & StackOverflow but unfortunately didn't found any answer as per my requirement. :(
i just wanted to know that is it possible to do??? If yes then what kind of mechanism is used for that???
As far as I know, this is not quite easy to accomplish.
There are two practices you may follow, with the first being the most common (IMHO).
Sites that have a music background that doesn't start all over when you navigate, mostly use Ajax or similar methods to navigate, instead of allowing the page to normally refresh. This is mostly common with flash websites, but it is possible to do with Ajax refreshing just the inner content of your site.
The second way would involve somehow passing on a variable that remembers where the user was, but you cannot avoid the loading gaps, and the whole result would be very uncommon and not really pleasant.
There's a few ways you can do this off the top of my head. The easiest would probably be some JavaScript that would load the content of the next page into the current page:
<div id="content">[Your changing page content goes in here]</div>
A link:
Some Page
Some JS:
function loadNext(page){
//using jquery
// assigning to a var like this lets you do things like abort the call
var jqxhr = $.ajax({type:"get",url:page,dataType:"text"});
jqxhr.success(function(result){ $("#content").html(result); });
}
Another, probably simpler way is to load your page content into an iframe and then just have them navigate within that, that'd be a lot safer too as it won't break if people have JS disabled.
<iframe src="homepage.html"></iframe> //You'll need to size this to whatever the content needs obviously, like 'style="width:100%;height:100%"'
Both of these solutions require that your content be able to be separately loaded from the wrapper of the page, so that things like headers and footers don't duplicate infinitely as you navigate around.
I'm hoping that someone may be able to help me out.
My Home page (Home.html) has a link to a mp3player located at (mp3.html)
On the mp3player page there is a link back to Home.html
If the user clicks on the link to the Mp3 player I would like for the music to continue to play even if the link to home.html is pressed.
What I would like to avoid is having multiple tabs from being opened if the user would re-click one of these links.
Also I would like to have the appropriate page to open when it's link is pressed instead of being locked in a tab and not displaying.
The mp3 player isn't affected by being refreshed.
I would prefer not to have different tabs open if at all possible.
This really got me stumped. I've tried different things out only to either be stuck choosing a tab or loosing the music from playing.
Thank you.
You can program your site with AJAX, so index page won't be reloaded but supplemented by content loaded be demand - Google Mail is a good example. Not a task for beginner, though.
You can use HTML frames (see examples) and load index and player at the same time in one tab. Very easy and may fit your needs, but makes your site harder to link to.
I'd go with the AJAX version as well, it's a nicer user experience. If there's a player somewhere in another tab, that's pretty annoying for the user to find if he wants to turn it off or change a track. Check out the Sixtyone and how they're solving the problem.
Sometimes a user will click on a link on a page, and it seems that there is no reaction -- nothing is loaded. It turns out that all the links on that page is targeting a window name, such as "news_content". The user previously already clicked on a news headline, and so when the user now clicks on another news headline, that window (usually another tab nowadays) will load the news, but the original tab is still the one being shown. To the user, this seems like nothing is happening.
Are those websites using <a href=" ... " target="news_content"> ? Is it a good idea to use something like that, or can it be changed a little bit so that the focus will go to that tab instead of staying at the original tab?
(is it better that the browser always switch to the target tab? if so, then this problem looks like will be solved).
In my opinion the user should always be in control of whether a link opens in a new window or not - If they're anything like me with numerous tabs endless new windows links are a mess.
What you seem to be asking is why the browser stays at the original page when a tab is updated with content, its simple, it sees it as another webpage, say you had a page that had realtime updating, your browser would not switch to that as it sees you are on another page - for all it knows you could be reading an article, watching a video etc.
All it takes to realise a different tab/window has updated is a little bit of awareness. With windows they would generally open over the current content, however as tabs are in one window this is not possible an it remains closed, but updated.
EDIT: In response to the title... I believe it to be better practice than opening something brand new each time however feel it should be the users choice whether to load a single new tab or stay in the same one. Hope this helps.
One caveat to add to the conversation.
I only use target= when I know the content is destined to be in an iframe and I don't want the link click to stay in the small window.
For example the graphs I embed here : http://webnumbr.com/stackoverflow-questions
Link behaviour should generally be left to the user to control. In some situations, a case can be made for target="_blank" (especially now that Firefox, at least, has a "New pages should be opened in: A new tab" option), but setting all links to open in the same new window is just bad.
I, for example, hate waiting for pages to load, so I'll read down a page middle-clicking each link that interests me, which will queue them up in a series of new tabs. Five interesting links become five tabs, each loaded in the background while I'm reading the first article, so no waiting. If you make all five open in the same window/tab, though, then each one disappears when I call up the next and not only do I have to 'pick one, wait for it to load, read it, go back to the original article, repeat', but, if I don't notice that this is what's happening, then I'll also need to go back and make a second pass through the original page to re-find the links to the lost documents (or, more likely, just say "not worth my time" and never read them).
Forcing newly-opened tags to the front has a similar problem: I opened it in a new tab because I want it to load in the background while I continue reading the original document. Don't subvert my intention. I cleared the "When I open a new tab, switch to it immediately" checkbox for a reason.
Yes, these websites are using target. Well. I can't imagine in which set of circumstances using the target attribute may be useful. But perhaps there's one. I haven't come across it.
Look, always switching to another tab solves the problem you describe, but it creates others. The biggest one is that switching to another tab may come as a surprise. Usability is by and large about never surprising the user. By the way, I greatly enjoyed the book "Don't make me think."