In the physical world, legislation such as the Equality Act 2010, and the earlier Disability Discrimination Act 1995 aimed to ensure that the idea of inclusivity was closer to the forefront of an organisation’s mind, by obliging them to make “Reasonable adjustments” to their infrastructure to enable disabled service users. As of 2018, the virtual world has made an attempt to close the accessibility gap - at least in Public Sector Bodies - with the introduction of The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
In short, public sector websites and apps must ensure they are compliant with a set of guidelines known as the Web Content Accessibility Guidelines (WCAG). For those who have not considered accessibility as part of their offerings previously, adhering to this can be a big ask.
So what is WCAG?
To answer this, we should first look at the organisation behind WCAG, the World Wide Web consortium (W3C). Headed by the father of the world wide web (WWW), Tim Berners-Lee, they develop the various web standards in use today across the WWW. An area particularly dear to their hearts is inclusivity, and through their accessibility wing the Web Accessibility Initiative (WAI), WCAG was born in the late 90’s.
Since then WCAG has gone through various revisions, accommodating the evolution in hardware and software, arriving at it’s current iteration, version 2.1 in 2018. Delving further, each iteration stipulates various levels of adherence - A, AA and AAA - with each level requiring a stronger focus on accessibility to ensure compliance.
With the history and the pedigree, it’s no surprise that organisations and nations have adopted WCAG 2.1 as their target accessibility standard, typically to the AA standard - some implementing it as law.
As such, ethical and commercial justifications are only an few of the motivators for implementation. Prior to the enshrinement of WCAG compliance in UK law, digital services have not been immune to lawsuits. Whilst the Equality Act 2010 does not explicitly make reference to websites, that has not stopped successful lawsuits such as the Royal National Institute of Blind suing BMI following a failure to make their website accessible.
In America, the Americans with Disabilities Act, which itself does not explicitly reference websites or apps, has been the basis for several successful high profile test cases which has in turn has led to over 5,000 lawsuits in the first half of 2018 alone in discrimination cases. It is not a stretch of the imagination to predict that as clearer guidelines become part of UK legislation, as they have with The Public Sector Bodies Accessibility Regulations, that we can expect a similar rise in legal action against non-compliant sites on our side of the pond. Furthermore, it would seem prudent to assume that once the public sector has its own house in order, that such legislation may be expanded to additionally apply to commercial services.
So proactive bests reactive. How do we ensure compliance?
A wealth of tools, both free and paid, are available that promise to analyse your site and advise your level of WCAG 2.1 compliance. These typically scan through the site and provide feedback on where you are failing, to what degree and, sometimes, what actions must be undertaken to comply. Whilst useful indicators, these suggestions cannot be used alone to determine overall compliance.
Different tools produce different interpretations of compliance and none can test all the requirements and aspects associated with WCAG 2.1 specification. Further, there are aspects of WCAG which are context dependent and require human eyes to determine compliance.
Automated tools cannot make the distinction between a decorative image and a “content” image where attribute values vary. In addition. they cannot determine if the page when rendered non-visually maintains a meaningful sequence, or that critical instruction provided to the user based solely on visual identifiers has not been used.
So there’s no quick-fix tool. How do we ensure compliance?
With 50 success criteria at the AA standard, an intimate understanding of each of these requirements is essential, and the WCAG 2.1 Quick Reference guide is the best starting point. It describes what is required for each and offers a variety of methods which can be employed to reach compliance. For the more intricate requirements, making use of the Understanding Success Criterion that accompanies each, offers practical examples, with pass / fail scenarios. Distilling this down to an audit checklist would be beneficial, and armed with your new knowledge, you can then conduct an audit of your site.
In the majority of cases, the site will typically split down the line of the code and the content.
The content, in this context, would be anything typically controlled by the site’s content editors rather than the development team. Dependent on the volume and variety of elements that content editors have the facility to include and manipulate, identification of compliance issues can vary in difficulty, but typically should be simpler to rectify than the code side.
Once the site has been audited, and failures listed against the success criteria, remedial action can then be taken to bring the site in line with WCAG. The Show techniques and failures section of the Quick Ref is particularly useful at this stage, which makes available a variety of methods to accommodate and address unforgiving setups. However, it may not always be possible to accommodate the WCAG criteria – and if suitable justification can be provided, that may be acceptable – provided it is noted within the Accessibility statement.
Any new public sector website published after the 23 September 2018 will need to meet the WCAG2.1 AA accessibility standards referred to in the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 and publish an accessibility statement by 23 September 2019. Sites published before the 23rd of September 2018 need to comply by the 23rd of September 2020.
Richard Downes is an Associate Developer with Chess Digital with a passion for front-end development. He has worked in technology for over 10 years, from hardware repairs and client support, to service delivery and photography .