Website Upgrade
Recently our website has undergone a massive design upgrade. It was a very large undertaking involving a team of designers, front end developers and copy writers. Everyone was very eager to get it out the door, so, as with a lot of websites and applications, making sure it was accessible was not made a priority. While there was nothing major wrong, it missed a fair amount of small accessibility features that improve the usability of the site. So I made it my mission to find them all and upgrade as many as I could.
Accessibility Review
The Web Content Accessibility Guidelines (WCAG) guidelines for accessibility has a large checklist, so I got to work testing each one to see if we passed or failed. Starting with level A and when that was done level AA, following the same steps I undertake for our clients when we perform an Accessibility Review.
Unfortunately, there’s no one way to test for accessibility, rather a whole toolbox of tools and techniques that I’m going to share with you.
Keyboard Accessibility
If you only use a mouse to navigate on your computer, chances are you haven’t used your keyboard for anything more than filling in forms. Some people however, use only their keyboards to get around a website. So testing here is as simple as putting the mouse away and seeing what you can and can’t do with just the keyboard (keyboard navigation tips).
Chances are there are a few things that don’t work the same way. The first thing I noticed was the sub navigation drop-down menu only worked when using a mouse and didn’t work with the keyboard. Other things too, like the accordions and our team information also were hidden when you only used a keyboard.
These were being done with the pseudo element of mouse hover. So we updated it, making sure the element was one a keyboard could access, like a link or button, then making it work on keyboard focus as well. This way if it’s changing appearance or functioning when using a mouse, it’ll do the same when using only a keyboard as well.
Accessible Colours
If you’ve heard people talk about accessibility before, chances are you’ve heard about colour contrast. Having good colour contrast means that the text stands out from the background clearly enough for people to read it. Independent of any visual difficulties someone may have, we’ve all been in meetings or presentations where we’ve struggled to read the text on the slide. So this is doing the same test on the website.
You don’t need to test every colour; black text on a white background for example is fine. But with any other major colour combinations you have, you can use a colour contrast checker test to make sure the text stands out enough.
In our case, our hero turquoise was not dark enough long with a few other colour combinations on our case studies page. So we went through and improved them.
Another consideration in terms of colours is that 4% of men have some form of colour blindness, so some information you are presenting may be lost if you remove the colour. I suggest using a tool like Sim Daltonism to test this out. In our case, the links in the text blocks was shown only using the colour red, so without this colour, the links got lost. We added in the standard text underline so they now stand out.
Accessible Images
The other talking point of accessibility tends to be alt tags. Adding alt attributes to your images serve two purposes:
- Someone using a screen reader to access your site will get a description of what the image is, or text if it’s an image of text like a logo
- Google’s SEO will get more information of what your website is about
If no alt is added, a screen reader will read out the filename instead which is very confusing. Especially for a Ruby on Rails website like ours, where it adds a large string of letters and numbers after each filename. So we went through and make sure all our images had alt tags, even if it was just an empty one, so the screen reader would skip it.
We also have a fair few icons on our site that the screen reader was missing. As these were not images, alt could not be used. Instead I used aria-label’s to describe what the icon was if it was helpful. If it could be skipped I added aria-hidden instead.
Accessible Videos
We had a few videos embedded on our website, mostly through YouTube, which needed to be checked for accessibility. The first thing to check was that they don’t play automatically when you load the page. Secondly I had to ensure they had accurate subtitles. YouTube has a great tool for adding in subtitles and the default ones are usually pretty close, so it is a good place to start. Watching our videos with the subtitles turned on was pretty eye opening. In a 2-minute video it got a few key terms and branding words incorrect (like our company name reinteractive). So we went through all videos and updated the subtitles.
Valid HTML’s
Having valid, up-to-date HTML code goes a long way towards accessibility. Making sure the markup matches what is on the screen and is using the latest HTML5 elements, like main, nav, header and footer, makes it that much easier for someone to use when on a screen reader, such as someone with a major visual impairment. I use the W3C validator to test for code validity.
On our site we had a few HTML issues which we fixed:
- Multiple id’s on the same page
- Outdated element attributes
- Updating from
div’s to the HTML5 elements above - Making sure our site had a language set
- Cross browser testing
Something you’re probably already doing for accessibility and not realising it is cross browser testing. Making sure that whatever you implement works and looks consistent in Chrome, Firefox, Safari, Edge and probably IE. So I went through and tested it on all the browsers‚Äîsome manually and others using BrowserStack. It was fairly consistent; a minor tweak here and there on Safari and IE. It then looked and worked the same everywhere.
Mobile Testing
More and more people are using mobile devices exclusively to browse the internet, so developers have been making sure their websites are responsive and look nice on small screens as a result. There can be a few gotchas though when making a website accessible on mobile.
Firstly, like the keyboard accessibility point, make sure everything you can do on a desktop, you can do on a phone. As the functionality on our website was all on click, it translated well to mobile.
The second point is making sure the touch targets are easy to use, such as links and buttons. They should be at least 44px by 44px in size and be far enough apart from other touch targets that you don’t hit something else by mistake. They should also not be too big. A target that fills the whole screen is going to make it really hard for someone to scroll past without touching it by accident.
Form Validation
Having forms that are easy to fill in and give you helpful feedback and errors as you go makes a better user experience for everyone. Previously, we had very generic errors that didn’t tell you much and you didn’t know which fields were mandatory until you tried to submit it. I added in * on forms where the questions were mandatory so people know which forms needed to be filled in upfront. If they’re missed, it adds an inline error and red borders to make it easier to spot. I’ve also added in aria attributes for the errors, so people using a screen reader have an easier time picking them up and recovering from the errors.
Making the forms more dynamic with javascript would improve the experience further. At the moment they are only shown after you submit the form instead of in real time.
Navigation
Having consistent navigation and making everything easy to find is good for all users. It means people can find what they are looking for quicker and have an easier time knowing where they are and how to get back.
- Skip to content link for keyboard users
- Sitemap for users and Google SEO
- Making sure each page has a unique title for screen readers and bookmarking
- Breadcrumbs on our nested pages such as our services
- Active styling on our navigation links to help readers keep track of where they are
- Adding in a site-wide search would also be a good addition to help people find what they are looking for.
Conclusion
Making sure your website is accessible for everyone can be daunting at first. I hope this rundown of checks and tools helps you find your sites weak-points. By following these strategies, I was able to get the site to WCAG level AA. The earlier you start thinking about accessibility and including it in your project, the easier it is to maintain. Adding in these checks and tools to the appropriate stage of your project, i.e. design, development and user testing, saves you time and resources at the end of your project. Let me know if you need any help.
