Startups – we know that selling to the public sector is tough; it can be hard to find a route in, understand the frameworks, find opportunities to prove the value of your product. 

Even when you jump through all the hoops that you prepared for, it’s inevitable that a little known guideline or requirement gets raised by a client that hadn’t been raised before. You might have prepared for it, you might not – and the consequences of the latter can be troublesome.

In this new series, we’ll be going through some of the things you need to know about working with the UK public sector* as a tech startup. If you’re selling a digital product to the government, the NHS or others, it’s essential that you are aware of these requirements and what they mean for your product.

This week, with the final deadline for public sector accessibility requirements coming into force on 23 September –  we’re looking at digital accessibility – and why – if you’re not clear on how it applies to you – your relationship with the public sector might come to an end sooner than you imagined.

* although this series is focused on the UK public sector, many of the lessons will be transferable to working with governments and public bodies elsewhere. The regulations mentioned in this article transpose an EU Directive into UK Law, and as such, other EU states will have comparable legislation and requirements. 

 

In this guide:

  1. What is digital accessibility, and why is it important?
  2. Isn’t accessibility just a nice to have, not a requirement?
  3. Do I have to take accessibility into account when developing or selling my product or service?
  4. What do I have to do to make my public-sector mobile application accessible?
  5. Accessibility in practice – Developing for an accessible user experience:

 

What is digital accessibility, and why is it important?

Digital accessibility is the idea that digital services can be designed in a way that by means they are inclusive and usable by the 1 in 5 people in the UK with a disability of some kind1

Accessibility principles exist to make sure that if you have a disability – whether it’s physical, (i.e. you’re visually impaired and use a screen reader, deaf and require subtitles, or you’re unable to use a mouse due to repetitive strain injury) or a cognitive disability (for example, you’re dyslexic) – you’re not arbitrarily prevented from using a digital service by poorly designed services that either fail to provide reasonable adjustment or that are over complicated, in language or design. 

 

Isn’t accessibility just a nice to have, not a requirement? Why does it matter to me?

You’ve not invested time into making your product accessible when selling to the private sector – and you’ve not come across any problems up until now – so why should you do it when it comes to selling to the public sector?

Well, simply put, it’s the law. 

The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 set out the requirement that any website, intranet, extranet or application developed for use in the public sector would be required to meet accessibility guidelines set out by the World Wide Web Consortium.

The clincher here for companies selling to the public sector is that this also applies to applications developed by third parties for the public sector. While the contracting department, agency or other public sector body has overall responsibility to ensure accessibility under the guidelines, you can be sure that one fast way to lose a potential contract would be to shirk your responsibilities in this area. 

 

Do I have to take accessibility into account when developing or selling my product or service?

The regulations apply to websites and mobile applications of a public sector body; you will need to take accessibility into account if actively involved in the development of either of these on behalf of any public sector organisation.

This will also likely be the case if you’re creating of developing bespoke versions of your applications of your product for use on a website or mobile application.

Exemptions under the regulations include third party applications under which the public body has no control (i.e using Google Maps to show where an office is located) but the likelihood is that – if you’re developing a mobile or web application for a government department, agency or other public body, they will ask you to develop it with accessibility in mind.

In fact, the Cabinet Office has put together guidance for public sector departments and bodies that, if correctly followed, will see startups selling digital applications to the government experiencing more regular reviews of whether they meet accessibility standards – and may find the duty to meet these standards is a contractual obligation2

Finally, even where your product is not covered by the guidelines, it really is worth asking yourself what your reasons would be for not ensuring your product is accessible. Day-to-day, it is hard to be confident of exactly who will be using your product now or in the future – or what their needs are.

If your answer for not making your product accessible was only ‘accessibility was optional’, then you might want to consider putting in that extra effort.

 

What do I have to do to make my public-sector application accessible?

Put concisely, according to the regulations, which transpose an EU Directive: for a public sector website or mobile application to be deemed accessible, it must meet the W3C’s Web Content Accessibility Guidelines (WCAG) 2.1, to AA standard

The WCAG 2.1 guidelines set out a series of criteria against which everything from design and content, to code and format is tested against3

It is worth highlighting at this point that many of the criteria have an AAA standard which reflect steps that you can take to ensure the highest level of accessibility for the given criteria. Under regulations currently in place, there is no obligation to meet this highest standard, but if you can, it may be easier to do this sooner rather than later. 

(A note for those wondering, some criteria have only an A standard, and have no AA listed. In this case, it is essential to meet this A standard, but there is no further action to take against this criteria.)

What this means in practice is ensuring that your web or application design is usable and readable by those who might struggle where their challenges have not been taken into account. 

 

Accessibility in practice – Developing for an accessible user experience:

Let’s look at it from a variety of user perspectives; this is a non-exhaustive list of challenges many people face when using digital interfaces such as websites and applications, goes someway to setting out how you can ensure your application or content is as inclusive as possible. 

 

  • Accessibility for the blind or partially sighted

Two million people in the UK are estimated to be either blind or visually impaired4. Screen readers are one of the most important and common tools for the blind or visually impaired to be able to access digital content on the web, and in applications. You need to make sure that your content and layout is logical to a screen reader. It needs to be clearly laid out, explained and programming markup should identify the difference between headings and other content, such as hyperlinks and other forms of navigation

Where there is non-text content – whether its images, infographics, graphs or video – accessibility means ensuring that text alternatives exist that a screen reader can use to explain the purpose of that content to the user5

 

  • Accessibility for the colour blind

Colour blindness is another impairment that may affect a user in an entirely different way to the blind or partially sighted. Three million people in the UK are estimated to suffer from colour blindness in some form6. While a colour blind user may have no problem actually seeing your website or application, the way you’ve designed the service may lead to pitfalls in their experience.

Perhaps you’ve used a visually striking colour combination to reflect your brand identity, using an edgy low contrast between the small web-text and the background. For some users, this decision means that they can no longer read your copy. Accessibility means designing in a way that ensures that either this decision isn’t taken, or that the size of the webtext is significant enough to ensure that it’s not a problem.

A similar problem exists for hyperllinks – without hyperlinks that contrast sufficiently against regular text, or that are clearly underlined to indicate that they are a hyperlink, then users can be left confused or struggling to use your application effectively. 

 

  • Limited movement

Imagine that, having developed repetitive strain injury, you’re no longer able to use a mouse. Your alternative is to only use a keyboard. Most websites now allow you to tab through the different links on the page, allowing you to read through the site. 

Poor web design and markup in your coding, however, often makes this experience frustrating to the point of impossibility. 

Make sure that your layout design is logical so that it makes sense to the user tabbing-through. Make sure that a ‘skip to content’ link exists at the top of every web page so that users don’t have to tab through all of the links on the navigation bar every time they go to a new page. 

Finally, make sure that any third party content you put in, whether that’s videos, or other embedded formats, or data visualisation software, allows you to continue to tab through using your keyboard.

 

  • Deafness and hard of hearing

Poor user experience and accessibility often makes web and digital content unusable for deaf people, but this can so easily be avoided. When developing non-text non-live media content for your website or app, make sure to provide a text equivalent, such as subtitles or captions. 

 

  • Reading age and language

For product and content designers who pride themselves on being user-centric, it goes without saying that writing and developing with a specific target user in mind is a key part of what they do. 

What this can sometimes fail to take into account is that, there are considerable variations in the ability of individuals to comprehend language and syntax. For some with lower capacity, this can be a significant barrier to understanding information presented to them if that information is presented in an overly complex way, such as by using longer words. 

It may surprise you to learn, according to the Office for National Statistics, that the average reading age in the UK is nine years old7. It’s likely that if you’re a specialist in a given field, or an expert in any given sector, then you will use jargon – complicated terms and phrases that are specific to your sector – at least semi-regularly to describe what you do or your product.

 

To make your website or application as accessible as possible, make sure that you write as simply as possible. Rarely does an alternative, simpler turn of phrase or wording not exist. This is particularly true where you’re developing a service aimed at the public or others who may not be as familiar with your product, service or sector as you are.

A handy checklist for ensuring that you’re meeting the criteria exactly when developing the different stages of your site is available on the W3C’s website.

Digital accessibility is an essential part of digital inclusion, and it’s vital that whether you’re coding an app, designing a product or developing content for use on a website, intranet or app, that you take these principles into account. 

For companies working with the public sector, it can make you stand out from the competition if you already have an understanding of these regulations and how to implement them when speaking to public sector buyers and bidding for contracts. Make sure you read up in advance!

 

References

  1.  “Nearly one in five people had some form of disability in ….” 13 Jul. 2015, https://www.ons.gov.uk/peoplepopulationandcommunity/healthandsocialcare/disability/articles/nearlyoneinfivepeoplehadsomeformofdisabilityinenglandandwales/2015-07-13. Accessed 14 Sep. 2020.
  2.  “Understanding accessibility requirements ….” https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps. Accessed 14 Sep. 2020.
  3.  “Web Content Accessibility Guidelines ….” https://www.w3.org/TR/WCAG21/. Accessed 14 Sep. 2020.
  4.  “Key information and statistics on sight loss in the UK – RNIB.” 1 Sep. 2019, https://www.rnib.org.uk/professionals/knowledge-and-research-hub/key-information-and-statistics. Accessed 14 Sep. 2020.
  5.  “Web Content Accessibility Guidelines ….” https://www.w3.org/TR/WCAG21/. Accessed 14 Sep. 2020.
  6.  “Colour Blind Awareness.” https://www.colourblindawareness.org/. Accessed 14 Sep. 2020.
  7.  “Reading level – Style.ONS.” 1 Jan. 2017, https://style.ons.gov.uk/writing-for-the-web/how-we-read-on-the-web-writing-for-the-web/reading-level/. Accessed 14 Sep. 2020.