Since the latest law around public sector accessibility (The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018) came into effect, it changed our own internal standard for new services from a "should have" into a "must have".
This shouldn't be an issue, but recent projects are still showing a disturbing trend of third parties claiming their solution meets WCAG 2.1 AA, only for our standard reviews to pick up some basic (but avoidable) issues that prove otherwise. Discussions with those third parties usually indicate either a lack of understanding of the standards, or a heavy reliance on automated testing, which only highlights a small range of the criteria and can't replicate how real people use the service.
This can also lead to some tension, as the service area who wants to go live with the solution isn't clear why they can't go live until the issues are resolved, and the supplier (understandably) needs time to review and plan in any work required to do so.
Which brings me to write this post... why is it that some people commissioning or providing digital services still aren't aware of the need for accessibility, let alone how to build and test solutions to meet the requirements?
Why does accessibility matter?
The most important thing to note is that an accessible website benefits everyone.
We've all been to websites where you've taken one look at the mess of links and images in the layout of the homepage and gone "I've no idea where to go for the info I want". Likewise, even if you think you have hit the right page, you are confronted by a long, complex chunk of text only to find that what you needed was in the second-to-last paragraph as a hyperlink using unhelpful (and easy to overlook) "click here" text.
Worse still, there are times when you are presented with an initially impressive-looking design, but there's no obvious way of getting round the content until you stumble across some key functionality when your mouse accidentally moves across a certain part of a page and triggers a hover effect.
These types of website are frustrating enough to those who are computer-savvy and don't need assistive technologies to browse the internet, so imagine how much more frustrating it is for those who aren't used to technology, or have dyslexia, or have physical or visual impairments.
We've covered the basic techniques for accessibility in a previous post, and there's a much more detailed version on the WAI website, so, for now, let's think about the potential causes for accessibility needs to slip through the net.
1 - Not knowing your target audience
The 2018 law aside, the need for accessibility is very clear when it comes to the target audience of some public sector services, such as social care and education. However, it is important to factor in the wider audience of your organisation, and, for us, this means our council website should cater to everyone who lives in, visits, or travels through our area.
Shropshire has a much older demographic than other local authorities, which, coupled with poor (but improving) broadband coverage, means there is a high likelihood of digital exclusion. We (like everyone else) have also noticed the proportion of people using phones and tablets to access our online services has overtaken those using laptops or desktop computers.
By ensuring we design our web pages to be less reliant on graphics and PDFs, better structured with headings, and using plain English, we hope to make it easier for people to use the site regardless of connection speed, device, or literacy.
If you are already doing this, then there's only a tiny bit more work to add to your design and development processes to meet the latest WCAG guidelines.
2 - Lack of in-house knowledge/resources/control
We are quite lucky to be part of a council that values technical skills and the importance of keeping staff up to date with the changing landscape of IT & digital/online services. When chatting to other public sector organisations, this doesn't always ring true, either from their organisational perspective, or the sheer fact that the ever-shrinking budget for all councils makes it hard to attract and retain the staff who have the right skills.
When it comes to websites and related online services, some organisations may only have one person "in charge", and rely on a number of third-parties to produce and maintain the systems for their online services. As such, their time is at a premium, and they will be taking on the multiple roles associated with that work, which sometimes can be alongside other duties. With the best will in the world, there is only so much they can do to keep things running, so some things, such as accessibility reviews, may not be something they can do or lack time to carry out properly.
Others have a fairly big team, but aren't sure how to check for accessibility, or aren't involved with projects early enough to ensure the accessibility requirements were included in the contract, or they may not have the internal authority to challenge when the product delivered doesn't meet those requirements. In such situations, it can cause internal friction when the internal team (or individual) is blamed for something they weren't aware of when something crops up after a service has gone live, or for "being awkward" when they point out the issues before it goes live and are blamed for any delays.
Sadly, all of this is more of a cultural/organisational issue, though one that is being addressed given the current pandemic is making organisations even more reliant on online services, which is, in turn, highlighting the need to have the staff to support them.
3 - Third-party products
One of the topics that has regularly come up when talking to others in the public sector is the thorny issues we've had when dealing with third-party products and their suppliers, and the (now thankfully rare) struggles to get them to address issues.
I will say that the vast majority of suppliers are honestly trying to improve their products and welcome any feedback and help, especially as the accessibility law is more well known now. However, there are still the odd outliers who seem to be reluctant to listen to the needs of their customers, and/or are very slow to change to meet new requirements. In such cases, it is important to take a step back and try to understand the situation from both sides.
Sadly, a few of the conversations I've had (or have heard about) when reporting accessibility concerns are countered with "our automated testing doesn't show any issues", or "other councils use this product, and they haven't mentioned any issues, so is this actually a problem?", or a "this is a change request and we will have to charge".
The first and second argument is more of an indication of the supplier's lack of understanding on how to test their product for accessibility (you'll need automated tools and a manual testing process to do it properly), along with an indication that other councils haven't got the time/resources/knowledge to review the product themselves so have to trust the supplier's claim. This is usually cleared up by a conversation with the supplier with a demonstration of the issues, so they can see for themselves why these issues are important and do need resolving. It is also helpful to include the service area who have asked for this product (if possible), so they can also understand the situation and can back you up.
The third argument is more frustrating, but more easily countered - if they have claimed to meet a particular standard, then they can't charge extra for any work needed as they haven't delivered what they have promised. It is understandable that they would be risk-averse, considering the time & effort they will have to put in to plan, test and implement any changes, and, in the cases of cloud-hosted solutions, they would run the risk of affecting their other customers too, but legally they have to uphold their end of the contract.
4 - The need to "be innovative" and have a "good looking website"
I'll put this out there - an "innovative" and "good looking" website can be accessible, and easier to maintain too.
If you are using the latest HTML5 & CSS3 to build a website, then you are using standards set by the W3C, and modern browsers will support it automatically. If you use a JavaScript library to supplement your design, then take a look through the documentation and forums to ensure you are aware of any potential extra code/configuration needed to make you compliant, or of any limitations that you will have to work around.
Most importantly, by ensuring your basic code/markup is built using the appropriate HTML tags and CSS, as this will prevent (or make it easy to fix) 90% of the common accessibility issues that I have encountered, and make it easier to test too.
It is alarming how many websites I've seen that have <span> or <div> or <i> tags relying on JavaScript to make them act as links or buttons, which often won't work with assistive technologies and won't be picked up by automated testing, yet HTML has those functions covered already with <a> or <input> or <button> tags. All that is needed is some minor CSS tweaks to make them look the same, and by stripping out multiple lines of HTML & JavaScript you are also helping your website perform quicker, as there is less for the browser to download and process.
To sum up
Ultimately, regardless of how your website is designed, or what it is built on, or who built it for you, you do need to plan and build with accessibility in mind, and test with a mixture of manual and automated tests.
When planning a new service, simple design and coding considerations can make that design more structured, grouping links and images into logical blocks based around the business and user needs. Content editors should be reviewing the proposed content, breaking the text down into shorter sentences and paragraphs over a number of pages, using plain English instead of jargon, and adding clear HTML headings throughout to aid readability.
The designers & developers should be adding visual, consistent cues for interactive elements, and ensure that the code behind the scenes also works for screen readers and those using non-mouse navigation. If they are keeping to HTML & CSS standards, this should only require a few easy additional additions/considerations during the build.
When testing, keep in mind that automated tools are useful, but shouldn't be your sole means of testing. Although they will allow you to quickly pick up technical issues with the markup and CSS used, they should be coupled with manual run-throughs of pages and functionality too. This manual process will help verify (or discount) issues found by the automated tools, as well as providing the important reviews on contextual issues with heading structures, wording, mobile responsiveness, keyboard navigation, UX issues etc.
The most valuable test comes from actual users who do need websites to be accessible - after all, they use a variety of techniques and assistive technologies in their daily life, and can tell you a lot about their own needs and expectations. Most of the time, we won't be able to get that feedback until a service is live, so make it easy for people to contact you, and, if possible, engage with them to see if they would be willing to find and test any fixes required.
It's OK to miss out on some accessibility criteria accidentally - no-one is perfect. Just remember to fix or mitigate the problem when it is pointed out, or when you discover it.