While working on a Divi site, I found myself browsing the Elegant Themes community support forum and stumbled upon this awesome comment from a user known only as “Maco.”
There is no situation in which inaccessibility is a desireable characteristic. Themes should always be accessible. It makes no sense to say “well we didn’t SAY it’s accessible.” That’s like buying a house and being told “we didn’t SAY there wasn’t a cougar in the bedroom closet waiting to maul you.” Inaccessible websites have resulted in lawsuit payouts for well over a decade; therefore, inaccessibility is always a bug.
He’s absolutely right. There is no excuse for trying to sell a product as “ready for launch” that is inaccessible. In line with the whole “the shoemaker’s children have no shoes” trope, I know my own personal website once a lot to be desired in terms of accessibility. But I did not try to pass it off as being acceptable. It was buggy. Yeah, I said it. My personal blog was buggy. Inaccessibility is always a bug. The websites of my clients always get priority over this site where I am basically just screaming out into the silent void. Did I improve it? Absolutely. Will I ever stop improving it? Nope, probably not. Was it “good enough” in its previous state? Hell no. Was I embarrassed about it? Yes, often. And you should be too if you are in the same boat as I was.
So how can you go about changing the way you define minimum accessibility standards?
Figure out where your website currently stands
Test, test, test. There are lots of different accessibility ranking tools out there that you can run and get a cool little report back about all the ways your site has excelled and/or fallen short of the current legal standards. It helps to have a checklist to work through and every tool you use will catch different issues and produce slightly different results. There are premium tools as well as free tools and some that focus on specific issues. Web AIM has a great tool that will scan your site to detect a variety of issues. I wrote a guest piece for WordCamp Miami about using tools to catch and correct color contrast issues.
Adapt your daily routine
Use the technology your users will be using. Most of the devices you use on a daily basis have innovative and interesting accessibility tools baked into their core features. Turn them on, learn how to use them, and then use them throughout the day whether you need them or not. Constant use of the technology that your audience uses will help you see opportunities to tie in their features into your current and future projects. While there are various default tools out there that can be activated in your device’s accessibility settings, some of these tools can be quite expensive (which is an entirely different conversation to be had). Some uber-popular tools like JAWS let you use their software in 40-minute bursts so long as you are willing to reboot your machine between uses. This is a more than fair compromise, in my opinion, for someone who is testing out the software and doesn’t rely on it.
Adopt and maintain a non-negotiable mindset. In one of my freelance assignments, I am in the truly fortunate position of having a direct project manager who is a blind woman. If I deliver a finished product to her that isn’t accessible, she simply cannot sign off on it. There is no, “Well maybe we can revisit this in the next version.” There is only, “If I can’t access it, it doesn’t exist.” Which means I don’t get paid. Which means I need to gather myself up and fix it. Being under her command for the past year has pushed me further as a developer than I’ve pushed myself in the past 5 years. Inclusion isn’t a cute buzzword for HR, it’s an absolute necessity for the quality of your business. I would strongly suggest elevating your future job searches to include a blind person in QA or at any point in your project flow. Nothing will whip your mindset and company culture into shape faster than being accountable to someone who actually relies on screen readers like JAWS on a day to day basis.
Abandon Common Shortcuts
Stop using header tags for design purposes. Header tags, like <H1> and <H2> do more than give your words a new color or weight on the page. They make up the very structure and layout of your website. People use these tags to decipher how all the information on your relates to each other, especially people who are using screen readers. You can fight with me about this on Twitter, but I truly believe that every page on your site should only have one H1 tag. After that, any H3 tags you have should be nested under an H2 tag. If you are really married to the look of your header classes in your style sheet and want to use them all over your site without confusing the life out of people, just wrap your text in a <span> tag and assign the desired header design by calling it by its class. For example:
&lt;span class="h1"&gt;This is going to look just like an H1 tag without being nonsensically labeled that way.&lt;/span&gt;Properly label every single image on your site entire site. I said what I said. Every single image. Anything on your site that gets called with an <img> tag needs to be properly labeled. So what do I mean by that? First of all, if the image is important to the overall context and understand of your page, then it needs to have a proper descriptive “alt” tag. That means using text to actually paint a picture to describe the photo. This is especially important when you are dealing with infographics or memes that contain lots of important information. Plugins like Divi Accessibility or WP Accessibility give you the ability to add longer descriptions to images that need it. But you should also consider removing information from a graphic image and simply included it on the page using stylized text whenever possible. Compared to an image, text loads faster, is accessible, and is better for SEO.
If an image exists on your page purely for decoration or spacing purposes, it still needs to be properly labeled. In this case, the proper label is a null or empty alt tag which would look like this:&lt;img alt="" src="filename.jpg" /&gt;Most screenreaders will interpret an empty alt tag as a decorative element and then ignore it. The complete absence of an alt tag usually results in the screenreader speaking the file name, so you must include the alt tag.
This is a simple overview to get you started on a topic that is complex enough to fill up a library! If you want to read more on this subject, here are a few links to get you going and hopefully more will be contributed in the comments section below.
Additional web accessibility resources