Uncategorized WordPress

What I want to see in the Twenty Thirteen theme

I’ve had the pleasure to contribute code to the last three default WordPress themes. All three have been great themes in my opinion, and all three have tried to tackle a different problem. All three have also served to help educate and inform theme developers of new, different and awesome ways to do things.


Twenty Ten was the first time in years that core developers became theme developers again. Developing it lead to enhancements in the apis mostly used by themes such Custom Headers becoming core code. Twenty Ten has also turned out to stand the test of time, with about fifteen thousands downloads last week alone (and not including all the times it was downloaded bundled with WordPress 3.0 – 3.5).

Twenty Eleven aimed to be responsive, and more of a magazine style. It demonstrated the power of post formats, with seven different ones baked in and included options for both a dark and light color scheme.  As the first default theme to feature responsive design, Twenty Eleven aimed to educate theme developers on simple responsive design and succeeded.

Twenty Twelve took this challenge a step further. Designed “Mobile First”,  It doesn’t scale down to phones, it scales up to the browser. By deciding on the goal from the get go, Twenty Twelve turned out great and it’s source code and the trac discussions that went into building it can now be used to teach developers about the concept of mobile first.

I want Twenty Thirteen to tackle another problem that the education and example of a default theme can do. I want Twenty Thirteen to be designed and built Accessibility First. So what do I mean by “Accessibility First”?

Accessibility First would involve a few decisions to be made upfront:

  • Color choices with high contrast in mind from the start. This is one area that Twenty Twelve barely missed.
  • Color choices with multiple types of color deficiencies in mind since an estimated 10% of all males suffer from some form of color deficiency.
  • Making up for browser deficiencies, specifically the skipnav focus bug in webkit
  • Make sure that the design still looks beautiful when the font size is increased 200%
  • Following the Theme Accessibility Audit Draft Proposal

By making the decision to be accessible upfront, before a single line of code is written or a single sketch is drawn, WordPress can demonstrate to theme developers what they need to do to make sure that every can experience and use a site to it’s fullest.

31 replies on “What I want to see in the Twenty Thirteen theme”

I’m really looking forward to this vision coming true! Given the reach that the default theme always has, this could be a major tool for people even outside of WordPress to see what designing for accessibility can be.

Ditto! I left a comment earlier today but it seems to have got lost in the ether. I’m particularly curious as to why there might be a color blindness issue in the new default theme if it follows the general design path of the others and uses a near black, white and blue color scheme? I think color choices would be a great idea but perhaps more aimed as those wanting high/low contrast displays would be better (visual impairment/dyslexia)?

If we stick to the dark grey, white and blue scheme then there won’t be any issues with Color Deficiency, but with the last three default themes using that scheme, perhaps it’s also time to change it up. I note the color deficiency issue because it is an often overlooked, yet is also something that is very common. The first accessibility bug I ever fixed in anything was related to color deficiency.

I think this is a valid goal in the evolution of WordPress’ default themes. The biggest downside when designing for accessibility in any arena is that it almost inevitably misses the balance between beautiful design and accessible design. With the talent and resources at the project’s disposable, I’d say that if any group can find the balance and leverage it, we can.

In addition to designing with contrast and color in mind, I’d love to see some switching in place to make things more (or less) accessible which would allow the theme to span a wider range of uses. What I mean by ‘switches’ is maybe the ability to ‘turn on’ or ‘turn off’ features like large text, high contrast, and other features.

Regardless of the choices that are made coming up with Twenty Thirteen, I look forward to working on it.

I don’t agree that designing for accessibility means ignoring the aesthetics. It has much more to do with being thoughtful of the possibilites for how people interact with the site, which includes users resizing the text themselves (either natively in the browser or with a screen magnifier).

As far as turning on and off features, I’m a believer in decisions, not options. Also, users that need specific contrasts for sight or other issues, can always load there own style sheet (it’s part of the WCAG 2.0 guidelines that users can do this). To achieve this, basically we just need to keep all styling in a stylesheet (which I think the developers of the default theme will want to do anyways).

Hello Aaron, Hello all,

Unfortunatelly, most of users doesn’t know how to make their own style sheet. Besides that, there are also users that don’t use a screen magnifier but a screen reader and need to change the contrast or fontsize just for a while. So I think that it is important to implement these accessibility options inside the Site.


I think that it is important for sites to not reinvent browser/os features. It creates a more consistent and thus easier to predict experience. Changing font size is one of those. I like the WCAG 2.0 guideline on resizing text

As far as custom stylesheets, browser plugins implement this for the user which is the most common scenerio. and are examples of this. Working well in these situations should be the goal.

The biggest downside when designing for accessibility in any arena is that it almost inevitably misses the balance between beautiful design and accessible design.

Oh – I so/ disagree with this! Joe Dolson & I worked for some years as part of a team reviewing sites on Accessites and we were privileged to see some absolutely beautiful designs.

Maybe I’m just used to dealing with truly atrocious-looking 508-compliant sites whose designers put in 20 percent effort in design and 80 percent effort in accessibility. It should be a balance. It should be an accomadation not a reservation.

Designs like those are exactly the reason I say we need more examples of beautiful design for accessibility! Unfortunately, the look you’re talking about has been used too often as an excuse for crap design on the one hand, or for not making any effort for accessibility on the other. A11y is a different set of constraints than most of us are used to working with, but it’s also another insight on how people use and interact with what we build…

Oh don’t get me wrong. A11y is _awesome_ … I think this whole discussion is. And I’m glad Aaron sort of started it as a precursor to Twenty Thirteen discussion. We’ve always sort of set the standard with the default themes about what’s possible and what’s the right way to do it and I think we have a great opportunity to set a positive example with something like this.

I love this and will share it with every WordPresser I can find.

A couple thoughts:

I think much making sure this happens involves how the theme is tested. Thinking about testing from the start will be key and that’s clearly something that Twenty Twelve didn’t really get right as evidenced by the whole IE7/8 menu bug. Also, I don’t think the drop-downs are very keyboard accessible in any of the Twenty-X themes. Even better, let’s get Twenty Twelve more thoroughly tested and make sure to explicitly address any issues that arise.

Though this is a slight tangent, I think it would be great if the theme were built with explicit support for certain plugins. For instance, there are plugins that help with font-sizing via a sidebar widget. Rather than reinventing the wheel (if that’s a feature people think is worth including), that could be a great excuse to contribute to another plugin as part of the default theme development and highlight the fact that there are an increasing number of a11y plugins in the repository.

If you don’t think #22044 was properly fixed, I would encourage you to reopen it and present some new arguments/information.

As far as the other Twenty X themes, I think anyone who has worked on developing accessibility knows that it is much easier to build it when it is planned from the beginning rather then trying to add it in later on. Hence this call for action before work has really begun on Twenty Thirteen.

As far as the plugins that change font size via a sidebar widget, I wonder why they are trying to reinvent a browser feature? I’m a fan of deferring to browser/os features since it provides a consistent and thus more easily to understand experience across the internet.

Thanks for the response.

What I meant to highlight in bringing up that bug is that it was filed after Twenty Twelve’s public release and it showed that nobody had tested the theme in IE8. That struck me as a rather large oversight and possibly a sign of lax testing overall.

I actually agree with you most of the time regarding the widget, but I’ve had the case made to me that some older populations—that may not think of themselves as “disabled”—don’t know how to manage browser sizing on their own, but greatly benefit from it. The one time I implemented it at the client’s request, I included some help text in an attempt to educate people about the built-in browser features.

Hi Aaron,

I’m excited to see this being put forward. I’ve recently joined the Theme Review Team, but haven’t reviewed any themes yet. I’ve also been following the Make Accessibility blog, so I’m trying to get more involved.

Are there any ways we can help you pitch and move this idea forward with the rest of the community?

This is great, Aaron. I agree accessibility should be at the heart of theme design and web design in general. It should be baked it in just like we’ve made a habit with other web standards like clean and semantic markup, styles separated from content, and unobtrusive behavior with JavaScript. Ensuring color contrast, flexible font size, and focus-aware interaction for menus and forms will get us most of the way there. Things we already know how to do.

Twenty Thirteen’s focus is already laid out by Matt M. in the kick-off dev chat.

So … Back to the Blog … something that is much more a blogger theme. The highlight being a really beautiful implementation of post formats, which could dovetail to some better post format support in core, but not dependent on it. In the future we can start rotating between blog and CMS-focused theme, because we always ship two people would have both when they start using WP.

While having a visually very unique and maybe even a little quirky, but that’s all CSS.

I’m fully committed to keeping accessibility principles in mind, doing everything we can that is logical and reasonable in the implementation, and asking you and any other volunteer with passion and expertise in accessibility to jump in often in Trac, test the theme during the dev cycle, and of course give us patches and recommendations.

I’m not willing to promise 508 or WCAG 100% compliance in any default theme — that is a pie-in-the-sky and too-specific goal for the Twenty Something themes in my opinion.

However — if anyone here wants to help me build a 508 and WCAG 100% theme, I’d love to chat. We really need good-looking, solid themes for governments to launch on and Extend — ping me lance at simpledream dot net if that’s something that piques your interest — or if you have one.

Thanks for your feedback Lance.

I’m going to agree with you (even if it isn’t popular in the accessibility community) that 508 or WCAG compliance shouldn’t be the goal. Much like we don’t make it our goal to be 100% compliant with the HTML or CSS specs, the guidelines and specs should guide and inform us, not constrain us.

I hope the development of Twenty Thirteen is an opportunity for the team to contribute early and often with both testing and patches.

Hi Esmi! Twenty Thirteen development hasn’t started yet. We’re hoping to get the first commit into core and kick off a dev cycle by mid-February. I’ll post to make/core probably around that time — I’ll make sure to ping you again also.

Hi Aaron,
Wow! You redesigned.

Twenty Thirteen is in core, and we’d love your help.

I can’t comment on the Make Accessibility P2 right now (not sure why) so commenting here to ask you, Esmi, Dave Kennedy, and AccessibleJoe to jump in when you get a chance.

We ran the Theme Check a11y tests and have been doing baked-in color contrast and form/input since the beginning.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.