WPML versus qTranslateX – a Clear Winner?

All over the world people use multilingual websites so they can get information they want in the language they prefer. Closer to home, in Wales, a large minority of web users prefer to access content in Welsh. For this reason, many businesses and organizations in Wales provide bilingual websites giving their visitors the choice to read Welsh or English.

When building a bilingual website there are different approaches to consider depending on what the project needs.

For WordPress, a popular choice for managing websites, handling bilingual content is done through addon plugins. I tend to use either qTranslateX or WPML. Which one I’d choose would vary from project to project. As well as the project spec, an important decision factor is the experience and preferences of the team involved in looking after the website.

Comparing the 2, on balance I prefer qTranslateX. I’ve used both plugins on a variety of projects and qTranslateX just feels easier. Easier to use and easier to integrate with other plugins – a simpler way of doing things. When I have to do something new with WPML it usually feels like a mission to work out how to do it, whereas with qTranslateX everything’s where you expect it to be. But in the end they both do a great job of managing a bilingual site.

Chalk or Cheese?

A fundamental difference between the 2 plugins is that WPML creates a new post for each translation while qTranslateX uses just one post to hold both languanges. This offers pros and cons with different situations and set ups.

WPML provides a comprehensive framework for multilingual content, and it feels complicated. Translation is done through various interfaces within the framework and it can be confusing to find out where to enter a translation. That said the support team and forums are great, and you’ll find most of the issues people come across are fixable – either by changing or refining the settings, or finding out where something is translated.

To take advantage of all of WPML’s features you need to install a suite of plugins which will allow translation of everything including media items such as images and galleries, and slugs (the URL address of each page). Some of the bigger plugins like WooCommerce, Yoast SEO and Event Manager have plugins that interface with WPML creating extra admin fields for translation.

QTranslateX, on the other hand, uses ‘languange tags’. These tags allow you to add multiple languanges in the same post, or content type (e.g. menu items, custom post types, categories, other taxonomies). So adding a translation is done there and then on the same screen. Most of the time You can switch between languages using the WYSIWYG language tabs and you’ll never see the tags at all.

Occasionally, you might find one of the plugins you’ve got installed hasn’t got the language tabs set up on an editable field. If this happens you can simply enter your translation using language tags – they look like this: [:en]Welcome to Wales[:cy]Croeso i Gymru[:]. This is a quick handy work around, just pop in the language tags and [:fr]Voila![:]. When you’ve got a bit more time you can make your field translatable in the Advanced Settings.

Translating pages or posts.

With WPML you first create your post in one languange. When you’ve finished writing your post and saved it, the ‘plus’ icon in the Languages box shows you that you need to add a translation. Click this and it creates a new post. There are buttons to either ‘Copy content from [Welsh/English]’ or ‘Overwrite with Welsh Content’, handy if you’re translating directly in the editor window. When the translation is saved, and has been correctly linked with its sibling, you can click between the languange versions.

In qTranslateX both translations go into the same post. There are tabs within the edit window which allow you to click between the languanges. Click ‘Publish’ or ‘Update’ and this saves both languages. Simple.

Translating your theme and plugins

Most themes usually allow you to change the text pretty much everywhere, but there may be things like buttons or forms labels for instance, that are hard coded in the templates. When you test the website, you realise they’re not translated. This is where WPML’s string translation comes in. WPML > String Translation will list all strings and show if they’re translated or not. Use the search box to find your string and click translations to add your translation. (‘String’ is a term for a string of letters or numbers that are human readable i.e. a word, or a phrase, or a sentence).

qTranslateX does it a different way. Instead of the ‘String Translation’ tool, qTranslateX relies on the special language files that WordPress use for ‘WordPress in your language’. These files hold all a list of all the ‘strings’ with a translation for each string. These files are are MO (Mobile Object ) files and are made with the open source gettext language framework.

California Dreamin’ …
…The MOs & the POs (and don’t forget the POT)

In a nutshell, by using the gettext framework, WordPress provides language files for over 160 languages. Teams of volunteers contribute to the language files to make sure they’re up to date with the latest version. Plugin and theme developers are also encouraged to provide a language template (file extention .pot) and some language files (which have file extention .mo and .po). If your language isn’t there you can us the template to add your own language.

How does it work? And what’s POT, PO, MO?

1. POT – Portable Object Template:

The POT is made by the theme or plugin developer. It is simply a list of all the strings (messages, labels, phrases etc) used in the theme or plugin.

2. PO – Portable Object:

Using the POT the translator will create a PO for their language by adding suitable translations for each phrase. A theme often ships with a few PO files already translated for popular languages.

3. MO – Machine Object:

The PO is then compiled into a MO file that can be read by computers and is used by WordPress to display the website in the correct language.
The MOs and POs are provided with the plugin or theme in the language folder.

If you find an untranslated string it can be added to the MO file using tools such as POedit. For further reading check the WordPress website: [https://developer.wordpress.org/themes/functionality/localization/](https://developer.wordpress.org/themes/functionality/localization/)

Translating your menus

In WPML you need to create a separate menu for each languange. You use the menu translation and menu syncing features to set the languange, and link the translated menus together. Follow the instructions on their website carefully! The menu sync feature is a good idea, allowing you to compare the 2 menus and correct any discrepencies. But it can lead to unexpected results, again follow instructions carefully.

QTranslateX uses the language tab toggle within the menu editing screen. You have just one menu. Menu items are translated behind the scenes with the language tags within the menu items. For a while (round about the release of WordPress 4.5) this was buggy for large menus, but the team has fixed this.

Translating categories and tags
Don’t forget the milk [white, drink, calcium]

For content writers and editors this area seems to be a sticking point. They are used to choosing and adding new categories and tags from the post editor when adding a post or page. But translating the tags and categories often gets forgotten. This is probably because in both plugins you have to leave the post/page editor to translate categories, tags and other taxonomies. For both plugins you need to go to categories/tag editor. WPML also has a separate Taxonomy Translation screen to allow you to manage translation of all taxonomies in one place. Until a better way of doing this is released, it’s going to continue to be a training issue.

Translating slugs

Slug translation is integral to the way WPML works. Because of the way it creates a separate post for each language, it automatically creates a different slug for each language.

With qTranslateX the slug is the same for each language. While there’s a plugin you can install to translate the slug, I’ve not actually used it myself. I’ve never found a good enough reason use it. For each plugin you add to WP you increase the system bloat, making it increasingly difficult to keep software to date. Anyhow my feeling is if slug translation is important to your project, use WPML.

In summary/ In a nutshell/ round up

qTranslateX is free (although donations are welcome), so this might be a clincher for some people. It’s also a bit more hands on: customizations can be added through the functions file or directly in the templates. And the language tags can be used to add quick and dirty translations. For additional translations to theme and plugins you’d need to update your MO language file. For support you need to use the forums.

WPML is a pay-for plugin (cost $79 annually, $199 unlimited). It can be confusing and complicated to get new features set up. On the plus side, they have a great support team, where you’ll get an answer to your problem, if it hasn’t been answered in a previous thread. And there’s an interface to do most things you need to do.… Once you found out where…


While researching this blog I checked back to the grid on the WMPL website that compares WPML to alternative language plugins ( [https://wpml.org/home/comparing-wpml-free-paid-alternatives/](https://wpml.org/home/comparing-wpml-free-paid-alternatives/) ). The grid shows that while WPML does ‘everything’ on the list, qTranslateX only does ‘basic translation controls’. As you might guess, this is not the whole story. To be clear, for WPML to do some of the things in this list, you’d need to install an add-on plugin (e.g. string translation). Plus, some of the things (that this grid says qTranslate can’t do) are available in qTranslateX (e.g. menu translation) or can be done with a plugin (e.g. slug translation). However that aside, it’s qTranslateX ‘basic translation controls’ that make it so attractive!

Accessible xhtml tables 1: scope, id, headers

I haven’t had much call for creating hard core data table in my websites as most of the web work I do is promotional websites for companies in the tourism and leisure industry. However when asked to re-write some xhtml for an online bookings system I found some of the information generated seemed to lend itself to tabular organisation.

So I started to wonder if my limited knowledge of tables and table headers <th> was enough to make my tables accessible. Would I need to use <tbody> for instance. Is it necessary to use the scope attribute in the <th> element? What is the difference between a summary and a caption?

As it happened I decided that using a table for the data in question wasn’t the most semantic choice, but my appetite whetted, I thought I better brush up my table knowledge… just in case!

How do screen readers access tables?

Bim’s article on the RNIB website (Better Connected, Better Results: Table Headers) has got a great description of a screen reader user trying to navigate a table with no table header or <th> elements. Quite a task involving guessing which table cells hold the key heading information then trying to remember where you are the table and probably doing quite a bit of scrolling back and forth to work out what a particular piece of data represents.

She then goes on to explain how much easier it is when key information is coded as <th> instead of as <td>. When scrolling down a column, the row headers are announced together with the data. And to check which column you are in, instead of scrolling back to check, a keystroke will prompt Jaws to announce the column heading information. Although by default Jaws announces the row header and on a key stroke announces the column header, other screen readers may act differently.

So is <th> enough?


Do we need to include the attribute scope? I guess it would depend on the type and complexity of data you had to describe. If your table headers happened to be on the second row or second column for instance, it might be unclear as to which data the header described. With scope you can be certain.

What does the WCAG2 say about scope?

Scope can be an attribute of a table cell <td> or header <th>. Its values ‘row’ and ‘col’ (or ‘rowgroup’ and ‘colgroup’ see below) says whether the cell describes a row or a column.

Because the presence of the scope attribute implies the data in that cell is heading data, WCAG2 says you are allowed to use it in both data cells td or header cells th. However its suggested use is for data cells marked up with td that are actually header cells (although I’m not sure why you don’t just use th in this case … )

WCAG2 link: H63: Using the scope attribute to associate header cells and data cells in data tables

Note: The ‘rowgroup’ or ‘colgroup’ attributes are used to say if the header data describes groups of rows <thead>, <tfoot> and <tbody> element, or groups of columns <colgroup> element. See the w3c sample table, more info on rowgroup and more info on colgroup

Id, axis and header attributes

Scope isn’t consistently supported across screen reader technology apparently. So for more complex tables, a more robust alternative to scope is to use the ‘id’ attribute of a <th> and ‘headers’ attribute of a <td> to directly link a data cell to its header. The ‘axis’ attribute also allows you to give more information about your headers e.g time, location, weight, colour. It also allows you to style the table to make the info easier to understand.

Holistic healing work shop example

Dining Room Morning Room Blue Room The Orangery
Mon Flower arranging Origami Crystal healing Pottery
Tues Egg decorating Water colours Reflexology Yogurt weaving

<th id="dining" axis="venue">
Dining Room </th>
<th id="morning" axis="venue">
Morning Room </th>
<th id="blue" axis="venue">
Blue Room </th>
<th id="orange" axis="venue">
The Orangery </th></tr>
<th id="mon" axis="day">
Mon </th>
<td headers="dining mon">
Flower arranging </td>
<td headers="morning mon">
Origami </td>
<td headers="blue mon">
Crystal healing </td>
<td headers="orange mon">
Pottery </td>
<th id="tues" axis="day">
Tues </th>
<td headers="dining tues">
Egg decorating </td>
<td headers="morning tues">
Water colours </td>
<td headers="blue tues">
Reflexology </td>
<td headers="orange tues">
Yogurt weaving </td></tr>

What does the WCAG2 say?

If a table data cell has more than one header associated with it (e.g a row header and column header), it must have a headers attribute that lists all of the ids of the associated headers. Thus each header cell must have a unique id.

WCAG2 link: H43: Using id and headers attributes to associate data cells with header cells in data tables

Next up Captions and Summaries!

Pobol Peblig website gets accessibility standard

I’m very pleased to announce that the bilingual Pobol Peblig Partnership website has been awarded the RNIB’s (Royal National Institute of the Blind) See It Right standard for web accessibility. For more information on See It Right, other audits and web accessibility visit the RNIB Web Access Centre.

Our experience of the See It Right auditing process was very positive. It challenged our perceived understanding of web accessibility and allowed us to create a fully accessible solution for our client. The following is an overview of our See It Right experience with some examples of issues we faced and how we solved them.


Pobol Peblig Partnership is a Communities First project in Caernarfon North Wales. Communities First is a WAG program to help and support to the most disadvantages areas in the country. Peblig ward lies in the top 10% of the poorest in the country and is eligible for Communities First support. Tai Eryri has been running the project for 7 years.

The main emphasis of the project is capacity building; building skills, experience, knowledge and confidence of the community members, allowing all developments to be community led. The website reflects this dynamic by playing an important role in communication between volunteers, publicity of events, meetings and activities, sharing resources and ideas.

The Pobol Peblig website was built by Chris Slinn of Free Range Developers and Kate Watkiss Interactive Design. More background information on the Pobol Peblig web build.

Choosing See It Right

Having previously undergone staff development training with the RNIB. The Pobol Peblig staff decided that the new website would benefit from RNIB’s web auditing process.

As we were in the relatively early stages of building the site, we were advised to go for the See It Right development audit. This audit guides the web development process to ensure that the finished site is accessible. The development audit also allowed us to continue building the site as normal and once the first check was done and the solutions implemented, we were able to apply the same rationale to the continuing build.

Audit Process

The auditor goes through the site checkpoint by checkpoint. When examples of failures are found, they are reported, together with the URL, code snippets and a clear explanation of why they have failed and the impact on users. The report gives a comprehensive set of instructions, telling you exactly what to do to make the site accessible and why.

The emphasis on how the issues impact on the user makes the report more that just a set of corrections. Not only does it explain how to make the current pages accessible but it also provides a framework to enable the designer to evaluate problems in the future, helping with decisions on how to tackle issues from functionality to design and layout.

We had 2 rechecks after the initial assessment. And at the end of the last recheck we had an informal email exchange with our auditor, Bim Egan, giving us the chance to tie up a few loose ends (thanks Bim!). The rechecks allowed us to address unresolved issues from the first report and assessed new issues that had arisen during the build.

Throughout the process Bim was available to answer questions. The answers were comprehensive and relevant to the site’s specific problems. If we had reasons for not wanting to implement suggested solutions these reasons were listened to and we managed to reach a solution which was agreeable to everyone.

Issues with our CMS

When the first report came back we were well on the way with the construction of the site and had started to populate it with content.

We’d chosen to use Joomla as it has a quick learning curve for the web authors. This was an important consideration as the staff at Ty Peblig would be taking over the website updates and management. And from the development point of view, Joomla also has the added advantage of a variety of open source plugins from the Joomla development community. We chose to extend the basic functionality with plugins such as the calendar and comment modules.

The CMS and plugins generate html code snippets for menus, and other content modules and components, which slot into the site templates. By working on the site templates we were able to make the overall structure of the page accessible. Once the changes to the site templates were made we were ready to look at the generated code.

There is a strong relationship between accessibility and web standard compliance. If your site meets web standards you are well on the way to being accessible. Good quality code means your site is easily transported to different user agents and technologies. The various Joomla plugins on offer deliver a wide range of functionality, however there are also wide differences in the quality of code generated. The failed code had to be identified and then modified according to the See It Right report.

Other issues we faced related to the way Joomla dictated how information was organised. We found some code blocks were generated that didn’t make sense semantically when applied to our content. However Joomla was flexible enough to allow us to ‘shoe horn’ our content into the system and generate semantic and accessible pages that we could easily style up.

Layout and Semantic Content

For various physical and technical reasons a number of people use the keyboard tab key to navigate through web pages. The order of the code and the layout of information on the page should be such that the tab order is logical, and focus moves smoothly across the page without jumping back and forward.

In our original design we put a search and contact link on the top right of the page. We’d positioned them here partly to conform to convention and partly in order to visually balance the page elements. Since we had implemented a logical code order in our page, positioning the tools to match our conventional layout moved the tools out of the flow of the document. This caused problems with the tab order.

The expected tab order would be to tab left to right through the section links at the top and then through the tools (search, contact etc) at the top right. BUT we also had a context menu down the left. Logically, the context menu came after the section menu in the code. So after tabbing through the top section menu and down the context menu on the left, the focus jumped back up to the top to get to the tools.

Following the advice given, we repositioned the tools to fit under the contextual menu allowing the tab order to move logically across the page. Moving the tools down also provided extra space across the top of the page so the user could increase section link text size without the text overlapping.

Bilingual Content

The Pobol Peblig Partnership website is a fully bilingual website complying with Welsh Assembly Guideline: Publically funded projects in Wales must provide all public communications in both English and Welsh. Because the first language of most of the Peblig residents is Welsh this is a very real, practical requirement.

Coding language changes

Language implementation has a particular impact on screen reader users. When the language of a page changes, it must be coded so the screen reader software can select the appropriate language with which to read the page. It is the ‘lang’ attribute that tells the screen reader what language to use.

The language of an entire page is coded in the ‘lang’ attribute of the html element which surrounds the entire page content and meta information. This means if lang=’cy’ every text string that will be read by a human must be in Welsh, and conversely, if lang=’en’, human read text must be in English. If text occurs in this page of a different language to the page overall language, it must be coded.

We used a language switcher, so there is both an English version and a Welsh version of each page. As the site is dynamic and regularly updated we needed to make sure all articles were translated, if no translation was available there would be a line of text explaining a translation was on its way. As it happens the staff have been entering Welsh and English text at the same time so this hasn’t really been a problem.

How to code everyday Welsh

The main problematic issue was the implementation of ‘bilingual’ project titles and organisation names.

The way the Welsh language is developing, as those living in Wales will know, means that words are being incorporated in everyday Welsh (and English) that are hybrids of Welsh and English. Some of the projects use regional slang Welsh for the project names and these names are used whether the residents are speaking Welsh or English.

An example is the walking project ‘Miglo’. Miglo is a ‘cofi’ word which means escape (or ‘dianc’ in Welsh). Miglo is used in both Welsh and English conversations. Another example is the sex education project ‘Jiwsi’ run by the FPA (Family Planning Association). The name ‘Jiwsi’ is a welsh spelling of the English word juicy.

In both these examples the title can be considered bilingual and can be used in both the English and Welsh pages. In other instances, because our residents only used the welsh project names anyway it was harder to establish if these were really bilingual names.

We approached Bim with this problem who returned with this very practical advice: Ask the question ‘would English speakers refer to the project or organisation with its English name?’, if not, use an English translation followed by the Welsh name, if they would, just use the English name.

Training and Accessibility

As our website is a communication tool for Pobol Peblig and they are in the process of taking over the management it was very important that the staff also understand about web accessibility, the impact it has on users and how to make sure new content they put in is accessible.

The clear explanations and solutions given in the audit have allowed us to easily create training material and give practical advice during the handover period. The staff now have a broad understanding of why websites need to be accessible and the types of usability issues that need to be addressed. We have also covered how to make sure the Pobol Peblig website remains accessible. Ongoing website update training will reinforce the specific accessibility issues as they come up.

Your domain name: updating DNS settings and domain transfer

If you have your site redesigned or change your web hosting you will want your domain to point to the new site. This should be straightforward if you registered the domain yourself and look after your account. If someone else registered the domain for you, you might come across problems. This article explains what you need to know, gives a bit of background about domain names & the DNS, and how to go about solving any problems you come across.

Are you the legal registrant?

Before you start you’ll need to check if you are the legal registrant of the domain. You’ll also need to know the registrar i.e. the company who you registered the domain with, and your user name and password for your account with the registrar.

If you haven’t got this information already you’ll be able to find it by using a ‘WHOIS’ query. You can make a WHOIS query for a domain name by using the following services and entering your domain:

For domains ending in .uk use nominet’s WHOIS service.

Nominet is a not for profit organisation that looks after the registry of .uk domains. See this wikipedia article for more info on Nominet.

For other domains including those ending in .com, .net, and .info use Internic. This will generally give you a referral web address (see note). Go to the referral website and make a WHOIS query from here.

Referral Web Address: The reason you have to go to a different website is because the company you bought your .com (or other) domain from has bought a load of domains ‘wholesale’ from a registry operator Eg. Melbourne IT or Tucows, and has sold the domain on to you. These are known as resellers or retail registrars.

For more detailed info read the WHOIS article in wikipedia

The query will give you the name and address of the legal registrant (hopefully it is you, or someone you know). It will also show the company you registered with i.e. your registrar.

In order to update your domain name with your new website details you’ll need to login to your account. If you have lost your login details you can contact your registrar’s customer services and they’ll be able to help.

If your domain name is in the account of a third party (e.g. your web designer, or consultant) and you no longer want to work with them you can get the domain transfered into your own account. Scroll down for more info on DNS transfers.

If you are not the legal registrant you will need to get the domain transferred to you. Scroll down to read more about changing the registrant details.

Updating your domain records

Login to the control panel of your registrar and change the A record for web hosting and MX record for mail hosting. The A record is the IP address of the computer where your website is hosted. The MX record (or Mail exchanger record) is the IP address of the computer where your email is received. Your webdesigner or hosting company will be able to tell you the IP address for both these records.

How it works: When you type your domain name into a browser (e.g. Firefox) it will find the Name server. This is a big computer that holds the registry where your domain name is sitting. This is where your A record comes in. The name server uses the A record to redirect the browser, across the internet, to your web host, where all your web pages are waiting to be seen.

How exactly you change these records will vary from company to company. But you’ll probably need to go to your list of domain names, click on the one you want to update and look for DNS settings in the menu options. Click here and you should be presented with a selection of settings. Look for A record and MX record and fill in your new IP address. If this looks scary contact your webdesigner and ask them to do it for you!

It can take 24 hours or more for these settings to “propagate” around the internet so don’t worry if you don’t see your new website straight away.

Changing the registrant details

If you have bought your domain through a reseller (e.g. your web-designer or marketing consultant) they may be listed as the legal registrant. If, for whatever reason, they are no longer able to look after the domain for you or you lose contact with them you will need to regain control of the domain by becoming the legal registrant.

You‘ll need to ask the reseller to change the registrant details, For all .com domains this is free of charge. For .co.uk domains they will need to login to their nominet account and initiate the transfer process, which has a £10+VAT charge.

This is the number for the nominet transfer service at the time of writing: 01865 332244. You can also get more information and request a call back from the tranfer page on Nominet’s website:

If you’ve lost contact with the reseller you’ll need to prove that you are the legal owner of the domain so the registrar can change the registrant details for you. Contact the registrar and explain the situation. They’ll tell you exactly what you need to do.

DNS Transfer

Once you have the domain in your name you have 2 options:

  1. Keep the domain with the current registrar
  2. Move the domain to another registrar by changing the ‘TAG’

Keep the domain with the current registrar

The simplest thing to do is to keep the same registrar. This is a two step process (substitute [the registrar] for your provider e.g. Namesco, UKreg etc.):

  1. set up an account with [the registrar].
  2. send a fax on headed paper saying that you are the legal registrant and you want your domain(s) moving to your account giving the rererence number of your account. Sign it and give the position you hold in your company

They will then contact eh previous account holder and explain they will need to move the domain. The domain will then be ‘Pushed’ into your account

Move the domain to another registrar

You might have good reasons for changing providers. For example you feel the cost of domains, quality of customer service or range of services are better with another provider. Or you have other domains and you want to keep all your domains in one account.

The old provider may charge for this service and the procedure will vary slightly from provider to provider however your new provider will be glad to help you as they want your business!

123-reg gives their customers step by step instructions on how to transfer away from a variety of different providers (see the domain transfer guides under step 1)

This wikipedia article outlines the detailed stages involved in Domain name transfers.

Building an Accessible Website: RNIB See it Right

A website I’ve just been working on (Pobol Peblig Partnership) is currently being audited by the RNIB under the RNIB See it Right accessibility standard. This article covers some of the things we learned through the audit process, with background information to help understand how to approach building accessible sites and then gives some practical tips and things to remember.

Who are your visitors?

Your website visitors are likely to be a diverse group of individuals with different levels of experience, using a variety of different web browsing technologies as well as having a range of needs and preferences. Someone who is partially sighted, for example, may have difficulty viewing a particular webpage but increasing the text size will allow them to read it. A visitor with a slow internet connection may decide to turn off the images to make download times quicker.

Note: Mark Pilgrim introduces us to a diverse bunch of internet users who use the net in a variety of ways in his excellent download Dive into Accessiblity.

What are they using to view your site?

There are different assistive technologies out there to help you if you have particular browsing needs such as screen readers, brail displays or alternative user input devices. Many of these work along side a visual browser. Alternatively you may prefer not to use additional assistive technologies but instead, tailor your visual browser to meet your particular requirements. Or do a bit of both.

The key thing to remember is that users have found their own way to do things based on the technology they use, practical necessity and personal preference. As web designers, who are we to tell our users what to do? An interesting piece anecdotal evidence that illustrates this, relates to website keyboard shortcuts or “access keys”. Although aimed at users with motor difficulties, apparently the majority of users who use access keys are actually web developers who routinely use keyboard commands in their day to day jobs.

Although including access keys is necessary for WAI priority 3 compliance, there are issues with its use and it is not required for See It Right. For more info read the RNIB’s article on access keys.

Anyway, to give your visitors the potential to have the best experience possible, whatever their browsing needs or preferences, your web design must be as robust as possible, allowing for text and colour change and able to be viewed with images turned off both with or without css styles. You should also be able to use your website without scripting or plugins. This is known as graceful degradation which means the same thing today as it did in 2002 when Peter-Paul Koch suggested:

The first step in adapting [graceful degradation] successfully is fluid thinking: accepting the unpredictability that rules the user interface of the Web.

See It Right

Although our design ticked quite a few of the accessibility boxes, we missed the mark on a number of points. Although we were thinking about accessibility from the beginning of the build, our main error was to follow our perceived wisdom as web developers/designers rather than thinking first and foremost about how the site would be used.

Bim Egan who did the audit for us was extremely helpful and her explanations were clear, and solutions offered, logical and practical. The common thread through all the different solutions we implemented was “empathise with your users”. Read more about how See It Right can benefit your visitors.

The following tips are not a how to or check list but just a few of the key issues we tackled during the audit.

Text size and positioning

You should be able to increase and decrease text size by 3 times without any text being obscured. This can be a challenge when absolute positioning has been employed and elements have been pulled out of the flow of the document.

However, by using a combination of relative (em) and absolute (px) units for position, dimensions, margin and padding, most layout designs can display at 3x decrease and 3x increase. If it isn’t possible you may need to rethink the way you’ve implemented your layout. That’s the last thing you want to do at the end of a build so its a good idea therefore to test that 3x text size increase and decrease (in different browsers) from the beginning.

Alt text

Alt text can do more harm than good. Badly written alt text can be confusing and make a passage of text difficult to understand. Use an empty alt attribute on purely decorative images.

How do I decide if an image is purely decorative? Well, ask your self if the meaning of a document can be fully understood by reading the text. If so, the image could be considered decorative as the text provides enough explanation for the meaning to be expressed. For users with images turned on in their browsers the meaning may be enhanced by a decorative image. But for a user browsing without images, the use of an ill considered piece of alt text can be very confusing. We were given the following advice in the audit

It might be pertinent to consider all content images decorative, unless they are linked images, images of text, or convey real information that helps to make sense of adjacent text.

You may decide that alt text is needed to give your page equal meaning to those browsing without images or those who find it difficult to see images. If you do, check how the alt text ‘reads’ in the context of the rest of the copy.

The key is to ensure that ALT text is given to images that convey content or bring meaning to a page. Using null ALT text for other images prevents the user experience becoming cluttered with redundant information for a screen reader user. Web Access Centre


The following examples from the audit show how alt text can be confusing for screen reader users:

… the image “Ty-Cymunedol.jpg” immediately below the question “What is the Pobol Peblig Partnership?”, audibly follows with the information from the ALT attribute “outside Tyˆ Peblig”.

In another example on the same page, the question, ” Who is the Partnership?, the image ALT appears to answer “2 Peblig Pensioners”

The Audit goes on to say:

Ideally, ALT attribute text should not appear to be a change of subject, interrupt reading flow, nor be misleading

When images are used as links

Functional images such as links use a combination of plain text and alt attribute to make the meaning of these non-text elements clear to text only browsers and screen readers. Read the link text plus alt attribute to check they make sense. Remember screen readers can’t just ignore links, and will announce the file path to the image, when there is no text available.

Our helper links to ‘print page”, “download pdf’ or ‘email to a friend’ used the following images pdf, print, email, with respective alt attributes: PDF, Print, E-mail. The problem with this code was that users without a mouse wouldn’t get a tool tip and, if they hadn’t seen the icons before or couldn’t see very well, the purpose of the links would be unclear.

The solution was to include link text (PDF, Print, E-mail) next to the image then add the following alt attributes

  • “pdf_button.gif”: ” version of this page: (new window).”
  • “printButton.gif”: ” of this page : (new window).”
  • “emailButton.gif: ” to a friend: (new window).”.

The end result will be three links, announced by screen readers as:

  • “PDF version of this page: (new window).”
  • “Print version of this page: (new window).”
  • “E-mail to a friend: (new window).”

pdf, print, email

The right tool for the job (or the riddle of the nested lists)

Inspired by Andy Clark’s book Transcending CSS I tried to make sure my site template had a meaningful order underlying the page organisation and attempted to make the most of the xhml elements available. During this process I decided to use unordered lists to create a structure within my document. For example I created a list to hold supplementary information which highlighted features in the rest of the site. I used css to display the list as a colourful side bar. This is the xhtml I used:

<ul> <li class="supp1"> <h3>Next Meeting</h3><p><a href="">18.06.2007 Ty Pobl Peblig</p></li>
<li class="supp2">
<h3>Get Organised</h3><p><a href="">Resources pages</a></p></li>

<li class="supp3">
<h3>Reports</h3><p>The partnership is drawing up reports</p></li>


Unfortunately I hadn’t taken into account the complexity of the content of each box. Some of the feature boxes contained lists of events or related projects, some contained archive links or project summaries. So my sidebar list items were expanding as the website was populated

Lists are used to describe a group of objects or bits of information that are similar in some way. It might also be useful to have a preceding header to describe the list. . A website user will use bullet points and the header to quickly get information about a list and the items within it. A screen reader user will receive the same information, but by listening to the information being read out.

Here is an example of a simple list of events being read out by a screen reader:

  • What’s on?
  • List of 4 items
  • bullet SBARC!
  • bullet Arts & Craft
  • bullet SBARC!
  • bullet Storm O Stori Calan Gaeaf
  • list end

Unfortunately this simple list was nested inside my supplementary list, so if you are listening to a screen reader to access this page you will hear:

  • What’s on?
  • List of 4 items nesting level 1 (contains 4 nested lists)
  • bullet List of 1 items nesting level 2
  • bullet SBARC!list end nesting level 2
  • bullet List of 1 items nesting level 2
  • bullet Arts & Craftlist end nesting level 2
  • bullet List of 1 items nesting level 2
  • bullet SBARC!list end nesting level 2
  • bullet List of 1 items nesting level 2
  • bullet Storm O Stori Calan Gaeaflist end nesting level 2
  • list end nesting level 1

It may sometimes be useful to code headings inside lists item content. However it is worth remembering headings also provides extra wordage in a screen reader which can add to confusion rather than enhance meaning. As it would probably be stretching the useage of a list to use it as a structural element, I will be using it in the future with more caution!

Semantic Flow and Tab Index

It’s important that the content in a document makes sense without css style information to guide the user around the page.

Equally when style information is being used to position elements on the page the order should still be logical. In other words the focus should move in a consistent, regular manner and not hop back and forward when tabbing through the document.

Although we’d carefully planned the semantic flow throughout the document, the way we’d positioned some of the elements on the page meant a jump across the page while tabbing through. When we fixed this by repositioning some of the elements, the page actually worked better visually, as well as allowing a logical tab order through tabbed elements on the page.

Remember if your page content is organised logically there is no need to use tab index and often, if tab index is used inconsistently resulting in an illogical tab order, it can be confusing and obstructive.

Validation, validation, validation!

… And finally if you validate your code, both xhtml and css, you are probably well on the way to being accessible without even trying!

Gettext: Images and Flash

Translating image replaced text

If you use CSS to replace your header text with a text based graphic remember these need translating too. By using gettext to change the lang attribute of the xhtml tag, you can then use CSS to change element background images. This gives added flexibility to wordpress plugins like polyglot and language switcher.

1. Prepare the graphics
You’ll need to prepare the graphic text for your chosen languages. Either in separate files or in one file if you are using Petr Stanicek’s (Pixy) Fast Rollovers Without Preload (note: if you create a separate graphic for each language and give it identical dimensions all you need to change in the css is the background image url.)
talk tab english version
talk tab welsh version

2. Prepare your CSS e.g.

html[lang="en"] #header h1{background-image: url(images/h.gif);}
html[lang="cy"] #header h1{background-image: url(images/h_cy.gif);}

3. Prepare your xhtml template
A well formed page should have a language attribute in the html because it helps screen readers speak more clearly and browsers to render characters correctly (more info: Language information and text direction ). It’s also a very useful formatting hook when designing multilingual sites!

<html lang="<?php _e('en') ?>">

4. update your .po file
add a message string to your .po file
#: wp-content/themes/test/header.php:42
msgid "en"
msgstr "cy"

When the user switches language the html lang attribute changes and your css pulls in the graphic with the correct language.

Changing file names using Gettext

Translating flash

You can also use gettext with the SWFObject method of embedding Flash files. Use the en string to change the file name of the alternative image and the flash file. When the language is English the image is image_en.jpg and the flash file is flash_en.swf. When the language is switched the gettext translates ‘en’ to ‘cy’ and the file names change accordingly to image_cy.jpg and flash_cy.swf.

Heres the example xhtml

<div id="flashcontent">

<img src="http://www.mydomain.com/images/image_<?php _e('en') ?>.jpg" width="654" height="150" alt="<?php _e('Alt text for my image') ?>" /></div>

<script type="text/javascript"> /* <![CDATA[ */ var so = new SWFObject("http://www. mydomain.com/flash/flash_<?php _e('en') ?>.swf", "myswfid", "654", "150", "6", "#0e0e70"); so.write("flashcontent"); /* ]]> */ </script>


A Bilingual blog

Making a blog bilingual is relatively straightforward. There are a variety of plugins available which allow you to provide your blog in two or more languages. Go to the wordpress translation and languages plugin page for more info.

They all use the gettext platform which is the GNU internationalization (i18n) library wikipedia.

A bit of gettext background

Gettext allows you to find all the natural language strings in a program by marking them up so they can be easily translated. (so string could become _e(‘string’) OR __(‘string’)). These strings are grabbed and put in a POT (portable object template), like a text file really.

Then translators come along turn the POT into a PO, and translate the strings so you end up with a French version; fr.po, a welsh version; cy.po, a British English version; en_GB.po etc. The POs are turned into MOs so they can be read by your program. And Voila! Bob’s yer Uncle you have a localised program in your language. More info on localizing wordpress

Before translation, documents have to be ‘gettexted’ as outlined above. WordPress has already gettextted its basic install. You need to make sure however, that your wordpress theme, pages and blog content have been gettexted too. Details of how you do that should be covered by the plugin documentation.

Polyglot and Language Switcher

Initially I chose Polyglot which worked really well in 2.0.5 after a few tweaks to the php files. However, after upgrading to 2.1.3 I tried to reactivate polyglot but certain sections of the site weren’t being translated.

In my original installation I’d changed some of the php functions to make sure everything could be translated. In WordPress 2.13 some of the php functions that I’d tweaked, had been changed in the upgrade. For instance the date functions are using all wp-locale, I couldn’t find where to ‘gettext’ the date. I’m sure its possible but I ran out of time.

Luckily, I found Language Switcher, a plugin that lives in a friendly hand-holding site called Poplar Software. Language Switcher, based on Polyglot, has been upgraded to work with WordPress 2.1.2 and above and has got really detailed yet easy to understand documentation. On uploading the software I found that all the “hackery” had been done for me and everything, even my illogical archive structure, was translated.