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
A great step-by-step walkthrough by Heydon of making an accessible to-do list, the “Hello World” of JavaScript frameworks.
There’s a lot of great knowledge in here that can be applied to plenty of other interface elements too.
Yesterday was a good day with Amber. She’s been marking up her CV and it was the perfect opportunity to take a deep dive into HTML.
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?”
(I added a small historical note in the comments pointing to the first occurrence of this proposal way back in 1991.)
Ever wondered what the most commonly used HTML elements are?
A handy prettifier for front-end code. Useful if you’re trying to find something inside code markup, CSS, or JavaScript that’s been minified.
Some great thoughts here from Francis on how crafting solid HTML is information architecture.
A really nice pattern, similar to one I wrote about a little while back. There’s also this little gem of an observation:
Progressive enhancement is also well-suited to Agile, as you can start with the core functionality and then iterate.
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.
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.
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.
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.
Here’s an interesting collection from Lea: small JavaScript libraries that do their configuration declaratively via HTML, rather than in JavaScript.
A great series of short videos from Marcy on web accessibility.