This philosophy doesn’t apply to every website out there, but it sure as hell applies to a lot of them.
I always loved the way that Gov.uk styled their radio buttns and checkboxes with nice big visible labels, but it turns out that users never used the label area. And because it’s still so frickin’ hard to style native form elements, custom controls with generated content is the only way to go if you want nice big hit areas.
A little tool for testing common form issues.
- Did we remember to give every input a label? (No, placeholders are not an adequate replacement)?
- Do our labels’ for attributes match our inputs’ ids?
- Did we take advantage of the url, email, and password input types, or did we forget and just use text?
- Are our required fields marked as such?
This is nice example of a web component that degrades gracefully—if custom elements aren’t supported, you still get the markdown content, just not converted to HTML.
<ah-markdown> ## Render some markdown! </ah-markdown>
Some more food for thought, following on from Shaun’s post about HTML as the foundation of web development:
Building a good foundation using HTML is like building a good foundation for a house. Without it, you run the risk of having to deal with issues that are difficult and expensive to fix later on.
Equal parts clever and scary. By using
autocomplete in HTML and some offscreen positioning in CSS, it’s possible to extract some unexpected personal information.
I expect browsers will be closing these holes pretty quickly.
It’s a bit like CodePen but it shows the whole HTML document, which makes it particularly useful for teaching front-end development to beginners (ideal for Codebar!).
CodePen for snippets; Thimble for pages.
This is a truly fantastic example of progressive enhancement applied to a form.
What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.
This is such a great perspective on what it’s like to build for the web over the long term. The web will always be a little bit broken, and that’s okay—we can plan for that.
The Web has history. If you build with web technology it will stick around. We try not to break the web even if it means the mistakes and bad decisions we have made in the past (and will make in the future) get set in stone.
Chris runs through the process and pitfalls of POSSEing a site (like CSS Tricks) to Apple’s News app, Facebook’s Instant Articles, and Google’s AMP.
Hey, whatever you want. As long as…
- It’s not very much work
- The content’s canonical home is my website.
I just want people to read and like CSS-Tricks.
Here’s a handy graph from Paul:
Powered by data from caniuse.com and StatCounter, this page indicates the percentage of users who have a browser that natively supports various web platform features.
Heydon asked screen readers some questions about their everyday interactions with websites. The answers quite revealing: if you’re using headings and forms correctly, you’re already making life a lot easier for them.
This is a terrific read that gets to the heart of why progressive enhancement is such a solid methodology: progressive enhancement improves resilience.
Meeting our many users’ needs is number one on our list of design principles. We can’t know every different setup a person might use while building our systems, but we can build them in a way that gives all of our users the greatest chance of success. Progressive enhancement lets us do this.
The article is full of great insights from a very large-scale web project.
Choosing the right input type for your form field.
I wrote a while back about how I switched from using a button to using a link for progressive disclosure patterns. That looks like it was a good move—if I use a button, I’d need to use
aria-controls and, as Heydon outlines here, the screen reader support is pants.
An in-depth look at the current Shadow DOM spec. It’s well-written but I don’t think this will really click with me until I start playing around with it for myself.
It’s good to see that the examples have some thought given to fallback content.
There’s also a corresponding tutorial on custom elements
Another dive into the archives of the www-talk mailing list. This time there are some gems about the origins of the
input element, triggered by the old
A great series of short videos from Marcy on web accessibility.