Skip to Content

I want to take a break from the code focused session to talk about an important topic – accessibility. I was only recently enlightened as to how important this is at a conference I attended in April. Before we get too deep into this, if you want to review the coding stuff (as I will mention it occasionally in this post), review these posts:


1: Starting at index.html

2: Adding some style with CSS

3: Get moving with JavaScript

4: What is Bootstrap?


In previous posts, I have made mention of “this is not best practice” or “don’t do this in production”. I used to think Best Practices were mostly for developers who inherit your project later (who has ever inherited a project that is held together from some combination of gum and magic? 🙋‍♀️) or cause someone needed to get paid to make up rules that we have to follow just to make our lives miserable. That all changed when I attended on workshop on designing accessible websites at the Women in Tech Summit Northeast.

Adina Halter, Sr. Product Manager and Chief Technologist for Accessibility at Comcast NBCUniversal, led this workshop and opened my eyes for the first time since I started developing websites and web apps. I guess a lot of frameworks I had used in the based probably adhered to these rules, but I had never considered it before as a developer. She helped us gain empathy and perspective for the non-fully-able-bodied human. I have to say, I am disappointed in myself for not being aware of this for so long.

But back to the best practices tie in. A lot of these actually stem from WCAG. Take a gander through the list of Web Content Accessibility Guidelines, and tell me, does anything sounds familiar as to a way you were told to program for the web?

Let’s start with one like Success Criteria 1.1.1 – Non-text Content. How many times have you been told to include alternate text for an image? And how many times have you do it so that is meaningful to someone who is being read the text and cannot see the image? Or better yet, how many of you had skipped over that? Alternative text is important beyond in case an image can’t render. That is the text that is read to a user who is using a screen reader. And if it isn’t there, the image URL is read. How useful is that?

Did you know that screen readers read the HTML tags as well? This is why it it important to use CSS for styling and not tags. You want your page to read like an essay outline, not a random scattering of header tags.

Your structure should look like this:

<h1>About Us</h1>
<h2 class="h3">Our History</h2>
<h2>Our Staff</h2>
<h3 class="h2">Leadership Team</h3>
<h1>Projects</h1>
<h2 class="h3">Who we've worked with</h2>

Not this:

<h1>About Us</h1>
<h3>Our History</h3>
<h2>Our Staff</h2>
<h2>Leadership Team</h2>
<h1>Projects</h1>
<h3>Who we've worked with</h3>

While this may seem trivial, if you were jumping around level 2 header, which one would be easier to follow and understand? Which one helps you find out which sections have more information?

When it comes to JavaScript and dynamic components, this can be a little more complicated to implement. And that’s where ARIA comes in. ARIA provides a great library of resources to help with dynamic webpages – it points out which JavaScript UI frameworks have ARIA baked in and how to use ARIA in your HTML components.

It’s important to be empathetic to all users when designing your web pages. It makes for a better user experience for all (and it can also mean not facing financial ramification for failing to comply with WCAG). So take a second to review WCAG and your web apps you’ve built, and maybe reconsider – did you design this for everyone?

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply