Speaker 1: Yeah, so just to give you a little insight into who I am, I'm a white middle-aged male wearing black glasses, black ring glasses, short hair, wearing a blue jumper and I'm in an orange room, the background is quite orange. So yeah, I'm going to talk about the online public accessibility services regulations and in particular about making public services online accessible to as many people as possible. So yeah, I'm Richard Morton, I'm Head of Accessibility at the Government Digital Service or GDS. GDS is actually part of Cabinet Office and we lead the digital transformation of government, which means that we run government's websites, GovUK amongst many other things. My role is to raise awareness of accessibility needs across government and the wider public sector as well as building capability in central government and also I have to ensure that we at GDS make our services as accessible as we can. So first a bit of background about digital accessibility, sorry, jumping ahead. It means ensuring your services and content can be used and understood by the widest possible audience. In the UK, at least one in five people have a long-term illness, impairment or disability and many more have a temporary or situational disability. The UK public has to use government services, they don't have a choice about different providers for passports or for passport-based collections from councils, for example. This means it's everyone's responsibility to make sure we remove as many barriers or obstacles to accessing information and services as possible. It's the ambition of the Government Digital Service to make services as accessible and inclusive as possible, to ensure there are no barriers that might prevent people from interacting with government. Everything we create must be accessible to as many people as possible, regardless of whether or not they have impairments in any of the areas shown on the screen, which are vision, hearing, speech, motor or cognitive, or a combination of those. And for example, this means we must make sure that you don't need to rely on sight alone to understand information. The information conveyed needs to be accessible to a screen reader, which is a piece of software that's used to read out the text on a website for someone who's visually impaired or blind. Similarly, we shouldn't rely on people being able to hear the audio of a film or animation and should provide captioned text for those. It's important also to remember that impairments aren't always permanent. People sometimes don't have use of one or more of their senses due to illness or injury, which is temporary, such as having an ear infection or a burst eardrum or a cold. We must also consider people don't have full access to things because of the situation they're in, such as being in a noisy environment that prevents you from being able to hear as clearly. User needs must be considered and met, whether an impairment or disability is permanent, temporary, or situational. It doesn't make any difference in terms of how we design and build services and information. Accessibility isn't something new for GDS. It's built into our design standards and ways of working. But making online services accessible to all isn't just something we're passionate about. It's also the law. So I want to talk a bit about the law. Firstly, the Equality Act 2010, as it says on the slide, reads, we have a legal obligation to provide equal access to people with disabilities. And for Northern Ireland, this is covered by the Disability Discrimination Act 1995. In the Equality Act 2010, it says that public authorities must comply with the public sector equality duty. This means that public organisations like central, local government, health care and education must think about the needs of people who are disadvantaged or suffer inequality when they make decisions about how they provide their services and implement policies. So while the 2010 and 1995 laws have been in place for quite some time, there are some newer online accessibility regulations that public organisations need to follow. These don't replace or supersede the Equality Act or the public sector equality duty, but they're in addition to it. In fact, they're underpinned by it. These are the public sector bodies' website and mobile applications accessibility regulations 2018. And they mean that public organisations have a legal obligation to make their websites and mobile apps accessible to people with disabilities. This means meeting the requirements of the Web Content Accessibility Guidelines, otherwise known as WCAG 2.1 to Level AA. And I'll explain a little more on that in a moment. Web Content Accessibility Guidelines or WCAG are a standard that can be followed to make web pages, services and documents more accessible. The guidelines break down into three levels. Level A covers the most basic web accessibility features. Level AA, which includes Level A, is for websites that tackle the most common barriers for disabled users. And Level AAA is for sites with the highest and most complex level of web accessibility. There's some important dates for these regulations. The timeline for the regulations are shown on the slide. Websites and documents published on or after 23rd of September 2018 had to be compliant by September 2019. Existing websites and documents published before September 23rd 2018 had to be compliant by September 2020. And mobile apps have to be compliant by 23rd of June 2021. So in other words, all existing and new websites need to be compliant from now. There are four actions as a public sector body you need to take to make sure you're compliant. Firstly, you need to understand how the regulations will impact you. You're likely to be impacted if you manage your website or mobile app or publish content to go.uk, for example. Secondly, you need to check the accessibility of your website or app and publish documents by carrying out an accessibility audit. It's important to engage with your digital team or accessibility champions if you have them for conducting an audit or support on conducting an accessibility audit. You can find professional advice and audits through things like the digital marketplace as well. Thirdly, you need to make a plan to fix any problems that come out of the accessibility audit. And fourthly, you need to publish an accessibility statement. Accessibility statements are one of the key requirements of the new regulations and the statement needs to include a few things. Firstly, how accessibility was evaluated, the level of compliance, known issues, how users can get accessible alternatives, a feedback mechanism and how to contact the enforcement bodies. And importantly, it needs to be regularly updated as and when you make changes to your website. We would advise you revisit the statement at least once a year, but more often, obviously, if you make substantial changes. There's a sample statement on gov.uk that can be used as a template to help website owners write their own. In fact, there are lots of resources available to help you be compliant that GDS have provided. There's guidance and other resources available through a link and a link to the regulations and you can get to all of those through this link, which is accessibility.campaign.gov.uk. GDS also has a role in making sure compliance with the regulations happens. So we are monitoring public sector websites and documents and we will in future be monitoring mobile apps as well for accessibility when that deadline comes through and GDS has been chosen to do this because we're a leader in online accessibility. We're also responsible for enforcing the requirement to publish accessibility statements. What does this mean? Well, it's a big job to undertake. We've identified tens of thousands of public sector websites. Sorry, wrong slide. Can you go back a slide, please? We're testing a sample of websites based on the population size and we're enforced the requirement to publish accessibility statements and our findings are reported to the Minister for the Cabinet Office. They'll be shared with enforcement bodies and they will be published online. So while GDS is the reporting and monitoring body, enforcement of the law is carried out by separate bodies, which are the Equality and Human Rights Commission in Great Britain and the Equality Commission for Northern Ireland or ECNI in Northern Ireland. This means they can use their existing legal powers under the Equality Act 2010 and the Disability Discrimination Act 1995 to launch investigations, issue unlawful notices and take court action against offending organisations. So that's if organisations don't comply and if they don't cooperate with reports and things like that to actually improve. As well as talking about the regulations, I wanted to give a few hints and tips about accessibility and in particular things around accessible content in this talk. So it isn't just about the technical architecture of a website, which is very important of course. It's important to make sure the content you're creating and publishing is accessible too. So here are some simple techniques and tips that you can use. Some of this goes beyond the regulations to include best practice, but I do encourage people to go beyond the regulations. Regulations are there as a framework, as a guideline, but they don't guarantee full accessibility. So firstly, let's talk about language and how the structure of content can be made accessible. When writing content, it's important to consider the different reading levels of the public. The average reading age in the UK is nine years old and for many people, English is the second language, including many deaf people for whom sign language may be their first language. Long sentences can be complicated and confusing. Try to stick to 25 words per sentence or fewer, as someone could say this in one breath. Walls of text are also tricky to read, especially on mobile devices and can be off-putting. So try and use no more than five lines per paragraph. So here's an example. It's a simple fact that constantly observing cold water rising in temperature until it arrives at the boiling point of 100 degrees will not in fact make it come to that temperature any faster than say, staring at the nearest wallpaper. That's the non-plain English version, if you like. People with a low reading age can understand the sentence, but it is long and complicated and makes people do more work to understand what it means. But it can be simplified. So here's a simplified version of it. Water does not boil faster if you watch it heat up, or to use the inaccurate old expression A washed pot never boils, and I bet you believed that when you were told. It's not true. So now onto headings and subheadings. Next slide, please. Or previous slide, I think. Sorry, it's jumped a bit. The one after that. Sorry, I'm having trouble getting the slides correct. There. So it's headings and subheadings. When structuring a document on a website or within a document, many of us are guilty of using font size or making things bold to create things that look like headers. And that's fine visually, but these things aren't understood by screen readers, for example. So using the correct page structures to format your content helps those using screen readers to understand the layout of the document and the hierarchy of the content. Each document or page should have one main heading and subheadings can then be used to provide more detailed structure. And you can find and edit the preformatted headings and subheadings within the format tab of most content management systems or programs. It's also important that you use a sensible font size and, of course, a sensible font. Preferably something that's reasonably simple, you know, fancy heading type fonts. They might look good on invitation cards and things like that, but they don't really work very well for many people on digital systems. So use simple fonts. You need to use your judgment, of course, when deciding which font size to use, taking into account the style of the font and the type of content you're producing. Many people don't know even about things like browser zoom, for example. And think about link text. There are some simple things you can do to make link text more accessible. It should be meaningful and it should make sense without the context of surrounding content. This is to make sure it's accessible to users navigating the content with a keyboard instead of a mouse or those using screen readers. And that's because screen reader users often get a list of links on the page or they jump through links on the page. So they need to have this meaningful content in the link text. To meet the Web Content Accessibility Guidelines, you need to make sure links stand out from other text, ideally by underlining them or making the colour significantly different or other means, but make it different from the surrounding text. If you distinguish them by colour, you need to make sure there's at least a 3 to 1 colour contrast ratio between the link text and the rest of the content. And I'll talk a bit about colour contrast ratios a little more later. As a general rule, start with a verb if you're asking people to do something and you're linking to information. And if you're linking to information, link directly over the text that describes the information. So the example here says, if you're telling people to do something, start with a verb and then apply for a password is link text. And it says, if you're linking to information, link directly over the text. Find out about types of election, where types of election is the link text. So here's some examples of good, bad and ugly link text that I'm sure you've all come across. Read more is bad because screen reader users may tab through a page and not read the surrounding content. Or even access a list of links on the page and potentially get multiple links that just say the same thing that might say read more, but going to different pages. Click is ugly because it's non-specific, like read more. But it also doesn't really make much sense for anyone not using a mouse, for example, a keyboard or a touch screen or voice recognition. And of course, many people are using mobile devices. So the good example is link text is read guidance on applying for a driving licence. This isn't just about websites, though. The regulations and accessibility generally isn't just about websites. It also includes documents, and that isn't just PDFs. It's also things like Word documents or spreadsheets or other forms of document. Any content being published to websites should ideally be published in HTML by default. When sharing an attachment document, open document formats are the best option, as this format is compatible with most applications. Not everyone has Microsoft Word or Google Docs, for example. PDFs should ideally only be used for printed documents. However, if there are situations when you need to upload a PDF, you should publish them as additional documents. You should still publish HTML as the default. So we get asked a lot of questions about how to publish a PDF document. And the answer is pretty straightforward. You can publish a PDF document as a PDF document. You can publish a PDF document as a PDF document. So we get asked a lot of questions about what is wrong with PDFs or the accessibility of PDFs. PDF documents are created really to be printed. So they're not built to be read on screens. And this means they aren't responsive, which can make them more challenging to open and read on mobile. It also means they aren't often compatible with screen magnification. And they're often not structured correctly. So it can be difficult for screen reader users to navigate. There are ways of making PDFs more accessible, but they're never perfect. They're never going to be fully accessible to everyone. Let's talk a bit about colour now. First of all, don't use colour to convey meaning. What do I mean by that? Well, colour can be used to add emphasis and to engage on websites and in documents. But it shouldn't be used to convey key information by itself. This can be particularly challenging when you're publishing things like graphs, where you might use a colour key. You need to think about how that would work without the colours. And you can test that by printing things in monochrome or using a black browser plugin, for example, to test things in monochrome. So here's a quick question for you. Are these buttons accessible? Have a think for a moment about that. There's a red button on the screen with the word stop on it. And there's a green button on the screen with the word start on it. The idea here is they are accessible visually, in terms of colour and in terms of text, because they're not relying on colour to convey a key message. The colour here is used for emphasis. So the red button says stop, the green button says start. So even if someone has a red-green colour vision deficiency, they'd still be able to distinguish these. And in fact, if you take away the colour, the message can still be understood. So here's a plain white background button with the word stop on it, and a plain white background button with the word start on it. However, the next slide shows with colour but without the text. So there's just a plain red button and a plain green button. They're not accessible because it's not clear if you couldn't distinguish between those two. So if a couple of you said press the red button to cancel and the green button to continue, that wouldn't be accessible to many people. We also need to think about colour contrast. It's one of the Web Content Accessibility Guidelines requirements. You need to make sure there's sufficient contrast between the colour of your text and the background it's on. It's also around the colour of interface components as well. And the Web Content Guidelines state that you should use a minimum ratio of 4.5 to 1. Working out the ratio is tricky, so you probably need to use a piece of software to check that ratio. There's some free online tools that can be used to check the contrast, and we use a thing called Contrast Checker, which is now on the screen. It's a really valuable tool that can be used to check what colours are in use on the page and the contrast between them. And here's an example of colour contrast that fails the Web Content Accessibility Guidelines standards. So this is white text on an orange background and some reverse as well with orange text on a white background. And these have a low colour contrast, making it difficult to read the content. They're quite bad to read in even good light, but with good vision. But with low vision, or if you were trying to read this on a mobile device in bright daylight, things like that would be pretty difficult. In general terms, pale colours like orange, pale greens, pale yellows, don't work well and they're not contrasting enough against pale backgrounds like white. So they might work well against a darker background. So here's a better example, an example of good colour contrast. And this is one where there's some white text on a green or blue-green background. And it has a contrast ratio slightly above the recommended minimum of 4.5 to 1. These figures are kind of recommendations. Again, they don't guarantee accessibility, but they do help many people if you stick to these minimums. I'm going to talk about making images, videos and podcasts more accessible. First of all, let's talk a bit about alternative text. You're probably familiar with this, but alt text is used to describe an image. It's read by software for visually impaired users and displays when an image doesn't load. So this is an image, I won't describe it here, but the question is, what would be a good alternative text description for this image? And I'll tell you in the next slide. So actually in this case, it's probably just pancakes. It's a pile of pancakes on a sauce or a plate with some blueberries. But it depends on the context. So there might be a need to provide a more detailed description of the image, but it does very much depend on context. ... ...