Introducing Components: A Toolbox for WordPress Theme Development

Meet Components, a starter-theme generator to speed up WordPress theme development.

We love a good starter theme. Since launching Toolbox and its popular successor, Underscores, we’ve always reached for a starter theme when building our next, awesome WordPress theme to get us off on the right foot. With Underscores, we always say it gives you a 1,000-hour start. We get excited when we see someone fork Underscores and make it their own, so it shouldn’t come as a surprise that we’re obsessed with evolving what we think of as a starter theme.

Continuing that journey, we’re pleased to announce Components. Think of it as a toolbox for taking your themes where you want them to go, faster. Forked from Underscores, Components gives you a solid base to work from – but it also takes the starter theme to the next level, offering a choice between five different theme types. Each one adds the code needed for starting a certain type of theme. You can select from:

The Classic Blog

  • A two-column layout
  • A sidebar with widgets
  • Navigation in the header
  • A fixed maximum width of 1120px in your style.css file

The Modern Blog

  • A single-column layout
  • A sliding panel for navigation, social menu, and also widgets
  • A large featured image with full-width script

Portfolio

  • A portfolio post type, courtesy of Jetpack, added to all the necessary files
  • A grid portfolio view
  • A single column blog template
  • A sliding panel for navigation, social menu, and also widgets
  • A large featured image with full-width script

Magazine

  • A front page template with featured images in grid a layout, plus a two-column blog
  • Layout with excerpts
  • A two-column layout
  • A sidebar with widgets
  • Navigation in the header
  • A fixed maximum width of 1120px in your style.css file

Business

  • A front-page template with a custom header, testimonials section, and  page content area
  • A custom testimonial post type turned on, courtesy of Jetpack
  • A two-column layout
  • A sidebar with widgets
  • Navigation in the header
  • A fixed maximum width of 1120px in your style.css file

Why Components?

So why the different approach with Components? Three main things inspired this direction: the community behind Underscores, the people who use our themes every day, and the web design and development community.

While maintaining and improving Underscores, we always see great pull requests from the community that we turn away because the contributions end up being too specific for a normal starter theme. Many of those additions would have been perfect in most themes. Now, some of them have a home in a project that zeroes in on a certain kind of user with each theme it builds. Speaking of users, we know from launching hundreds of themes on WordPress.com that themes are one of the most challenging areas of WordPress for people to understand. They need more themes that “just work,” and we hope Components will help achieve that. Lastly, the web community has embraced building systems, methodically created with the pieces that make up a site. Even some popular libraries have taken this approach. We see Components as the first step to allowing you to make a starter theme that’s just right for your project.

We’re very excited to see what the community brings to the project and are looking forward to evolving Components with your help. Right now, we’re in the early stages of our vision and execution for Components, so expect both repositories that power this project, theme-components and components.underscores.me to evolve quickly and constantly.

Fork or download Components on GitHub or generate your own custom starter theme at components.underscores.me and have fun making awesome new WordPress themes!

The ThemeShaper JavaScript Theme Tutorial

Dive into the brave new world of JavaScript WordPress theming, looking at best practices and pitfalls along the way.

Introduction

WordPress theming hasn’t changed very much over the past few years. It’s certainly become more refined, and projects such as Underscores (_s) have helped promote best practices and robust standards. That said, we can still go as far back as Kubrick and find plenty of common ground with the most recent WordPress themes.

This isn’t a bad thing, and it’s probably one of the reasons WordPress is so popular and so many people have been able to get involved in theming. But the web has changed substantially since WordPress welcomed its first default theme in 2006. More than half the web’s users now access it from mobile devices. We have HTML5, and with it a whole host of browser APIs that didn’t exist in 2006. These advances have helped a whole new ecosystem of JavaScript-based web apps blossom.

Some aspects of this ecosystem have found their way into WordPress themes. Most of us have probably seen our fair share of jQuery-enabled carousels. We have JavaScript-enhanced tiled galleries and lightboxes available through plugins like Jetpack. Yet very few of us would consider building a theme entirely in JavaScript. The thought may even send shivers down many of our spines.

Building a WordPress theme with JavaScript might be considered lunacy by some, who may wonder why you’d want to attempt such a thing. Others may have questions about SEO, performance, accessibility, plugin compatibility, among a myriad of issues. There are definitely challenges to building a theme with JavaScript, and before reading any further you should know that this is still an experimental area of WordPress theme development.

But, and this is a big “but,” a JavaScript-based approach to theme-building opens up a wonderful world of new possibilities to the curious developer, including:

  • Storing and pre-fetching content using the browser’s Web Storage API to allow server-less, seamless transitions — using the browser’s History API — between posts and pages.
  • Animations within themes, for more natural and intuitive interactions.
  • The ability to create entirely offline experiences using all new Service Workers.

Along with these exciting improvements, the WordPress REST API is being integrated into Core. The REST API makes it much easier for us to build themes with JavaScript. There is no better time to start getting familiar with how the WordPress ecosystem is changing.

The Series

In this five-part tutorial, we’ll expose you to the brave new world that WordPress theme development might inhabit in the coming years. While the best practices for building a theme in this way are still to be established, we’ll do our very best to guide you into the secret garden of the future.

Stay tuned for:

  1. JavaScript, jQuery and the web landscape today
  2. Introducing REST APIs
  3. Challenges in JavaScript-Based Theming
  4. Bringing React into our theme
  5. Et voila, a JavaScript WordPress theme that uses the WordPress REST API

Building a Strong Foundation with Keyboard Accessibility

Learn how keyboard accessibility can serve as your foundation for an accessibility-ready theme, helping you create a solid base.

When you build a house, you start with the foundation. It becomes the base upon which you form everything else around. Without it, your house could crumble because of improper construction. Web accessibility shares some of the same principles. You need a solid foundation to have an accessible website and WordPress theme.

Keyboard accessibility can serve as your foundation for an accessibility-ready theme, helping you create a base that you can build on with confidence. Once you have it in place, accessibility becomes easier as you go.

Keyboard Accessibility Principles

But where do you start? You can tackle any of the four principles below one at a time. Pick one, practice implementing it in your next theme, and you’ll see the benefits. Bringing these to your project matters more than mastering them in any specific order.

Use the Keyboard

Know how to navigate with a keyboard alone. WebAIM, a non-profit organization focused on web accessibility, has an excellent article on keyboard accessibility. It includes how to use a page with the keyboard alone. From the article:

With modern web accessibility, there are many ways in which keyboard accessibility can become difficult or impossible. Fortunately, keyboard testing is easy – simply put the mouse away and test the page using only a keyboard. The tab and shift + tab keys can be used to navigate through links and form controls, and Enter can be used to activate links, buttons, or other interactive elements.

Who uses the keyboard every day on the Web? People who are blind use it almost exclusively. People with low vision may also use it if a page can be enlarged and the contrast is high enough. Those with motor disabilities often can’t use a mouse. Alternative devices also come into play too, like those that allow users to “puff and sip,” and work with airflow from the mouth. These devices interact with the computer similar to a keyboard, so they benefit from proper keyboard accessibility.

Watch your Source Order

Keep your source order in mind. Source order means how your HTML is ordered and how it flows on the page. As you create your theme, make sure that it’s logical. Turning off CSS provides a good, simple way to test this. Once everything on the page becomes linearized, does it still make sense?

Links and Buttons are Links and Buttons

Use semantic HTML and controls that have accessibility already built in. This means that links Home and buttons Main Menu are your best choice. Only three elements in HTML can be focused on by default: links, buttons and form fields. If you use a

or to create an element that’s clickable via JavaScript, a keyboard user will not be able to reach that element. Sure, you can use JavaScript to make it focusable, but why would you if HTML already does the work for you? If you don’t like the default styles of a normal , then you can style it however you’d like with CSS.

Don’t Lose Your :focus

Design and pay attention to the :focus states for your theme. Users with disabilities have an array of needs that don’t always start with a screen reader. Many users access the web using a keyboard alone, or other devices that rely on keyboard access to navigate the web. Having visual :focus styles on elements like links, buttons and form fields means they can see where they are as they navigate. For example, Underscores comes with this bit of CSS on links in the Reset section:

a:focus {
	outline: thin dotted;
}

a:hover,
a:active {
	outline: 0;
}

Having a thin, dotted outline on :focus is considered the default focus style in most browsers. It’s a good place to start, but if you’d like something different, you can design it. However, do not completely remove focus styles by setting outline: 0. That leaves your theme unusable by people who depend on the keyboard. Focus states can often mimic hover states, but they do not have to be identical. The important point here is that they do not rely on color alone. Many users have varying degrees of color blindness and/or low vision. Relying on color alone can become problematic. Using an outline, border or some other kind of shape helps your focus styles shine.

Potential Problems and Enhancements

Keyboard accessibility can become more complex in a few places. Patterns like dropdown menus, menu toggles, tabs, and modals require extra care and thought, but the same principles apply. Knowledge of the tab index attribute and ARIA roles and properties come in handy here. These advanced techniques are beyond the scope of this article, but some useful posts and tutorials have more information:

Further Reading and Resources

Let me know if you have any questions in the comments. Happy theming with accessibility in mind!