Carousel’s and slideshows are the red-headed stepchild of the web design world, but they are still used (and useful) in many scenarios. That said, they are often horribly inaccessible. This article offers a step-by-step walkthrough of common accessibility issues with this interface and details how to address them.
Do you use CKEditor? You should really grab the new Accessibility Checker.
Next week I’ll be giving a talk on Progressive Web Apps (PWAs) on Windows (and desktop) at Microsoft Build. While researching folks perspectives on PWAs for the desktop, I stumbled on this post from Justin Ribeiro. In it, he makes a solid case for why discussions of PWAs should not be limited to mobile contexts: > As web developers we use the desktop browser different than an average user. We use the desktop to develop and we sometimes fall prey to assumptions about the platform from that experience.
Yes, yes, and yes!
An excellent response to Patrick Lauke’s post on High Contrast Mode in Windows. Greg makes seem great points and provides a clear use case using system color keywords.
Edge usage is growing. NetMarketShare.com puts it above Safari usage on macOS and the U.S. government websites have seen more than 98 million visits in the last 3 months alone. If you’re not testing on Edge you should be.
This post offers exactly what it says on the tin: 7 screen reader/browser combos you should be using in your testing work.
A good overview of considerations here. In particular, this bit particularly resonated with me:
I also secretly judge [agencies/freelancers] based on whether or not I would actually hire them for work. Many designers with a strong sense of aesthetics are lacking in the UX department, and their site is nearly impossible to navigate. Sometimes the the UI is easy to navigate, but there are possible functional problems. Sometimes they’re issues that could easily be solved with progressive enhancement, but no one bothered.
There are two reasons for this: bandwagon-hopping, and misplaced experimentation.
An excellent overview of how to create an accessible ToDo list from the one and only Heydon Pickering. This is a great project, we should all support him so we get more amazing content like this.
While the name is a bit confusing, this new tool helps you compare the volume of code you’ve authored to the the amount of code that is actually executed by the browser. It’s a cool idea, but you should take it’s results with a grain of salt: This tool is only diagnosing your project based on the current page and/or flow (if it’s a single page app). Be careful not to take the results as gospel and start eliminating code without knowing whether it’s actually unused in all scenarios.
Now… tie this into an automated testing tool and gather results from a complete run-through of an app or site and you’ve got something you can actually use to improve your site’s performance.
It’s worth noting that there are static analysis tools for many task runners that can actually run queries against your HTML templates and remove unused styles automatically. I’ve used gulp-uncss on a few projects and found it to work reasonably well (though you have to tune it for any JavaScript-related styles since it only consults your HTML to find matches).