Darren Clark has worked for Chess for over 12 years and leads the team at the forefront of application development. Darren and his team design and develop web applications, including web APIs, user interface, business intelligence solutions as well as custom Umbraco solutions with focus on quality and automated execution of tests and deployment and he is also Certified Microsoft developer with a specialism in Umbraco.
We recommend:
To learn more about Web Accessibility Compliance, watch our webinar where we cover:
- What web accessibility means and why it's important
- What guidelines your organisation needs to follow
- First steps towards meeting level AA of the Web Content Accessibility Guidelines (WCAG 2.1)
- Our customers' success stories
- Frequently asked questions
Introduction:
A relaxed approach to accessibility compliance could be an expensive oversight. With the virtual world an extension of the physical, accessibility has often been treated the same – as an afterthought. It's time for a change.
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 attempted to close the accessibility gap in Public Sector Bodies by introducing The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.
To meet government accessibility requirements, digital services must:
- meet level AA of the Web Content Accessibility Guidelines (WCAG 2.1) as a minimum
- work on the most commonly used assistive technologies - including screen magnifiers, screen readers and speech recognition tools
- include people with disabilities in user research
- have an accessibility statement that explains how accessible the service is - you need to publish this when the service moves into public beta
Source: www.gov.uk
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). Adhering to this can be a big ask for those who have not considered accessibility as part of their offerings previously.
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 '90s.
Since then, WCAG has gone through various revisions, accommodating hardware and software evolution, arriving at its current iteration, version 2.1 in 2018. Each iteration stipulates multiple adherence levels - A, AA and AAA - each 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 a few of the motivators for implementation.
Even before the enshrinement of WCAG compliance in UK law, digital services were not immune to lawsuits. The Equality Act 2010 does not explicitly reference websites, but that hasn't stopped successful lawsuits such as the Royal National Institute of Blind suing BMI following a failure to make their website accessible. In the US, the Americans with Disabilities Act does not explicitly reference websites or apps either. Yet it has been the basis for several successful high profile test cases, leading to over 5,000 discrimination lawsuits in the first half of 2018 alone.
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, we can expect a similar rise in legal action against non-compliant sites. Furthermore, it would seem prudent to assume that once the public sector has its own house in order, the government may expand such legislation to apply to commercial services.
How do we ensure compliance?
Proactive beats reactive
A wealth of tools, both free and paid, are available to analyse your site and advise your WCAG 2.1 compliance level. These typically scan through the site and provide feedback on where you are failing, to what degree and, sometimes, what actions you must undertake to comply. While useful indicators, you cannot use these suggestions alone to determine overall compliance.
Different tools produce different compliance interpretations, 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 distinguish between a decorative image and a "content" image where attribute values vary. They cannot determine if the page when rendered non-visually maintains a meaningful sequence or if critical instruction is provided to the user based solely on visual identifiers.
There's no quick-fix tool
With 50 success criteria at the AA standard, an intimate understanding of each requirement is essential, and the WCAG 2.1 Quick Reference guide is the best starting point. It describes what is required for each and offers various methods that can be employed to reach compliance. For the more complex requirements, use the Understanding Success Criterion, which offers practical examples and pass/fail scenarios. Distilling this down to an audit checklist would be beneficial, and arm you with new knowledge to conduct an audit of your site.
In most cases, the site will typically split down the line of the code and the content. The code, consisting of HTML in views, templates, injected via JavaScript, practically all aspects not controlled by content editors, should be audited. Focus not only on what is rendered on the page at the point of testing but on all variables. In this context, the content 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, you can then take remedial action to bring the site in line with WCAG. The Show techniques and failures section of the Quick Ref is instrumental at this stage. It makes available a variety of methods to accommodate and address unforgiving setups. However, it may not always be possible to accommodate the WCAG criteria. If you can provide a suitable justification, that may be acceptable as long as it is noted within the Accessibility Statement.
To learn more about Web Accessibility Compliance, watch our webinar where we cover:
- What web accessibility means and why it's important
- What guidelines your organisation needs to follow
- First steps towards meeting level AA of the Web Content Accessibility Guidelines (WCAG 2.1)
- Our customers' success stories
- Frequently asked questions