Skip to content

Watch now: 8 step plan to accessible and inclusive websites

Webinar with Texthelp & Department for Work and Pensions

The recording is available to watch below. We’ve also sent it to your inbox for later viewing. 

Psst. Keep scrolling for some free resources to help you drive accessibility and online inclusion in your organisation.

Your questions answered

During the live webinar, our listeners asked us lots of great questions. Craig Abbott, has kindly answered some of the most commonly asked questions below:

  • 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 (

  • 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:

  • 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.

Follow up webinar: Tools to improve digital accessibility and readability

If you'd like to find out how accessible your website and content is, check out our next webinar on 11th November.

Join the short 30 minute session to find out how you can:

  • Check the accessibility of your website
  • Improve the readability of your online content
  • Support website visitors with assistive technology tools

Extra resources

From pdfs and graphics, to videos and social media, it's important that we open up every piece of digital content, so that it's available and accessible to everyone. When it comes to digital accessibility, both design and content must be considered. 

A truly accessible website welcomes the user with an experience that’s simple and enjoyable. And with this comes making sure that content is easy to understand. These resources will help you to improve accessibility and readability. So that you can open up your content to all.

Accessibility checklist: for marketing and comms

Share this checklist with your Marketing team. It'll help them to keep accessibility in mind throughout their digital campaigns.

Guide: understanding the POUR principles

Websites should be Perceivable, Operable, Understandable and Robust. Discover what the POUR principles are and what they mean for accessibility.

All in one accessibility solution: ReachDeck

Check accessibility. Improve readability. Provide online support. All with one solution. ReachDeck is available to try free for 30 days.

Share this webinar

If you think any of your colleagues or team members would benefit from attending our session, feel free to share this invite link: