- Do not depend on color
- Do not block zoom
- Rediscover the alt attribute
- Add subtitles and captions to your videos
- Semantics = accessibility
- Use the right mark-up
- Use roles when necessary
- On hiding elements
- Follow web accessibility standards
- Audit and review
Another great deep dive by Heydon into a single interface pattern. This time it’s the tooltip, and its cousin, the toggletip.
There’s some great accessibility advice in here.
Dave explains how Jekyll Includes are starting to convert him to web components. The encapsulation is nice and neat. And he answers the inevitable “but why not use React?” question:
I like that Web Components are an entirely client-side technology but can be rendered server-side in existing tech stacks whether it’s Jekyll, Rails, or even some Enterprise Java system.
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.
This is an excellent proposal from Emil. If we can apply
display: contents to fieldsets, then we would finally have a way of undoing the byzantine browser styles that have hindered adoption of this element. This proposal also ensures backwards compatibility so there’d be no breakage of older sites:
The legacy appearance of fieldsets probably needs to be preserved for compatibility reasons. But
display: contentsis not supported in any old browsers, and is most likely used on exactly zero sites using the legacy look of fieldsets.
Whaddya say, browser makers?
A great one-page intro to microformats (h-card in particular), complete with a parser that exports JSON. Bookmark this for future reference.
Comparing different ways to hide content accessibly:
There are three reasons behind hiding content in an interface, and it’s important to identify what those reasons are, as they will correlate with the appropriate technique needed to hide such content.
- Temporarily Hidden Content
- Purposefully Visually Hidden Content
- Purposefully Visual-Only Content
There’s a lot of great knowledge in here that can be applied to plenty of other interface elements too.
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.
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.
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?”
Ever wondered what the most commonly used HTML elements are?
Some great thoughts here from Francis on how crafting solid HTML is information architecture.
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?
Really, really smart thinking from Paul here, musing on the power relationship between the creators of custom elements and the users of custom elements.
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>
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.