To my shame, most of the sites I work on are only semi-accessible. The 1995 Disability Act established accessibility requirements for websites in the UK. These laws were further strengthened in the 2010 Equality Act which requires service providers to take reasonable steps to provide an equal experience for disabled users both online and offline.
Working in the educational sector, budgets are often tight and timelines are even tighter. We rely on frameworks such as Bootstrap to get us part-way towards accessibility compliance.
A full-scale accessibility audit is costly, time consuming and most importantly, necessary. Additional regulations introduced in 2018 require public bodies, such as a university, to include accessibility statements on all of their sites.
To write an accessibility statement, you need to know which parts of your site are accessible and which are not. The best way to do this is to conduct a full accessibility audit.
If an application has not received an accessibility audit, it should not be considered as completed or ready for deployment.
To reduce the amount of work conducting an accessibility audit, we are automatically testing all our projects every time we make a change to its user interface. By doing so, we should fix many of the "low hanging fruits" with minimum effort.
Accessibility Review of a Legacy System
I have recently been working on a legacy system called the BMS Honours Project. It is a site that allows students in the Biomedical School to select projects to work on for their final honours project.
I was asked to update some text on the front page and decided to run some accessibility checks agains the page. For all tests, I used the excellent Axe developer tools plugin for Firefox. If you don't use Firefox, the plugin is available for other browsers such as Chrome.
Colour contrast is the most well known accessibility issues that web sites face. Sites should have sufficient contrast between the text in the foreground and the colour in the background.
When a site has poor colour contrast people with low vision and colour blindness can have issues reading the content on the page.
Two elements on the BMS site failed the basic WCAG 2.0 AA contrast requirements. The header text and the link to register for an EASE Friend account both had insufficient contrast.
I wanted to fix these issues without changing the look of the site too drastically as I didn't want my task to grow in scope. To choose new colours, I used the excellent tanaguru contrast finder tool.
I set the existing colours of the foreground and background colours and the tool provided me with an array of colours that were similar, but which satisfied WCAG's 2.0 AA contrast requirement.
Document Must Have One Main Landmark
The homepage does not have a main landmark but what does this mean?
A page is a lot easier to navigate if it is split up into logical sections. In earlier versions of HTML, there was no way to semantically section a page, but with the advent of HTML 5 we had new tags that helped separate the page:
- main - contains the main content of the page
- footer - usually contains author information, copyright data etc.
- nav - page navigation links are contained within a nav tag
- header - heading elements such as a logo or search box
Prior to HTML 5, developers could provide semantic meaning to HTML divs using ARIA tags such as banner, navigation, main, and contentinfo. These are added using the role attribute against a div.
<div role="navigation"> <a href="link-one">Link One</a> <a href="link-two">Link Two</a> </div>
Axe is asking us to ensure we identify our main content by using a
<main> tag instead of a basic
<div>. It is also good practice to use ARIA tags in conjunction with semantic HTML 5 tags to ensure the best coverage for accessibilty tools.
By signposting our main content or putting down a landmark, users that are blind, deaf blind, or have mobility issues can jump to the main content with ease.
To fix the issues on the BMS homepage, I changed standard divs to HTML 5 tags and used their ARIA role counterparts.
Page Must Contain a Level-One Heading
This is another accessibility consideration most developers will be familiar with. Having a level-one heading on your page is considered a best-practice rather than a requirement.
It allows sighted, blind, deafblind, and low vision users to jump to the main topic of the page which will usually be located next to the main content.
The BMS Honours Project used level-two headings but no level-one headings. To rectify this, I changed the LOGIN heading to a
<h1> header to sign post the start of the main content and give the header more prominence, compared with its level-two siblings
These are baby steps. Automated analysis will only find around thirty percent of the issues on a site. It is not a replacement for a manual accessibility audit but it will make manual testing quicker by identifying many errors automatically.
At the moment, my team is using browser plugins to run automated accessibility tests. In the coming months we will use a continuous integration tool called pa11y so that these tests are conducted automatically.
I wil also be reading Laura Kalbag's book, Accessibility for Everyone to increase my knowledge and ensure all of our sites are fully accessible in future.