We bought a mattress from Ikea a week ago and it still smells so much of chemicals it’s impossible to even be in the same room without getting a headache, let alone sleep on it. I guess that’s why they have such a long return policy.

Yesterday we bought a tray for our baby’s high chair. It came with a small instructions leaflet with the same text in multiple languages. They all seem to have more or less the same information content, but there were some differences. Here is the beginning of the text in each language.

UK

Congratulations on your new Playtray!

Germany

Herzlichen Glückwunsch zum Kauf von Playtray!

Sweden

Grattis till er nya Playtray!

Denmark

Tillykke med jeres nye Playtray.

Norway

Gratulerer med anskaffelsen av Playtray.

France

Nous vous remercions d’avoir choisi la tablette Playtray!

Spain

Enhorabuena por la compra de su nueva Playtray!

Netherlands

Dank u wel voor het aanschaffen van de Playtray.

US

WARNINGS

If you do not follow these warnings, your child could suffer from serious injuries.

Last night I got home at 3:00 from the first ever multi-nation WordCamp, WordCamp Europe 2013 in Leiden, The Netherlands. The weekend was packed with many inspiring talks, but above all it was a unique chance to meet other developers and designers from around Europe and the world. Based on discussions I had during the past two days, advanced use cases of WordPress as an app platform are becoming more and more common. I also had the opportunity to talk to many WordPress “superstars” like Andrew Nacin, Nikolay Bachyisky and The Matt.

Putting together a conference of over 700 people can not be an easy task, but everything went pretty much without a hiccup (there were occasional wifi problems but that’s almost to be expected). A big thanks to the international team of organisers!

Hello WordCamp Europe attendees! My name’s Daniel and I live in Tampere, Finland. After seeing similar posts by Rhys, Nuno and Jeremy, I thought I’d steal the idea and introduce myself to the WordCamp Europe croud in blog form. Hope you don’t mind.

So here goes: I’m the main translator for the Finnish version of WordPress and get paid by my employer H1 to work on interesting WordPress projects all day long. My first experiences with WordPress date back to 2005, professionally since 2008. I’m traveling to Leiden with all my beautiful colleagues (Aki, Jaana, Marco and Markus) so it’s going to be a grand weekend!

In addition to learning lots of new things from the conference sessions, I’m looking forward to meeting fellow WordPress professionals and discussing the following topics:

Using WordPress as an application platform

Scaling issues in deeply hierarchical and/or multilingual sites

Development/staging/production environments and workflows for teams

We’re arriving in Leiden on Friday evening. See you there folks! Meanwhile you may connect with me on Twitter.

I gave a short talk last Saturday on accessibility at Treweb, consisting of a few easy tips you can do to improve the accessibility of your web site or app, as a developer. This blog post is a summary of my main points.

Don’t prevent keyboard-only navigation

There are various reasons why some might be unable to use a mouse, but good keyboard support for web navigation also benefits power users. Unfortunately, some of the most popular CSS frameworks and resets include the following rule:

a:focus {
outline: none
}

While this makes a lot of graphic designers happy, in practise it makes tabbing through links on a site practically impossible. Often the frameworks expect that you will redefine your own focus styles, but this rarely happens. The best option then is just to not disable them in the first place. A good second is to make hover and focus styles the same:

a:hover,
a:focus {
background: #990099;
}

In forms, it can help to have a similar distinction for the active element, especially if the form is long. Placing form elements on top of each other (instead of side-by-side) will also make keeping track of the focused element easier.

Make pop-ups easy to close

Pop-up windows should be easy to get rid of, whether they’re “virtual” modal layers or actual windows (increasingly rare). It doesn’t matter if the pop-up was created via a user action or not, closing it should be simple both with a mouse and a keyboard. Make the click target big enough (see below) and support the ESC key:

Big click targets

In today’s touch-device-filled world you should be doing this anyway, but large click zones will also help anyone with difficulties using a mouse, such as people with Parkinson’s, the elderly, or you after a wild night out. For touch, a generally recommended size is 44 pt. Read this post by Luke Wroblewski on Touch Target Size.

Dropdowns

A long-time favourite annoyance of mine are large dropdown menus that just won’t stay open. Setting a delay (500-1000 ms) before a menu closes (after the mouse cursor leaves) will help all users. Also, test tabbing through your menus with a keyboard, can you tab through to the dropdowns?

Support custom stylesheets

According to the European Dyslexia Association, dyslexia affects about 8% of the population. Often dyslexics find that using a different font (such as Comic Sans) can help reading, so it’s a good idea to keep basic typographic styles fairly simple, thus making them easy to override with a custom style sheet.

Use WAI-ARIA landmarks and roles

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

In brief, ARIA includes a large set of attributes that add more semantics to HTML, and are especially useful in making complex dynamic UIs accessible to assistive devices, such as screen readers. However, the accessibility of any web page can be improved by ARIA landmarks, such as role="article", main, navigation, search and complementary. All popular screen readers support dividing the page into according to these roles, thus making skipping to a specific area of the page quicker. I won’t go into more detail here, instead I suggest reading this introduction to landmarks on the Opera website.

The default theme for WordPress has included ARIA landmarks for at least the last 4 years.

Use enough contrast and support zooming text

For users with low vision and/or color blindness, a sufficient contrast between foreground and background is important. Total black-on-white is not necessarily the best option though, instead a slightly off-black (#222) on off-white (#eee or #ffe) might be better for a lot of users. For a long list of different contrast checking tools, go to 456 Berea Street.

Also check that your site supports zooming without breaking the page and hiding content. Using Ems and percentage units will help there.

Books

There are many books on accessibility, but I can recommend these:

The Accessibility Handbook by Katie Cunningham (published 2012)
Short and practical and fairly up-to-date, my presentation (and this blog post) was strongly inspired by it.

Sublpress is a new extension for Sublime Text by Nic Dienstbier that makes it possible to manage your WordPress site (or multiple sites) in the editor. Currently you can edit settings, create and edit posts and manage taxonomy terms. All features can be easily accessed via the Command Palette.

Creating a new post with Sublpress

I tested Sublpress in both Sublime Text 2 and beta of Sublime Text 3, and my initial impressions are it seems to be a bit more stable (ironically) in the latter. This could be just something relating to my setup however.

Sublpress options

I’m still not entirely sure whether I want to manage my WordPress sites in my text editor, but if it sounds like fun to you, go get Sublpress on GitHub.

In an earlier post, I promised to shed some light on our git workflow for WordPress projects. The above image sums it up pretty nicely, but read on for the details.

Most of the development we do happens in a local Apache + PHP + MySQL environment, using MAMP Pro. That means I have a local copy of each site I’m developing, which creates some overhead compared to everyone just working on a central dev server. It’s worth it though because it makes working on different features and code branches easy.

Repository structure

Every project has its own git repository, which we set to the WordPress root directory. This is because most of our projects involve a combination of custom themes and plugins, and it makes sense to group them in a single repository. We still don’t want any of the core WordPress code in git, so we use a .gitignore file based on this excellent template by Joe Bartlett:

Sharing code and automated staging with Beanstalk

When I want to share code with my colleagues or am ready to something to a client, I do a git push to a central repository hosted on Beanstalk. Beanstalk has loads of useful features, but the best thing about it has to be the simple deployments it offers. For all projects, we set up automated deployments to a staging server, where we have copies of each site. Deployments to production are also set up in Beanstalk, but (intentionally) require a manual click in the web app.

Going to production

Finally, moving from staging to production can require some tricky search-and-replacing domains and absolute paths in the database. WordPress in Network mode tends to be particularly keen on saving the site URL in way too many places. One way to do this is to perform a search and replace on a SQL dump, but we use this nifty tool by Interconnect/IT, because it correctly handles serialised strings, which are often used in WordPress for things like widget options etc. The same tool is useful when doing the reverse, ie. creating a local copy of an existing site.