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!

Between Pixels Team

I love to hear from people who have read my book or used Wuhcag.com and used their new skills to make their projects more accessible or meet the Web Content Accessibility Guidelines (WCAG). From time to time, readers are kind enough to answer a short questionnaire case study (feel free to request one).

Today, I’m featuring the experience of Brandon Travis.

Tell me a little about yourself and/or your organisation

Foto of Brandon TravisMy name is Brandon Travis, and I’ve been a front-end developer for a total of about six years. I recently got back into the industry after leaving a career in retail leadership. I am the Director of Web Services at Between Pixels, a video production and marketing firm located in North Metro, Atlanta. We have only been formally offering websites for about a year, when I was brought in to help expand the company’s capabilities and services.

How much did you know about WCAG 2.0?

To be perfectly honest, even though I thought I knew ‘the basics’, it wasn’t until a project brief came across my desk that listed ‘WCAG 2.0 Level AA Compliance’ that I really bothered to learn it. I think that, like many developers, I waited to really learn about creating accessible web pages and applications until a project required it.

What problems were you facing with web accessibility?

My organization was hired to create an entirely new website for a local university. While we had done websites with a similar scope and size in the past, we hadn’t really had a project that specifically dictated WCAG compliance in the project brief.

We faced many challenges with this project that made it unique with a fairly high level of risk. For one, our team was still very small and relatively new to working with each other when we began this project. Additionally, as I’ve already mentioned, we never would have considered ourselves experts in accessibility before we began this project, and often fell victim to the ‘we’ll do it later’ mentality that so many teams face when under the gun.

So, for this project, we had a completely new frontend system that we didn’t design with accessibility at the forefront of our minds, and were now under the gun to deliver a finished product – including WCAG 2.0 AA Compliance.

When we first started to really dig in and audit our new site, we found numerous issues. We had chosen to use some pre-built plugins for areas like sliders and galleries, and learned early on that those developers didn’t build their products with accessibility in mind, either.

At the end of the day, we were left with a product that was well built and very performant, but had many different developers who had all implemented partial WCAG compatibility, but it was all over the map.

What was the impact of these problems on your (or your client’s) business?

Luckily, we started working to correct the issue early enough that we never had any real complaints about accessibility. Before the site went live, we ran an open beta and invited all of the university’s faculty, staff and existing students to review and provide feedback.

By the end of the beta period, roughly 5% of all the comments we had gotten could directly be related to the lack of accessibility in certain areas. For example, one thing we learned while using the WordPress Gravity Forms plugin was that we had some very unpredictable results with tabindex, depending on what other components might be on the page. In areas where we had a third-party slider or a gallery and a form created by Gravity Forms, we were almost guaranteed to have keyboard navigation issues.

How did you diagnose the problem?

To be perfectly honest, we knew that accessibility was a concern on the day we launched the Beta, so it wasn’t hard for us to know where to start looking.

What expertise did you need?

Ultimately, we still didn’t have an expert on staff that we could rely on to give us reliable information around creating accessible web applications. We needed to get someone up to speed quickly on all three levels of WCAG 2.0, and knew that we needed to get a solid grasp on things like WAI-ARIA before we could really put this one behind us.

How did you solve the problem?

Honestly, I reached out to some people in my network around where to even begin. I had purchased a few books on the subject, and looked into video courses offered on sites like TeamTreehouse.com, but we needed to start making traction rapidly. I was directed to the Wuhcag.com website via a response on Twitter, and after reading some of the first few articles on the site, I immediately bought the book.

What process or strategy did you use?

Over the next few days, I immersed myself in WCAG 2.0 using a combination of Luke’s book, website, and the W3C spec on the subject. After I considered myself to have a relatively solid theoretical understand of the ways to implement the WCAG guidelines, I put together a working session with my developers where we would examine the site within the context of one to two guidelines at a time, and determine what a particular fix would be.
We discovered that about 80% of our accessibility problems could be solved by correctly implementing about 20% of the rules that we either:

  • didn’t know about when we began working on the site; or
  • incorrectly built somewhere along the way.

What were the technical challenges and achievements involved?

Ultimately, I would say that nearly all of our problems were either related to a design element or to a third-party tool or plugin. Of course there were the random one-offs that don’t fit into these broad buckets, but those cover the bulk of the issues we faced.

Design-based challenges were honestly probably the hardest to fix, as it meant needing to go back to the university team to get approval on redesigned elements. One particular example is how we utilize video on the site as it relates to overall design. We created many background ‘b-roll’ videos to help create an immersive experience. Ultimately, these videos had no critical content or message, but were a design choice that we believed would help convey the overall atmosphere and culture of the campus. There are a number of WCAG 2.0 guidelines that relate to audio and video and what we found is that, while most of the standards were relevant to our project, not all of them directly related to how we were using video.

Additionally, one major challenge we faced was the ability to pause / pause all / pause all for good. We knew we needed some control buttons, however couldn’t use the built in controls, as these videos were basically treated like full screen backgrounds. So we had to solve a lot of problems, just with that one particular component.

When it came to third-party plugins and software, we really felt as if we had hit a major roadblock. All of the ‘rules’ say that you shouldn’t modify other people’s plugins or core source unless you are building your own version, which we weren’t. We ended up getting a pretty long way into this journey before realizing that we had critical functionality built into software that simply wasn’t accessible. For most of these tools, we were able to find relatively accessible alternatives. Where we couldn’t, we were faced with tough business / quasi-ethics related decision: do we ignore the accessibility issues and attempt a Band-Aid fix, or do we spend the time and money now to build these in-house, even though we were rapidly approaching a ship date?

Ultimately, we opted to rebuild any tools that were not deemed salvageable by our development team. Even though this introduced other challenges around hitting key dates, ultimately we felt very strongly that having a fully accessible site was the right move and would pay off in the long run.

Did you work with a team?

Absolutely! We were dealing with nearly a thousand pages, all with varying degrees of non-compliance. Ultimately, we had three developers, a designer, and a content strategist that worked in conjunction with the university to get the site to a state that we were all happy with.

How will you stop the problem coming back?

That’s the real challenge, isn’t it? During this project, we implemented a code review process that had been lacking before, and it has worked very well for us thus far. Additionally, all of our developers are fully trained in creating accessible sites and applications, and we consider it a mortal sin to push code that isn’t accessible. We also have spent a lot of time with our User Interactive (UI) Designer to make sure that she is up-to-speed on how to design for accessibility.

At the end of the day, I think we made all made a mental shift during this particular project, and realized that accessibility isn’t something you can just ‘throw in’ during deployment, and it has to be part of the conversation from day one. We make sure that we include WCAG 2.0 Compliance (at different levels, as each project dictates) as a deliverable in all of our contracts, regardless of whether or not the client has specifically asked for it. For all of our clients where we are providing any kind of ongoing support, we include a monthly or quarterly accessibility audit, depending on how active the sites are.

What was the result of your work?

We are only ninety days past our launch, so we are still working on quantifying some of our results, however initial feedback has been very positive. There were some decisions made in partnership with the university to delay certain items, as we knew that that system was either being redesigned or rebuilt over the next few months, but with the exception of those known issues, we have been able to keep things on track during our review process that I mentioned above.

Did your project find a new audience or grow its existing audience?

That’s hard to say, as this was really part of a much larger marketing project for the university. I would say that we are certainly much better equipped to cater to an audience that has special browsing needs because of the work that has been done.

Did your work increase sales?

While we don’t ‘sell’ anything on the site, per se, we do have a ‘Request Information’ form on our homepage for new students. We have seen significantly more submissions on that form since we corrected the accessibility issues that were on the homepage. Again, this could be due to a number of factors, as I’ve stated above, however I personally believe that is partially a result of having a more accessible site, as we did have several issues with this form and the page it is on before we began working to correct accessibility on the site.

Share your personal insights from the project

My biggest ‘a-ha!’ moment during this work was the realization that I had to make this a priority at the beginning of every project. This meant not just reviewing a design comp to make sure that they were aesthetically pleasing, but also making sure that what our designers wanted us to build was possible within the WCAG requirements for the project.

I also learned that I simply cannot be the only one thinking through this on every new project. If a prototype gets to me for review without my architect, designer, or developer intentionally taking accessibility into account, it could very well cost us days trying to backtrack and correct the problems. We have incorporated accessibility as a non-negotiable sign-off into every major stage of our project calendars, and would encourage every other agency out there to do the same.

Do your team have any additional insights?

While many people on my team worked together to correct the issues on the site discussed above, I had one developer that completed the majority of the work. After the project was completed, we spent some time discussing his experience and how to make the process smoother as we moved forward as an agency. His largest piece of insight was around the need to begin working on accessibility at the start of every project. As I mentioned above, we have added several accessibility checks during our development stages, and complete a full audit at least quarterly with our clients. These practices came directly out of the insight and experience that he gained while working on this project.

What worked well for you?

We utilize the checklists provided on Wuhcag.com on every single project. Those checklists, along with the book, have become a critical reference point that we utilize dozens of times on any given project.

What would you do differently next time?

I’ve mentioned it before, so I won’t go into detail, but there are two key things I will do differently moving forward.

First, we absolutely will plan for accessibility from the very beginning of every project. This means that we will define the requirements as we scope the project, and build review points into every stage of the project to make sure that we are delivering against the requirement.

Second, we will seriously audit any third-party tool or plugin before we make a decision to include it in a project, regardless of its rating or popularity. We ended up spending several days trying to make plugins work that we had already committed to earlier in the project, and that is a mistake that I am not willing to make again

What were your doubts?

Honestly, I think that, like most front-end developers, we thought of WCAG as a somewhat restrictive construct that we would ‘do our best’ with. It made it easier on earlier projects to say, ‘Well, it wasn’t really defined as a deliverable on the project, and we just never got to it inside of the timeline. Maybe during the next revision, we’ll take a look at accessibility more in depth.’ It created some serious anxiety about correctly implementing the WCAG 2.0 standards, and ‘accessibility’ had almost become this big overbearing monster that we were afraid to deal with.

Until there is a specific, billable reason to learn it, I think most developers treat accessibility as an added bonus, and we were no exception.

What surprised you?

First, it’s not as hard as one would think when first setting out to learn it.

Second, one of the mental roadblocks that I had to address is that there are several guidelines that aren’t clearly black-and-white. As a developer, I’m used to there being a generally accepted ‘right way’ to do something and, conversely, a generally frowned upon ‘wrong way’ of doing the same thing. When dealing with web accessibility, much like Search Engine Optimisation (SEO), this just isn’t the case. Yes, there are several things that are clearly defined, but there are just as many things (if not more) that can’t be run through a validator or code linter.

Web Accessibility isn’t difficult to get right, but it takes work. If you start at the end and think that you can just ‘go look up how to do that’, you are in for a very bad experience.

Thank you for sharing Brandon!

You can read more about Brandon’s work on his blog at www.brandontravis.io.