I just finished an accessibility audit on my site. There is only one flag that is raised by Axe, the accessibility validator I use. I believe I can ignore that flag. It relates to the arrows that I use for my webrings. I do not believe the suggestion impacts the quality or accessibility of my website. I am proud to say that I’ve resolved many accessibility issues over the last few weeks.
This website is the first project where I’ve thought about accessibility to the extent that I am today. I’ve never really thought about how other people see my creations. I’ve always thought about how I consume what I make. This is normal. I like to eat my own dog food. In other words, I build the tools and websites that I need myself. This site is different. I want other people to read my content. The whole point in having a blog is to let me share my thoughts with the world. I want people to be able to read those thoughts.
I went down the accessibility rabbit hole about a month or two ago. I have read quite a bit on the topic. After doing some reading, I have more conviction than ever that accessibility should not be an after-thought. It needs to be a central part of my design.
Testing for Accessibility
A friend recommended a tool called Axe to me. This tool validates HTML code from an accessibility perspective. The tool checks for issues like poor color contrasts, invalid HTML, and incorrect markup. Axe is a browser extension so I can easily run it on any page. I was initially apprehensive about installing yet another browser extension but this one proved to be worth my time.
Axe takes a few seconds to analyze a page. Once the tool has analyzed a page, I am presented with a list of suggestions on how I can improve my code. My goal is for every page to validate without any issues. I have achieved this goal on all of the pages I have checked, bar the one insignificant suggestion I mentioned earlier. It’s become almost a game for me. The more issues I can resolve, the better I feel about my website.
What I’ve learned in using Axe is that most accessibility issues are the result of not using the correct semantics. When I use tags like
<nav> correctly, I don’t get any errors. When I use
<div> tags in places where there is a semantic alternative, I start to see problems. It’s amazing how accessible HTML is out-of-the-box. I just need to learn the semantics.
##Validating My Code
I use a command line tool called
html5validator to validate my HTML code. I believe the tool uses an engine similar to the W3C markup validator. I use this tool to check for semantic issues in my code or areas where my code is incorrect. When I run this tool earlier today, I caught a few tags that I had not correctly closed on my site. These mistakes would likely cause accessibility issues on my site. For instance, there was an element that did not have a closing </a> tag. A screen reader would have read out more content than it needed to because I forgot to close the tag.
Validating HTML code is easy to do. I’m still trying to make it part of my workflow. I do not validate my code after every change I make to my blog but I probably should. I’m getting better at remembering to validate my code.
Reading About Accessibility
To accompany the validation tools I use, I have spent some time reading about accessibility. A good recent read was on how to write “alt” attribute descriptions for images called “How to write better alt-text descriptions for accessibility”. The post highlighted that I was not writing good “alt” attribuet descriptions. I was saying “A photo of” at the start of almost every description. Screen readers already know that an image is an image and they indicate so to their users. I don’t need to say that an image is a photo of something in an “alt” attribute.
I went over all the images on my website and checked to make sure they had an “alt” attribute. If they did not, I added one. I checked to make sure that each attribute accurately and concisely described the image with which the attribute was associated. I found this was not the case in most instances. I referred back to the blog post on how to write “alt” attribute tags and made a few improvements. My images are now easier to consume for people who are unable to view them.
I’m just reading as I build this website. Earlier today, I read about how to write accessible tables. I learned about the
<tfooter> tags that are used to write semantic tables. HTML gives me all the tools I need to make an accessible experience. It’s just a matter of learning how those tools work. I am proud to say that my new “Wishlist” page includes a table that is accessible. I looked up how to write better anchor text to make sure that the links on the page are optimal for visitors who use a screen reader to navigate through my site.
One surprising fact I learned is that header tags should appear in descending order. Every
<section> should have a header tag and it’s improper to skip a tag. I can use a
<h3> on a page but only if I use a
<h2> and an
<h1> first. I should not skip tags. I made this mistake on almost every page about a week ago and I had to go correct it.
Accessibility is going to be a long-term project for me. My new weather station application is accessible. This website is accessible as far as I can tell. I’m yet to do a test where I actually use a screen reader. I’ve not had the time. I am still learning about new ways to make my site accessible. The “Skip to main content” and “Go back to top” anchors on each page were the first accessible feature I really thought about adding. Now I realize that there are so many cogs that go into providing an accessible experience.
I’ve been able to get this far because I have asked the question “how can I make this site more accessible?”