I am trying to make an existing website accessible but I'm struggling with a banner that has a video background streamed from vimeo. I found an identical issue in this SO thread Making a video element with no sound accessible. The poster stated that axe Tools failed the video as it had no captions - the same situation I face.
The accepted answer does not solve that issue though. Setting a parent element to aria-hidden has no impact on axeTools. I need to make the site accessible but also to pass an audit. Does anyone know a way to do this? It seems to me that WCAG is not well thought out here as it seems to have no video equivalent to alt="" or aria-role="presentation" as it does for images when a video is purely decorative and conveys no meaningful information.
Ignore axe or any other automated testing tool for the moment because they often have errors in their reporting. Axe-like tools are not the standard for measuring accessibility. WCAG is. Using a human and the Web Content Accessibility Guidelines is your sure source to know if you are conformant or not.
In this case, you have two guidelines that apply.
1.2.1 Audio-only and Video-only (Prerecorded)
2.2.2 Pause, Stop, Hide
For the first, it says:
Either an alternative for time-based media or an audio track is provided that presents equivalent information for prerecorded video-only content.
So two key points here are:
You can either have an alternative for time-based media (which is often a transcript, and in this case you could have a transcript that describes what is going on in the video) or you can have an audio track that describes the same thing.
You only need this alternative if the video has meaning. The guideline says the alternative must provide "equivalent information". So what's the purpose or meaning of the video? Does it provide information or is it decorative? If the video were removed, would critical information be lost? If it's purely decorative and doesn't provide anything, then the "equivalent information" would essentially be "nothing". The video could be hidden from assistive technology. But you'd want to talk to your designers about the purpose or meaning of the video.
The second guideline, 2.2.2, says if there's moving content (usually an animation but a video counts as moving information), then the user needs a way to stop it. That's normally done with a pause button on the video but it could be done with lots of other ways.
In summary, you need to decide the purpose of the video and whether it conveys information, and if so, decide what an "equivalent" experience would be, and also provide a way to pause the video.
Related
I am using Microsoft.Directx.AudioVideo.Playback.dll for my video player and everything went very well...
But now I have videos with a double audio track and I can't find how to change the audio track or how to put subtitles...
Could you help me please, I know that somehow it has to be done, but I don't know how!
Thank you so much for everything
The design of this API is not taking into account that media files might have multiple audio tracks. You will need to use a different API offering better track and subtitle flexibility, such as high level WPF MediaElement or some wrapper over low level media APIs like DirectShow or Media Foundation (respectively DirectShow.NET library, and less so MediaFoundation.NET).
If you expect similar ease of use equal to Microsoft.DirectX.AudioVideoPlayback API, you would probably want to use .NET APIs and controls like WPF MediaElement, XAML MediaPlayerElement, staying within their limitations and types of media they offer support for.
Use of low level media APIs (which in turn are all expecting consumption from C++ and not .NET) with wrappers is offering better flexibility but is also notoriously associated with need to dive deep into very small details of media playback.
If a website is to provide non-free content in terms of videos and documents, how is one about to serve this kind of content? I don't want to write an occasionally connected desktop application (similar to iTunes) that prevents to easily share bought content so I have a few questions about this:
Documents: What's best document format for this kind of scenario that would prevent one to share it freely after it was bought?
If I think of PDF it's a great format so people can't temper with its content and they will actually see what you created, but the problem is that after one obtains it, it can easily get shared with others. Either having password or not.
Videos: If supporting video it's probably wise to use some public (may be payable as well) service that can handle video streaming like YouTube (which is AFAIK not able to have a non-public videos).
I'm well aware that there is no 100% perfect solution that prevents it all, but having a 90% successfully locked down content is still better than hoping people won't share something that can easily be shared.
Can you list a few websites that do a similar thing. I may learn a lot from them. And please provide some guidelines I should follow in this regard.
Is there maybe a similar to PDF document format that has built in security capabilities? Commercial even... It should support some kind of authorization functionality within that would work similarly to any software activation.
Note: I wasn't sure whether this should be posted on webapps.stackexchange.com or here but I decided it should be posted here because it's related to development. I'm generally interested in programmable approaches I could use.
I know they are, but my co-worker doesn't believe me. He keeps telling me that Google crawls the inside content and caches it just fine. According to Google, it does crawl them, but doesn't guarantee doing it properly.
Any thoughts why frames are bad for public web sites?
There are various usability and accessibility issues with frames:
link can open in the frame it is enclosed in (e.g. a side pane);
can break the forward/backward navigation;
difficult to bookmark;
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
can break with screen readers and magnifiers (for blind users and visual impaired users);
See http://www.angelfire.com/super/badwebs/ for an example of what not to do.
Frames are more difficult to bookmark and, therefore, more difficult to share with others.
http://www.yourhtmlsource.com/frames/goodorbad.html
IFrames (like HTML tables) are not bad. However, people were abusing them quite a lot, thus giving them the bad name.
IFrames do represent a good concept - single visual representation of documents coming from different sources, while keeping the DOM trees properly separated and isolated.
The problem arises when a script in one of the DOM trees needs to access the elements in another tree. Or when people want to reference the document location, which happens to be the URL of the root document, and fail to realize they need to location of the secondary document.
But the biggest problem with frames is that there are sites that want to encapsulated other sites in frame and trick the user to think they are interacting with the framed site, while in fact interacting with the outer one. This is the primary reason why most websites will employ some form of frame-busting scripts for their login pages.
Update: It's Friday and we need some fun, so here's the (obligatory) link to Jeff's post on frames-busting-busters-busting... :-)
At the beginning ...
The idea behind framesets is great. It's alive and kicking today; check StackOverflow's left side panel, or the header. They are fixed divs, which is basically the same thing as having frames, although a lot more flexible.
The very concept of keeping some part while changing another is simply necessary by the logic of webpages. We need something to stay where it was (typically navigation) while we go through a lot of details in the main area. Framesets served this purpose very well, they were easy to use and fully supported by all browsers, meaning 3 at that time (Netscape, IE, Opera).
Then we scorched the sky
The real, practical problems with frames had nothing to do with their basic concept. Instead, it was us being only human. I followed this whole debate very closely so believe me when I say these were the real charges against frame technology:
Designers hated them. Yes, that was the deadliest punch. Everything looked square and straight. They hated it. They wanted arcs and image backgrounds and rounded borders. Now they have it in CSS3 - guess what, they're drawing squares. #whatever
Programmers had trouble with them. It was inconvenient to follow the logic of frames, and you had to do some extra work. I mean, some. Today it's a lot harder to create AJAX solutions for the same problem, but no one complains. #whatever
Websites could include one another. This was painful for some site owners because they worked hard on something and another fella used it as own content. Later, they invented same origin policy, but it was way after starting to hate frames. Content stealing is still an issue today, absolutely unrelated to whether we have frames or not. #whatever
Back button worked differently. Yes, it was a bit annoying. But it was not the frame concept's fault, again: it was browsers who did this to us. Could have been solved easily, but nah, browsers kept going back one by one, not providing the site a way to implement its own "step back" method, and alas, this is still happening today. #whatever
So instead of coming up with a solution, the world's web developers decided to hate frames. They ditched it, and now we live in a world where there are lots of better solutions - but with a lot more effort. This was not the only feature going thru the hate-ditch-reinvent-love cycle; see vertical centering and flexbox, aka the table tag debate - and it will happen many more times because it's always easier to point fingers at something than to learn why it's great.
I don't hate frames; don't miss them either, they belong to a somewhat outdated world of web. But they were a good solution for something, and there's a chance we'll see something similar in the future just as CSS grids came back to implement what table layouts did before. The same community who hates the old solution will happily embrace the new and tell you why it's not the same at all.
I think this story has a single takeaway:
Implementations come and go.Concepts stay and evolve.
Depending on what you want to do, most things done with frames can be done with CSS. CSS stylesheets are compatible with all MODERN browsers, meaning your website will look the same if using firefox, chrome, or IE 7(with some tweaks). Also backward-compatibility is not a concern as users can view the content even with CSS off (where as a website using frames and without a frameless version of the site will be useless to a user with an old browser), it just won't be as stylized. It's also quite easy to learn, and once you get the hang of it you'll wonder why you haven't learned it in the first place.
I know this is an old thread but..
Been using Frames almost all my life and I think they are great. I still have a few websites using frames and I cannot understand why they are being droppped. Read all of the comments above and disagree with most of them. Problem is most people never bothered to overcome the issues.
Link can open in the frame it is enclosed in (e.g. a side pane);
Yes it can, but if you do it properly it does not matter. Frames can in fact be very useful for this precise reason, as clicking on a link will only refresh the frame the link it pointing to, not the entire webpage. In the days of dialup modems at very slow speeds this used to be extremely useful to save on bandwidth and make webpages appear superfast. Dont forget, there are still people around the world today (albeit not many) that have very limited internet connectivity at very slow speeds. (people on sailboats in the middle of oceans, those die hards that dial into the internet using HF radio. Oh and those that live in war zones that revert back to poor mobile phone signals, or possibly even need to dial into the internet in another contry using their infrared connections on mobile phones via a modem)
can break the forward/backward navigation.
Yes it can, but if you do it properly it wont.
difficult to bookmark
again very easy to overcome, requires very little additional work, but can be easily overcome
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
Already covered by somebody else earlier. Personally I have never even heard of Lynx (apart from the deodarant). In fact it used to be quite useful that pages werent searchable when you did not want to get spammed by bots searching for email addresses... Unfortunately Google or somebody figured out how to do it.
Difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
Clearly whoever wrote this has hardly any experience of using frames. This was exactly why I used frames because I could make it work on any screensize in what some would refer to as Fluid views on modern web design
can break with screen readers and magnifiers (for blind users and visual impaired users);
I suppose it can if screen reading software and maginfiers are cheap and rubbish and dont know what they are doing, probably them that complained about it, but there are others that manage this easily.
The only argument that I think makes sense, is that people were abusing them. Now I would not know how that was done, as I am not in that game, but I suppose it would be easy to use frames to show a copy of lets say a financial payment page inside another another frame which is completely hidden to make it look like the user is on the correct page. Therefore conning users out of their beer tokens. But I believe more modern webbrowsers have been updated to overcome these issues and not allow re-direction where encryption certificates are used.
I can therefore understand why they would want to restrict the use of frames, but dont understand why they need to completely remove what is a pretty good bit of tech. (Bit like saying we are going to stop people from using 0 when they do math as it causes can sometimes cause problems when you add many 0's together.)
I still have some websites that use frames and wonder when I am going to have to re-code them one day.
PS. also note that google calendar and youtube allow one to imbed pages into websites and both of these use iframes.
I was making a website for a music band, and i was wondering the best way to play background music on the website without interrupting the flow of the music (even for a split second).
At the moment, i am considering using frames, but this is not supposed to be good practice. Please someone tell me how i can do this. I would prefer to use HTML to code the website as i have not yet mastered coding in flash.
This might sound controversial, but here's an idea: Don't play music on your website. Seriously, don't. I think everyone knows how incredibly annoying that is, and asking a group of software developers to help you out with that is going to be like asking a group of sheep the best way to make a lambskin coat.
If you really have to do it, frames would be the simplest way, so I'd do that. But you're not going to do it anyway, right?
I can think of four ways:
Frames, as you said.
Make your entire website in Flash and have only one page. You need to know Flash to be able to do this, which could make this difficult.
Pop-out your music player. This is probably the easiest approach, but the downside is this could be annoying, and a lot of web browsers these days would block it.
Use AJAX and dynamically load all your site content within one page, like Gmail. Users will need to have newer browsers, and this will take quite a bit of coding on both the client and the server side.
The only way to prevent the music from stopping is to not let the page your music component is on reload. Currently the only way to do this is to use frames, unfortunately.
The only alternative is to develop the whole site in Flash or another technology that doesn't rely on changing pages as navigation.
It wouldn't be pretty but you could do it using AJAX. Have the master page with the header/footer/navigation controls with a big empty content div, and instead of regular links you have calls to AJAX functions that return HTML to be injected in the content div.
I tend to agree with the others who recommend frames. It may be considered "bad practice", but so is playing background music in the first place.
As was said, to do that you have to prevent your website from relaoding.
An option to achieve this might be to use asynchronous requests to modify your website content without reloading the whole page, that's basically what Ajax is about.
That being said, I sort of agree with Alex here : dont' play music.
This may be a topic for another post, but why would you cosnider IFrames to be good practice? you could out the content you want to change into an IFrame and have your code running your music player ouside it. When you load a page it woul load on the IFrame. Just a thought...
You would most likely need flash or a new window (pop-up) outside of the window.
Don't use frames. Ever.
EDIT: To all the people downmodding and commenting on this, not a single person has given a valid reason why you SHOULD use frames.
Just to clarify my position, please read ANY article on usability, the web, and frames.
For those still learning (and to those old people to dumb to update)
Frames break the unified model of the web.
Frames cause problems for search engine robots.
Frames make URLs stop working.
Frames break bookmarking.
Frames make printing more difficult.
Frames hurt accessibility.
Frames increase technical complexity.
and the #1 reason to not use frames......
USERS HATE THEM!
http://www.456bereastreet.com/archive/200411/who_framed_the_web_frames_and_usability/
Are there seriously this many people out there suggesting frames are a valid solution in 2009? How disappointing.
One of our next projects is supposed to be a MS Windows based game (written in C#, with a winform GUI and an integrated DirectX display-control) for a customer who wants to give away prizes to the best players. This project is meant to run for a couple of years, with championships, ladders, tournaments, player vs. player-action and so on.
One of the main concerns here is cheating, as a player would benefit dramatically if he was able to - for instance - let a custom made bot play the game for him (more in terms of strategy-decisions than in terms of playing many hours).
So my question is: what technical possibilites do we have to detect bot activity? We can of course track the number of hours played, analyze strategies to detect anomalies and so on, but as far as this question is concerned, I would be more interested in knowing details like
how to detect if another application makes periodical screenshots?
how to detect if another application scans our process memory?
what are good ways to determine whether user input (mouse movement, keyboard input) is human-generated and not automated?
is it possible to detect if another application requests informations about controls in our application (position of controls etc)?
what other ways exist in which a cheater could gather informations about the current game state, feed those to a bot and send the determined actions back to the client?
Your feedback is highly appreciated!
I wrote d2botnet, a .net diablo 2 automation engine a while back, and something you can add to your list of things to watch out for are malformed /invalid/forged packets. I assume this game will communicate over TCP. Packet sniffing and forging are usually the first way games (online anyways) are automated. I know blizzard would detect malformed packets, somehting i tried to stay away from doing in d2botnet.
So make sure you detect invalid packets. Encrypt them. Hash them. do somethign to make sure they are valid. If you think about it, if someone can know exactly what every packet means that is sent back and forth they dont even need to run the client software, which then makes any process based detection a moot point. So you can also add in some sort of packet based challenge response that your cleint must know how to respond to.
Just an idea what if the 'cheater' runs your software in a virtual machine (like vmware) and makes screenshots of that window? I doubt you can defend against that.
You obviously can't defend against the 'analog gap', e.g. the cheater's system makes external screenshots with a high quality camera - I guess it's only a theoretical issue.
Maybe you should investigate chess sites. There is a lot of money in chess, they don't like bots either - maybe they have come up with a solution already.
The best protection against automation is to not have tasks that require grinding.
That being said, the best way to detect automation is to actively engage the user and require periodic CAPTCHA-like tests (except without the image and so forth). I'd recommend utilizing a database of several thousand simple one-off questions that get posed to the user every so often.
However, based on your question, I'd say your best bet is to not implement the anti-automation features in C#. You stand very little chance of detecting well-written hacks/bots from within managed code, especially when all the hacker has to do is simply go into ring0 to avoid detection via any standard method. I'd recommend a Warden-like approach (download-able module that you can update whenever you feel like) combined with a Kernel-Mode Driver that hooks all of the windows API functions and watches them for "inappropriate" calls. Note, however, that you're going to run into a lot of false positives, so you need to not base your banning system on your automated data. Always have a human look over it before banning.
A common method of listening to keyboard and mouse input in an application is setting a windows hook using SetWindowsHookEx.
Vendors usually try to protect their software during installation so that hacker won't automate and crack/find a serial for their application.
Google the term: "Key Loggers"...
Here's an article that describes the problem and methods to prevent it.
I have no deeper understanding on how PunkBuster and such softwar works, but this is the way I'd go:
Iintercept calls to the API functions that handle the memory stuff like ReadProcessMemory, WriteProcessMemory and so on.
You'd detect if your process is involved in the call, log it, and trampoline the call back to the original function.
This should work for the screenshot taking too, but you might want to intercept the BitBlt function.
Here's a basic tutorial concerning the function interception:
Intercepting System API Calls
You should look into what goes into Punkbuster, Valve Anti-Cheat, and some other anti-cheat stuff for some pointers.
Edit: What I mean is, look into how they do it; how they detect that stuff.
I don't know the technical details, but Intenet Chess Club's BlitzIn program seems to have integrated program switching detection. That's of course for detecting people running a chess engine on the side and not directly applicable to your case, but you may be able to extrapolate the apporach to something like if process X takes more than Z% CPU time the next Y cycles, it's probably a bot running.
That in addition to a "you must not run anything else while playing the game to be eligible for prizes" as part of the contest rules might work.
Also, a draconian "we might decide in any time for any reason that you have been using a bot and disqualify you" rule also helps with the heuristic approach above (used in prized ICC chess tournaments).
All these questions are easily solved by the rule 1 above:
* how to detect if another application makes periodical screenshots?
* how to detect if another application scans our process memory?
* what are good ways to determine whether user input (mouse movement, keyboard input) is human-generated and not automated?
* is it possible to detect if another application requests informations about controls in our application (position of controls etc)?
I think a good way to make harder the problem to the crackers is to have the only authoritative copies of the game state in your servers, only sending to and receiving updates from the clients, that way you can embed in the communication protocol itself client validation (that it hasn't been cracked and thus the detection rules are still in place). That, and actively monitoring for new weird behavior found might get you close to where you want to be.