I want to make a browser game that has users guess some blurred photos of celebrities.The image will be blurred and the user will have a limited amount of time to guess what celebrity is.As time passes the the picture will become clearer.My question is:how can I stop the user from viewing the clear image ?I apply the blurr effect using css3 and send the image to the browser.I think the user can see the image without any effects on it.How can I stop that ?
The only way to implement this is by generating blurred images on the serverside, using encoded unguessable URLs, which are then loading on the client based on a timed update.
There is no way to safely hide something that it already accessible to the client.
Without changing your whole approach (e.g. to one where you send multiple images (in different levels of blurriness) one image at a time and use session tokens and a timer to determine which ones a given user is allowed access to), you can't: Any data sent to the browser is accessible to the user. If you sent a clear image and ask the browser to obscure it, then the user will have access to the clear image.
For setting blure image u can use blur value of filter property
here is example http://html5-demos.appspot.com/static/css/filters/index.html
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 doing a training class right now and one of the games I plan on doing is a Jeopardy style of Q & A. The problem I'm trying to figure out is the buzzer. My idea is to use the projector as the question board I control. The trainees would go to an HTML page with nothing more than a single button. They would turn their monitors around to face me up front. As soon as I read the question they would click the button and it would change their screens the color red.
The button and background color change is easy enough, I got that. There are two problems I'm facing: 1) I need it so that they can't click the button until I'm done reading the question - this one isn't as important, I can just make up a rule. 2) Only the fastest person will have a red screen. To show me who clicked first. The others' buttons will be disabled.
I just have no idea how to even Google these two things. Like: "Disable button for other users"...? Or maybe, "only one click"...?
Any direction to search is appreciated. Eventually, I'd like to add other aspects to like the presenter could click an "incorrect button" then it would clear the screen and enable all the buttons again, for the answer steal.
You can do it with modern WebSocket or applications interact via TCP. However, WebSocket may be overkill for the simple application with a few teams. I faced the same problem before and developed a simple solution with PHP using Flock to write into a shared file on disk. Only request from one team gets the chance to write into that file. Stick to not to use WebSocket, the web page on client site does some polling to receive the "restart" signal from the server for the new question/round. It can run in LAN, different team gets different site, i.e. http://[server-ip]/team1, http://[server-ip]/team2.
You can have control over the round: allow them to press button/ restart, start a new question in http://[server-ip]/admin.
Further improvement can be made in several ways to facilitate your needs (i.e. assign team name, register team, use database instead of a flock file). The code is available here : https://github.com/minhhn2910/buzzergameshow
I have a control in which I repeatedly run some animations (e.g. DoubleAnimation). Can I detect if my control is no longer visible to the user? E.g it gets scrolled away from, the user navigates forward to another page, or it gets obscured behind other controls.
I don't want to run those animations unless at least some part of my control is visible for the user.
You could analyze the visual tree or get a transform from control coordinates to screen coordinates to see if its positioning is within the view port and also check things like opacities, visibilities etc. of controls down the visual tree path, but that is so processing intensive that it is not worth doing all the time for a general solution.
The only thing that would make sense is to handle the ScrollViewer.ViewChanged event and check if the offsets make it visible or not while limiting the TransformToVisual or VisualTreeHelper calls only to times when the actual layout within your ScrollViewer changes.
I have an iframe that displays thumbnail images from Flickr in my web application. The problem, I see is when I reload the page, sometimes, I see the same set of images being appended to the earlier set of images. So I get two sets of every image and on a subsequent reload, I get 3 sets of images.
The images are part of a form. So I see multiple submit and cancel buttons as well. Any suggestions on what might be causing this and how I can avoid this from happening?
Pardon my ignorance. I was not resetting my server side variable after the fetch and hence I was seeing the above weirdness. Firebug helped me debug this.
I have a dialog box with a bunch of dimensions that a user can change by moving/dragging, including a JTable with resizable/draggable columns.
What I would like to do is to make the state of these resizable columns / dialog boxes / etc. persistent, so the next time my application starts up, the user doesn't have to go through the resizing step all over again.
What's the most convenient way to do this?
You should probably take a look at the code in (the now probably dead) JSR-296. A part of it was focused on persistent session state, and I know for sure that the code for persisting window locations and such was already functional and in the basic framework. It should either already do what you want, or provide a good starting point.
Cfr. dev.java.net site for JSR-296