Blue Beanie Day in support of web standards is celebrated around the world on November 30. Hey, that’s today.
So how can you help? Glad you asked! Take a self-portrait wearing a blue beanie (toque, tuque, cap) and post it to your website and social media channels with the hashtag #BlueBeanieDay.
And for that extra extra, slap a blue beanie on your web and social media avatars, as well.
Do this on November 30 as a reminder to design accessible, web-standards-based websites 365 days a year. Thank you. Love you.
It’s one thing to seek diverse talent to add to your team, another to retain the people you’ve hired. Why do so many folks we bring in to add depth and breadth of experience to our design and business decision-making process end up leaving?
Hear thoughtful, useful answers to this question and other mysteries of UX design and tech recruitment in this Live User Defenders podcast video recorded at An Event Apart Denver. Featuring Mina Markham, Farai Madzima, and Derek Featherstone. Discussion led by Jason Ogle. Thanks to Todd Libby for the 4K recording.
The last An Event Apart conference of 2019 begins next week in San Francisco.
“You don’t get to decide which platform or device your customers use to access your content: they do.”—Karen McGrane, Content Strategy for Mobile
“When a person tells you that you hurt them, you don’t get to decide that you didn’t.”—Louis C.K.
“Discomfort with others’ burdens has no place in good design.”—Mica McPheeters
“Historically, teams simply have not been trained to imagine their users as different from themselves—not really, not in any sort of deep and empathetic way.”—Sara Wachter-Boettcher
“USER CUSTOMIZATION” on the web hearkens back to the deluded old days of portals, when companies imagined you’d start your daily “net browsing” session by “logging on” to their website’s homepage. Customization was among the chief (largely imaginary) inducements for you to return to their “start” page and not others.
The thought was that changing the fonts and color scheme would make their page feel more like your home. After all, Windows 3.1 users seemed to enjoy switching their home computers to “Black Leather Jacket” or other personalized settings—if only as an escape from the computer environment at work, where their bosses enforced a rigid conformist look and feel, and dictated which software and fonts were allowed on your workstation. Surely, the thinking went, pioneering web explorers would demand custom accommodations as plush as those found in the best-selling operating system.
MySpace … and beyond!
This fetish for pointless customization—customization for its own sake—persisted through the MySpace era, where it actually made sense as an early mass offering of page owner personal branding. Its descendants are the WordPress, Tumblr, and Squarespace themes that create a professional appearance for the websites of individuals and small businesses. This is a positive (and inevitable) evolution, and a perfect denouement for the impulse that began life as “user customization.”
But, except on a few quirky personal sites like Jeremy Keith’s adactio.com, where sidebar customization widgets live on as a winking look back to the early days of personal content on the web, user customization for its own sake has long been out of favor—because experience, referrer logs, and testing have long shown that visitors don’t bother with it.
Perhaps that’s because people don’t really visit websites any more. They drop in quickly on a page found by search or referred by social media, scan quickly and incompletely, and leave, mostly never to return.
When you use Google, Bing, or Duck Duck Go to find out what a knocking sound in your radiator or a pang in your gulliver might mean, you scan for the information you sought, find it (if you’re lucky), and leave. The notion that most sites could get you to come back by offering you the ability to change fonts or colors is self-evidently absurd. Why bother?
Readability and font customization
Ah, but there’s another kind of user customization that I’m hoping and betting will make a comeback: a subtle, inclusive sort of customization that doesn’t exist for its own sake, but rather to serve.
Our glowing, high-density screens are great for watching Westworld, but a bit too bright and backlit for prolonged reading compared to the paper they’re intended to replace. But screens have one advantage over printed books (besides storage and portability): namely, they offer accessibility features a printed book never could.
I once received an architecture book written by an important scholar, but I was never able to read it, because the layout was terrible: the type was too small, the leading too tight, and (most of all) the measure far too wide to be readable. If an ebook version had been available, I’d have purchased it; but this was before the mass market availability of ebooks, and the tome is now out of print. I own it, but I shall never be able to read it.
It wouldn’t be a problem with an ebook, because all ebooks offer readers the ability to alter the contrast and the basic theme (white text on black, black text on white, dark text on a light background); all ebooks offer the ability to adjust font size; and most include the ability to change fonts. Why do Kindle and iBooks offer this flexibility? Because it helps readers who might otherwise not be able to read the text comfortably—or at all. This isn’t customization for its own sake. It’s customization for the sake of inclusion.
The grey lady and user customization
Now notice who else provides some of this same inclusive customization function: the mighty New York Times.
People in our industry tend to repeat things they’ve heard as if they are eternal verities—when the real truth is that each digital experience is different, each person who engages with it is different, and each device used to access each experience brings its own strengths and limitations.
A font size widget may smell like the pointless old-fashioned “user customization” to be found on half the unvisited sites in the Wayback Machine, but it is the very opposite of such stuff. Even mighty responsive design benefits from offering a choice of font sizes—because there are just too many complications between too many screen sizes and device features and too many pairs of eyes to ensure that even the best designer can provide a readable experience for everyone without adding a simple text size widget.
Most of the sites we’ve designed in the past few years have not had a text size widget, but I believe this was due to our privileged assumptions and biases, and not to the reality of the needs of those we serve. Going forward on client projects at studio.zeldman, and in my publications like A List Apart, I hope to correct this—and I hope you will think about it, too.
DESIGN is a balancing act—and never more so than when it comes to accessibility (AKA #a11y). So what can you do when an a11y solution you’ve devised for one group creates a fresh a11y dilemma for another?
Through the prism of typeface choice, Eleanor Ratliff relates how she and her team tackled the problem of accessibility whack-a-mole for a rebranding project. In today’s edition of A List Apart, for people who make websites.
AT FIRST GLANCE, November 2016 has bigger fish to fry than a small, cult holiday celebrated by web developers and designers.
Each day since November 8, 2016 has brought new, and, to some of us, unimaginable challenges to the surface. Half of America is angry and terrified. The other half is angry and celebrating. At a time like now, of what possible use is an annual holiday celebrated mainly on social media by a tiny posse of standards- and accessibility-oriented web developers and designers?
From Blue Beanies to Black Hats
Many web developers have “moved on” from a progressive-enhancement-focused practice that designs web content and web experiences in such a way as to ensure that they are available to all people, regardless of personal ability or the browser or device they use.
Indeed, with more and more new developers entering the profession each day, it’s safe to say that many have never even heard of progressive enhancement and accessible, standards-based design.
For many developers—newcomer and seasoned pro alike—web development is about chasing the edge. The exciting stuff is mainly being done on frameworks that not only use, but in many cases actually requireJavaScript.
The trouble with this top-down approach is threefold:
Firstly, many new developers will build powerful portfolios by mastering tools whose functioning and implications they may not fully understand. Their work may be inaccessible to people and devices, and they may not know it—or know how to go under the hood and fix it. (It may also be slow and bloated, and they may not know how to fix that either.) The impressive portfolios of these builders of inaccessible sites will get them hired and promoted to positions of power, where they train other developers to use frameworks to build impressive but inaccessible sites.
Only developers who understand and value accessibility, and can write their own code, will bother learning the equally exciting, equally edgy, equally new standards (like CSS Grid Layout) that enable us to design lean, accessible, forward-compatible, future-friendly web experiences. Fewer and fewer will do so.
Secondly, since companies rely on their senior developers to tell them what kinds of digital experiences to create, as the web-standards-based approach fades from memory, and frameworks eat the universe, more and more organizations will be advised by framework- and Javascript-oriented developers.
Thirdly, and as a result of the first and second points, more and more web experiences every day are being created that are simply not accessible to people with disabilities (or with the “wrong” phone or browser or device), and this will increase as standards-focused professionals retire or are phased out of the work force, superseded by frameworkistas.
#a11y is Code for “Love Your Neighbor”
This third point is important because people with disabilities are already under attack, by example of the U.S. president-elect, and as part of of a recent rise in hate crimes perpetrated by a small but vocal fringe. This fringe group of haters has always been with us, but now they are out of the shadows. They are organized and motivated, and to an unmeasured degree, they helped Donald Trump win the White House. Now that he’s there, people of good will ardently hope that he will condemn the worst bigots among his supporters, and fulfill his executive duties on behalf of all the people. I’m not saying I expect him to do this today. I’m saying I hope he does—and meantime it behooves us to find ways to do more than just hope. Ways to make change.
One small thing designers and developers can do is to make accessibility and usability Job 1 on every project. And to take a broad view of what that means. It means taking people’s messy humanity into account and designing for extreme ends of the bell curve, not just following accessibility authoring guidelines. (But it also means following them.)
In doing those things, we can love our neighbors through action. That—and not simply making sure your HTML validates—is what designing with web standards was always about.
On November 30, I will put on my blue hat and renew my commitment to that cause. Please join me.
12 LESSONS from An Event Apart San Francisco – ? 3: Derek Featherstone was the 10th speaker at An Event Apart San Francisco, which ended Wednesday. His session, Extreme Design, showed how creating great experiences for people with disabilities results in better designs for everyone.
Focusing relentlessly on accessibility helps us think of extreme scenarios and ask questions like “how can we make this work eyes free?” and “how can we make this work with the least amount of typing?” Most importantly, it leads to deeper design thinking that solves problems for everyone who uses our sites and products.
A Map For The Blind
One of my favorite examples from Derek’s presentation had to do with a map. A Canadian city was expanding geographically to encompass some of the surrounding suburbs. The city’s website was charged with letting all citizens know about the change. The web team did what you or I would probably do: they created a map that clearly showed the old and new city limits.
Unfortunately, this visual map was by definition inaccessible to blind citizens, so the city brought in Derek and his colleagues to design an equivalent experience for the unsighted. Derek’s team and the web team pondered typical solutions—such as laborious written descriptions of the city’s shifting geographic borders. But these were not user-friendly, nor did they get to the heart of the problem.
Maybe creating a verbal equivalent of a visual map wasn’t the answer. Derek’s team kept digging. Why was the map created in the first place, they asked. What was the point of it? What were users supposed to take away from it?
It turned out, people wanted to know if their street fell within the new city boundaries because, if it did, then their taxes were going to go up.
Solving for a map wasn’t the point at all. Allowing people to find out if their home address fell inside the new city limits was the point.
A simple data entry form accomplished the task, and was by definition accessible to all users. It was also a much quicker way even for sighted user to get the information they wanted. By solving for an extreme case—people who can’t see this map—the web teams were able to create a design that worked better for everyone.
Tomorrow I’ll be back with another top takeaway from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017.
VAL HEAD and I discuss how to create an animation style guide, the genius of user queries, the web animation API, frame by frame animation, animating with math in Flash, Disney animation and the illusion of life, animating for meaning, how to animate without triggering vestibular disorders, resources for accessible animations, and what to eat in Lawrenceville, PA.
Introducing Deque’s aXeDeque System’s aXe (The Accessibility Engine) open source library is a lightweight (~100 KB), fast, portable JavaScript library that executes automated accessibility testing inside your testing framework or browser of choice.Re-written from scratch over the last year, leveraging 15 years of accessibility experience, these rules represent the state of the art in automated accessibility testing.
ACCESSIBILITY IS LIKE the weather: everyone talks about it, but not enough of us do anything about it. Austin-based Knowbility is one of the few groups in the world with the commitment and expertise to change this. If enough of us fund their new IndieGogo project, they’ll gain the resources they need to create online modules that teach the world how to make our sites work for people with disabilities. This is a cause any web designer or developer should be able to get behind.
I love the web because it is democratic, agnostic, and empowering. Progressive enhancement, responsive design, and other core components of standards-based web design are all about making sure that the experiences we create online are available to any person, via any browser, on any device. That promise is the heart of web accessibility. It will seem obvious to most folks reading this page that a site that works for all is way better than a site that works only for some.
Yet, for all the sophistication and excitement of modern web design, accessibility remains the least-taught, least-understood, least-cared-about of all our new and classic best practices. Let’s help Knowbility change that. Let’s help them help us, and, by extension, help everyone who uses the web (or tries to).
Please contribute to, and spread the word about, Online Training to Make Sites and Apps Accessible: http://is.gd/knowbility. And please hurry! There are only five days left to make a difference.
Update
Here comes Phase II in the fundraising effort. Please visit this updated URL: http://is.gd/knowbility. You know what to do from there. Thanks!
In A List Apart Issue No. 367, Peter-Paul Koch, Lyza Danger Gardner, Luke Wroblewski, and Stephanie Rieger explain why Apple’s new iPad Mini creates a vexing situation for designers and developers who create flexible, multi-device experiences.
Each week, new devices appear with varying screen sizes, pixel densities, input types, and more. As developers and designers, we agree to use standards to mark up, style, and program what we create. Browser makers in turn agree to support those standards and set defaults appropriately, so we can hold up our end of the deal. This agreement has never been more important.
That’s why it hurts when a device or browser maker does something that goes against our agreement—especially when they’re a visible and trusted friend of the web like Apple. Read Vexing Viewports and contribute to the discussion.
This issue of the magazine also marks the departure of Jason Santa Maria as creative director after seven years of brilliant design and support.
Jason’s elegant redesign of A List Apart and its brand in 2005, together with the master stroke of bringing in Kevin Cornell as illustrator, brought the magazine new fame, new readers, and new respect. Over seven great years, his attention to detail, lack of pretension, and cheerful, can-do attitude has made working on ALA a pleasure. Jason was also a key member of the strategic team that envisioned ALA’s upcoming content expansion—about which, more will be revealed when the site relaunches in January.
Jason will continue at ALA as a contributing writer and as designer of A Book Apart (“brief books for people who make websites”), of which he is also a co-founder.
“In his opening keynote at An Event Apart in Austin, TX 2012 Jeffrey Zeldman talked about the need to keep content front and center in websites and the web design process.” Enjoy Luke Wroblewski’s notes on my presentation, “Content First.”
“In her presentation at An Event Apart in Austin, TX 2012 Sarah Parmenter talked about the changes responsive web design requires of web designers.” Enjoy Luke Wroblewski’s notes from her talk on “Responsive Design Workflow.”
“In her Content Strategy Roadmap presentation at An Event Apart in Austin TX 2012 Kristina Halvorson talked about how to integrate content strategy into a typical web design workflow.” Enjoy Luke Wroblewski’s notes from her talk.
In this presentation, Ethan Marcotte walks through ways to tackle thorny issues in responsive design layouts, media, advertising, and more. Here are Luke Wroblewksi’s notes on the talk.
“With the explosion of web-enabled devices of all shapes and sizes, the practice of web design and development seems more complex than ever. But if we can learn to see below this overwhelming surface to the underlying web beneath, we can learn to make sites not for specific devices but for the people using them. This presentation will demonstrate how tried and tested principles like REST and progressive enhancement are more important than ever. By embracing the spirit of the web, you can ensure that your websites are backwards compatible and future friendly.” – Jeremy Keith
“Andy Clarke talked about the changing processes in web design and shared a number of tools and techniques that can help designers make transition to a more modern workflow.” Luke Wroblewski’s notes from the talk.
MARISSA CHRISTINA joins Jeffrey Zeldman and Dan Benjamin to discuss her path as a web designer diagnosed with a debilitating vestibular disorder, and her blog Abledis.com, documenting living with a hidden disability.
SHOWING AND HIDING CONTENT using JavaScript-based page manipulations for tabbed interfaces, collapsible elements, and accordion widgets is a common development pattern. Learn how your choice of hiding mechanism can influence content accessibility in assistive technologies like screen readers in an excerpt from Aaron Gustafson’s Adaptive Web Design.
For seven years, progressive enhancement has been how we build sustainable, interoperable, and accessible web solutions.
Now that the release of ARIA is approaching, let’s see how ARIA fits within progressive enhancement strategy. Can we use ARIA in a way that respects progressive enhancement? Can we use ARIA in ways that ensure we have a working solution at every level?
Web developers interested in accessibility issues often look to WAI-ARIA to bridge the accessibility gap created by ubiquitous scripting and make web applications more accessible to blind and visually impaired users. But can we recommend WAI-ARIA without reservation? Are there times when appropriate semantic HTML elements are preferable to custom widgets?
About the Magazine
A List Apart explores the design, development, and meaning of web content, with a special focus on web standards and best practices.
“You don’t get to decide which platform or device your customers use to access your content: they do.”—
This fetish for pointless customization—customization for its own sake—persisted through the MySpace era, where it actually made sense as an early mass offering of page owner personal branding. Its descendants are the WordPress, Tumblr, and Squarespace themes that create a professional appearance for the websites of individuals and small businesses. This is a positive (and inevitable) evolution, and a perfect denouement for the impulse that began life as “user customization.”
Now notice who else provides some of this same inclusive customization function: the mighty New York Times.
