When we think about the idea of an application, one central question constantly trembles: What would be the best platform to develop it for initially? The reason for this question is the highly fragmented market today we live in.
Currently, a user has two primary options to operate an application. For example, a ticket booking application can either be opened as a web application on a desktop or a mobile device can be considered for the same process. Users can also download the mobile application if they choose a mobile device. After this, these options divide further. Let’s say they prefer a mobile device to download the application. But then, which operating system are they using? Since Android and iOS have APIs and structure that is poles apart, they need separate applications.
In Java programming, language generics are introduced in J2SE 5 for dealing with type-safe objects. It detects bugs at the compile time by which code is made stable. Any object type is allowed to be stored in the collection before the generic introduction. Now after the generic introduction in the Java programming language, programmers are forced to store particular object types.
Advantages of Java Generics
Three main advantages of using generics are given below:
Note: YouTube Feed also has a free version. However, it does not support the Live Stream feature.
Once the plugin has been activated, you need to visit the Youtube Feed » Settings page from the admin sidebar. Here, you need to enter the license key and click on the ‘Activate’ button.
You can get the license key from your Accounts page on the Smash Balloon website.
Next, you need to visit the YouTube Feeds » All Feeds page from the WordPress admin sidebar.
From here, simply click on the ‘Add New’ button at the top.
This will open up the ‘Select Feed Type’ prompt.
Now, you need to choose the ‘Live Streams’ option and then click on the ‘Next’ button to continue.
On the next step, you need to connect YouTube Feed Pro with your Youtube account. You will be asked to provide your YouTube API key.
If you already have an API key, simply copy and paste it into the ‘Enter API Key’ box and click on the ‘Add’ button.
Create a YouTube API Key
If you don’t have an API key yet, then you need to go to the Google Cloud Console and sign in using your Google account.
Once you are logged in, click on the ‘Select a project’ button at the top.
This will open a popup window that will display all the projects that you have created.
Next, simply click on the ‘New Project’ button at the top.
This will take you to the ‘New Project’ page, where you can start by typing in a name for your project. This can be anything that will help you easily identify it.
Next, you must also select an ‘Organization’ and its location from the dropdown menu. You can select ‘No Organization’ and click the ‘Create’ button to continue.
Once the project has been created, you will be taken to the project dashboard.
From here, you need to click on the ‘+ Enable APIs And Services’ button in the top menu.
This will take you to the API Library page. It shows the different Google services that you can create APIs for and use in your projects.
Now go ahead and search for ‘YouTube Data API v3’ in the search box.
Once the ‘YouTube Data API v3’ result shows up, just click on it.
This will take you to a new page where you need to click on the ‘Enable’ button to activate the YouTube API key.
You’ll now be taken to the ‘API/Service Details’ page.
From here, simply click on the ‘Create Credentials’ button at the top.
Next, you’ll be directed to a new page where you must check the box next to the ‘Public Data’ option.
After that, click on the ‘Next’ button to create your API.
Your API Key will now be created and displayed on the page.
Simply copy the API key and click on the ‘Done’ button.
Next, it is time to head back to the WordPress dashboard.
Go ahead and paste the API key into the API Key Required box. Then, click on the ‘Add’ button to continue.
Add the YouTube Live Stream to Your WordPress Website
Once you’ve added your YouTube API key, you will be redirected to the ‘Select Feed Type’ page.
From here, you need to click on the ‘Live Stream’ option again, followed by the ‘Next’ button.
This will open the ‘Add Channel ID For Live Stream’ page.
Now, you need to visit the YouTube channel that contains your live-stream videos.
From here, go ahead and copy the text that comes after ‘/channel/’ or ‘/user/’ in the URL at the top.
Next, switch back to the WordPress dashboard and paste the code into the ‘Add Channel ID for Livestream’ box.
After that, click on the ‘Connect’ button to connect your YouTube channel with WordPress.
Once the channel is connected, you need to click on the ‘Next’ button to continue.
Customize Your YouTube Feed
Now that your YouTube live stream feed has been created, you can customize it. Smash Balloon’s YouTube Feed Pro offers many different display options.
First, you will need to choose a template on the ‘Start with a template’ page. You can choose from Default, Carousel, Cards, List, Gallery, and Grid layouts.
Once you have made your choice, simply click on the ‘Next’ button.
After you have chosen a template, an editing screen will open up that displays a preview of your YouTube feed to the right and customization settings in the left menu column.
Here, you can start by expanding the ‘Feed Layout’ panel.
On this screen, you can switch between the layouts.
You may also be able to configure additional settings depending on your chosen layout.
Next, you need to click on the ‘Color Scheme’ panel.
By default, YouTube Feed Pro uses the same color scheme as your WordPress theme. However, you can also use a ‘Light’ or ‘Dark’ color scheme for the video feed.
You can also design your own color scheme by clicking on the ‘Custom’ option and then using controls to change the background, text, and link colors.
To add a header to your YouTube feed, you need to visit the ‘Header’ panel. From here, simply toggle the ‘Enable’ switch to activate the header.
You can also use the controls to switch between standard and text header styles. Choosing the ‘Text’ option will allow you to change the text size and color.
You can also customize the appearance of the video player by going to the ‘Videos’ panel.
Here, you will see a list of options.
To customize the video layout and individual properties, you need to visit the ‘Video Style’ settings panel.
Here, you can select the video layout, background color, and border.
After that, open the ‘Edit Individual Elements’ panel. Here, simply check the boxes next to the elements you want to display along with the YouTube live stream videos.
You can show or hide the Play icon, video title, live stream countdown, descriptions, and more.
Next, you need to head over to the ‘Hover State’ setting. Here, you can choose the individual elements that will display when the user hovers their mouse over the YouTube video.
You can pick many elements, including video title, description, date, views, and more.
After that, you need to visit the ‘Video Player Experience’ panel.
From here, you can change the video player’s aspect ratio. You can also choose whether the video will start playing automatically or wait until the visitor clicks the play button.
After customizing the individual video elements, switch to the ‘Load More Button’ panel.
Here, under the ‘Load More Button’ setting, you can switch the toggle to ‘Enable.’ This will display more video suggestions after the live stream.
You can also choose the background color, hover state, and text from the settings in the left panel.
After that, switch to the ‘Subscribe Button’ panel and toggle the switch to ‘Enable’ if you want to activate the YouTube subscribe button.
You can also change the button’s color, text, and hover state in the settings.
Once you have customized the YouTube live feed, you can preview how it will look on desktop computers, tablets, and smartphones. Simply click on the different buttons in the upper-right corner to preview the feed on different devices.
Finally, don’t forget to click the ‘Save’ button at the top to save your changes.
Embed the YouTube Live Stream on a WordPress Page
The next step is to embed your YouTube live feed on a WordPress page. To do this, you must first click on the ‘Embed’ button at the top.
This will open up the ‘Embed Feed’ prompt. Here, click on the ‘Add to a Page’ button to continue.
The popup will now show a list of all the WordPress pages on your website.
Simply choose the page where you want to embed the YouTube live stream and click the ‘Add’ button.
The page you selected will now open up in the block editor.
From here, you need to click the ‘Add Block’ (+) button in the top left corner and search for the ‘Feeds for YouTube’ block.
Once you have found it, add the block to your page by clicking on it.
Don’t forget to click on the ‘Update’ or ‘Publish’ button to save your changes or make them live.
This is how the YouTube live feed looks on our demo website.
Add a YouTube Live Feed as a Widget
You can also add a YouTube live feed to the WordPress sidebar as a widget.
First, you will need to visit the Appearance » Widgets page from the admin sidebar.
From here, click on the ‘Add Block’ (+) button in the top left corner of the screen and locate the ‘Feeds for YouTube’ block.
Next, click on the block to add it to the widget area.
Don’t forget to click on the ‘Update’ button to save your changes.
This is how the YouTube live feed looks in the sidebar on our demo website.
First, go to the Appearance » Editor page from the admin sidebar to launch the site editor.
From here, click on the ‘Add Block (+)’ button at the top and look for the ‘Feeds for YouTube’ block.
Next, you can drag and drop the block to wherever you want to display the YouTube feed on your page.
Once you are done, don’t forget to click on the ‘Save’ button to apply the changes.
Here is a preview of the live streams on our demo website.
We hope this article helped you learn how to embed YouTube live streams in WordPress. You may also want to read our ultimate WordPress SEO guide or check out our top picks for the best social media plugins to grow your site.
If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.
Conditional statements are used for making decisions based on different conditions. Also, conditionals in JavaScript allow you to execute different blocks of code based on whether a certain condition is true or false.
Conditions can be implemented using the following ways:
Discover how Progress Kendo UI, a commercial-grade UI library featuring data grids, charts, schedulers, date pickers, and rich content editors, streamlines UI development and saves time for web developers.
More and more users prefer browsing websites in dark mode to reduce eye strain and save battery life. To provide the best user experience, it’s helpful to implement an automatic dark mode on your website that adjusts according to a user’s operating system settings. In this tutorial, we’ll walk you through the steps to achieve this.
Your Web Designer Toolbox Unlimited Downloads: 500,000+ Web Templates, Icon Sets, Themes & Design Assets
1. Create a CSS file for dark mode
First, create a separate CSS file called “darkmode.css” that contains the styles for your website’s dark mode. This file should include the color palette, font styles, and other design elements that cater to dark mode. For example:
The “media” attribute ensures that the dark mode CSS file will only be applied if the user’s operating system is set to dark mode.
3. Detect operating system’s color scheme
Now it’s time to detect the user’s operating system color scheme with JavaScript. Create a new JavaScript file called “darkmode.js” and add the following code:
This function checks if the user’s operating system is set to dark mode or light mode by evaluating the ‘prefers-color-scheme’ media query.
4. Save the user’s preference
To improve the user experience, we’ll save their preference in the browser’s local storage. Add the following code to the “darkmode.js” file:
function saveUserPreference(preference) {
localStorage.setItem('color-scheme', preference);
}
function loadUserPreference() {
return localStorage.getItem('color-scheme');
}
These two functions save and load the user’s color scheme preference, respectively.
5. Toggle dark mode
Create a function to toggle dark mode on and off by adding or removing the “dark” class from the HTML body element:
function toggleDarkMode(enableDarkMode) {
if (enableDarkMode) {
document.body.classList.add('dark');
} else {
document.body.classList.remove('dark');
}
}
6. Initialize dark mode based on user preference or system settings
Now, add a function to initialize dark mode on page load. This function checks if the user has a saved preference in local storage; if not, it defaults to their operating system’s settings:
As a fallback and also providing a better experience for your users, it is a good practice to give them the ability to switch between dark and light modes manually. To do this, add a button or a switch element in your website’s main HTML file:
<button id="toggle-darkmode">Toggle Dark Mode</button>
Next, add an event listener for this button in your “darkmode.js” file:
This function toggles dark mode, saves the new preference in local storage, and updates the user interface.
8. Listen for operating system changes
To ensure that your website’s dark mode adapts to changes in the user’s operating system settings, add an event listener to the “darkmode.js” file that listens for changes to the ‘prefers-color-scheme’ media query:
function handleSystemColorSchemeChange(event) {
if (!loadUserPreference()) {
toggleDarkMode(event.matches);
}
}
window.matchMedia('(prefers-color-scheme: dark)').addListener(handleSystemColorSchemeChange);
This function checks if the user has a saved preference in local storage. If not, it toggles dark mode based on the updated operating system settings.
9. Link the JavaScript file
Finally, include the “darkmode.js” file in your main HTML file by adding the following script tag inside the head section:
<script src="darkmode.js" defer></script>
The “defer” attribute ensures that the script is executed only after the HTML document has been fully parsed.
All done! Now you have everything you need to implement dark mode on your future projects!
No matter what your stance is on them, no matter what your perspective is on data protection, web advertisement, setting cookies, EU’s General Data Protection Regulation (GDPR), and privacy preferences, cookie consent widgets (or “cookie banners”) are a reality on the web today.
For this reason, it is worth looking into how accessible and usable these banners are or can be. They have become, for better or worse, a component of the majority of today’s websites. Even more, cookie banners are often the first thing a user encounters. And, of course, they are part of every site of a webpage once they are implemented.
Sometimes, cookie banners are a technical necessity because of the page’s feature set or because of advertisements on the page. Even more often, cookie banners are not built by the front-end team but are a ready-made solution, like UserCentrics or others.
Before I explain why the cookie banner deserves special attention regarding its accessibility, let’s quickly explain how the current gold standard of web accessibility, Web Content Accessibility Guidelines (WCAG) Version 2.1, works.
WCAG consists of principles, guidelines, and success criteria. The latter are testable steps to check against a webpage. For example:
“Is the main language of the document set?”
“Does this non-text content have a suitable text alternative?”
“Is it perceivable where my focus is when I’m using the web presence with the keyboard (or another tech that emulates keyboard presses)?”
You may have noticed that these are “yes or no” questions. Accordingly, this means that the final verdict of any given success criterion is either “pass” or “fail.”
Additionally, conformance to WCAG, as defined by the W3C (the governing body of the Web), means that none of its success criteria is allowed to “fail” when the whole document needs to be conformant:
“Conformance to a standard means that you meet or satisfy the ‘requirements’ of the standard. In WCAG 2.0, the ‘requirements’ are the Success Criteria. To conform to WCAG 2.0, you need to satisfy the Success Criteria, that is, there is no content which violates the Success Criteria.”
No nuance here. Going back to our cookie consent interface, this means that the banner (or any other component) alone has the potential to negatively affect the WCAG conformance of an entire web project.
WCAG conformance could be a big legal deal for many websites, whether part of the public sector in the European Union or the United States, as it is considered to fall under non-discrimination or market access laws or overall human rights to access to information. Webpages frequently must adhere to directives and regulations that directly or indirectly refer to WCAG, often its newest version, and conformance to its level AA standards. Therefore, all the following WCAG criteria are viewed through this lens, being fully aware that they are only a mere starting point when it comes to true web accessibility. On top of that, cookie consent interfaces are implemented on every subpage of a website, consequently harming accessibility and conformance throughout an entire website.
So, in order to not let a faulty cookie banner interface drag down your page’s conformance with accessibility laws and, more importantly, not exclude users from accessing and exercising their rights, let’s list what to look for, what to configure, and what to build properly in the first place.
Contrast Errors
This is especially relevant when it comes to important controls such as the setting of cookies or the overall acceptance of the recommended cookie set. It is crucial that form controls and text can be sufficiently perceived. Unsurprisingly, a solid contrast is also important for WCAG in general. Namely, in success criteria 1.4.3 and 1.4.11, both define contrast boundaries.
What To Do
When you are using a ready-made cookie management solution, try to influence the colors (if possible, potentially in your cookie vendor’s settings) and make sure interactive controls have sufficient color contrast.
Additionally, if your website relies on a dedicated contrast mode for WCAG conformance, check whether it extends to (or influences) the cookie management interface. I have seen cases in my accessibility auditor practice where this was not considered, and an inaccessible (often branded) color combination was used in the cookie interface, thinking the contrast mode takes care of every color-related violation. But the contrast setting of the website did not affect the third-party cookie banner due to it being, well, third-party and loaded from external sources or after the contrast mode had done its work, resulting in a “Fail” on WCAG’s contrast-related success criteria.
Pseudo Buttons
Another cookie banner issue can be one thing that is, unfortunately, an error pattern that you can find outside of cookie management: divs or spans with click events posing as links or buttons. These controls may be styled like buttons but lack the semantic information of a button.
On top of that, these controls usually aren’t keyboard focusable. Hence, many serious barriers and WCAG violations are occurring all at once. If we were about to imagine the most “pseudo” button, e.g., a div with a click handler, this would at least violate success criteria 2.1.1 (Keyboard), because it is neither reachable nor “activatable,” and 4.1.2 (Name, Role, Value) because it doesn’t “introduce” itself as a button and lacks a programmatic label.
What To Do
The easiest thing to do, assuming you have built the cookie management interface yourself, is to replace those above-mentioned pseudo buttons with real <button> elements because it provides semantics, focusability, and even keyboard event handlers for free. But even if we don’t talk literally about buttons, the pattern is the same: check your cookie prompt for interactive elements that are built with elements that are only styled to look like “the real thing” but consist of non-semantic divs and spans. This is a red flag for you to implement native interactive elements, like a, button, or input instead.
The situation gets a lot tougher, of course, when these semantic errors are in a third-party script and are, therefore, beyond your direct influence and control. Understandably, we have to leave the engineering side of things and start to dive into politics of some sort. If you work within an organization where the decision of cookie management infrastructure is outside your control, you have to escalate matters to your supervisors and managers (especially, but not only when your web projects have to adhere to accessibility laws).
Three abstract steps have to happen:
Your organization has to become aware of the barrier and potential legal risk — “up” to the powers that have the influence to change technical decisions like these.
As a consequence, the vendor that provided the faulty cookie banner has to be contacted about the issue.
A form of pressure should be applied by your organization — not just for your own sake but also regarding all the other web pages where the faulty cookie banner negatively influences accessibility and conformance.
In a possible fourth step, your company or agency should reflect on its vending process for third-party services and the HTML (and possible barriers) that come with it.
Unlabeled Form Fields
When you think about it, the main user control that one could imagine for cookie management widgets is a form control: You can select which set of cookies you are willing to accept by interacting with checkboxes in a form element. And, of course, it is important that checkbox inputs are built in the correct way.
Alas, that is not always the case. While a checkbox and its label may visually appear adjacent, the checkbox can lack a programmatic label. This adds unnecessary confusion and barriers to the interface and also a failure of success criterion 1.3.1 when you look into the web accessibility standard.
What To Do
The most solid strategy to connect form inputs with their corresponding labels is to:
Use a label element for the label (obviously).
Establish an id on the respective input you want to label.
Add a for attribute, filling it with the control’s id you created in the last step.
This also works for inputs of all types, like textareas and selects. Here’s an example of how a properly labeled checkbox could look:
If you can’t directly influence the HTML of the cookie banner’s code, the situation is comparable to the situation around pseudo buttons. Make sure that necessary pressure is applied to your cookie service provider to fix the problem. All of their customers will thank you for it, and even more so the people who visit their sites.
Broken Dialog Semantics (Or None At All)
Quite a few cookie banners are actually cookie dialogs, and of the modal kind. Modal, in the context of a dialog, means that such a window blocks everything but itself, leaving only itself accessible. That is, at least, the theory. But quite some cookie management dialogs do “want to be as aggressive,” presenting as a modal part of the interface but have no according semantics and behavior, which would violate WCAG success criterion 4.1.
What To Do
Up until recently, the recommendation was to build a dialog with WAI-ARIA roles and states and implement focus management yourself (or use Kitty Giraudel’s great a11y-dialog) component).
But the situation has (mostly) changed for the better. Lately, the native <dialog> element has matured to the point where it’s being recommended in most contexts as long as it is used reasonably. A great win for accessibility, in my opinion. The past way of building (modal) dialogs had so many moving parts and factors (roles, states, focus behaviors) to think about and implement manually that it was quite difficult to get it right. Now creating a dialog means using an aptly-named HTML element (and initializing it with .showModal() if you think the cookie dialog needs to be interface-blocking).
What I’ve written so far is, of course, also valid when you cannot influence a third party’s code, and what I wrote earlier about comparable situations and potential cookie consent barriers is valid as well. If you detect errors in the third-party script you are implementing (such as no focus trapping, no dialog role, no aria-modal="true" — and if everything else points towards “modalness”), escalate things internally and educate the decision-making powers about web accessibility consequences. Maybe even educate the third-party developers that things concerning modals have gotten a lot better recently.
Cookie Banners Are Hard To Find In The First Place
There are three typical places where you can usually find cookie consent interfaces, at least visually:
As a modal dialog, i.e., in the middle or — more rarely — corners of the viewport;
On top, sometimes in a fixed manner;
At the bottom of the viewport, sometimes also somewhat positioned in a fixed way.
But what matters way more for some people is how easy it is to find, should they go on a hunt for it. A great way of presenting this very problem is a presentation that accessibility specialist Léonie Watson gave some time ago. Léonie is a seasoned screen reader user, and her presentation showcases a bunch of webpages and how the placement and “findability” of cookie banners influence the screen reader experiences, particularly as it is related to privacy. Hampering the ability to find important content in a document can, for example, negatively affect WCAG 1.3.2 (Meaningful Sequence).
What To Do
In Léonie’s presentation, the best practices for cookie notice findability become very clear, especially in the last example:
Place the banner preferably at the top of the document.
Build a bridge back to proper dialog semantics by making sure that if a dialog is meant to be the “exclusive” part of the interface, it uses appropriate semantic and state descriptions (see above for details).
When we’re talking about changing third-party code, I reckon you know the drill by now. Try to influence this code indirectly on the “political level” because direct control is not possible.
Conclusion
Hopefully, two things emerged while reading this article:
Awareness of the issue, namely, that an often unloved stepchild interface element has the potential to make it harder for some people to manage their privacy settings and, on top of that, to even pose a legal risk.
A sense of how you can possibly remediate barriers you encounter when working with a cookie management banner. The direct way is described in a certain detail in the details I provided earlier and often has to do with code, styling, or overall education on how to prevent this in the future. The indirect way leads to a path of either setting the consent interface up properly or influencing the inner and outer politics of your vendor scripts. And again, there is the aspect of educating everyone involved. This time, structured information may be aimed at the powers that be in your organization, showing them that their choice of service providers may have unintended consequences.
But regardless of whether you and your team manage to fix accessibility bugs directly or indirectly in your cookie consent interfaces, you can see their ubiquity and component architecture as an advantage. By getting the accessibility right in one place, you influence many other pages (or even foreign websites) for the better.
If you want to extend your horizon regarding the user experience side of cookie banners and learn about how you can actually turn privacy settings into a pleasant and respectful involvement with at least EU laws, please proceed to Vitaly’s smashing read, “Privacy UX: Better Cookie Consent Experiences”.
