My application has to call server several times per one second (to check if position on board changed or not). I didn't find anything better for now then implement a timer and call server so often to check if something was updated (actually only small amount of data is sent so I think nothing bad will happen). Anyway some browsers like firefox, shows in status line something like "Transferring data...", and the text which flicker there is annoying.
I wonder if there is a way to control the status line from the flex application?
There's nothing you can use out-of-the-box in Flex (or Flash, for that matter) to control the status bar, you need to use JavaScript for that. Communicating Flash and JS is easy, just take a look to ExternalInterface.
Problem is this never ending "Transferring data" message in Firefox, it's annoying as hell, and I still haven't found how to get rid of it. I was once told sending some specific headers would do the trick, but just didn't fully work for me at that time.
I'd love to hear a definitive answer on this one as well.
Juan
Related
i have a few buttons on my site with audio playing on button hover.
i have main sound on/off toggle button on my navbar.
my question is if it's accessible to play an audio on mouse hover and not on button click? since the user doesn't expect to hear sound when hovering on an element.
i can't find anything on wcag site about play on hover. nothing but this https://www.w3.org/TR/WCAG21/#audio-control
What an interesting question!
Short answer
Don't play sounds on hover automatically without the user explicitly setting the sound to "on" on the site first.
This isn't just an accessibility issue this is a user experience issue, playing sounds without asking permission first is a terrible practice as your user may be reading your page in a library or on a train and will not expect sounds.
If you really want sounds on your site I would suggest a popup on site load that allows a user to enable sounds if they wish.
Longer Answer
Does playing a sound on hover break any rules in the WCAG?
There is no specific guidance as far as WCAG is concerned as to whether a sound can play on hover.
However there is a lot of general guidance that is very closely related that although doesn't specifically mention this scenario is close enough that we can infer whether or not this is a good idea.
I would recommend referencing guidance G170: Providing a control near the beginning of the Web page that turns off sounds that play automatically, guidance G60: Playing a sound that turns off automatically within three seconds and guidance G171: Playing sounds only on user request
You will see there is a common theme, give users the choice as to whether they want sounds and if you do play sounds automatically make sure they don't last more than 3 seconds.
There is also one other thing to consider
The unspoken rule(s) of accessibility
These aren't hard and fast rules but in accessibility there are two things applicable to this question you should always strive to adhere to.
1. Follow Expected practices
Navigating the web I expect to see certain things. If I click a link I expect the page to change, if I click on a picture I expect either nothing to happen or that image to pop up in a lightbox or open in a new page.
Expected behaviour is a key part of accessibility for all sorts of people with disabilities, but especially those with anxiety disorders and those with cognitive impairments.
Having a sound play on hover could startle, scare or confuse certain people or be very distracting for others (e.g. someone with ADHD or Autism).
2. Try to offer the same experience to all users.
The other thing you are doing wrong is offering a different experience to different users.
If someone has mobility issues / accuracy issues (e.g. Parkinson's Disease or Cerebral Palsy) then they may use a keyboard instead of a mouse and will not hear the sounds that mouse users experience on hover.
For this reason if you implement sounds make sure they fire on both the focus state and hover state.
So with all of the above in mind what should you do?
The simplest answer is not to have sounds at all, but you may have a good reason you want sounds on hover / focus.
So the first thing you should do is give your visitors a choice when they first land. Do they want sounds on the site or not.
Instead of switching it on automatically people should explicitly tell you that they want sounds to be played on the site. If they dismiss the message assume they do not want sounds.
This will also help screen reader users etc. as not every screen reader user uses a keyboard (for example someone with severe Dyslexia may hover over items to have them read out loud, your sounds on hover would interfere with that).
The second thing you should do is make sure that no sound plays when over your switch to turn sounds off (in case someone switched them on by mistake), or at least make sure that sound is less than 3 seconds if you really must have a sound. For all other buttons / links etc.
I would probably say make sure sounds last no more than 3 seconds, although one scenario where this may be allowed is if hovering a link previews an audio file. If this is the case I would make sure that when someone decides to enable sounds it is clearly stated that some links may play audio for more than 3 seconds.
The final thing you should do is make sure that sounds are played on hover and on focus. You should give your keyboard users the option to enjoy the same experience as mouse users if they want.
Finally - reconsider using sound. It is likely just going to annoy your users anyway as hearing a sound every time I hover an interactive element is soon going to get frustrating if I have been on your site for more than a minute.
Obviously there will be valid use cases for sound on hover, but there are probably very few of them.
I'm trying to enhance the gTile extension by allowing it to resize a fullscreen window to a tiled area of the screen. That's a pretty common thing to do when tiling and it's pretty handy since some windows will hide some chrome when in fullscreen mode. But I'm having the hardest time figuring out how to do that.
Searching the internet led me to this forum post which mentions EWMH and _NET_WM_FULLSCREEN. I've tried to find ways to access window manager hints but can't find anything bashing by head on Looking Glass or scanning through the docs. Is this kind of thing possible through a shell extension?
Meta.Window is likely what you are looking for:
https://gjs-docs.gnome.org/meta4~4_api/
Setting Window.decorated = false may be able to remove the title bar or perhaps getting the compositor object and changing it from there. However this will still keep the address and tab bars in chrome. You may need to find another method to signal chrome to hide those.
There is not really an easy way to do this, the thread you linked is in regards to VLC and modifying it's source code.
Is there a simple way to trigger a mobile OS's native pop-up/alert/etc. from some form of web code? I'm writing an ASP.NET mobile web page and I'd like to, for example, have the iPhone's UIAlertView appear.
EDIT: What I'm looking for is not the method with which to detect which mobile browser is accessing the site (I already know how to do that). If the code to trigger a pop-up that will look nice in an Android browser is different than the code to trigger a pop-up that will look nice in an iPhone browser, I can simply throw in a switch statement that redirects the user to the pop-up that corresponds with their browser. I'm trying to find the html/javascript/asp.net code which will create a mobile-friendly pop-up, either in general or for the various popular mobile web browsers specifically.
Don't know whether there is any pre-built functionality in .NET that can achieve this, but you can surely write one yourself.
You can write a method, that returns the code for your popup, based on the user OS (simple switch statement should do).
EDIT after taking a short nap:
I believe you should reconsider using popups. They are quite annoying even on desktop browsers and many people block them automatically. Probably every blog about accessibility will tell you, that you should keep mobile version of your website as simple as possible because of various compatibility issues that you can run into.
Instead, try to think about some interesting way to incorporate messages for users in a different and appealing way, that won't disturb anybody.
What I do is use a div popup (that floats ontop of the page) and eighter make a big close button or set at timeout to remove it.
jquery mobile is a good place to start.
How to Disable print, print screen, right click using asp.net
You cant. You cannot avoid content being copied from your pages.
Disabling Right Click is possible, but it doesnt solve your 'problem'. The user could still copy your image, by disabling javascript or just inspecting the source.
And even if you could disable those keys, the user could still just make a photo of his monitor. Good luck disabling that!
Short answer: You don't. You are writing a web application; features of the underlying platform are outside your scope, and you have no business trying to fiddle with them.
Long answer: You can try to capture those keys using javascript, and override the default behaviour, which will somewhat stop very naïve users, but all it takes to disable this "security" is to turn off javascript. Even if you come up with more sophisticated "protection", the essence remains: You are sending content to the client, and once it gets there, it is out of your hands. Given suitable tools (wget is enough for most things), anyone can copy and modify your content in any way they like. Similarly, whatever can be shown on the screen inside a browser can be captured and saved. There is no way around it. If you don't want your content copied, don't send it.
Forget about it. You will irritate your end users who will find a way to con you and do what you didn't want them to do. Forbidden fruit is always the sweetest. By telling them explicitly "you cannot do this", they will wonder why do you want to guard your content and they might try even harder to do stuff you otherwise wouldn't want them to do.
Psychology and technology are against you in this case.
Printing
You could disable printing (well sort of - it's not 100% effective) using a "print" style sheet.
I have not tried it myself, but here is a link that could get you started: http://webdesign.about.com/od/advancedcss/qt/block_print.htm
Print screen
Print screen is something that is typically controlled by the operating system not the browser nor webpage. So you are unlikely to be able to stop this. However, casting my mind back I remember a time (perhaps a long long time ago), where you couldn't take screen shots in Windows (maybe Windows 98) of videos... so if your really in need of disabling print screen - perhaps you could perhaps encode your content in a video... but this will have many many downfalls - namely accessibility, search engine optimisation and it being a royal pain to do... so I wouldn't recommend it under any circumstance.
Right screen
Right click you can disable, but not using a server-side technology (such as ASP.net) instead in a client-side technology such as javascript. A quick search in your favourite search engine will find some help. But disabling right click is rudimentary to get around, so it is not full proof.
An alternative to protect your content is to possibly investigate "rights" in PDFs. I believe you can disable the "right" to print.
However none of these solutions are going to be full-proof. As long as you are making your content available to an end-user on their own computer, there is always going to be a way around your restrictions.
I have implemented for disabling printing using window.onbeforeprint()
Refer this Answer
customers does not want to allow user to use back or forward button. Just a clean page without commandbar and toolbar, same for FF an IE.
Disabling them is not an option as now.
You cannot change that kind of thing in a existing window -- the only way you can make those disappear is by opening a popup, specifying they should not appear in that popup when it's being opened.
Still, note that you should not try to disable those buttons nor have them disappear : your application should work fine with them, handle their actions -- after all, it's one of the few things users have understood in browsers...
And as a user, this is disturbing and annoying :
I don't like popup windows -- and I'm not the only one who doesn't
I don't like when a website tryies to take control over my browser
It will not always work anyway.
And, as a sidenote : even if the back/forward buttons are not displayed, users can still use Ctrl+left/right or some kind of equivalent !
I know this is not easy, but a part of your work as a web-developper is to explain your clients how Internet and web-applications work... not the same way as desktop applications !
If you can force your users into IE (can't believe I'm suggesting use of IE!) you can do this trick. Try running this from the command line
"C:\Program Files\Internet Explorer\iexplore.exe" -k
This will force IE into kiosk (or full screen mode), similar to pressing F11 when in a usual browser session.
PS. I agree with the other answers suggesting this should be discouraged but there are instances (such as when the end user really can't be trusted) that this is a good solution.
No, there's no other way.
However, this is extremely annoying behavior and should be greatly discouraged. This isn't a code issue to solve...this is behavior that shouldn't be implemented at all.
My opinion here, you have a client problem not a code problem. Whatever standard is the expectation, and the user has the expectation of having their back/forward buttons, break that and you break their experience.
Ever see a Windows application that removes the taskbar? That's the equivalent...
I don't think there is a reasonable way to disable the behavior. You may get rid of the buttons in various ways, but the behavior is still there (through keyboard commands, popup menus and so on).
The only reasonable way is to make your web application follow web semantics, and make the client realize this.
many web based ERP (for example) does not tolerate people using navigation buttons. BUT these web applications handle the fact people use these buttons and do not crash. That's what you should do. If each time people use the back button, they get an error message, they will quickly stop using it.
The solution that used to work in IE was adding a startup script with one line:
location.forward();