I don’t pay as much attention to accessibility as I should. I suspect it’s the same for many web designers and developers. We know we should do more, but it’s often something we’ll get to and not something we actually do.
In February and March of this year I ran a series about HTML5 structural elements like the header, footer, section, and aside elements. I relied quite a bit on ARIA roles and their definitions to gain more insight into using them.
I came away from the series with a renewed desire to use the new elements and to learn more about ARIA and accessibility in general. To help me, and hopefully you, better understand accessibility concerns for websites I thought I’d work through a series and see what we can learn.
Today I want to talk more about where I am, and maybe where you are too, in regards to building accessible sites and understanding what to do. Next week I’ll consider what accessibility really means to add context for the details we’ll learn about in the weeks after.
General Thoughts Going into the Series
I’m going to guess you agree with me that designing and developing accessible sites is important. At the very least, it’s the right thing to do, but there are business cases for having a more accessible site as well.
The obvious case is the more accessible our sites, the more people can use them and hire us or buy products from us. What might be less obvious is that in making our sites more accessible we’ll make them more usable for everyone who visits. That also includes search engines by the way.
I’ve thought about writing this series for a long time. It’s been at least two years since I added the idea to my collection of ideas. And yet in all that time I didn’t write the series. Why? Some of it has to do with the overwhelming feeling that can accompany any large topic, particularly when you don’t know where to start.
I want to build more accessible sites, but when I’ve looked into it, I usually find myself lost in the details without any general context to connect all the dots. I’m not saying the general information isn’t out there, but rather that I didn’t know where to find it.
If you know how I like to learn, you know I prefer to start with some general context before jumping into the specific details. Having a big picture view helps me understand which details are more important and why.
Searching for context didn’t help. For example while working on the series, one of my searches was for “ARIA roles model,” something I’ll cover later in this series. The results pointed to a few W3C pages from across several specs, a few tips that were more specific than I was ready for, and a lot of pages lifting text from the spec and reprinting it word for word.
There are some good articles as well, but sadly they were fewer and further between than such an important topic deserves.
The situation was similar for most of the search queries I tried while researching. When I could find information in and out of the spec, it mostly felt like reference material pointing me from one document to the next. By the time I found the details to answer my question, I had long since forgotten my question.
Again, there are some good general articles out there. I don’t want to imply there aren’t any and I’ll link to those I did find throughout this series. Unfortunately none that I could find provided the introduction I was looking for.
Eventually I found a handful of articles and W3C documents that helped me find enough context to understand what the details were telling me.
There’s another reason for my taking so long to treat accessibility with the importance it deserves. It’s a reason I’m not proud to admit. I have a feeling part of why accessibility falls lower on my list of priorities than it should is because it doesn’t affect me personally to any great degree.
To be fair to myself, part of the issue is I simply don’t notice. If the layout for a site I’m working on is broken, I’ll see it the next time I visit the site. If the site isn’t signaling to screen readers where the navigation is, I’m probably not going to know unless I’m specifically testing or if someone tells me. That’s not meant as an excuse, but it is the reality.
Once upon a time I thought I did a good job developing accessible sites. There was less that could be done then which made it easier to comply. Early on I learned to use alt text appropriately and to choose colors with enough contrast. I know to add labels to forms and basic things like that. Still I know that I forget to do all of these things more often than I should.
That was then. This is now and it’s time to do more.
My first goal with this series is to find the way in. I want to supply for myself and maybe for you some general context as well as a roadmap to learn the subject.
My longer term goal is to help us both figure out how to develop more accessible websites. I want to figure out what I’m doing wrong here and fix as much as I can. I have to admit I’m a bit scared to look through the spaghetti of code behind this site. It’s amazing how good a job I thought I was doing at the time and how a few years later the code doesn’t look so great.
Scared though I might be, I want to make this site and all the others I work on more accessible as a result of this series.
I also have a goal with this specific post. It’s to shame myself a little. If I don’t write this series I could easily go back to telling myself I’ll get to accessibility later. I have to admit I’m also hoping to shame any of you reading, who like me have put accessibility off for too long. I can do better and so can you.
Tools for Testing Accessibility
Speaking of shaming myself, I thought I’d run this site through a couple of testing tools and I now have a long list of errors to clean up. Some I’ll need to learn how to fix, but many I just needed pointed out to me.
Here’s a screenshot showing a partial list of things I should address. Each of the errors listed expands to a few more. These are only the accessibility issues. There are more errors when I click to the other tabs on the results page.
If you want to see all of them, check the SortSite link (or any of the others) later in this section and test this domain. You should probably check yours while you’re there. SortSite is a paid tool, but I used the free version online, which doesn’t show you everything it finds. Ugh. That just means there’s even more errors with this site than what I saw.
Many of the errors I do see are things like missing alt text, title text, and similar. I thought I was good about adding them, but clearly not as good as I thought. I’m not surprised I forgot to add some text here or there. I am surprised by how often. A lot look like errors due to carelessness on my part, though quite a few are things I wasn’t aware I should do.
I won’t be surprised if a significant number of the errors have been introduced by WordPress plugins. I know a few of them are responsible for most of the issues with standards here. Regardless I’ll do my best to clean them up as much as I can.
Here are some tools you can use to test your site (or mine if you really want). You don’t have to share the results of testing your site with anyone if you don’t want to, but it’s a good idea to see where your site is.
- SortSite – Accessibility Checker and Validator
- WAVE: Web Accessibility Evaluation Tool
- Web Accessibility Evaluation Tools List
- Resources from The Paciello Group
- Screen readers for different operating systems
Later in this series or perhaps in the next go round at this series, I’ll point the finger at myself again. I’ll talk in more detail about where I’ve failed regarding accessibility and hopefully how I corrected those errors and meet more accessibility standards.
My goal today was to hopefully convince you that now is the time to learn how to build accessible sites. I’d be thrilled to know that all of you already develop to the highest level of accessibility standard and don’t need the rest of this series. I’m pretty sure that doesn’t describe most of you any more than it does me, though.
If you’re like me, you know this is important and you’ve probably tried once or twice to learn about accessibility only to find yourself quickly lost and confused.
I want to do what I can to help both of us find a way into the topic without feeling lost and overwhelmed. My next goal is to provide an overview and some context so we can continue learning beyond anything in this series.
Next week I’ll talk about what accessibility really is and what it means for us as designers and developers. In the weeks that follow I’ll walk you through some of the documentation for the Web Content Accessibility Guidelines (WCAG) and Accessible Rich Internet Applications (ARIA).
Later in the year I expect I’ll come back with more specific accessibility topics and again at some point I hope to show you how I made this site more accessible.
Download a free sample from my book, Design Fundamentals.