Section 4 of WCAG 2.1 is “Robust”. This says your site must work on a range of browsers and assistive technologies. So, really you should test it on the most popular ones. Chrome, Firefox, Safari, Edge. 

The accessibility extensions are available for most of them.

However, there are some combination issues to be aware of. For example, if you’re using the Voiceover screen reader, or the Voice Control speech recognition software, they will only work properly in the Safari browser. Apple tools don’t play well with non-apple browsers.

The GOV.UK Service Manual has a list of common browsers and assistive technology combinations which might help to streamline your testing efforts: Testing with assistive technologies - Service Manual - GOV.UK (www.gov.uk)

It’s better to test your service as much as you can yourself before you put it in front of users. The reason being, is that user research sessions are hard to recruit for, time consuming to set up, and often expensive. You want to test context in user research, not tool compatibility. You can test compatibility on your own.

To get the most out of the user research session, you want to understand if the context and the interactions make sense. If the user can get from point A to point B in a service. If the nuances in the policy can be understood. You don’t want to come away from the research session with a list of things you could have found yourself like missing alt-text on images. 

We find the most efficient way to do accessibility testing is to follow a particular order. Each stage relies on the other one before it being correct, and they get increasingly more time consuming. So you don’t want to test with a screen reader if your HTML is not valid, because it’s unlikely to work and screen reader testing is slow. Validating the HTML can be done with a tool in about 2 or 3 seconds. So, before user testing we’d usually do the following:

1. Validate the HTML
2. Run the automated tools
3. Do the manual checks
4. Test assistive technologies

We’ve published guidance on how to do each one of it’s useful: How to do accessibility testing - DWP Accessibility Manual

It depends. WYSIWYG (“whizzy-wig” - stands for what you see is what you get) websites such as GoDaddy or WIX are usually pretty awful. You can usually choose from a few themes or layouts then you drag and drop content around. 

Because you’re dragging and dropping content around, YOU have an understanding of how you expect the content to be read based on your understanding of design and human language etc. But, you’re relying on the HTML generator coming to the same conclusion; and it rarely does. Unless it’s simple content and a simple layout, it is likely to get it wrong. As soon as you have columns and sidebars etc it starts to get complicated. 

The added problem with these types of editors is that they don’t produce simple human readable code. When you have an accessibility problem, being able to look at the HTML to debug it is essential, but with WIX, a human is never expected to look at the code so it is often overcomplicated. For example, if you’ve got a text input and a label which says “First name”, you’d expect the ID and the FOR attribute on the label to be something like “first-name” so it’s easy to see they are related. But with WIX you might find the ID and the FOR attribute is just a mash of numbers and letters about 20 characters long. A machine can tell if they match in less than half a second, but for a human it could take several minutes and it’s very easy to get wrong.

Wordpress is similar in that it uses themes, but anybody can create themes from scratch for Wordpress if they know how to code PHP and HTML. Depending on how good the developer is, and how much effort they put into accessibility will determine how accessible the end result is. The good thing about Wordpress is you can build your own themes or you can at least modify the one you have installed. It would be worth researching which themes have been designed with accessibility in mind and throwing some of the automated tools at them to test them to get a feeler for how accessible they actually are.

Again though, there are added pitfalls. With something like Wordpress, you have the added complexity that you can install various plugins, and they are all built by different developers. Any one of them could conflict with the others as they’ve likely never been tested together. So, your theme could be accessible and then the plugins could ruin it all. So testing would always be essential.

I guess in short the answer is, WIX and GoDaddy type site builders are unlikely to be accessible. Wordpress is entirely dependent on theme and plugin choice. Drupal, which is similar to Wordpress, committed to WCAG 2.0 in versions 8 and 9, so even though it is an outdated standard, it’s still a relatively accessible foundation. But again it would depend on the theme you installed etc.

I’m not aware of any. I guess it’s a bit of a chicken and egg scenario as a CMS will take inputted content and spit out HTML. So, a good CMS might take bad content and create good HTML. A bad CMS might take good content and create bad HTML. 

If you’re looking for an automated way to test your CMS content, you’re far better off using the automated accessibility tools on the output. Publish the page, then view it in the browser and hit it with things like Axe, ARC and Wave. This way you can see if the outputted HTML is throwing errors. If it is, you need to work out if it’s the content you’ve put in the CMS or if it’s the CMS translating your content to bad HTML.

This would be a better solution (in my opinion) than relying on the CMS itself marking its own homework.

Unfortunately, no. It isn’t information which is available to the Google Analytics API. It will capture the browser and the device and the operating system etc, but assistive technology runs as a separate programme and does not expose itself to these data captures. It’s like if I’m using Spotify while browsing the site. There’s just no way to know that programme is running on my computer.

For assistive technology usage, we rely on survey analysis such as the GOV.UK 2016 Assistive Technology Survey and the more recent WebAim 2019 Screen Reader Survey:

• Results of the 2016 GOV.UK assistive technology survey - Accessibility in government (blog.gov.uk)
• WebAIM: Screen Reader User Survey #8 Results

Voice UI is very useful for a lot of people. But like all things accessibility, no two people are the same.

Voice UI would be useful as an alternative route or channel, but less likely to work for everyone as the sole method of interaction. 

For example, relying on voice alone might negatively impact people with a vocal impairment. Vocal impairments aren’t as common so often get overlooked, but they can affect people who may have vocal-chord damage from things like trauma or laryngeal cancer. It could also impact people with hearing impairments as they may not hear the cues. It may also affect people where English is not their first language. A lot of people can read a second language better than they can speak it.

So, just like visual websites can be tricky for some people, voice UI can be tricky for others. I don’t think a Voice UI would be an easier product to make compliant, and wouldn’t necessarily be a solution which would result in less work, as there may be less criteria to meet, but all 4 aspects of WCAG would still apply which would be Perceivable, Operable, Understandable and Robust. 

Unfortunately, there is often a lack of respect for frontend development as a specialism as HTML and CSS is often viewed as ‘easy’. But cobbling together HTML and CSS to make something look correct, as we all know is dramatically different to using the right elements, tags and aria-attributes to actually make something behave as expected.

Getting accessibility into your definition of done is one of the best ways to stop people just churning out bad code and moving on. If you have a policy as a team that you won’t merge code which has not passed accessibility testing, then you will very quickly highlight the problem. 

If the ‘hotshots’ can’t move onto developing the new features because the ones they’ve just built aren’t up to scratch, then the number of senior people available to help fix the accessibility bugs suddenly goes up. It also reduces tech-debt and increases the standard of the code. The obvious drawback is that the delivery velocity of the team will take a bit of a dive at first. But once you’ve fixed the same bugs a few times you quickly learn not to do it again in future and the velocity of the team will recover.

Another option is to build automated checkers into your continuous integration pipeline. By doing this, it means the tool is saying the code isn’t good enough, not another team member, which makes it less personal and can reduce conflict.

It’s worth pointing out that I rarely come across people who don’t want to do a better job. It’s often just a lack of awareness or forsight. People rarely make things bad on purpose and often don’t know how bad something is until you show them. It could be that the developers just aren’t aware that the code they turn out is that bad. I find doing demonstrations with screen readers etc is often a really good way to make people empathise, but it’s important to handle it in a sensitive manner. ‘Hotshots’ may be upset to find that their code actually isn’t as good as they thought it was, and the last thing anybody wants is to be accused of deliberate discrimination.

Obviously everybody is different, and will respond to different methods. HTML is often viewed as boring compared to other aspects of software engineering. But, I find there’s an aspect of technicality and problem solving to accessibility which you don’t get with regular HTML templating, and this can often pique the interest of developers.  

If you can pique this interest, you often find they get really into it. So, sometimes doing an afternoon hackathon session where everyone has a go at trying to fix a particular accessibility problem is good. If you can create an environment where people are encouraged to work together and solve a problem, it promotes learning and comradery, rather than simply assigning them a sprint task they feel is boring and uninspiring. I’ve literally seen a developer whoop before when a screen reader read out their code correctly, which was definitely an unexpected result for everybody involved.