Building a Level AAA Accessible WordPress Theme for Wuhcag.com

In this blog I speak to Isabel Kowalska, the brains behind the new accessible WordPress theme here at Wuhcag.com.

Tell me a little about yourself and your organization?

We are a team of four brands related to web development services and software for Joomla and WordPress. My name is Izabela Kowalska, and I am the manager of two of them, Joomla-Monster.com that provides Joomla templates and extensions, and PixelEmu.com that delivers WordPress themes & plugins.

How long have you worked with the Web Content Accessibility Guidelines (WCAG) 2.0?

The first time WCAG appeared for our team as a subject to consider, and later implement in our products, was July 2015.
We kept learning about technical solutions and the possibilities to use them with our products. As a result, we’ve released the first Joomla template with WCAG compliance, and after the great appreciation from our customers we expanded the knowledge and tried to repeat the same process with WordPress themes and plugins, and we did it with success.

The best proof of our success as a team is a warm feedback we receive from our customers. Due to the legal requirements in many countries, website owners need to look for solutions for their websites to make them accessible for people with different disabilities. They find our products suitable for their needs. What is more, many web developers use our web templates to build websites for public institutions.

One example I can share is one of our customers who has been awarded at WCAG conference in Poland for creating the website using our WCAG ready WordPress theme.

What steps did you take to analyse wuhcag.com against WCAG 2.0?

We always make a list of all available pages on a website and test them all step-by-step, taking into account the knowledge we previously learned from the Web Content Accessibility Guidelines and of course, the valuable help gives us WCAG validators like wave.webaim.org or achecker.ca/checker.

There are more and more other validators appearing, but usually, they are marked as the “testing phase” so until they are not stable versions we use the most recommended and popular checkers.

Once we have a list of all potential issues, we verify if they are results of a theme bugs (code) or the incorrect content implementation.

How much of your analysis is automated and how much is human?

All available WCAG checkers allow automating the process of catching potential problems since they give many suggestions to understand (a significant step while creating WCAG compliant website) and solutions to solve them. However, there may appear issues on the website not reported by WCAG checkers for example problems with menu navigation using shortcuts. In other words, WCAG checkers are not always 100% effective.

What is more, sometimes web accessibility checkers report false information. That’s why we may treat them all as great helpers while making a website accessible for people with disabilities but if we want to get the full tested website against WCAG compatibility it is recommended to test it by people with disabilities.

Our first project was a WCAG-ready Joomla template for the polish organization that launched the project KUŹNIA DOSTĘPNYCH STRON. The great team from the organisation arranged the environment to test this first WCAG-ready website template by people with different disabilities. Thanks to this, we received the great portion of knowledge to improve our work and implement those solutions in next our projects.

Since our customers come from all over the world, we often receive very valuable feedback from them. We collect all reported issues, verify them and, where possible, improve our products.

How did the original wuhcag.com score against WCAG 2.0?

The report was quite positive. The content of the website is prepared correctly and passes HTML5 coding web standards which result in the low scope of work with the content improving for WCAG standards. The issues related to WCAG compliance were not complicated but resulted in the bad WCAG validation level. Actually, it did not meet the lowest one – WCAG A level because of issues like contrast errors, multiple search labels or lack of ALT attributes for images.

What problems did the original wuhcag.com present?

The most popular problem was lack or wrong (too long) ALT attribute for images used on the website. It’s the alternate text for an image which plays a significant role for people with visual disabilities.

The other ones were related to links named “continue reading” which may be not clear to understand since it has to described for screen readers what content will be displayed by clicking on “continue reading”. The other problem was a low contrast for several website elements, usually links.

What was the impact of these problems on visitors with disabilities?

The problems mentioned above were not very serious. However, visitors that struggle with visual disabilities may sometimes feel lost on the website taking into account issues related to unreadable elements on the website – contrast or lack of ALT for images.

The whole overview of the website was at the high-level thanks to the correctly implemented content.

What process or strategy did you use to fix the site?

The website was quite simple with the minimalist design, in our opinion it’s the primary value and we wanted to keep it. That’s why we decided to choose also clean and not intrusive design of Simple WordPress WCAG 2.0 theme. This WCAG WordPress theme includes many facilities for people with disabilities like high contrast modes, font size switcher, “page layout switcher” or “skip menu” feature that allows jumping to the selected site section (recommended for front pages composed of many parts). The theme is also optimized for the shortcuts to let site visitors navigate with ease.

The next step was posts and pages verification according to WCAG validators reports; all needed to improve understanding the content while using screen readers. For example, using the specific code in the theme, screen readers may recognize the content that should be read or omit website elements that shouldn’t be read.

What were the technical challenges and achievements involved?

It’s simple website taking into account the website components. However, there are many blog posts, and pages, all of them about 100 items required separate verification against WCAG.

Did you work with a team?

Yes, we work in a team and if any problems we talk about solutions in a team. This task was done by two specialists who tested the website.

What was the result of your work?

First of all, now the website has the better support for screen readers and is more accessible for people with visual disabilities.
Site visitors may use shortcuts while navigating the website which is the significant ease of website browsing usability. The visibility of each link is now marked with a red border focusing on the active element like links or inputs in a form.

What Level is the site at now?

At the time of finishing the work on the website, I may say it meets WCAG 2.0 AAA criteria including website design contrast which is 7:1 and all verified content.

However, I would be far from determining the fixed website WCAG level since each WCAG requirement applies to different WCAG criteria and it may occur that one issue may significantly affect the whole website and decrease overall WCAG level. For example, let’s assume the scenario. If now, today, we claim that the website meets AAA level it may occur that tomorrow the new post with WCAG bugs will be published, that may disqualify the website from the highest level!

That’s why besides technical requirements that must be met the most important is caring about the quality of content. The WCAG ready WordPress theme is a great help and tool to create a WCAG ready website.

I’m very happy we could work on this project. It was a pleasure and challenge for us to work under the eye of such a WCAG specialist like Luke. If he is satisfied with the final result then we, I mean our team, are satisfied twice!