One of the videos I'm releasing as free is the "How web accessibility is a continuum," and this was an important lesson for me. Unless it's baked into your system and you are obligated to conform to accessibility standards by law, it's tough to justify the extra time to learn and implement full-on accessibility. But, the guilt of not implementing accessibility doesn't need to be paralyzing. Even many the most accessible sites could use some improvements. Being aware that it's not an all or nothing thing helped me feel more confident about acting on what I knew and slowly increasing my knowledge.
Hope all of you learners out there having a great summer, or winter depending on your hemisphere. If you look out your window and see some snow, consider sending me a shovelful or two.
We need a separate plugin for minifying CSS, so here we download the grunt-contrib-css min Grunt plugin and get our CSS file size down by half.
After both concatenating and minifying our code, we've made a lot of improvement when it comes to performance. Here we summarize our gains.
So far we've only needed one set of configuration for each Grunt plugin, but we need to be able to run two different configurations for grunt-injector now, one for development and the other for production. Here we set up a second configuration, something we can do for any of our plugins.
Being able to swap out which Grunt plugin configurations we use by simply editing a single key in our Grunt task is great, but we can improve this further by adding a second Grunt task so we can run either task on the command line at any time. Super cool.
After getting our concatenation and minification automation squared away, we cross our fingers and hop to the browser to see if everything is solid. Oops! Looks like we've got a bit of an issue with our custom fonts not being pulled in. In this video we track down the issue to a setting in our Grunt concatenation settings where a semi-colon is being added between files, breaking a rather critical line of CSS code where we pull in our font.
Comparing the performance of our optimized site with our pre-optimized version New! (This one's FREE!)
Finally, we get to the fun part where we see the results of all our hard work manifest. At first, we notice that even though we've dramatically reduced the number of files download and the overall size of our site, the optimized version of the site appears to actually load slower than our original version. In this video we get to the bottom of this strange behavior and demonstrate how in less optimal conditions, our optimized site performs way better across a number of different metrics.
We've discussed adding browser prefixes for our CSS multiple times throughout the coding of our template, and have explained why adding the prefixes manually can be error-prone. Here we also explain why were bypassing Compass' built-in functions for creating prefixed CSS rules, and how post-processing our CSS to add prefixes is a much better approach.
Here we install the grunt-autoprefixer plugin and explain how it queries the "caniuse.com" database to decide which browser prefixes to add to our CSS, and which ones to remove.
In this video, we dig a bit deeper into the Autoprefixer settings to see how we can support specific browsers or browser groupings, and we compare our CSS before and after prefixing.
Here we get ready for our next steps by switching from using the concatenated, minified versions of our files to the development-friendly versions.
If you'd like to hop into this series but don't want to start from the beginning, you can watch this to get your environment set up and ready to start the next videos.
What "accessibility" means in terms of the web New! (This one's FREE!)
The term "accessibility" generally means to make a resource available to everyone, not just those in the majority. When it comes to the web, this usually means making a site accessible to those along a continuum of physical ability. Here we talk briefly about with accessibility means and what it implies for developers of web sites.
Section 508 versus WCAG and how to justify spending resources on accessibility New! (This one's FREE!)
In this video we briefly talk about the two standards for web accessibility that you're likely to run into as a front end developer and lay out some arguments for building accessibility into a budget for a project.
Here we use the handy WCAG (Web Content Accessibility Guidelines) Quick Reference checklist as a jumping off point for testing how accessible our site is, and mention that it's a good idea to read through this list to get a sense of common accessibility issues and solutions.
How web accessibility is a continuum New! (This one's FREE!)
Making a site accessible isn't an on / off thing. Instead, each site lands somewhere on the continuum between absolutely not accessible and very accessible. As we improve our awareness of accessibility, we improve our chances of making our sites more accessible during the building process, even without spending any additional time.
Making a site compatible with keyboard navigation means that we're not assuming the user has access to a mouse. Here we start the process of testing our site for navigability with a keyboard and find it lacking in a couple respects.
As we used the "tab" key to jump between different inputs in our template, we noticed that we were unable to focus on the radio buttons since they were hidden with CSS. Here we demonstrate another way we can hide our default radio buttons but still make them accessible.
Most web site headers include a barrage of links that are easy to scroll by, but time consuming to tab through on the keyboard. Here we demonstrate a solution where we add a "skip to content" link that is hidden by default but displays as soon as the user beings leveraging the keyboard for navigation.
Even though it's a great idea to get a handle on the various accessibility pitfalls and solutions and apply them to your templating process as you go, it's also nice to be able to run an audit on your template to get a sense of where your missed opportunities are. Here we demonstrate one, a Chrome Add-on called "Accessibility Developer Tools," and start the process of adjusting our site to make it more accessible.
One big red warning from our accessibility audit was that many of our form inputs were missing labels. That's fine for those that can view the site since there are enough visual queues to give the user a sense of what to do with those inputs, but screen readers are going to have a much harder time. Here we add some labels to our search form but hide them for those who are using visual browsers.
As we continue adjusting our site to fix accessibility issues, we add some labels to our contact form but have to use a different approach to hiding the labels than we did with our contact form, since we only want to hide specific labels. We discuss some options but end up using a SMACSS state, something we haven't pulled out of our toolbox for a while.
How did we miss adding some alternative text to our logo?! This kind of thing happens all the time, and checks like the one were doing are an excellent way to patch up accessibility issues that slip through the cracks.