Deejay 2.6 and 2.7

= 2.7 – November 17 2018 =

Updated readme file.

Added an option for a search form in the top navigation bar.
-To maintain the positions of the top social menu and and the search form,
a new span with the class top-bar-right was added to header.php.
The search form is filtered to hide the submit button for the form in the top navigation bar, unless the menu is toggled. A screen reader text for the submit button will be displayed just below the input field.

= 2.6 – November 8 2018 =

Improved theme support for the new editor:
Centered post and page content.
Changed content width to 720px.
Color palette, align wide, block styles, responsive embeds.

Improved support for system fonts:
-You may experience a slight shift in the font styles as the theme is no longer only using “sans-serif” as the font family.
New font-families are: BlinkMacSystemFont, -apple-system, ‘Segoe UI’, Roboto, Helvetica, Arial, sans-serif.

Additional tests and improvements for the advanced mobile header,
including header image size, text size and positioning for the site title and the header menu.

Added options for a sticky menu and for disabling the priority menu.

Spooky! A Halloween theme adoption

Last year, I released a Christmas theme, and I wanted to create a holiday theme this year as well.  While I was considering a name for my new theme, I found a theme in the theme directory called Spooky, that had not been updated since 2009.   I thought this was a great name for Halloween, and that it would be fun to see if I could revive it.

So I found the contact information to the themes creator, Esther, from in the themes readme file, and to my surprise, she soon replied back and said yes, I could adopt the theme!

To adopt a theme, you need to change the username of the author in the back end of the theme directory. So In order to do that, I contacted the Team Leads of the Theme Review Team who quickly transferred the theme over to my account.

When testing the original theme, I discovered a lot of PHP warnings, because of course it did not have any of the functions that have been added to WordPress in the last 9 years, that we take for granted today.

Because I only had a few days to spare before the holiday, I decide I would not be able to keep any of the original code and rewrite it, so instead, I started over with a fresh copy of underscores.

A screenshot of the original theme

But I definitely wanted to keep the theme in the same style, with the black background, grey text colors with orange details, a castle in the footer, and a moon at the top. 

I already had the moon that I could borrow from the Bunny theme, and I went through many of the Halloween themed images on pixabay before I chose this image for the footer:

I edited out the second moon behind the castle and also added some gradients to the themes footer and header area. In the end, I opted out of the sidebar so that it would be easier to use the wide and full width alignments in Gutenberg.

I tested a large number of menus with different spider animations, until I chose the narrower drop down menu with the cobwebs.

I am still struggling with getting the animations to work on Ipad, so if you have any tips, please e-mail me 🙂

For the screenshot, I choose The Raven, by Edgar Allan Poe.

The Screenshot of the new version of the theme

For 3 days of developing and testing, I am still pretty happy with how it turned out.

The downside to adopting a theme is that if the theme was already live, -as was the case for Spooky; it wont be on the latest themes list on

If you want to dress up your blog for Halloween, you can download the theme here.

The theme as one menu, a footer widget area, support for full width images with the Gutenberg editor, and an orange and yellow color palette. There is also a color option in the customizer where you can replace the orange accent color.

Updates for Star

Star is one of my oldest themes and it now has basic support for the new editor. Because this theme has an optional sidebar, the theme will not have support for full width and wide content.

Version 1.11 is a maintenance update and it is the first update for this theme in 2018.


  • Housekeeping: Updated links. Updated credits in the readme file.
  • CSS and PHP code style changes according to WordPress coding standards.
  • Added a rtl stylesheet and print style.
  • Added various theme support for the new editor.
  • Added a link to the privacy policy page in the footer.
  • Updated screenshot.

Changelog for Embla 0.8

Version 0.8,   October 12 2018 

  • Made more functions pluggable to make it easier to create child themes.
  • Style improvements to match the theme with the new and the classic editor, and for BBPress and Jetpack.
  • Made sure that longer post titles does not overflow the post area, but displays over multiple rows instead.
  • Changed the post pagination style to wrap over 3 lines on mobile/handheld devices to make the clickable areas larger and since the longer line sometimes created a scroll.
  • Removed blocks.css, the styles are now part of style.css
  • Housekeeping: Validated html, updated links.

Aaron is getting ready for the new editor

Two months ago,  I finally started the process of creating new demos for some of my existing themes. But after seeing very little actually being done 😉 I have realised I need a better plan for which themes I want to continue working on.

The first theme that has recieved an update in preparation for Gutenberg, and a new demo and information page, is Aaron.

While I continue the testing together with a couple of my theme users,  you can expect several smaller updates to fine tune the styling.  I want the editor and the front to match, but I still want it too look and feel like the same theme.

I am generally a fan of Gutenberg -I am writing this post on my mobile,  with the plugin installed – but the frequent changes has not made it easy for theme developers.

The following changes were made in version 3.2 of Aaron:

  • Made sure that the custom templates works for all pages, not only for the front page.
  • Made sure that the meta box options works with the Jetpack portfolio and testimonial post formats.
  • Added a testimonial widget. This widget requires the Jetpack testimonial functionality to be activated. (This widget is the same widget that has been added to some of my more recent themes)
  • Made sure that the excerpt_more filter returns the default value in the admin.
  • Included a footer link to the privacy policy page, if one is set up.
  • Minor style changes:
  • A left side border was added to the blockquote.
  • A border was removed from the footer widgets.
  • Matched font and styles used in the gutenberg editor.
  • I also updated the screenshot, to follow the new guidelines for the theme directory.

Version 3.3 is scheduled for mid october and will mostly be style changes.

If you have any suggestions and ideas for Aaron, you can email me or use the support forum.


So, my latest child theme has nothing to do with goats*, but is inspired by the 2018 FIFA World Cup.
Sweden is out of the cup, but I have wanted to make a theme for SportsPress for a while and this was good opportunity to try it out. This is a basic theme, but together with the plugin you can set up team and player profiles, present upcoming games, statistics and results. If you are new to using SportsPress, they have lots of video tutorials to help you get started.

You can download GOAT from here.

*But if you love goats, my theme Farm has a goat header image :p .

Farm, a new child theme

Farm is a new child theme for Embla.
It is a basic blog theme with a romantic header font and just a hint of green.
Farm is responsive with a large header images and a two column grid layout.
Present your farm and your staff with the custom staff template, or sell your goods with the help of the WooCommerce plugin.

You can download Farm from

Updates for Aaron and Deejay

This weekend I made two small theme updates. Here are the changelogs:

== Aaron ==
Version 3.1, 2018-01-28
Fixed an issue with the featured content option.

Changed the customizer type from text to url for the link options.

Moved the pingback url from header.php into a separate, conditional function.

Moved the content width global setup inside the aaron_setup function.

Improved sanitization for the metabox options.

Minor code styling updates.


== Deejay ==
2.3 – January 28 2018 =

Fixed missing border colors for images and the menu button.

Added theme support for the editor color palette.



My next theme is called Embla and has now been in queue for 8 weeks.


Getting ready to do accessibility reviews

The scope of this post is reviewing accessible themes submitted to Updated December 6 2017.

The accessibility-ready tag has been available in the theme directory for over 2 years. Themes that include the tag are not set live until the theme has had a full review plus an additional accessibility review.

While most agree that accessibility is important, the number of theme reviewers who are comfortable reviewing it is still very low; no more than 4 people at any one time.

Some of the reviewers are members of the accessibility team and their main focus is on improving the accessibility of WordPress as a whole, and they only have limited time to help out with theme reviews.

This means that:

  • The waiting time for accessible themes are even longer than for regular themes.
  • Author’s remove the tag because the waiting time is too long.
  • Authors submit accessible themes without adding the tag, so it becomes more difficult for users to find accessible themes.

I personally believe that the low number of reviewers is because of lack of confidence: Reviewers does not want to promise that a theme is accessible if they are not 100% sure.

So how can we encourage and make it easier for active reviewers to start reviewing accessibility (and usability)?

First of all I would like to assure you that:

  • It is not more difficult to do an accessibility review than to do a regular theme review.
  • It does not take longer than a regular review.
  • You do not need to test the theme with a screen reader.
  • The members of the theme review or accessibility team can help answer your questions.
  • The world will not end if you missed something during the review*.
  • The theme author is responsible for making the theme accessible, not the reviewer.

The requirements for using the accessibility-ready tag each have a section named “How to test” and suggestions of tools to use, so I could even argue that the accessibility requirements are easier to test than some of our other requirements.

You can literally open the accessibility requirements page, read the first requirement and start testing it simply by tabbing through the selected theme. -If you can’t see the focus, then the theme needs to be updated.

But it is important to remember that as with any part of the theme review, it becomes easier and much more valuable for you as a developer if you also have a basic understanding of why something is required. 

The accessibility requirements are based on a guideline from W3C called WCAG 2.0, or Web Content Accessibility Guidelines 2.0 (I am sure that you have heard of this guideline before).

WCAG has 3 levels: A, AA, and AAA. The theme accessibility requirements mainly refer to level AA.

Even when we have a list of requirements, everything cannot be covered, and we need to use both our own judgement and our collective knowledge as a team. This is true for all kinds of reviews that we do. But in cases where the accessibility requirements does not cover everything, we don’t need to rely on trends or vague and varying “best practices”, instead, we can go back to read the WCAG.

I understand that trying to read and make sense of the official documents can feel overwhelming, and luckily for us, there are several other people who have recognized this and has written some helpful guides.

Web Content Accessibility Guidelines—for People Who Haven’t Read Them

Mozilla: Understanding the Web Content Accessibility Guidelines

How to do an assessment -From Duke University

The first thing to be aware of is that using an accessible WordPress theme does not automatically mean that a website is accessible, because the content must also be accessible. That a theme passes the review does not mean that the website is compliant with WCAG 2.0, or with the U.S section 508, which is sometimes believed.

Steps to get ready

I recommend the following steps to get ready to review accessible themes. If you need to skip a step, you can always save the resource and refer to it later.

  1. Read the WordPress accessibility coding standards.
  2. Read the Web Content Accessibility Guidelines. 
  3. Visit and subscribe to the blog of the Accessibility team:
  4. Join the accessibility team channel on Slack (Please be respectful and remember that it is not a support channel).
  5. Read about the requirements, recommendations and review process for accessible themes.
  6. Take the WordPress accessibility course by Joe Dolson on Joe is a member of the accessibility team, a plugin and theme developer and the one who has done most of the accessibility theme reviews.
  7. Sign up for A11yweekly, a newsletter by David A Kennedy. It includes a section called “New to A11y” and has a lot of good tips and links to resources.  You can also find the previous issues here. David has helped us with accessibility reviews in the past and is one of the maintainers of the default WordPress themes.
  8. Read and learn from other reviews:
    1. All open tickets with the accessibility-ready tag are in a separate queue on Trac:
    2. You can read old reviews by listing accessible themes in the directory and using the Trac Tickets link on the themes page.
  9. Don’t forget to test and improve your own themes! Submit a theme with the accessibility-ready tag to go through the process yourself.

I also recommend the following videos on

Adrian Roselli: Selfish Accessibility

Rian Rietveld: The Accessibility-Ready Tag for Your Theme – Why and How

Rachel Cherry : Understanding and Supporting Web Accessibility

Graham Armfield: Designing for Accessibility



*-The process in case you happen to miss something during an accessibility review is the same as for any other requirement: If we find out that a live theme does not pass a requirement, the author will be notified in ticket and we will ask them to submit an update. If the problem is not solved, we can ask the author to remove the tag, and ultimately in a worst case scenario, the theme can be suspended from the directory.