Unless you yourself are actually visually impaired or know someone who is, chances are you don’t think about how the blind or visually impaired use the web. Accessibility testing is something that needs to be considered more often for those with impairments using the web. Running accessibility validators on various sites, you can find a litany of errors. Some aren’t high priority fixes, some are. You’ll find errors ranging from background/font colors not having enough contrast to headings being incorrectly nested to divs and spans not being used correctly. Usually it doesn’t take much to get your site up to standard and typically won’t stifle your designs. Designing or developing with some of the most common errors in mind makes troubleshooting easier in the long run.
Common Accessibility Errors
As I mentioned earlier, there are simple fixes to add better interactivity to sites making them more accessible for those with impairments. Starting off with: Proper HTML Markups Simple, right? Well it’s one of those things people can get in the habit of not keeping in the forefront of their mind. This is something I see a lot on various websites, the misusing of heading tags (h1 – h6). Skipping them and/or using classes to achieve the same thing can be confusing for those using the DOM (via screen reader) to navigate your site. Images in Place of Text More often than not, I see this being used to get a navigation button to look a certain way across several browsers (looking at you, IE8 and below) or maybe it’s there to act as a header image. Either way, setting images to be used as text is not something that should be done, however, if it can’t be avoided use the image alt text to provide context. Speaking of… Using Alt Text for Images All images need to have alt text provided for them. The alt text then gets read by screen readers to blind users. If you have an image that acts as decoration, leaving your alt text as – alt=” ” – is acceptable. This gets interpreted as decoration and the screen reader will ignore it. Not Using ARIA Compliance Probably one of the most important things you can do for your site organizationally (as far as screen readers are concerned). Having your markup be ARIA compliant will help define a set of attributes associated with your elements to help screen readers decipher your markup in the proper way. For instance, ARIA can be used to assign a role of menu or header to your markup. I strongly suggest reading the WC3 ARIA Guidelines for further information.
Most of these errors are easy to repair within your code. However, mistakes can still be made and in those instances there are plenty of tools and screen checkers we can use. Web-based website accessibility evaluation tools are a handy resource for anyone who wants to ensure that the site they are developing meets established accessibility standards. Cynthia Says Cynthia Says has been around for some time, since about 2003. It helps users identify errors in their Web content related to Section 508 standards and/or the WCAG guidelines for Web accessibility. Cynthia Says allows users to test individual pages on their website and provides feedback in a reporting format that is clear and easy to understand. Tota11y Tota11y is an accessibility visualization toolkit that will help show you how your site performs with assistive technologies. If your site has any violations, it will show you in a visual format with suggestions on how to correct those mistakes. Check out their announcement post describing their inspiration for the toolkit and how it works. AChecker AChecker is a validation tool that has been around for a while. You enter the URL of your website and it evaluates your HTML content for accessibility errors. You can also paste in your code, or upload your HTML file. The AChecker will then produce a report listing the errors, if any, on your site. Issues are broken up into three groups, Known Problems (Known accessibility issues), Likely Problems (Possible barriers to impaired users) and Potential Problems (Issues AChecker can’t identify on its own, will a need human decision). Check My Colours From the website: “[Check My Colours] is a tool for checking foreground and background color combinations of all DOM elements and determining if they provide sufficient contrast when viewed by someone having color deficits.” Enter your site’s URL into the Check input and you’ll get a list of the colors used on your site and whether they pass or fail along with an example of what it looks like on your background. Keep in mind, if you have an patterned image background the validator won’t use that, instead it will use the default or whatever you have set as your background color. Google Intro to Web Accessibility Introduction to Web Accessibility is an online course that introduces tools and techniques for web developers to easily ensure that websites are more accessible to users who are blind or have low vision. Lesson plans with accompanying video make this a great learning source for those who really want to start their projects on the right foot.
Googling “website accessibility tools” will bring up even more tools and resources to use to make your site accessible to those with vision impairments. Github repository A11y is one of those resources. These tools are great but something I want to mention is, these tools can not replace good ol’ human interaction. Download Chrome Vox or Fangs on Firefox or any of the other screen readers available for use and navigate your site using a screen reader. Close your eyes if that helps and navigate your site using the keyboard and ‘see’ it as someone who is blind would. You will have a better understanding of how you need to code your site and how those with vision impairments view the web.