My Top Mistakes with Web Accessibility

As I am wrapping up my time at Flatiron, I am getting more free time to explore my personal interests, and subsequently, figure out what I do not know before the inevitable job search and technical interview. While nerve racking in and of itself, I often try to break-up the necessary subjects with broader topics that are relevant but of more interest to me. One area I always seem to focus on is web accessibility. I am sure many are aware of World Wide Web Consortium (W3C) and The A11Y Project. Rather than give a summary of these two organizations, I highlight below three key points that I found the most interesting and applicable to my own coding experience.

Start from the Top, Literally: Page Titles

I often overlook giving topical page titles. When I was first starting to build my own projects, I would title the page something generic and had little relevance to my own web page. Naively, I thought it cheeky to make it something funny and the more random made my webpage seem more humorous. Little did I know that this is the first item screen readers grab. So naming the page titles properly is critical for accessibility. Moving forward, I am trying to write these with literally only the unique title of my actual web page. It seemed logical to me, but I have no experience using a screen reader. I would love to hear ways to improve the UX for this!

See the Difference: Color Contrast

For my pet projects, I love the freedom to design the pages how I want, which often includes picking pastels that I find easy on my eyes. Big no-no! I had no idea that web pages should have a minimum contrast of at least 4.5:1. Higher contract helps those with visual impairments read and use your webpage more easily. W3C gives a step-by-step guide on how to check contrast with IE WAT. Honestly, I have not used Internet Explorer in ages so I found an alternative website, WebAIM, that provides a much more intuitive system for checking contrast.

Keep It Simple: Keyboard Compatibility

This is essentially that all functionality of the webpage can be usable with only a keyboard. This means that someone who has physical limitations to be unable to use a mouse can use keystrokes to navigate the page, and complete and submit forms. While my current designs are relatively simplistic, before now I have never tested my designs for keyboard only functionality. Personally, I am partial to a good Modal and have made a habit of removing the default close button usually located in the Footer. Again, this is poor practice on my part. I am now going through and re-adding these buttons to make my Modals more accessible. Another item to note that I was not previously aware of, native HTML controls are inherently keyboard accessible. However, custom CSS and scripts often need to have this functionality built-out. W3C has some additional useful information along with user stories, which I found particularly interesting.

Bring It on Home

At this point, I am doing my best to implement good web accessibility practices in my own coding as I write. I have also been trying to go back through old projects to improve already published code, which I have found is no easy task. Luckily, W3C has a quick checklist readily available to help guide newbies, like myself, through the process. Beyond just changing CSS styling, it sometimes requires changing the actual functionality of an entire page, making the whole process more tedious than initially anticipated. It is, however, a small price to pay for a more usable and overall smoother UX.

Thanks again for reading! Now enjoy this cute baby cheering for our accessible webpages.