People who are disabled want to be treated equally, so they expect you to design and build your website with inclusion and accessibility in mind and not to throw a band-aid on it. The only way to do that is to commit, provision for it up front, and make accessibility a part of your process throughout the lifetime of your website. End of story.
A succinct way I’ve framed the split is that a front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked.
CSS is yet to have a switch rule or conditional if, aside from the specific nature of @media queries and some deep trickery with CSS custom properties. Let’s have a look at why it would be useful if we did, and look at a trick that is usable today for pulling it off.
In this blog I’ll explore both sides of the case for continuing to develop for IE11, the problems that it causes, the features that it offers (including accessibility features), but also the challenges people may face if developers don’t build for it.
Spoiler Alert: Our recommendation is that developers and companies continue to support Internet Explorer 11 for now, until the newer version of Edge (Chromium) can deliver a comparable experience for assistive technologies – especially JAWS, Dragon NaturallySpeaking and Zoomtext.
Performance budgets are one of those ideas that everyone gets behind conceptually, but then are challenged to put into practice – and for very good reason. Web pages are unbelievably complex, and there are hundreds of different metrics available to track. If you’re just getting started with performance budgets – or if you’ve been using them for a while and want to validate your work – this post is for you.