Is Accessibility Hard?

Well, no. And yes. Let me explain.

Every now and then, I see something like this from someone in the web community:

But I’m just gonna be honest here… for most developers, coding for #a11y (especially screen readers) is might as well be voodoo

I get it. I still remember the first time I turned on a screen reader. What a foreign experience! I felt so lost. But remember, when users visit a site that isn’t as accessible as they need it to be, that’s how they feel too. I’m not trying to guilt you into accessibility, but show you that we can all have similar experiences that fuel empathy.

The entire Web can feel like voodoo at times. A blur of fast-paced, “what should I learn next?” – “oh no, I feel so left behind” – “I don’t know this all that well” pile of voodoo. Accessibility is no different than learning anything else. Like responsive design, Sass, React or whatever comes next. You can learn accessibility. That’s the “no” part of my answer to “Is accessibility hard?”

So what’s the “yes” part? Accessibility is hard because you have to take that first step. You have to be willing to try. Feel lost. Make mistakes. And of course, like anything else, the deeper you go – the more complex it all becomes. But then you remember, you know a little voodoo, and you’ve got this.

The Power of the Web

The Web has never been a place of purity. Yet people often want to turn it into that.

In The Case Against Progressive Enhancement’s Flimsy Moral Foundation, Josh Korr lays out his case that progressive enhancement has a giant flaw. “Progressive enhancement is a philosophical, moral argument disguised as a practical approach to web development,” he says. He goes onto to poke holes in the moral case for progressive enhancement, saying that those advocating for progressive enhancement are: “Pushing an incoherent moral philosophy in the guise of a practical discussion, and kinda being a jerk about it.”

Korr has also wrote a follow-up post, clarifying his tone snd points. He says:

“The purpose of my post was not to assess progressive enhancement as an approach to web development. (Hence my not-a-dev-disclaimer.) And yes, PE is undeniably a practical approach to web development.

The purpose was to offer an explanation for the PE discussion’s dynamic: how it’s highly combustible and seems to go around in frustrating circles.”

I can understand why Korr makes his main point. The discussion around some topics in the web world do go in circles, and get contentious. This happens in the accessibility community too.

Progressive enhancement, like most principles on the Web doesn’t have an always-optimal approach. To succeed with it depends on your users and your project. A site can have okay accessibility and still deliver a passable experience to users with disabilities. A project can do a decent job with performance, and still be production ready. The Web is messy. It moves fast and slow. Think of how fast responsive design took hold. Now, remember what a monumental change happened when images hit the Web in Mosaic. But we’re still trying to figure out to best deliver those images responsibly today. The Web is a fragile environment. The entire thing relies on connections, which can be broken, interrupted or suboptimal. Progressive enhancement just helps you think critically about how to handle the variables. That way, your users don’t have to worry about them.

The power of the Web lies in its millions of different connections. All powered by people somewhere in the world. That provides all the fuel needed for a difference of opinion now and then. The circular conversations don’t matter as much as the acknowledgment that many paths to success exist when we hear each other out. We just need to stay open to new ideas and not get too caught up in semantics.

One Way to Learn JavaScript Deeply

At WordCamp U.S. 2015, Matt Mullenweg set a goal for everyone in the community: Learn JavaScript deeply. But how does one do that?

In this post, I’ll share what’s worked for me in the past six months or so as I’ve dove deeper into JavaScript.

How Do You Learn?

These days, you can go in many directions. From books and blog post tutorials to courses and bootcamps, you have many ways to learn something new. There’s no one right way for everyone. You have to experiment to figure out which method works best for you. Once you figure out which method works, stick with it, and don’t be afraid to mix and match as you go.

For me, working through courses on Code School and reading in-depth blog posts has stuck best. Blog posts have helped the most since I can consider about how the concepts might surface in my own projects.

And speaking of projects, let’s talk about those. After all, you can’t just read and listen to concepts if you want to truly learn something. Here are five things I recommend that have helped me further my skills with JavaScript:

Just Dive In

Just build. At every opportunity I’ve had, I’ve tried to build with vanilla JavaScript if it made sense to do so. Whether that’s fixing bugs in themes on or taking on new work, I’ve looked for ways to touch JavaScript.

Find a mentor. If you really want to learn, you need a teacher. Someone that can take your questions, hear your frustrations and be there to push you. For me, that’s been my colleague at Automattic, Ernesto Mendez. He’s found a way to teach me something almost every day and challenged me in a way I couldn’t have done myself.

Start small. You might be tempted to jump into a big project when going deeper into a topic. I wanted to experiment with building a JavaScript-powered WordPress theme. But the more I researched and looked into it, the more complex it became. That’s not to say building something like that isn’t beneficial, but keeping what you’re working on manageable means you can control the complexity and get to the “Aha” moments faster.

Redo a project or code snippet you know. The best way to learn something new is to focus on it. You can do this by rewriting jQuery plugins and bits of code in vanilla JavaScript. I’ve done it with a JavaScript file on this site, and several other recent projects. It has forced me to see parts of JavaScript I’m unfamiliar with, and as a result, I’ve picked a lot of new knowledge.

Work on something consistently. Benjamin Franklin famously woke early to read and write. He set goals and measured them, always experimenting and dedicating time to those tasks every day. I’ve tried to do the same, finding projects and tinkering a little each day. It’s helped me progress steadily. I break the work up into two periods, one at the beginning, and one at the end of each day. Sometimes, that means I feel like I don’t get very far. Otherwise, the short amounts of time on tasks give me bursts of energy and excitement. It’s a balance.

I hope this helps you take on JavaScript sooner rather than later. WordPress needs you.

Less Apps, One Week In

A week ago, I came to the realization that I’d hit app overload. So I took action.

I deleted a number of apps from both my iPhone and iPad, my two primary iOS devices. The hitlist included Facebook, Twitter, MeetUp, Google Plus, Tumblr and more. In the last week, I’ve used only the web versions of Facebook and Twitter on those devices. It has felt both freeing and only slightly restrictive. To be honest, I don’t think I’m going back to the native apps.

I think I only had notifications enabled on Facebook and Twitter, and I probably used those two the most out of the deleted bunch. That said, just glancing at my home screen feels much less stressful. Every app there has provides more value than novelty. When I pop open my phone, I’m much less likely to get sucked into mindlessly browsing content, which is amazing. I now have small chunks of time for more important things.

It’s not that I think Facebook or Twitter don’t provide value. They do. They connect me with both real-life friends and online friends in a way I can’t achieve on my own. It’s more that I want to nuture and engage with those connections on my time, rather than know the second someone leaves a comment or like.

This new experiment has its faults though. My friends in town have a Facebook group that we use to coordinate events and fun stuff. A friend posted late one afternoon that he’d like to go to the movies that night. It balooned into a quick, last-minute event that I missed because I saw it too late. That likely wouldn’t have happened had I had the app, enabled with notifications.

But I still think a missing the occasional news or event is better than missing out on some of life’s little pleasures. I plan to keep this up, and see how it goes in the future. Maybe it will stick, and maybe it won’t.

Progressive Enhancement is

Everyone has a definition for progressive enhancement these days, and many often misunderstand the concept. I like Scott Jehl’s thoughts on the principle:

Progressive Enhancement is less “but what if JavaScript is disabled?”, more “can our core services be more tolerant of everyday conditions”

When you look at it that way, progressive enhancement becomes synonymous with quality. Why wouldn’t you want to build sites and applications this way? In a way that gives people a quality experience no matter what.

App Overload

I’ve hit app overload.

I realized this when I glanced at my phone recently. I saw quite a few apps I hardly used. Turns out, people have a limit. Users are spending more time on mobile apps each year, but the number of mobile apps actually used each month hasn’t changed much over the last few years. I experienced the next level of this at a recent tech event, where I tried out a few app prototypes. I’m normally excited to try out new apps and talk to designers and developers about how they’re made, but here my interest waned.

Then this week I listened to a talk by Christian Heilmann called, A New Hope: The Web Strikes Back. In it, he dives into how the Web is catching up to apps and their abilities. It reminded me why I love working on the Web – it’s ubiquitous and open. All you need to get it is a browser, and you’re not at the mercy of anyone. Beautiful.

Inspired by wanting to use the Web more, I’ve decided to delete a lot of apps from my computers and devices. I want to only keep the ones I use at least once a week or need in certain situations (like traveling). The ones I delete, I’ll try to use its Web version – I’m looking at you Facebook. We’ll see how it goes! Delete, delete, delete.

Themers, Themes and the Content Creation in WordPress

My colleague, Michael Arestad, wrote an excellent post awhile back called, The shape of WordPress shapes the web. In it, he poses the questions:

Should the design of content creation in WordPress expand past blogging?

If so, what would the creation of content look like? Would the shape of the editor be determined by the theme? Would it be something more flexible involving direct manipulation? Could it be a mix of both?

Those are tough questions, but fun ones to think about, especially without the limits of the current content creation process. Some of what I envision for a better experience there already exists – in bits and pieces in different content management systems and platforms. Some of the reasons WordPress lacks a more optimal content creation process doesn’t have to do with just user experience, design or code, but also some of its contributors. I’m talking about themers – myself included.

From my vantage point, themes cause some of the biggest frustrations for the people who use WordPress every day. As we all know, born as blogging software, WordPress has evolved into a full-fledged content management system and its contributors have it looking more and more like an application platform every day. With that fluidness comes freedom. WordPress can do a lot. Sure, the post screen available at post-new.php has its limits, but that hasn’t stopped anyone yet. Meta boxes, custom fields, widgets, special classes, page builders and more have all tried to make the process better. But nothing has stuck, and everything has felt like a patch instead of a cohesive experience. And worse, open up any WordPress site that extends beyond a blog and you’re likely to find them all handling content in slightly different ways. Everyone loses here. The people who use WordPress, and those who make it and build tools from it.

I certainly don’t think the perfect content creation process exist for all the types of content that goes into WordPress. And I don’t think pulling in ideas and concepts from other sources is the whole answer. If the design of content creation in WordPress expands past blogging, it will take experimentation, user testing and a lot of collaboration to find something that works. So how do we get there? We have to start – together.

I know that we as themers can do a better job of bringing consistency to the themes we build, both individually and as a community. We’re doing a better job than we once did, reducing theme options, sticking mostly to the Customizer, keeping content types in plugins, etc. but more work remains. We’re all creating themes in our own worlds, but something better lies ahead. We need to sketch, design, build and create outside of themes, and with each other. WordPress Core needs you. Maybe you start working through some tickets. Or revive a stalled feature plugin that’s needed. The opportunities exist everywhere, and content creation doesn’t get better without themers.

A Collection of WordPress Theme Review Tips

Seeing a call for theme review tips on the Make WordPress Themes site inspired me to share my own workflow. Hopefully, it helps some of you who may want to become theme reviewers or hone your craft.

A team of volunteers checks all the WordPress themes that end up in the theme directory. They ensure that the themes meet a set of standard requirements so people get a consistent experience when using a theme from the directory. You can become a reviewer too!

First, A Quick Peek

Before I even begin reviewing a theme, I like to scan it quickly to get an idea of what it’s like, and where I might find issues. This takes about five minutes, and I follow these steps:

  • Look at the file structure: What do you see? Is it a custom theme or child theme? What frameworks or libraries are used? Is the theme set up in a standard way, like a Core theme.
  • Check out the functions.php file. Does anything make you pause and wonder why it’s done like that?
  • Load the major pages in a browser to see if you notice anything out of the ordinary or broken. Major pages include: home, archive, page and single post. Also, check out the Customizer to see what the options and theme setup might be like.

Doing that gives me a broad overview of the theme, and helps pinpoint any areas I may need to pay extra attention to when reviewing. Next, I can begin my full review.

Next, A Full Review Workflow

  • Look at the code first, going file by file. I like to start with the functions.php file first, since it’s the brain of a theme. Then, I’ll look at other include files to get a sense of what should happen on the front end. Then I look at the template files to see the HTML. Lastly, I’ll check out the JavaScript and CSS files to see how they add to the theme.
  • I like to check for code related issues first, such as function names, escaping and translations, etc. Then I look at details, like documentation, screenshot and the stylesheet header.
  • Lastly, I’ll take the theme for a spin, testing the front end and theme options making sure they work properly.

Finally, A Few Tips and Tricks

I’m always tweaking my review process because I never think it’s efficient enough. Here are a few tips and tricks I’ve used lately:

  • I have templates for replying to reviews. I’ve put them on Github in case you want to steal them.
  • I always have the current requirements open in a browser tab to cross reference during the review, just in case something has changed recently
  • I run the Theme Check plugin on a theme before anything else in a full review to get clues where I may need to focus my attention.
  • My standard setup uses WordPress VVV with all of the theme-related plugins recommended in the Developer plugin.
  • I primarily use Chrome to test themes. I will use just Firefox to test keyboard accessibility because it has no default :focus styles, and Safari to test with Voiceover on because the two are well integrated.
  • Spotting possible escaping issues always proves challenging. I like to use PHP Codesniffer with the WordPress sniffs to check for escaping issues. Running this command just executes the escaping “sniff”: phpcs --standard=WordPress-Extra --sniffs=WordPress.XSS.EscapeOutput /path/to/code/ It won’t be perfect all the time, but it will save you time.
  • I like to use regular expressions in Atom to search for various things like function names, text domains, and more.

Now, go become a more prolific reviewer, and don’t forget to share your own tips!

Themes are for Users

This is an adaption of my talk for the 2015 WordCamp U.S. Download the PDF slides (23 MB) or view the talk on

I love themes because they’re central to the WordPress experience. After they install WordPress, users view the front end of their site and start configuring their theme. Despite this, themes have become very disconnected from users. Many theme authors approach themes by building for everyone, but when you build for everyone, you build for no one. Themers need to bring users into their theming process.

Meet Michelle


Meet Michelle. She wants to build a website to showcase the creativity that goes into her handmade purses and handbag accessories. She’s a full-time college student in her second year studying fashion marketing and management. She works part time at the school library and enjoys reading, photography and rowing as hobbies. She’s 20 years-old, maintains a 3.6 grade point average and is goal oriented. She’s interested in photo blogging about her creative process and building a community of followers on her blog. She’s fairly tech-savvy, owns an iPhone 5s and Chromebook. She loves browsing Etsy for pattern ideas, symbols and other neat inspiration that could adorn her handbags.

What Happens When Many Users Meet a Theme

Sounds like Michelle could be your ideal WordPress user. Right? She searches through the available themes, and believes she’s found the one. Michelle visits the demo and wonders how to make her site look like that. “It can’t be that hard,” she says to herself and activates the theme. She follows standard WordPress instructions to set her home page as a static page, and then sets a special home page template for the same page. But when she visits the site, she sees nothing but a blank page. Next, she clicks the “Customize” link in her toolbar and finds her way to the “Theme Options” panel. There, she sees a giant list of options and doesn’t know where to start. Understandably, Michelle gets frustrated. She plays with a few of the settings in the theme’s options, but gives up.

Michelle isn’t alone. Tons of WordPress users give up on themes they had their hearts set on. These are quotes from actual users who asked for refunds for their premium theme purchases:

So, I thought I could make my page look professional on my own…No way in ****. This is for technologically savvy only, I suppose.

Too hard to use! Disappointed!

Lovely theme but I just don’t have the time and patience to learn it, I discovered.

Those aren’t happy users. We see themes with misleading screenshots and demos. Themes with tons of options and complex setups too. This leaves users with false hopes and countless ways to fail. It doesn’t have to be this way. Let’s look at why we’re many people leave the theme experience disappointed.

People Resist Complicated

First, we need to start with the way the brain works. It is, after all, the chief instrument we’ll use in building our site.

Your brain, and yes, Michelle’s brain – our poor user who gave up on building her fashion blog, can only handle so much information. As you take in more information when working on something critical, like setting up a theme, the part of your brain that controls decision making and emotions can hit overload. When it does, it will shut off. Once that happens, Michelle could be prone to making stupid mistakes and bad choices.

The brain can also do tricky things when it comes to choices. In a fantastic Ted Talk, psychologist Barry Schwartz highlights the paradox of choice. Imagine a dairy aisle filled with endless varieties of yogurt. Sounds good, right? It may, but Schwartz says, “With so many options to choose from, people find it very difficult to choose at all.” Give a user too many theme options and you could have indecision and unsatisfied users. On the flip side, Schwartz says, “…Even if we manage to overcome the paralysis and make a choice, we end up less satisfied with the result of the choice than we would be if we had fewer options to choose from.” Why? Because we expect more? Michelle, our user saw all those options and thought she could make exactly what she wanted, but it didn’t turn out that way.

You may see a pattern developing here – less is more. The same approach has greater effect when looking at a number of steps a person has to finish before calling a task done. In 100 Things Every Designer Should Know About People, Susan Weinschenk points out that people focus on what’s left more than what’s completed. A study she sighted said people were more motivated to continue when they focused on what was left to do, so shorter lists help keep users like Michelle motivated.

Lastly, focusing on your user and the overall experience can impact your bottom line in a big way. As an example, when one major hotel chain launched various user improvements to its site, it saw a year-over-year revenue growth of 83 percent. Other branded websites within the industry saw a growth of 33 percent for the same time period. Michelle will buy more themes or services from you, and recommend you, if she has a better experience.

Creating a Mindful Process

So how do we give Michelle a better experience? We need to examine our process. The process for many themes might start with an idea. Great, we have an idea – let’s flesh that out in a design. Once we nudge all our pixels into place, we can start building. As we build, we’ll test the major aspects, and launch. Finished theme! Now, we’ll set back and watch the download counter rise!

However, it’s not that easy. You can’t find Michelle, her needs or voice anywhere in that process. In that process, the opportunity for failure, feedback and improvement doesn’t exist. Our process needs to embrace iteration more. What if it looked more like this? You have a discovery phase where you do research, like looking at analytics, creating surveys or conducting user interviews. A build phase where you sketch, create wireframes, style guides and start designing and coding your solution. Lastly, you evaluate all of that, running more user tests, looking at analytics and analyzing any data that will help you determine what has worked and what hasn’t.

That simplifies a lot of work into three major phases, but one thing to realize is that you can:

  • make this process a cycle, repeating it as you move along.
  • break up your project into chunks and use this method on different aspects.
  • launch at nearly any point, from showing a user test to design tweak to the full project.

This puts iteration at the forefront of your theming process. Sure, it can become messy at times, but that’s part of what makes creating fun. It’s how the creating, the making happens. You need feedback to get a more accurate view of how users will actually use your themes, and it will help you make better decisions and know why you made them.

Bringing Better User Experience to Your Themes

We know we need to alter our process somewhat to help create the best possible themes for Michelle. But how? Let’s look at the discover phase and what you can do to bring a mature user experience process into your theming workflow. It may seem intimidating to dive into research, especially if you haven’t done it much before, but it helps form a solid foundation to work from for all your future design decisions.


Here are some ways you can dive into your own “discover” phase:

  • Look at your analytics. What patterns do you see?
  • Look at your competitors. What themes are they building? What gaps in the marketplace have they not filled?
  • Talk to your support staff, or do support. What pain points do you notice?
  • Run surveys with your customers. They’ll tell you more than you think.
  • Interview users formally, and create user personas.
  • Test a current theme, asking users to perform specific tasks.


After the “discover” phase, you move onto the “build” phase. You may think of the build phase of your theming project as just for writing code, but it’s for any process where you create an artifact that would be something tangible. Here are some of those tangible items and tools that may help you create them:

  • Sketch (pencil and paper)
  • Moodboard (Sketch or Photoshop)
  • Style Guides (HTML/CSS/JS or CodePen)
  • Wireframes (Balsamiq)
  • Prototype (HTML/CSS/JS or CodePen)
  • Get feedback (Yes, again.)
  • User testing (Yes, again.)


Lastly, after you “build” what you need to build, you should evaluate whether or not it proved to be effective. You can loop back to some of the data you gathered or analyzed during the “discover” phase to compare it all. See if you see a change in your analytics, or your support staff hear something different from your customers – as an example. Of course, you’ll want to make changes based on what you find out. Small changes work best since they’re less risky and easier to test and measure against.

Moving into Theming

Once you begin making decisions based on user feedback and data you’ll find that:

your theme options become simpler:

  • they become what they truly are: optional.
  • they start to actually enhance a theme’s purpose.
  • you start to put them into logical groups.

When you’re working with your theme setup, you’ll find:

  • you’re following logical patterns across the web for common interactions.
  • you’re building your theme setup in layers, where each one works independently without need the others.
  • you’ll get your users from theme activation to complete setup in fewer steps.

Your theme documentation will:

  • be created in less time and easier to maintain.
  • no longer be required reading for users who want to get started using your themes.

Your screenshot and demo will:

  • be realistic in what it shows.

As you move through your theming process:

  • Before the theme: Research and focus.
  • While theming: Build your theme in chunks. Test as you go, and don’t be afraid to make and learn from your mistakes.
  • After theming: Ask yourself what you’ve learned. Iterate.

My favorite thing on the Internet is clicking on a link and landing on a personal site, customized by the author. A good WordPress theme can open up a new world to those using it, and in turn, reveal something unique about the site’s owner to the world. A theme can become the centerpiece to someone’s story. That can’t happen without all of us making better WordPress themes. Themes that just work for users like Michelle. Let’s build them.