ACCESSIBILITY MATTERS!

It’s gotten easier to make a website, but harder to make them accessible

BY JAMES WARNKEN

In a world where anyone can log in and build a website in a matter of hours without knowing any code, this has made the job of making those websites accessible to everyone more challenging than ever before. It also does not help that many platforms do not offer much support in guiding the author to make accessible design decisions during their creative process. I am a huge fan of how easy it has become to make a website that brings ideas in your head to life, but I do wish they considered accessibility a bit more. Unless you have experience working within the accessibility space, chances are you have no idea what is accessible and what is not.

The drag-and-drop builder is not the issue; it is more about providing feedback to the author to make choices that ensure equal opportunities and experience for all users, including those who cannot see, have a hard time seeing, have a hard time perceiving colors, have a hard time using common input methods like a mouse, or have a hard time hearing. It is highly unlikely and somewhat unfair to the author of the website to have to know all the details in order for their website to be accessible to everyone. Now, in some cases, our creative minds make accessible decisions like avoiding “click here” for links or using colors that clash when paired together. But on a more technical note, the structure and semantics of some elements require a bit more thought and consideration.

Let’s look at links, for example! Many builders offer the ability to make the plain text a link right within a paragraph, but customizing that link to make it visually distinct isn’t always available to the author. If text can be clicked on to go to a new destination, it should stand out from the rest of the words around it, right? The obvious answer is yes, so why can’t we customize it to make sure it is distinct? Building on this, many builders use “buttons” as a primary element for linking to things. The issue is that buttons and links are not necessarily the same thing. From a blind user’s perspective, if the language says “click the button below,” but that button is actually a link, users might not know which one is referenced. In this case, it causes confusion and is not the fault of the author, but because the builder calls it a “button,” but the code in the background tags it as a link.

What should we do as authors? I think the first step should be to spend some time understanding the basics and fundamentals of accessibility so that we don’t need to rely upon the builders to guide us. Secondly, we should be spending some time to see which builder offers more accessible solutions or asking the platforms to integrate some of the accessibility features for us to use. Lastly, we should be connecting with accessibility specialists and people with disabilities to learn how to improve the experience for everyone, not just those with certain disabilities. The task of digital accessibility may be a bit daunting and overwhelming, but once you lean into it, you’ll quickly realize it is not nearly as complex and technical as most make it seem.