Remembering Alex King

Alex King passed away last night after a long battle with cancer, leaving behind a wife, a daughter and many, many friends in the WordPress community. You can read the community’s thoughts and reaction on Twitter.

I never met Alex, but I read his code and used his plugins. Because of him, I did things with my site I previously couldn’t have done and became a better developer along the way. I suspect a lot of people in the WordPress feel that way today.

An Event Apart DC 2015: Day Two

Day two of An Event Apart DC 2015 kicked off with Brad Frost introducing us to a different way to create the pieces that make up the sites we build. As he went on, and speakers took the stage after him, I started to notice an overarching message forming from these separate presentations.

We need to challenge our assumptions. Whether it was Aaron Gustafson teaching us that we can love forms instead of hate them, Derek Featherstone taking us outside of the device “box” we have lived in or Eric Meyer reminding us that not all users are the ideal user… You get the idea.

We sometimes get caught up in the way we do things because of stale processes, tools we’ve used for too long or forgetting that the simplest approach to getting started works the best. Many of the presenters echoed ideas similar to this. I left the conference having that typical conference overload. So many new ideas floating around, I wasn’t sure where to start. But that’s my old assumption kicking in. It says I should master something before trying it in a project. But that’s not the right approach here. I just need to open the sketch pad or fire up a CodePen and start experimenting.

An Event Apart DC 2015: Day One

Today, I attended An Event Apart DC 2015, and loved how each talk touched on another, but yet little overlapped happened. I’m not one to write detailed posts about each talk because conferences help me expand my thinking, not show me exactly how to do something. They introduce me to topics, and point me in exciting directions. It’s still up to me to go in those directions though.

So what were they for day one? These are just a few of the points that stayed with me.

Jeffrey Zeldman encouraged us to get our ideas out there, newly formed or experimental. In code, sketch or blog post. Sarah Parmenter showed us data that the Web is more social than you think, but not like you think. Yesenia Perez-Cruz talked about how performance makes for good design. Jen Simmons brought us back to the world of funky magazine design layouts, and convinced us it much of it can be done with CSS — now. And Cassie McDaniel and Cameron Moll touched on the details of user experience and how they can serve as the connective tissue in your projects.

None of this is new, per se. But it is new when stacked next to where we’ve been as an industry and where we need to go. Each speaker provided that as a backdrop or touch point, so what is old is new and amplified. I’m excited to process it all a bit more and think about how I can bring it to my everyday work.

Publishing Versus Performance: Our Struggle for the Soul of the Web

Jeffrey Zeldman talks about the struggle for the soul of the Web, brought forth by the The Mobile Web Sucks on The Verge. It’s worth a read as is Jeremy Keith’s related On the Verge piece. To strike a balance between wonderful content and performance, like most things worth doing, we need more cooperation, experimentation, failure and patience.

Practicing Web Accessibility Differently

This is the third in a three-part series on everyday accessibility.

We make tasks, obstacles and goals harder than they are because we fear the unknown. Accessibility is no different, but you can change that perception by shining light on the unknown each day. With what you ask? What you already know.

Eighty percent of accessibility is the basics. The other 20 percent can prove difficult, but only if you let it. The 80–20 rule also applies to accessibility in that if you focus on solving the top 20 percent of your issues, 80 percent of the related problems go away or become easier.

You can begin to solve the hard problems, or the 20 percent, by focusing on the decisions, people and processes around accessibility. Then, it becomes something you can do.

The impetus for most accessibility successes or failures falls into one or more of these three categories:

  • Decisions
  • People
  • Details

What do I mean by those?


Decisions represent turning points or the foundation of your accessibility process. They’re usually strategy-related, and become points of no return. An example of a decision like this? Creating a separate, accessible website that’s different from your main website. It might seem like a good idea to isolate the challenge of accessibility into one website. But then you have two codebases, two sets of content and a myriad of “differences” to track and maintain. Not good.


People make accessibility happen, but what if they don’t know the how or the why? Many Web workers just haven’t experienced accessibility first hand. They don’t know much about it, much less how to implement it in their projects. Take this classic example of making a button within a Web application. Let’s say that button saves a state of work. A Web developer might do this:

<a href="#">Button</a>

That’s valid HTML, but in most cases, if not all, a real button would be better here:

<button>Real Button</button>

So what if the people carrying out your project just don’t know how to do it better?


In accessibility, details matter. In any given project, at least a thousand exist. If you don’t keep constant, intelligent pressure on them, they can get lost and ruin your efforts. Color contrast serves as a good example. Ensuring proper color contrast requires minding details like brand, color palettes, contrast guidelines, regular testing and more.

Question Everything

You might be thinking that all three of these points intersect. You’re right. People make decisions and track details, after all. What do we do about that? Ask good questions.

Don Norman, a well-known design and usability expert said:

What makes something simple or complex? It’s not the number of dials or controls or how many features it has: It is whether the person using the device has a good conceptual model of how it operates.

The truth in this extends beyond users. Often we, the people who design and build, don’t have a good conceptual model of how our project works. We’re too busy managing changing priorities, timelines and business requirements. We know that won’t change. But we can change how we look at those changes and the decisions, people and details within our work. That will help us solve the hard 20 percent of accessibility.

At each turning point, you should ask yourself, “How is this going to work?” Start the conversation with yourself and others. There are no bad questions or answers. Only the ones that never get asked or voiced. Accessibility is something you can do every day.

This is the third in a three-part series on everyday accessibility. Much of the content for this post came from a guest post I wrote for Digital Gov called Accessibility Is (Not) Scary.

Talking About Web Accessibility Differently

This is the second in a three-part series on everyday accessibility.

No one wants to talk about accessibility. At least not in an open, honest way.

Search the Web for “web accessibility,” and you’ll find a mixture of introductory articles about the basics, standards documentation and various testing tools. You’ll rarely find people, corporations or organizations admitting accessibility issues and talking about how they fixed them. No one will learn the how and why of accessibility unless we talk about it together, and go beyond the standards and tools to everyday challenges.

It doesn’t have to be this way. We can change the conversation by making it more akin to the way everything else works on the Web. It needs to be fluid and open. Why does that not happen in the first place? Because most conversations about accessibility end up in an awkward place. Often, people see accessibility differently. Some see it as a feature, a legal mandate or a moral obligation. So naturally conversations involve phrases like:

  • Let’s focus on that in the next release.
  • We need to do it to comply with the law.
  • It’s the right thing to do.

These phrases come from talking about accessibility the wrong way. People see that giant stack of requirements, no matter why they exist, as a yes or no problem that needs to be solved. It’s either victory or failure.

If they feel like they’re succeeding at accessibility within a process, project or organization, no one talks about it because that’s what they’re supposed to do. If they’re failing, they don’t want to talk about it. No one wants to talk about failure, especially failure to meet a legal obligation or complete a reasonable moral obligation.

Accessibility carries the same fluidity as the Web. Web accessibility is progress – forward or backward. See it as a continuum. The steps in the process from bad to better to excellent and vice versa don’t look all that different. But look at the beginning and end of the process, and you’ll see a transformation. The continuum always changes. You control what direction it goes.

Our words can set expectations, deliver inspiration and provide a foundation for action. Let’s talk about accessibility in a way that isn’t so black and white and still. Instead, let’s talk about it as something always in motion, full of chances, twists and turns. The progress of where that all goes belongs to us.

This is the second in a three-part series on everyday accessibility.

Thinking About Web Accessibility Differently

This is the first in a three-part series on everyday accessibility.

Accessibility is hard. It shouldn’t be.

Most people can’t define it. When you point a UXer, designer, developer, project manager or stakeholder to official specs, like the Web Content Accessibility Guidelines (WCAG), created by the World Wide Web Consortium, or W3C or the United States’ Section 508 standards, they have a hard time understanding what those specs actually mean.

This creates a negative mindset from the very beginning and blocks progress in a very real way. This has to stop. Accessibility isn’t just a legal mandate or list of requirements. It’s really about people. You.

You already have what it takes to make the Web accessible. Yes, really. No matter how much you know about web accessibility, you can make the Web a better place for everyone. In today’s world of evolving web standards, emerging best practices and a growing number of connected digital devices, the most important part of the puzzle is you. You, the web user. You, the project manager. You, the user experience designer. You, the web designer. You, the web developer.

What Accessibility Really Means

Making something accessible means designing and building websites and web applications that work for the widest possible audience, no matter their ability or disability. The Web’s creators developed it to be used by anyone, recognizing that its true power stems from its universality. They built it to be that way without any special configuration. We’re the ones that usually muck it up. How do we not do that?

Be Aware

While the technical details matter, your awareness matters more. The web accessibility landscape is far from clear and the perfect answers won’t always exist. Embrace this uncertainty as fuel for moving forward.

You need to:

  • design and develop without fear, uncertainty and doubt: It’s easy to fall into the trap of thinking that web accessibility will limit your creativity or your ability to build the next big thing. Don’t let that happen. Accessibility can be beautiful and help spur new approaches to old problems, especially when we keep doing what we know how to do. Move forward with confidence.
  • know what you don’t know: No one knows it all, and that’s okay. We’re better together when we’re honest with ourselves and those around us. Do your best to plan, design and code in the open so you and others can pinpoint accessibility obstacles early, learn more and find solutions to problems faster.
  • favor pragmatism over perfection: Focus on creating solutions to accessibility problems and not just on the problem itself. Aim to show each other the balance between pushing boundaries and following established principles. You may make compromises along the way, but don’t sacrifice your design vision. Accessibility is just another design constraint.
  • contribute to the accessibility body of knowledge: The Web flourishes most when its people, processes, tools and systems are open. Welcome that. Share your ideas, your barriers, your processes and your code – even when they may not fit neatly into a case study or showcase. Examples and experimentation inform progress.

You can help make web accessibility a reality, and easier for everyone who creates on and uses the Web. You know what to do next.

This is the first in a three-part series on everyday accessibility.

You and the Future of WordPress Themes

Road that curves into horizon

I have a confession.

When I created Accessible Zen, I wanted it to be downloaded and used by thousands. I thought since it would be one of the first accessibility-ready WordPress themes in the directory, it had a chance to become something special.

That turned out to be a selfish viewpoint though. Why? When you release open source code, you quickly learn that you alone have little control over what comes after the initial release. You never know how people will use your creation, and what will come of it as a result. I see it as a form of collaboration. It’s not about you and your ideas, but the community and its ideas.

I got much more pleasure out of getting a simple thank you for releasing the theme, or seeing someone use it for an amazing cause than anything else. At those moments, the number of downloads don’t matter. Neither does what was used to build it or whether it employs the latest design trends. What matters most is that someone took something I made, and created something even better with it. Like I said, collaboration.

That brings me to you and the future of themes. In a recent comment on a WordPress Tavern post, my colleague Ian Stewart, said:

It often feels like there are missing pieces in the WordPress experience outside themes themselves. Much like I wish more people released design ideas for future default themes it’d be great to see more people push forward on ideas and solutions that could benefit every theme and every user.

We often start building themes, plugins and side projects for ourselves and our own benefit. We forget that the real magic happens not because of how we create or why we create our projects, but in the simple act of sharing our ideas. Because then, someone else can take those ideas and build on them.

So as we think about the future of themes, we, not just you play a very big part in it. It matters less about the twists and turns we take to get somewhere new and exciting, and more that we go around those corners together. Have you collaborated with anyone in the WordPress community lately?

Image courtesy of

Happy Global Accessibility Awareness Day 2015!

Today marks Global Accessibility Awareness Day, an event that started in 2011 and has grown ever since.

If you want to know more, check out Marcy Sutton’s Accessibility Wins blog for a nice roundup of activities and resources. Even better, get involved and start talking, thinking and learning about digital accessibility. Today and any day is a great day to dive in!

If I were you, I’d read one of the articles or learn about one of the resources on my Accessibility and Me page. Then start tackling accessibility little by little in your every day work.

Happy Global Accessibility Awareness Day!

Accessibility Answers: How Do I Handle Alt Attributes

Woman sitting and raising her hand beside another woman.

When I give presentations on accessibility, I often get one or two questions I’ve fielded before. I’ve collected a handful for an ongoing series of posts with my answers. I hope it helps you understand accessibility better.

How do I handle alt attributes?

Alt attributes can trip up even the most seasoned web worker. But do them right, and they make a huge difference to screen reader users.

I like this table from an article by Whitney Quesenbery.

If the image contains…The alt text should…
TextRepeat the text
Visual informationExplain it
Sensory informationDescribe it
Nothing newKeep it very short
(if you can’t make it “null”)

If you want more explanation, check out the W3C’s alt decision tree.

All images should have an alt attribute, even if it’s empty or null, like: alt="" .

Follow the series Accessibility Answers. Ask me a question via my contact form or Twiter.

Image by rawpixel.