Do you have a role in web accessibility? (Spoiler alert: yes)

Maybe you’ve heard about web accessibility on a podcast or heard a developer friend talking about it. Maybe you’ve thought to yourself you should learn more and start implementing web accessibility standards on your site. Maybe you were gung-ho to get started, but were stopped dead in your tracks when you hit the mass volume of difficult-to-read guidelines.

Let’s be honest, web standards for accessibility are overwhelming.

The WCAG 2.0 guidelines are lengthy and legal sounding. Add to that the varying levels of accessibility (A, AA, AAA), along with some gray areas in-between. Finally, the site design looks like a throw back to early web: an intimidating wall of text that goes on and on (which is technically accessible, but not a great user experience).

What’s a web developer to do? You want to help make the web more accessible, but you don’t know how to actually do it.

We have an accessibility problem when it comes to understanding accessibility. #a11y Share on X

Web Accessibility Defined

Let’s start by getting on the same page about what web accessibility is. It’s more than just making your website look good on mobile or being screen-reader friendly. It’s about creating a website in such a way that anyone can access that content regardless of the device used to consume the content.

When sites are correctly designed, developed and edited, all users have equal access to information and functionality. – Wikipedia

Web accessibility in a nutshell: Make your website work for everyone. #a11y Share on X

Understanding Your Role in Web Accessibility

In the rest of this post, I’ll break down the roles involved when it comes to making a site more accessible. Then, hopefully, you’ll get an idea of where you fit into the picture. Sound good?

Making a website accessible involves three basic roles:

  1. Developers (people writing the code)
  2. Designers (people making decisions around layouts, fonts, and colors, etc)
  3. Content Creators (people writing and editing content for a website)

In the rest of this post, I’ll highlight some of the main accessibility concerns as they relate to each role.

1. Web Accessibility for Developers

Some accessibility features must be implemented at a code level. And let me tell you – it’s so much easier to start a project with this in mind rather than trying to tack on accessible features at the end.

These things include (but aren’t limited to):

  • Skip Links – A feature enabling users to more easily navigate a page. Most helpful for keyboard-only users (imagine having to tab through the entire header and menu on every page just to get to the content). If you want to know more, here’s a tutorial on adding skip link navigation to a site.
  • Keyboard Navigation – This means making sure that tabbing through a page goes sequentially from one link (or input) to the next, allowing someone to go through a page top to bottom without a mouse. Want to test it out? This article has some quick instruction (along with other helpful info).
  • ARIA roles (Accessible Rich Internet Applications) – This has its roots in semantic HTML markup – explicitly telling a browser what something is, does, or the state it’s in (i.e. pressed, hidden, expanded, etc.). Here’s a great human-readable article if you want to learn more.

By the way, if you’re working with WordPress, there are plugins like WP Accessibility and Genesis Accessible (for the Genesis Framework) that can help you do some of the developer stuff without code. While they don’t get you 100% there, they’re a fantastic starting point.

2. Web Accessibility for Designers

Even though a developer will ultimately code out a design, it’s the designer’s job to provide a flexible user experience that translates across multiple environments and screen sizes.

So, what are the most critical design factors for accessibility? In a nutshell, they revolve around reading comfort and element context.

  • Color contrast – Light gray text on a white background may look sexy, but oh it is hard to read. And then consider those folks with some form of color blindness – how it looks to you is not how it looks to them.  If it’s uncomfortable for people to read the text on your site, they’ll leave. And I’m pretty sure getting people to leave your site isn’t anyone’s goal. Here’s a quick tool for checking color contrast. A Google search will turn up plenty of other tools, too.
  • Avoid tiny-ass fonts – Thankfully, web design is trending toward larger font sizes, so this one is an easy win. But to the previous point, don’t make it hard to read your content. The WP Accessibility has an option to add a little tool-bar to the front-end of your site that can let readers adjust the font size on the fly.
  • Clear and consistent navigation – People are used to horizontal navigation menus across the top of websites. As a designer, you may think that’s boring (it kinda is) and passé (you’re right). Your points are valid, but here’s the deal: don’t get overly clever with the navigation or people won’t find it. There’s a reason why so many sites use a similar navigation structure. It’s great for usability.

3. Web Accessibility for Content Creators

Guess what? Developers and designers can hand off THE PERFECT site that meets all the right accessibility requirements. But what about the last link in the chain – the person writing the content? That person has the power to screw things up.

Encouraging, right?

Actually, don’t be discouraged. Writers have the opportunity to make huge accessibility improvements with just a few simple habits:

Content creators have the opportunity to (easily) make huge accessibility improvements. Share on X
  • Alt Text for imagesIf you’re using WordPress, adding Alt Text is super easy. Every time you add media to a post, you have the opportunity to enter Alt Text (short for Alternate Text).
  • Proper heading structure – You know those H1, H2, and H3 tags? Their purpose is to communicate the hierarchy of your content. Don’t use an H1 where it doesn’t belong just because you need a bigger font size. Using headings the right way enables users to quickly skim your content and hone in on the most important parts (or the parts that interest them).
  • Contextual link text – “CLICK HERE!” must die. Use link text (a.k.a. anchor text) to help the user know exactly what to expect when a link is clicked.

I wrote about these three tips in another post if you’d like more juicy details.

Which one are you?

Did you identify as a developer, designer, or content creator? It’s possible you overlap into all of those categories. Did you learn something here that you can apply in your situation?

If not, I did a crap job writing this post (feel free to say so in the comments and I’ll try to dig a little deeper). If so, my challenge to you is to go do ONE thing mentioned in this post today. That’s it.

You don’t have to be an accessibility guru or memorize WCAG 2.0 to start making your site(s) more accessible. Take baby steps and know that with each one you’re making the web a better place.

Get started by learning how to check your site for accessibility.

13 thoughts on “Do you have a role in web accessibility? (Spoiler alert: yes)”

  1. I get so frustrated by all the “feminine” WP themes with pastel coloured fonts. Yes, by all means use soft colours on your website but, please, not for the text! (I think I’ve probably annoyed quite a few people by pointing this out… 😉 )

    1. Ha! There is a very common misconception that using proper color contrast means UGLY COLOR COMBINATIONS. That doesn’t have to be true, though it does take some creativity to make it work. I would love to see a resource site (or maybe just a tag on ?) showing accessible color combinations for foreground/background.

      Keep preaching, Alice. 🙂

  2. Julie Romanowski

    I have to disagree about your skip links comments concerning screen reader users. Screen reader users have multiple options available to navigate web pages (e.g., headings, landmarks, etc.). Skips inks are most helpful for keyboard-only users. Imagine having to tab through the entire header and menu on every page just to get to the content.

    1. Hey Denis,

      That’s awesome – Thank you!!


      p.s. If you ever feel like picking up the pen again (or keyboard), I’m part of a side project with a group of authors writing about accessibility and you’d be welcome to join us. I’m sure you need another side project. 🙂

  3. checkingstateFlorian Beijers (@zersiax)

    I like this post, but there is one thing I am sorely missing.
    You jump from keyboard-navigable straight into ARIA, please don’t do that. ARIA is a brilliant specification for making things work …that weren’t broken to begin with. What I mean is that a lot of people misuse ARIA to make a clickable div-element behave like a button. This requires a bunch of JS, some aria-properties, all sorts of mucking about …while just using the native Button element would’ve given you all of that for free. I’d say the third thing for developers would be to use semantically correct markup and only resort to ARIA when there’s no other alternative.

  4. A little late in my reply, but I wanted to say that I literally spent weeks selecting my fonts and colors. I ended up with two fonts that complement each other nicely and are very readable.

    The trend is toward light gray sans-serif fonts for the body text. But I find them to be too smooth and distracting. It took quite a bit of back and forth before I finally decided to choose a nice serif for the main text on my website. It relaxes my eyes considerably and engages me more.

    Research on this seems to be inconclusive. But no one asked me. There is no doubt that for me, personally, serif fonts provide for a more comfortable reading experience. One font (serif) engages me and stimulates my brain in a way that keeps me more alert to what I’m reading, and the other (sans-serif) tends to keep my eyes floating on the surface of that same content.

Leave a Comment

Your email address will not be published. Required fields are marked *

Carrie Dils uses Accessibility Checker to monitor our website's accessibility.