Friday, March 17th, 2017
Wednesday, March 8th, 2017
Following on from Ire’s post about linting HTML with CSS, here’s an older post from Ebay about how being specific with your CSS selectors can help avoid inaccessible markup getting into production.
Wednesday, March 1st, 2017
Jason revisits responsive images. On the whole, things are looking good when it comes to browser support, but he points out that
scrset’s precursor in CSS—
image-set seems to have dropped off the radar of most browser makers, which is a real shame.
Monday, February 20th, 2017
Jake is absolutely spot-on here. There’s been a lot of excited talk about adding an
h element to HTML but it all seems to miss the question of why the currently-specced outline algorithm hasn’t been implemented.
This is a common mistake in standards discussion — a mistake I’ve made many times before. You cannot compare the current state of things, beholden to reality, with a utopian implementation of some currently non-existent thing.
If you’re proposing something almost identical to something that failed, you better know why your proposal will succeed where the other didn’t.
Jake rightly points out that the first step isn’t to propose a whole new element; it’s to ask “Why haven’t browsers implemented the outline for sectioned headings?”
Friday, February 17th, 2017
Ever wondered what the most commonly used HTML elements are?
Monday, February 13th, 2017
Teaching in Porto, day one
Today was the first day of the week long “masterclass” I’m leading here at The New Digital School in Porto.
When I was putting together my stab-in-the-dark attempt to provide an outline for the week, I labelled day one as “How the web works” and gave this synopsis:
The internet and the web; how browsers work; a history of visual design on the web; the evolution of HTML and CSS.
There ended up being less about the history of visual design and CSS (we’ll cover that tomorrow) and more about the infrastructure that the web sits upon. Before diving into the way the web works, I thought it would be good to talk about how the internet works, which led me back to the history of communication networks in general. So the day started from cave drawings and smoke signals, leading to trade networks, then the postal system, before getting to the telegraph, and then telephone networks, the ARPANET, and eventually the internet. By lunch time we had just arrived at the birth of the World Wide Web at CERN.
It wasn’t all talk though. To demonstrate a hub-and-spoke network architecture I had everyone write down someone else’s name on a post-it note, then stand in a circle around me, and pass me (the hub) those messages to relay to their intended receiver. Later we repeated this exercise but with a packet-switching model: everyone could pass a note to their left or to their right. The hub-and-spoke system took almost a minute to relay all six messages; the packet-switching version took less than 10 seconds.
Over the course of the day, three different laws came up that were relevant to the history of the internet and the web:
- Metcalfe’s Law
The value of a network is proportional to the square of the number of users.
- Postel’s Law
Be conservative in what you send, be liberal in what you accept.
- Sturgeon’s Law
Ninety percent of everything is crap.
There were also references to the giants of hypertext: Ted Nelson, Vannevar Bush, and Douglas Engelbart—for a while, I had the mother of all demos playing silently in the background.
After a most-excellent lunch in a nearby local restaurant (where I can highly recommend the tripe), we started on the building blocks of the web: HTTP, URLs, and HTML. I pulled up the first ever web page so that we could examine its markup and dive into the wonder of the
A element. That led us to the first version of HTML which gave us enough vocabulary to start marking up documents:
li, and a few others. We went around the room looking at posters and other documents pinned to the wall, and starting marking them up by slapping on post-it notes with opening and closing tags on them.
At this point we had covered the anatomy of an HTML element (opening tags, closing tags, attribute names and attribute values) as well as some of the history of HTML’s expanding vocabulary, including elements added in HTML5 like
nav. But so far everything was to do with marking up static content in a document. Stepping back a bit, we returned to HTTP, and talked about difference between
POST requests. That led in to ways of sending data to a server, which led to
form fields and the many types of
inputs at our disposal:
range, and more.
With that, the day drew to a close. I feel pretty good about what we covered. There was a lot of groundwork, and plenty of history, but also plenty of practical information about how browsers interpret HTML.
With the structural building blocks of the web in place, tomorrow is going to focus more on the design side of things.
Sunday, January 29th, 2017
Monday, December 19th, 2016
Some great thoughts here from Francis on how crafting solid HTML is information architecture.
Wednesday, December 14th, 2016
Monday, November 21st, 2016
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?
Thursday, November 10th, 2016
Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.
Sunday, November 6th, 2016
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>
Tuesday, November 1st, 2016
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.
Tuesday, September 27th, 2016
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.
Sunday, September 25th, 2016
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.
Wednesday, August 31st, 2016
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.
Monday, August 29th, 2016
Wednesday, August 24th, 2016
Marking up help text in forms
Zoe asked a question on Twitter recently:
#a11y folks: Is it still best to put form field instruction/help text inside the <label>, or is aria-describedby sufficient nowadays?— Zoe M. Gillenwater (@zomigi) August 18, 2016
‘Sfunny—I had been pondering this exact question. In fact, I threw a CodePen together a couple of weeks ago.
Visually, both examples look the same; there’s a label, then a form field, then some extra text (in this case, a validation message).
The first example puts the validation message in an
em element inside the
label text itself, so I know it won’t be missed by a screen reader—I think I first learned this technique from Derek many years ago.
<div class="first error example"> <label for="firstemail">Email <em class="message">must include the @ symbol</em> </label> <input type="email" id="firstemail" placeholder="e.g. firstname.lastname@example.org"> </div>
The second example puts the validation message after the form field, but uses
aria-describedby to explicitly associate that message with the form field—this means the message should be read after the form field.
<div class="second error example"> <label for="secondemail">Email</label> <input type="email" id="secondemail" placeholder="e.g. email@example.com" aria-describedby="seconderror"> <em class="message" id="seconderror">must include the @ symbol</em> </div>
In both cases, the validation message won’t be missed by screen readers, although there’s a slight difference in the order in which things get read out. In the first example we get:
- Label text,
- Validation message,
- Form field.
And in the second example we get:
- Label text,
- Form field,
- Validation message.
In this particular example, the ordering in the second example more closely matches the visual representation, although I’m not sure how much of a factor that should be in choosing between the options.
Anyway, I was wondering whether one of these two options is “better” or “worse” than the other. I suspect that there isn’t a hard and fast answer.
Tuesday, August 9th, 2016
A great series of short videos from Marcy on web accessibility.