
Pub talk.
5th | 10th | 15th | 20th | 25th | 30th | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
12am | |||||||||||||||||||||||||||||||
4am | |||||||||||||||||||||||||||||||
8am | |||||||||||||||||||||||||||||||
12pm | |||||||||||||||||||||||||||||||
4pm | |||||||||||||||||||||||||||||||
8pm |
Pub talk.
Fortunately there’s a back-up on the Internet Archive, but this tale of Google’s overnight destruction of fourteen years of writing is truly infuriating.
When we use their services, we trust that companies like Google will preserve some of the most personal things we have to share. They trust that we will not read the fine print.
When you pitch your tent in someone else’s walled garden, they can tear down your home whenever they want.
Walking with @lottejackson and @hana_stevenson.
Sheep on the Downs.
Walking past the windmill.
Out on the Downs.
Advice from a dog.
On the train with Mia!
Paul argues that the biggest problems for interoperability on the web don’t come from support (or lack of support) for entire features, but from the frustrating inconsistencies when features land in different browsers at different times with different implementations:
- Platform inconsistencies hurt us more than big feature differences, we should start to try and prioritize aligning the platform
- We need better tools to help us understand what the inconsistencies are and guidance on how to manage them
- Developers should raise more issues to keep browser vendors accountable when there are differences
Listening to @seb_ly geek out at @AsyncJS in @68MiddleSt.
Sushi with @tea_ivanova and @lottejackson.
“Monetary Jack cheese” may be my favourite menu misspelling yet.
Monetary Jack should be the name of a sleazy financial advisor.
Sixteen years on, this still rings true.
I realized there are dot-com people and there are web people. Dot-com people work for start-ups injected with large Silicon Valley coin, they have options, they talk options, they dream options. They have IPOs. They’re richer after four months of “web” work than many web people who’ve been doing it since the beginning. They don’t have personal sites. They don’t want personal sites. They don’t get personal sites. They don’t get personal. Web people can tell you the first site they ever saw, they can tell you the moment they knew: This, This Is It, I Will Do This. And they pour themselves into the web, with stories, with designs, with pictures.
This is a wonderful way of progressively explaining the layered approach to building for the web that Charlotte was teaching in her Codebar workshop.
Great turnout for Homebrew Website Club in Brighton this evening!
Yves Peters examines the typography of Star Trek. Unlike Typeset In The Future, which looks at on-screen typography, this article dives into titles and promotional posters.
Turning https://principles.adactio.com/ into a progressive web app.
I love this back and forth between Brad and Jonathon. I think they’ve both got some good ideas:
Margaret Hamilton:
Never let fear get in the way! Don’t be afraid to continue even when things appear to be impossible, even when the so-called “experts” say it is impossible. Don’t be afraid to stand alone, to be different, to be wrong, to make and admit mistakes, for only those who dare to fail greatly can ever achieve greatly.
An entertaining presentation from South By Southwest on the UI element of last resort.
It’s funny because it’s true.
Fish’n’chips.
A good introduction to custom elements, one piece of the web components stack.
That said, when using custom elements—or anything involving JavaScript, for that matter—you should always design experiences for progressive enhancement, and plan for the possibility that JavaScript isn’t enabled or available.
Hmmm …that’s kind of hard when JavaScript is required to make custom elements work at all.
If you’re planning on giving Fractal a test drive, jump into this Slack channel. Mark and others will be able to help you out with any questions that aren’t covered in the docs.
It’s Homebrew Website Club tomorrow evening …in Brighton and now London too!
https://indieweb.org/events/2016-07-27-homebrew-website-club
Salads and bread.
I’ve noticed a few nice examples of motion design on the web lately.
The Cloud Four gang recently redesigned their site, including a nice little animation on the home page.
Malcolm Gladwell has a new podcast called Revisionist History. The website for the podcast is quite lovely. Each episode is illustrated with an animated image. Lovely!
If you want to see some swishy animations triggered by navigation, the waaark websites has them a-plenty. Personally I find the scroll-triggered animations on internal pages too much to take (I have yet to find an example of scrolljacking that doesn’t infuriate me). But the homepage illustrations have some lovely subtle movement.
When it comes to subtlety in animation, my favourite example comes from Charlotte. She recently refactored the homepage of the website for the Leading Design conference. It originally featured one big background image. Switching over to SVG saved a lot of bandwidth. But what I really love is that the shapes in the background are now moving …ever so gently.
It’s like gazing at a slow-motion lava lamp of geometry.
These design principles are meant to guide the ongoing design and development of AMP. They should help us make internally consistent decisions.
I’ve added these to my collection of design principles.
Naming things with @lottejackson and @tea_ivanova.
Charlotte did a fantastic job putting this workshop together on the weekend. It was inspiring!
Here’s Daphne!
ES6 introduced a whole bunch of new features to JavaScript. One of those features is the class
keyword. This introduction has been accompanied by a fair amount of concern and criticism.
Here’s the issue: classes in JavaScript aren’t quite the same as classes in other programming languages. In fact, technically, JavaScript doesn’t really have classes at all. But some say that technically isn’t important. If it looks like a duck, and quacks like a duck, shouldn’t we call it a duck even if technically it’s somewhat similar—but not quite the same—species of waterfowl?
The argument for doing this is that classes are so familiar from other programming languages, that having some way of using classes in JavaScript—even if it isn’t technically the same as in other languages—brings a lot of benefit for people moving over to JavaScript from other programming languages.
But that comes with a side-effect. Anyone learning about classes in JavaScript will basically be told “here’s how classes work …but don’t look too closely.”
Now if you believe that outcomes matter more than understanding, then this is a perfectly acceptable trade-off. After all, we use computers every day without needing to understand the inner workings of every single piece of code under the hood.
It doesn’t sit well with me, though. I think that understanding how something works is important (in most cases). That’s why I favour learning underlying technologies first—HTML, CSS, JavaScript—before reaching for abstractions like frameworks and libraries. If you understand the way things work first, then your choice of framework, library, or any other abstraction is an informed choice.
The most common way that people refer to the new class
syntax in JavaScript is to describe it as syntactical sugar. In other words, it doesn’t fundamentally introduce anything new under the hood, but it gives you a shorter, cleaner, nicer way of dealing with objects. It’s an abstraction. But because it’s an abstraction taken from other programming languages that work differently to JavaScript, it’s a bit of fudge. It’s a little white lie. The class
keyword in JavaScript will work just fine as long as you don’t try to understand it.
My personal opinion is that this isn’t healthy.
I’ve come across two fantastic orators who cemented this view in my mind. At Render Conf in Oxford earlier this year, I had the great pleasure of hearing Ashley Williams talk about the challenges of teaching JavaScript. Skip to the 15 minute mark to hear her introduce the issues thrown up classes in JavaScript.
More recently, the mighty Kyle Simpson was on an episode of the JavaScript Jabber podcast. Skip to the 17 minute mark to hear him talk about classes in JavaScript.
(Full disclosure: Kyle also some very kind things about some of my blog posts at the end of that episode, but you can switch it off before it gets to that bit.)
Both Ashley and Kyle bring a much-needed perspective to the discussion of language design. That perspective is the perspective of a teacher.
In his essay on W3C’s design principles, Bert Bos lists learnability among the fundamental driving forces (closely tied to readability). Learnability and teachability are two sides of the same coin, and I find it valuable to examine any language decisions through that lens. With that mind, introducing a new feature into a language that comes with such low teachability value as to warrant a teacher actively telling a student not to learn how things really work …well, that just doesn’t seem right.
When I designed the Science Hack Day logo, I never expected to one day see it recreated with florescent E. coli.
Bring on the dancing girls!
Having a pint and a read while I wait for the doors to open for @wordridden’s dance performance this evening.
The story of Science Hack Day …as told in the Proceedings of the National Academy of Sciences of the United States of America!
(a PDF version is also available)
The trouble with overflow menus is that you didn’t actually take anything away, you just obnoxiously obfuscated it.
Words of warning and advice from Daniel.
Instead of prioritizing, we just sweep complexity under the rug and pretend that it doesn’t exist.
Halibut.
Slip sole in seaweed butter.
Pork belly.
Miso-glazed mackerel.
The Big Lebrewski.
Starting @wordridden’s birthday evening out with some oysters and cocktails.
Let’s share what we know @CodebarBrighton.
Workshopping.
Ready to start @lottejackson’s full day Codebar workshop in @68MiddleSt.
…out of the office.
In the office…
A nice little walkthrough of a straightforward Service Worker for a content-based site, like a blog.
The @Clearleft gang are getting a demo of http://fractal.build/ from @allmarkedup.
Mark sets the scene for Fractal, the fantastic tool he’s built for generating pattern libraries.
This 1.0 release is just a start; it hopefully provides a solid foundation on which we (and anyone else who wants to contribute) can build and expand on in the future.
Exciting!
This is the tool that we use at Clearleft to generate pattern libraries. It’s pretty damn cool. Mark built it. It’s pretty damn cool.
The life cycle of a Service Worker—with all its events and states—is the one bit that I’ve never paid that much attention to. My eyes just glaze over when it comes to installation, registration, and activation. But this post explains the whole process really clearly. Now it’s starting to make sense to me.
I’m not a fan of the checklist approach to accessibility, but this checklist of checklists makes for a handy starting point and it’s segmented by job role. Tick all the ones that apply to you, and this page will generate a list for you to copy and paste.
Daily oyster on the beach.
Mauve triplets in the @Clearleft office: @PaulRobertLloyd, @HarryBr, and @Boxman.
Well, this is interesting! It turns out you can turn your laptop into a beacon for broadcasting a URL to devices that support The Physical Web.
Fight the scourge of performance-killing redirect-laden t.co links in Twitter’s web interface with this handy Chrome extension.
A newsletter dedicated to all things related to design systems, style guides, and pattern libraries.
Slowly but surely the web is switching over to HTTPS. The past year shows a two to threefold increase.
I think Tyler’s onto something here:
I noticed three qualities that recurred in different combinations. Without at least two, the projects seemed doomed to failure.
- User-Friendly
- Collaborative
- Integrated
I certainly think there’s a difference in how you approach a pattern library intended as a deliverable (something we do a lot of at Clearleft) compared to building a pattern library for an ongoing ever-evolving product.
Phil’s write-up of teaching web development to beginners is immensely valuable in the run-up to the Codebar workshop that Charlotte is running this weekend. This bit gave both us a real “a-ha!” moment:
It only occurred to me at the end that I should have encouraged the students to try and fix each other’s bugs. If anyone had problems I’d go round and help people and often it’d be a little typo somewhere. Helping each other would acknowledge that this is entirely normal and that a second pair of eyes is often all that’s needed.
Enjoyed @FryRsquared’s “The Joy Of Data”, but a bit of a shame that Paul Baran didn’t get a mention with Donald Davies for packet switching.
Summer feast.
Shrimp.
Summertime.
Shamefully, I haven’t been doing one-to-ones with my front-end dev colleagues at Clearleft, but I’m planning to change that. This short list of starter questions from Lara will prove very useful indeed.
Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.
Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.
Cooling down on the beach.
Andrew picks out his favourite bits from this year’s Google I/O, covering web payments, CSS containment, and—of course—Service Workers and progressive web apps, although he does note (and I concur):
I wish Google would focus as much attention on ‘normal’ sites that perform navigations as they do on so called ‘app-shell’ (which is just a new name for single-page apps, as far as I can tell), but then many people will be building SPAs and these recipes will make those apps fly. In news publishing we seem to flip flop between traditional page navigations and SPAs, but I’ve never found a SPA news site (or a native app) that I really like more than a normal website. Maybe a really good progressive web app will change that. But I’m not convinced.
Still, as he says:
All this really just underscores how flexible ServiceWorker is and that with it we can disagree on what the right solution is, but we can all get what we want anyway.
A terrific rundown of all your options when it comes to web font loading.
So happy that @Tea_Ivanova has joined @Clearleft!
Jason looks at the business reasons for and against building progressive web apps. In short, there’s everything to gain and nothing to lose.
Seriously, why would you not add a Service Worker and a manifest file to your site? (assuming you’re already on HTTPS)
Having a post-work beer on the beach.
I lived in Freiburg for years but I never knew of this story.
Thank you, @Vasilis!
Barbecued Thai chicken.
Grilling chicken and peppers.
Migas.
* * *
Some days you T the P, other days you’re the P getting T’d.
Two weeks ago, writer and artist Dennis Cooper was checking his Gmail when something peculiar happened: the page was refreshed and he was notified that his account had been deactivated – along with the blog that he’d maintained for 14 years.
This is why the Indie Web exists.
His advice to other artists who work predominantly online is to maintain your own domain and back everything up.
The roadmap for progressive web apps from Microsoft; not just their support plans, but also some ideas for distribution.
From the ARPANET to the internet, this is a great history of the Domain Name System:
Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularly given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.
…and Anna describes the process of creating the Snyk style guide.
Susan describes the process behind creating Bocoup’s style guide…
A walkthrough of what’s new in Pattern Lab 2. It’s really interesting to see the convergent evolution of ideas here with what’s brewing in Fractal at Clearleft.
This is relevant to my interests because I think I’m supposed to be a senior developer. Or maybe a technical director. I’m really not sure (job titles suck).
Anyway, I very much appreciate the idea that a technical leadership position isn’t just about technical skills, but also communication and connectedness.
When we boiled down what we’re looking for, we came away with 12 traits that divide pretty cleanly along those three areas of responsibility: technical capability, leadership, and community.
For someone like me with fairly mediocre technical capability, this is reassuring.
Now if I only I weren’t also mediocre in those other areas too…
A handy tool for testing the legibility of different typefaces under all sorts of conditions.
We’re getting a bike shed at @Clearleft soon—people are literally bike-shedding in Slack.
Here’s a fun game to help practice those CSS selectors.
Hacking and blogging at Homebrew Website Club Brighton.
September 24th and 25th—those are the dates you should put in your diary. That’s when this year’s Indie Web Camp Brighton is happening.
Once again it’ll be at 68 Middle Street, home to Clearleft. You can register for free now, and then add your name to the list of participants on the wiki.
If you haven’t been to an Indie Web Camp before, it’s a very straightforward proposition. The idea is that you should have your own website. That’s it. Every thing else is predicated on that. So while there’ll be plenty of discussions, demos, and designs, they’re all in service to that fundamental premise.
The first day of an Indie Web Camp is like a BarCamp. We make a schedule grid at the start of the day and people organise topics by room and time slot. It sounds chaotic. It is chaotic. But it works surprisingly well. The discussions can be about technologies, or interfaces, or ideas, or just about anything really.
The second day is for making. After the discussions from the previous day, most people will have a clear idea at this point for something they might want to do. It might involve adding some new technology to their website, or making some design changes, or helping build a tool. For people starting from scratch, this is the perfect time for them to build and launch a basic website.
At the end of the second day, everyone demos what they’ve done. I’m always amazed by how much people can accomplish in just one weekend. There’s something about having other people around to help you that makes it super productive.
You might be thinking “but I’m not a coder!” Don’t worry—there’ll be plenty of coders there so you can get their help on whatever you might decide to do. If you’re a designer, your skills will be in high demand by those coders. It’s that mish-mash of people that makes it such a fun gathering.
Last year’s Indie Web Camp Brighton was lots of fun. Let’s make Indie Web Camp Brighton 2016 even better!
Did you know that Abby Covert’s book is available online in its gloriously hyperlinked entirety?
Hot on the heels of an accessible toggle, here’s an accessible modal dialog script.
My mise en place brings all the garçons to the yard.
One sleep until Homebrew Website Club Brighton
https://indieweb.org/events/2016-07-13-homebrew-website-club#Brighton
I really, really like what Ember is aiming for here:
First, we deliver the raw content, ensuring those on slow connections or without JavaScript get they’re after as soon as possible. Next, we load the minimum set of JavaScript needed to interactivity for that page, keeping transfer time and parsing time low. Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data.
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
Simon’s in-depth report on the Decentralized Web Summit.
Moonscape is a free and freely shareable high-definition documentary about the first manned Moon landing. Funded and produced by space enthusiasts from all over the world, it shows the full Apollo 11 landing and moonwalk, using only the original audio, TV and film footage and the original photographs, rescanned and restored from the best available sources, with full English subtitles (other languages will follow).
A way of declaring the scope of an element’s layout and paint styles, which browsers can then use as a hint to optimise performance. It’s already shipping in Chrome and Opera.
I’ve always loved the way that Edward Tufte consistently uses Bembo to typeset his books. Here’s a version made for screen and freely licensed.
An attempt to crack the element query nut. It relies on executing JavaScript at runtime so it doesn’t feel production-ready to me unless you’re already relying on JavaScript to render or style your content. Still, there’s a lot of good thinking has gone into the syntax—it’s worth investigating for that reason alone.
Depending on how you’re currently structuring your CSS and class attributes, web components might not make all that much of a difference to your workflow.
Gotta catch ’em all.
A handy Chrome extension to simulate different kinds of visual impairment.
My buffer overfloweth.
Sunday roast.
Soul of the City Choir.
Flatiron steak with toasted spice vinaigrette.
Tomato and red onion salad.
Huxley!
End of week stand-down at @Clearleft …featuring Huxley!
Margaret Hamilton’s code after scanning and transcribing.
The code is commented too. But there might still be issues.
You can think of this as a short book or a long article, but either way it’s a handy overview of typography on the web:
A concise, referential guide on best web typographic practices.
Mind you, I take issue with this assertion:
Establishing a vertical rhythm is simple.
An alternative to using the :checked
pseudo-class for sprinkling in some behaviour—you can use the :target
pseudo-class. It might mess up the browser history though.
Ten of us reminisce about where we were and what we were doing a decade ago.
Ten years ago I was writing on my blog. Lots of other people were writing on their blogs back then too. That would soon change, though. Twitter and Facebook were picking up steam and soon they’d be luring bloggers away with enticing and seductive short-form convenience. I’ve stubbornly continued writing on my own site. I fully intend to keep on writing there for the next ten years too.
I can’t wait for this documentary to come out (I linked to its website a while back).
When I was moderating that panel at the Progressive Web App dev Summit, I brought up this point about twenty minutes in:
Alex, in your talk yesterday you were showing the AMP demo there with the Washington Post. You click through and there’s the Washington Post AMP thing, and it was able to install the Service Worker with that custom element. But I was looking at the URL bar …and that wasn’t the Washington Post. It was on the CDN from AMP. So I talked to Paul Backaus from the AMP team, and he explained that it’s an
iframe
, and using aniframe
you can install a Service Worker from somewhere else.
Alex and Emily explained that, duh, that’s the way iframe
s work. It makes sense when you think about it—an iframe
is pretty much the same as any other browser window. Still, it feels like it might violate the principle of least surprise.
Let’s say you followed my tongue-in-cheek advice to build a progressive web app store. Your homepage might have the latest 10 or 20 progressive web apps. You could also include 10 or 20 iframe
s so that those sites are “pre-installed” for the person viewing your page.
Enough theory. Here’s a practical example…
Suppose you’ve never visited the website for my book, html5forwebdesigners.com (if you have visited it, and you want to play along with this experiment, go to your browser settings and delete anything stored by that domain).
You happen to visit my website adactio.com. There’s a little blurb buried down on the home page that says “Read my book” with a link through to html5forwebdesigners.com. I’ve added this markup after the link:
<iframe src="https://html5forwebdesigners.com/iframe.html" style="width: 0; height: 0; border: 0">
</iframe>
That hidden iframe
pulls in an empty page with a script
element:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>HTML5 For Web Designers</title>
<script>
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/serviceworker.js');
}
</script>
</head>
</html>
That registers the Service Worker on my book’s site which then proceeds to install all the assets it needs to render the entire site offline.
There you have it. Without ever visiting the domain html5forwebdesigners.com, the site has been pre-loaded onto your device because you visited the domain adactio.com.
A few caveats:
I had to relax the Content Security Policy for html5forwebdesigners.com to allow the iframe
to be embedded on adactio.com:
Header always set Access-Control-Allow-Origin: "https://adactio.com"
If your browser’s settings has “Block third-party cookies and site data” selected in the preferences, the iframe
-invoked Service Worker won’t install:
Uncaught (in promise) DOMException: Failed to register a ServiceWorker: The user denied permission to use Service Worker.
The example I’ve put together here is relatively harmless. But it’s possible to imagine more extreme scenarios. Imagine there’s a publishing company that has 50 websites for 50 different publications. Each one of them could have an empty page waiting to be embedded via iframe
from the other 49 sites. You only need to visit one page on one of those 50 sites to have 50 Service Workers spun up and caching assets in the background.
There’s the potential here for a tragedy of the commons. I hope we’ll be sensible about how we use this power.
Just don’t tell the advertising industry about this.
Spaghetti with grilled sardines.
The second book in Adam Scott’s series on ethical web development is a nice quick read, covering URL design, Service Workers, and performance.
Seafood tacos.
This sixteen year old cool URI has not changed. I think this idea of domains entering an archive state is worth pursuing.
Also, I love the science fictional footnote “Note for readers after 2100”.
Tomato salad.
Grilled peppers and courgettes.
Grilled lamb neck and red onion.
Huxley!
Loving the subtlety of the motion design that @lottejackson has added to http://leadingdesignconf.com/
OH: “I don’t think it’s a can of worms—it’s the Ark of the Covenant.”
Dave is making a nifty in-browser game that you can play by yourself or in co-operative mode. If your device has a gyroscope, you can use that to aim. Very cool!
(And it looks like it’s all set to become a progressive web app once it’s running on HTTPS.)
The World Wide Web, with all of its pages, blogs and so on- has allowed human expression in ways that would have been uneconomic and out of reach before. The most dramatic effect has been this ability for almost anyone to express himself or herself whenever they want to- and potentially be heard by many others.
Vint Cerf there, taking part in this wide-ranging discussion with, among others, Kevin Kelly and Bob Metcalfe.
The introduction leans a bit too heavily on Nicholas Carr for my liking, but it ends up in a good place.
The internet connects us cognitively and becomes a membrane through which our minds can interact, manifesting a whole new iteration of our species, who have begun to exist in a connected symbiotic relationship with technology.
The internet is the first technology we have created, that makes us more human.
Homemade pappardelle with pig cheek ragu.
Adam Silver is writing a book on forms—you may be familiar with his previous book on maintainable CSS. In a recent article (that for some reason isn’t on his blog), he looks at markup patterns for search forms and advocates that we should always use a label. I agree. But for some reason, we keep getting handed designs that show unlabelled search forms. And no, a placeholder is not a label.
I had a discussion with Mark about this the other day. The form he was marking up didn’t have a label, but it did have a button with some text that would work as a label:
<input type="search" placeholder="…">
<button type="submit">
Search
</button>
He was wondering if there was a way of using the button’s text as the label. I think there is. Using aria-labelledby
like this, the button’s text should be read out before the input field:
<input aria-labelledby="searchtext" type="search" placeholder="…">
<button type="submit" id="searchtext">
Search
</button>
Notice that I say “think” and “should.” It’s one thing to figure out a theoretical solution, but only testing will show whether it actually works.
The W3C’s WAI tutorial on labelling content gives an example that uses aria-label
instead:
<input type="text" name="search" aria-label="Search">
<button type="submit">Search</button>
It seems a bit of a shame to me that the label text is duplicated in the button
and in the aria-label
attribute (and being squirrelled away in an attribute, it runs the risk of metacrap rot). But they know what they’re talking about so there may well be very good reasons to prefer duplicating the value with aria-label
rather than pointing to the value with aria-labelledby
.
I thought it would be interesting to see how other sites are approaching this pattern—unlabelled search forms are all too common. All the markup examples here have been simplified a bit, removing class
attributes and the like…
The BBC’s search form does actually have a label:
<label for="orb-search-q">
Search the BBC
</label>
<input id="orb-search-q" placeholder="Search" type="text">
<button>Search the BBC</button>
But that label is then hidden using CSS:
position: absolute;
height: 1px;
width: 1px;
overflow: hidden;
clip: rect(1px, 1px, 1px, 1px);
That CSS—as pioneered by Snook—ensures that the label is visually hidden but remains accessible to assistive technology. Using something like display: none
would hide the label for everyone.
Medium wraps the input
(and icon) in a label
and then gives the label
a title
attribute. Like aria-label
, a title
attribute should be read out by screen readers, but it has the added advantage of also being visible as a tooltip on hover:
<label title="Search Medium">
<span class="svgIcon"><svg></svg></span>
<input type="search">
</label>
This is also what Google does on what must be the most visited search form on the web. But the W3C’s WAI tutorial warns against using the title
attribute like this:
This approach is generally less reliable and not recommended because some screen readers and assistive technologies do not interpret the
title
attribute as a replacement for the label element, possibly because thetitle
attribute is often used to provide non-essential information.
Twitter follows the BBC’s pattern of having a label but visually hiding it. They also have some descriptive text for the icon, and that text gets visually hidden too:
<label class="visuallyhidden" for="search-query">Search query</label>
<input id="search-query" placeholder="Search Twitter" type="text">
<span class="search-icon>
<button type="submit" class="Icon" tabindex="-1">
<span class="visuallyhidden">Search Twitter</span>
</button>
</span>
Here’s their CSS for hiding those bits of text—it’s very similar to the BBC’s:
.visuallyhidden {
border: 0;
clip: rect(0 0 0 0);
height: 1px;
margin: -1px;
overflow: hidden;
padding: 0;
position: absolute;
width: 1px;
}
That’s exactly the CSS recommended in the W3C’s WAI tutorial.
Flickr have gone with the aria-label
pattern as recommended in that W3C WAI tutorial:
<input placeholder="Photos, people, or groups" aria-label="Search" type="text">
<input type="submit" value="Search">
Interestingly, neither Twitter or Flickr are using type="search"
on the input
elements. I’m guessing this is probably because of frustrations with trying to undo the default styles that some browsers apply to input type="search"
fields. Seems a shame though.
Instagram also doesn’t use type="search"
and makes no attempt to expose any kind of accessible label:
<input type="text" placeholder="Search">
<span class="coreSpriteSearchIcon"></span>
Same with Tumblr:
<input tabindex="1" type="text" name="q" id="search_query" placeholder="Search Tumblr" autocomplete="off" required="required">
…although the search form itself does have role="search"
applied to it. Perhaps that helps to mitigate the lack of a clear label?
After that whistle-stop tour of a few of the web’s unlabelled search forms, it looks like the options are:
label
element,aria-label
attribute,title
attribute, oraria-labelledby
.But that last one needs some testing.
Update: Emil did some testing. Looks like all screen-reader/browser combinations will read the associated text.
Saucer over Brighton.
Kara-age.
Spicy miso ramen.
A cautionary tale of digital preservation.
.generation is a short film that intimately documents three millennials in the year 2054 - uncovering their relationships with technology in the aftermath of the information age.