History of Our Company – Part 1

Cell phone and notebook with web design wireframes

Symbols for visual, hearing, physical, and mental impairment.The Accessibility Guidelines that they teach in colleges doesn’t even begin to cover what actually needs to be done. We’ve all been building websites for years that weren’t good enough. So when people started getting sued for non-compliance with the ADA (a new trend that the DOJ won’t issue an official statement on) we decided to dive in head-first and step our game up.

Everyone’s screaming about keeping the internet free (because of the idiocy surrounding Net Neutrality) but we decided to throw our voices in on the side of keeping the internet free for all. Our founder’s father is partially colorblind and he didn’t realize there was a science to keeping the entire internet visible for him. He just always thought that if he can’t see it, it must not be important.

This is the first post going up on this site, and we just wanted to let you know why we’re doing this. The next series of posts will walk you through what we’ve done to get this site accessible.

**If you’re thinking about suing us before we’re finished, please refer to our TOS page and realize that you can’t, and quit being such a Negative Nancy for the sake of lining your own pockets. Yes lawyer’s, I’m talking to you.**

DOJ Makes Accessibility More Confusing

A seemingly confused monkey scratching it's head.

Just yesterday, the DOJ finally responded to the two letters sent to them from members of Congress, asking for a decision on how accessibility regulations apply to private sector websites.

Existing regulations about physical accessibility have previously been applied to websites of any Government and government-funded institutions, however no official decision has ever been made on how these apply to private-sector websites. The DOJs answer was clear as mud. Here’s the meat and potatoes:

“…the ADA applies to public accommodations’ websites…”

“This interpretation is consistent with the ADA’s title III requirement that the goods, services, privileges, or activities provided by places of public accommodation be equally accessible to people with disabilities.”

So… yes? Wait for it…

“…the absence of a specific regulation does not serve as a basis for noncompliance…”

“…noncompliance with a voluntary technical standard… does not necessarily indicate noncompliance with the ADA.”

Our summary:

Public accommodation websites have to be accessible. If you deal with the public, this means you. However, the DOJ is not pointing to the WCAG guidelines as the technical standard for meeting these requirements, like they did for public sites. These are the “Voluntary Technical Standards” they’re talking about here.

They go as far as to say that failing to meet WCAG standards does not mean that you’re non-compliant with ADA requirements. This is both good and bad news for our clients who are facing lawsuits. My favorite line from the document is this: “…public accommodations have flexibility in how to comply with the ADA’s general requirements of nondiscrimination and effective communication.”

They’re telling public accommodations that their sites have to be accessible, but won’t point the finger to any guidelines that provide a measurable compliance level. They’re leaving it up to Congress to get something written into law to provide more “clarity” on the matter.

“Given Congress’ ability to provide greater clarity through the legislative process, we look forward to working with you to continue these efforts.”

This is why we, at AccessibiliBuddy, do not rely on automated scanners to tell us what’s wrong with your site. We do, of course, deploy such solutions in an effort to maintain WCAG compliance and ensure that changes to the site’s content do not cause obvious accessibility issues, but that’s only part of it. We use real users, on real devices, to test your site as only a human can.

You can read the DOJs letter for yourself here.

Speak Out Loud for Visually Impaired Users

Accessing Media

Unless you’re using a screen-reader, you have no idea that the first sentence of this article is actually: “This is an icon that depicts volume increasing.”

We’ve been on this kick lately where we talk to ourselves while we read every element on a web page that we create. We’re using it to develop our Theme, as well as using it to identify points where visually impaired users might have trouble using our sites. We found that actual content for stand-alone icons rarely exist. When this happens, most icons are just hidden from the screen-reader and skipped over completely. That’s the lazy way out.

It’s become a huge fad lately to use icons in place of images, but we’ve completely neglected them in regards to accessibility. Font Awesome provides a pretty great accessibility guide, but it wasn’t integrated into our favorite page builder (WP Bakery Page Builder fka. Visual Composer) so we decided to integrate their tips into the template ourselves.

First, we had to add a parameter to use for the title=”meaning” attribute, so we added this to functions.php in our child theme:

function vc_after_init_actions() {
    $vc_column_text_new_params = array(
            'type' => 'textfield',
            'holder' => 'h3',
            'class' => 'sr-only',
            'heading' => __( 'ARIA Details', 'text-domain' ),
            'param_name' => 'aria_details',
            'value' => __( 'This is an icon that the site author has neglected to provide a description for.', 'text-domain' ),
            'description' => __( 'Provide a description of the icon (semantic meaning is appropriate) for screen reading software to verbalize this icon.', 'text-domain' ),
            'admin_label' => true,
            'dependency' => '',
            'weight' => 0,
            'group' => 'ARIA',
    vc_add_params( 'vc_icon', $vc_column_text_new_params ); 
} add_action( 'vc_after_init', 'vc_after_init_actions' );

Now, it was time to edit the vc_icon.php template. To do this, create a directory in your theme folder called “vc_templates” and copy the icon template from /plugins/js_composer/include/templates/shortcodes/ into your new folder.

First, we changed the output to use the icon element instead of the span element that Visual Composer uses by default. We just replaced ‘span’ with ‘i’ to get this:

<i class="vc_icon_element-icon <?php echo $iconClass; ?>" <?php echo( 'custom' === $color ? 'style="color:' . esc_attr( $custom_color ) . ' !important"' : '' ); ?>></i>

Now, we just need to incorporate our custom attribute for the title element. We’ll use the initial variables declaration at the top of vc_icons.php to include our $aria_details variable. This will automatically be assigned the value of the attribute we created earlier (via whatever voodoo magic is running inside Visual Composer).

After implementing the above changes to the theme files, we now have screen-reader accessible icons, like this one. If your voice-over is activated, you should hear: “An icon showing a speaker with no sound coming out, indicating the end of this article.”

Why I’m not worried about WCAG 2.1

Laptop with Code

WCAG 2.0 - the 0 has been crossed out in red and a 1 has been written in to replace it.Hi everyone, Richard here, Founder and CEO of AccessibiliBuddy. If you’ve been following accessibility news, you might have seen that the new Web Content Accessibility Guidelines (WCAG) 2.1 guidelines have been published and are expected to be ratified in June.

Following this announcement, here’s quick FAQ on what questions I’ve been getting from clients and other members of the web development community:

  1. Are you worried about the learning curve and retraining your team?
    1. No. We’ve already reviewed the updates and they are already covered in our current practices.
  2. At least you’ll be making more money from revisions for your existing clients.
    1. Nope, see the answer to #1.
  3. Do you think people will be upset if they paid for work that isn’t required under 2.1?
    1. Nope, there’s no such thing. 2.1 is complimentary to 2.0 and doesn’t exclude anything.
  4. Does anything worry you about the 2.1 rollout?
    1. Yes. Opportunists using scare tactics.

#4 is probably what worries me the most about this update. If you search ‘Accessibility Lawsuits‘, you’ll notice a few paid ads in the search results to agencies trying to convince you that you’re going to sued if your site isn’t accessible. While this could happen, and has been generating quite a bit of news over the last couple of years, it’s not THE reason to make your site accessible. Aside from it not being ‘fair’ to not have accessible websites, take a look at the stats on our About page and you’ll realize how large of market share you’re probably missing out on by not having accessible content on your site. It boils down to this:

It’s ROI positive for you to make your site Accessible. End of story.

Day 2 – Focusing on the Header

Header tags

Now that we have a good idea of the accessibility status of the overall site, we’ve decided to focus on making the header.php file in the theme accessible. This might be more than we can tackle in one day, but we’re ready to dive in! I’m live-writing this article, so we’ll see what happens!

First, I’m running a test on WAVE of the homepage, and looking for errors in the header. The report came out looking like this (right). There are 12 errors on this page overall, but we’re not done editing the body of this page yet. The only error corresponding to the header is for our mobile menu link. Since it contains an icon but no text, it’s not accessible to screen-reading software. We’ll fix this by adding a copy of this file to the child theme, and adding text specifically for screen readers to follow.

In order to hide the text in this link from normal users, but to ensure that it remains in it’s correct order within the code so that it’s screen-reader accessible, we used this CSS to simply move it off of the visible screen:

.sr-only { position:absolute; left: -10000px; }

The way this ensures accessibility while keeping the display we want is by moving it out of the viewport. Meanwhile, the text in our div says “View the Menu”. This enables screen-readers to alert the user that there’s a like that allows a menu to display, without corrupting the page design.

We didn’t have to modify any more than that. The theme does a pretty good job including most accessibility features. One main accessibility feature of the header is always the skip link. This tells screen reading software where the main content of the page begins. This prevents users from having to listen to the header and menu being read over and over again.

Wave report of home page showing 12 errors

Time Lapse Video of Our Modifications to the Header

The Build – Day 1

Network foreground in front of a cityscape

We decided not to do a fully custom build, because we don’t always do fully custom builds for clients. We wanted to know what it would take to make our favorite theme, which also happens to be one of the highest selling themes on Theme Forest, compliant with the WCAG 2.0 Accessibility Guidelines.

Here’s what we started out with for our build:

We decided to use BeTheme for this build. It’s one of our all time favorites, and we recommend it to just about every client. It has almost anything you can thing of already built in, and they’ve also integrated a lot of other features which were previously only available through paid plugins. It’s $59 for a license, but it’s well worth it when you consider how much is being saved in development costs.

  • Visual Composer – We wanted to stick with a page builder that’s not theme-specific and very well documented. BeTheme has a pretty good page builder, but if you change themes, you lose your page content. We’re also certain that since it runs in place of the standard WordPress editor, it’s compatible with…
  • Yoast! Which we chose because, well, it’s Yoast. Since Yoast doesn’t link up to your Google Analytics anymore, we chose…
  • Google Analytics by Monster Insight – they actually took this portion of the plugin over from Yoast, so that’s one less compatibility issue we have to worry about.
  • Slider Revolution – it’s great, has tons of add-ons available, came included with BeTheme and can be adjusted for accessibility with very little code knowledge.

So, after we installed BeTheme and the aforementioned plugins, we imported one of the 290+ available BeTheme layouts and then ran a scan on it using the WAVE tool. Our results weren’t great, but we didn’t expect them to be. Honestly though, they weren’t as bad as they could have been.

This report is just for the homepage, and shows 36 errors and 25 alerts. It also shows 178 Features, 54 Structural Elements, and 211 HTML5 and ARIA tags, which are used by screen readers to guide visually impaired users through your site. We aren’t too worried about the 108 contrast errors because that’s all design and will be cleaned up as we build this out to be OUR site.

If your site has 108 contrast errors, you should probably have someone take a look at that for you. It makes it really hard for anyone with any degree of colorblindness to use your site.

WAVE report for our "out of the box" homepage.

Our First Compliance Issue During Build

Our first impasse came when we ran the evaluation on this post after publishing it. We’ve found that the Accordion element above publishes it’s headers as <H4> elements, and we have no built-in control over this. With the absence of an H2 and H3 between the H1 and H4, this is semantically incorrect per the WCAG 2.0 accessibility guidelines. We’ll either have to replace this, or find a way to fix it.

Oddly enough, the headline above this that reads “Our First Compliance Issue During Build” is also being published as an H4. This seems to be the default for Visual Composer elements and will need to be addressed.