Accessibility Testing – Part Two

This post is the second in a two part post about accessibility. For an overview on the basics of Accessibility Testing, please see Part One.

The target

I’ve chosen to perform the analysis on, the website representing scouting in the UK. This is for two reasons, firstly because it is a large organisation which promotes itself as being open and welcome to those from all backgrounds and opportunities. Secondly, is because as a scout leader I hope that the website is well developed. Any feedback I have will be passed back to the Scouting Association. image of homepage

I will be using Accessibility Insights Google Chrome Add-On to help with the analysis of this site. This add-on provides a comprehensive suite of tests which are based on the WCAG guidelines.

Fast Pass – The results

Using this tool there are two main options that we will be using. Firstly there is ‘Fast Pass’ which provides a quick scan off the page and provides instant feedback on any issues where the site fails, in addition to a link to the WCAG specific guideline. Furthermore, it highlights on the website where the element is that is failing the test.

Appraising the results

aria-hidden-focus: ARIA hidden element must not contain focusable elements

What does this mean?
If an element is focusable, i.e. can be clicked on by an ‘ordinary user’, by setting it as a hidden element means that it will not be visible to those using assistive technologies such as screen readers.

WCAG Rules:
4.1.2 and 1.3.1. Accessibility insights offer links to the specific elements within the WCAG guidelines.

How to fix?
There are two solutions to this: either do not set this element as aria-hidden=”true” as it is required for navigation, or to remove the element from the DOM.

Thinking practically, if you are using a screen reader, you will not need to scroll through this list as you will have all options available to you, so arguably this is not an issue, because this clickable option is only relevant for those using the website as an ‘ordinary user’.

color-contrast: Elements must have sufficient color contrast

What does this mean?
The WCAG guidelines require there should be a specific amount of contrast between colours for A, AA, or AAA level accessibility. The colours here are: #00a794 and #FFFFFF.

How to fix?
The contrast can be appraised using a number of online tools, for this example I’m using the WebAIM Contrast Checker:

With this tool you can use the sliders to adjust the colours until the requisite contrast is reached:

link-name: Links must have discernible text

What does this mean?
As you can see from the image with the highlights, the images which are links are images of business logos. By nature, these logos often have text in indicating a name for the user with clear vision.

How to fix?
Fixing this is remarkably simple and can be completed by using ‘aria-label’ within the anchor tag. Something like: aria-label=”business name”. Interestingly, on closer inspection there are no alt tags provided within the img tag. There is simply the keyword alt within the tag. Naughty naughty!

What’s next?

There are a multitude of accessibility tests. These barely scraped the surface of what is possible, but hopefully this blog post highlights some easy ways to get started. As was said in part one of this post, most of these fixes could have been avoided by writing robust HTML in the first place.