Submitted by Chris Shattuck on Tue, 2016-08-09 07:30
Greetings fellow learners!
Here it is, the final installment in the "Front End Development" series. In this last batch of videos, we look at what ARIA tags are, how they can improve the accessibility of your site, and how to implement them. We also take a look at a tool for Firefox that scans your site for accessibility issues and offers suggestions for fixing them.
This has been our longest video series by far, and for a good reason. Going from a mockup to a functioning template requires a ton of knowledge and awareness of numerous angles. I hope that if you've been a watcher of the series that you've seen your toolset grow and been able to put some pieces together that might have been difficult to put together on your own.
Chromes Accessibility Developer Tools gives us a warning to check if we're using meaningful images for CSS backgrounds where they're hidden from screen readers. We are, and we discuss some alternatives to make sure our textual browser users get the meaning of these images.
The contrast between the foreground and background color can be a big factor in readability. In this video we use the accessibility audit as a jumping off point for discussing what contrast ratio means, and how it is one factor in seeking a higher WCAG rating.
Chrome's accessibility audit tools are concise and quick, but the "AInspector Sidebar" add-on for Firefox is more complete. We get this installed and open up the sidebar to see what our Chrome audit might have let slip through the cracks.
ARIA (Accessible Rich Internet Applications) is a specification that helps us create rich interfaces for our websites without sacrificing usability for screen readers. Most of what's covered in ARIA's scope is beyond what we need at this point in our site development, but there are a couple techniques we'll end up using, the first being adding landmark roles to our site to more easily identify the role of each element.
Even though the "nav" element pretty clearly has a navigation role, some browsers don't add that role by default. Here we reference a useful web page that lists possible elements and default ARIA roles and explain why sometimes we have to be so explicit.
Many HTML elements have roles built-in, and whenever possible, using a specific HTML tag instead of setting the role of a generic HTML tag makes the HTML more readable and reduces redundancy. In this video we knock out another accessibility violation of our site by adding container elements and discuss the benefits of using HTML tags when we can.
We saw in the Flexslider navigation how it's possible to add text to a link but hide it from view, and here we do the same thing to the empty submit button in our search form. It's a nice trick to know.
An earlier decision we made to hide any labels with the CSS "display" property that weren't supposed to be visible in graphical browsers threw a red flag in our accessibility audit, so we explore another approach to hiding them visibly that gets a pass.
Holy cow! Did you really make it through the entire "Front End Development" series? That's no small feat, and the skills you have now put you in a great position to work on virtually any web based project as a front end developer. Great work!
Even though we've covered an incredible amount of material throughout this series, I thought we should leave the series in a spirit of learning, since you'll find yourself constantly learning more as you further develop your skills. Good luck moving forward!