What it says on the tin—a few suggestions to ensure the accessibility of your site.
Sunday, January 21st, 2018
Friday, December 29th, 2017
Everything you ever wanted to know about the
title attribute in HTML.
What’s hot: using
What’s not: using
title on anything else.
Thursday, December 7th, 2017
I like this distinction between coders and developers.
The Coder is characterized by his proficiency in a narrow range of chosen skills.
By contrast the Developer’s single greatest skill is in being an applied learner.
I’m definitely not a coder. Alas, by this criterion, I’m also not a developer (because I do not pick things up fast):
Quite simply the Developer has a knack for grokking new [languages|frameworks|platforms] and becoming proficient very quickly.
I prefer Charlie’s framing. It’s not about speed, it’s about priorities:
I’m not a “developer” in that I’m obsessed with code and frameworks. I’m a “developer” as in I develop the users experience for the better.
Thursday, October 5th, 2017
James has been tweaking the accessibility of his site navigation. I’m looking forward to the sequel.
Tuesday, July 4th, 2017
Here’s an interesting proposal to slightly amend the semantics of the
small element so it could apply to the use-case that
hgroup was trying to cover.
Sunday, June 18th, 2017
A great one-page intro to microformats (h-card in particular), complete with a parser that exports JSON. Bookmark this for future reference.
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?”
Monday, January 2nd, 2017
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.
Thursday, May 26th, 2016
Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.
Sunday, April 24th, 2016
Psst… Jeremy! Right now you’re getting notified every time something is posted to Slack. That’s great at first, but now that activity is increasing you’ll probably prefer dialing that down.
Why does everyone always look at me? I know I’m a chalkboard and that’s my job, I just wish people would ask before staring at me. Sometimes I don’t have anything to say.
I’m Little MOO - the bit of software that will be managing your order with us. It will shortly be sent to Big MOO, our print machine who will print it for you in the next few days. I’ll let you know when it’s done and on it’s way to you.
It looks like you’re writing a letter.
Your quest is to find the Warlock’s treasure, hidden deep within a dungeon populated with a multitude of terrifying monsters. You will need courage, determination and a fair amount of luck if you are to survive all the traps and battles, and reach your goal — the innermost chambers of the Warlock’s domain.
Welcome to Adventure!! Would you like instructions?
I am a lead pencil—the ordinary wooden pencil familiar to all boys and girls and adults who can read and write.
ÆLFRED MECH HET GEWYRCAN
Ælfred ordered me to be made
I have marked up the protagonist of each conversation using the
cite element. There is a long-running dispute over the use of this element. In HTML 4.01 it was perfectly fine to use
cite to mark up a person being quoted. In the HTML Living Standard, usage has been narrowed:
citeelement represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc). This can be a work that is being quoted or referenced in detail (i.e. a citation), or it can just be a work that is mentioned in passing.
A person’s name is not the title of a work — even if people call that person a piece of work — and the element must therefore not be used to mark up people’s names.
In the examples above, it’s pretty clear that I, Pencil and Warlock Of Firetop Mountain are valid use cases for the
cite element according to the HTML5 definition; they are titles of works. But what about Clippy or Little Moo or Slackbot? They’re not people …but they’re not exactly titles of works either.
If I were to mark up a dialogue between Eliza and a human being, should I only mark up Eliza’s remarks with
cite? In text transcripts of conversations with Alexa, Siri, or Cortana, should only their side of the conversation get attributed as a source? Or should they also be written without the
cite element because it must not be used to mark up people’s names …even though they are not people, according to conventional definition.
It’s downright botist.
Wednesday, March 2nd, 2016
There is one truism that has been constant throughout my career on the web, and it’s this: naming things is hard.
Trent talks about the strategies out there for naming things. He makes specific mention of Atomic Design, which as Brad is always at pains to point out, is just one way of naming things: atoms, molecules, organisms, etc.
In some situations, having that pre-made vocabulary is perfect. In other situations, I’ve seen it cause all sorts of problems. It all depends on the project and the people.
Personally, I like the vocabulary to emerge from the domain knowledge of the people on the project. Building a newspaper website? Use journalism-related terms. Making a website about bicycles? Use bike-related terms.
Wednesday, December 9th, 2015
The best ARIA role is the one you don’t need to use.
Saturday, November 7th, 2015
This is such an incredibly useful resource by Steve and Léonie: documenting how multiple screen readers handle each and every element in HTML.
It’s a work in progress, but it’s definitely one to remember the next time you’re thinking “I wonder how screen readers treat this markup…”
Wednesday, September 9th, 2015
Here’s a classic. David Siegel—of Creating Killer Websites fame—outlines exactly why he turned his back on that 1×1 spacer .gif trick he invented.
Tuesday, March 31st, 2015
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
Tuesday, December 9th, 2014
With all my talk about extending existing elements instead of making new ones, I was reminded of one of my favourite examples of custom elements in action: Github’s extensions of the
Saturday, November 22nd, 2014
A great presentation on web components by Marcy, with an emphasis on keeping them accessible.
Wednesday, October 22nd, 2014
A question of markup
I’m really sorry it’s taken me so long to write back to you (over a month!)—I’m really crap at email.
I’m writing to you hoping you can help me make my colleagues take html5 “seriously”. They have read your book, they know it’s the “right” thing to do, but still they write !doctype HTML and then div, div, div, div, div…
Now, if you could provide me with some answers to their “why bother?- questions” would be really appreciated.
I have to be honest, I don’t think it’s worth spending lots of time agonising over what’s the right element to use for marking up a particular piece of content.
That said, I also think it’s lazy to just use divs and spans for everything, if a more appropriate element is available.
Paragraphs, lists, figures …these are all pretty straightforward and require almost no thought.
Deciding whether something is a section or an article, though …that’s another story. It’s not so clear. And I’m not sure it’s worth the effort. Frankly, a div might be just fine in most cases.
For example, can one assume that in the future we will be pulling content directly from websites and therefore it would be smart to tell this technology which content is the article, what are the navigation and so on?
There are some third-party tools (like Readability) that pay attention to the semantics of the elements you use, but the most important use-case is assistive technology. For tools such as screen readers, there’s a massive benefit to marking up headings, lists, and other straightforward elements, as well as some of the newer additions like nav and main.
But for many situations, a div is just fine. If you’re just grouping some stuff together that doesn’t have a thematic relation (for instance, you might be grouping them together to apply a particular style), then div works perfectly well. And if you’re marking up a piece of inline text and you’re not emphasising it, or otherwise differentiating it semantically, then a span is the right element to use.
So for most situations, I don’t think it’s worth overthinking the choice of HTML elements. A moment or two should be enough to decide which element is right. Any longer than that, and you might as well just use a div or span, and move on to other decisions.
But there’s one area where I think it’s worth spending a bit longer to decide on the right element, and that’s with forms.
When you’re marking up forms, it’s really worth making sure that you’re using the right element. Never use a span or a div if you’re just going to add style and behaviour to make it look and act like a button: use an actual button instead (not only is it the correct element to use, it’s going to save you a lot of work).
Likewise, if a piece of text is labelling a form control, don’t just use a span; use the label element. Again, this is not only the most meaningful element, but it will provide plenty of practical benefit, not only to screen readers, but to all browsers.
So when it comes to forms, it’s worth sweating the details of the markup. I think it’s also worth making sure that the major chunks of your pages are correctly marked up: navigation, headings. But beyond that, don’t spend too much brain energy deciding questions like “Is this a definition list? Or a regular list?” or perhaps “Is this an aside? Or is it a footer?” Choose something that works well enough (even if that’s a div) and move on.
There’s a bit of a contradiction to what I’m saying here.
On the one hand, I’m saying you should usually choose the most appropriate element available because it will save you work. In other words, it’s the lazy option. Be lazy!
On the other hand, I’m saying that it’s worth taking a little time to choose the most appropriate element instead of always using a div or a span. Don’t be lazy!
I guess what I’m saying is: find a good balance. Don’t agonise over choosing appropriate HTML elements, but don’t just use divs and spans either.
Hope that helps.
Hmmm… you know, I think I might publish this response on my blog.
Friday, August 15th, 2014
Remember when I was talking about refactoring the markup for Code for America? Well, it turns out that Heydon Pickering is way ahead of me.
He talks about the viewpoint of a writer (named Victoria) who wants to be able to write in Markdown, or HTML, or a textarea, without having to add classes to everything. That’s going to mean more complex CSS, but it turns out that you can do a lot of complex things in CSS without using class selectors.
There are slides.