5XÉçÇøÊÓƵ

Watch the recording of An Introduction to Digital Accessibility, which covers a broad range of subject areas including; assistive technologies, accessible web pages, page layout, using hyperlinks, colour contrast, video, images, procurement, and working with agencies.

• view our staff guidance on creating accessible web pages and documents
• view a toolkit by Technology Enhanced Learning to support staff in creating digitally accessible content for the online learning environment.

Video transcript

Ben Proctor-Rogers: 

OK, cool. So I'm going to give a brief introduction to digital accessibility today. I'm going to kind of try and cover quite a broad spectrum of things.

So I usually focus on web, but I'm aware that not everybody is a web editor, so I'm going to make it a bit more broad today.

It's quite well timed to have a digital accessibility talk today. It is Global Accessibility Awareness Day tomorrow, so it's very well timed.

The talk is mostly going to be me talking. There will be a few slides where I might ask people to put ideas or things that you might think already about digital accessibility in the chat. Kaye here is going to be monitoring the chat and let me know anything that's put there. Feel free to ask me to slow down as well at any point. I'm aware that I can start talking quite quickly when I get into a subject, so yeah, feel free to ask me to slow down if I'm going too quick.

There will be the possibility for questions as well. I'd ask if you could keep them to the end. Normally I would say interrupt me, but I think because there's quite a lot of people on the call today, if you've got some detailed questions, then try and keep them towards the end.

I will make the slides available and send them out to everybody at the end because there's a lot of useful links and you might find they're good to revisit. And also, it's worth mentioning that the presentation today is going to be recorded.

OK. I am going to start with one of those questions actually, and see if anybody knows already what they think, if they have any ideas what digital accessibility will be.

You don't have to put anything in the chat as an answer, but I want you to just kind of have a think for 30 seconds or so.

If you've come across this before as a concept, any idea of what digital accessibility might mean to you. And yeah, if you want to put anything in the chat, then feel free, but no pressure to.

OK. Cool. I'll continue. Just wanted you to have a few moments to think about it for yourselves.

If you were to Google digital or web accessibility, the definition that you find online is this.

It's the inclusive practice of ensuring there are no barriers that prevent interaction with or access to websites or digital media. And what this means to us is that we need to show empathy and understanding of all needs in the design of our digital content. This is absolutely all of our digital content. What this means, again, is that we need to think about it in the design process, and a lot of people think that maybe designing accessible content means that you have to sacrifice the aesthetics or the messaging in the content, and you don't have to. Inclusive design is always good design. If it's designed to work for everybody, then it will be well-designed. And the same with content. If the content is inclusive, then it's good, the content is well-designed. So these two don't need to be mutually exclusive.

OK. So we've got another one for you to have a little think on before I carry on. How might users be impaired by the design of a website with digital content? Have a little think about how somebody visiting our website or accessing some digital content that you may have on your pages - how might they be impacted by the design of the website or digital content? Again. Feel free to put something in the chat if you want. If not, then don't worry.

OK. We've got some answers in the chat.

Kaye:

Yeah. So we've got sight, colours, etc. If they have dyslexia, they might struggle to read some colours. Videos without subs could be problematic. If they're not accessible by screen reader. Non-accessible documents. Too much text. Language barriers. Using pictures more than pure text.

Ben:

Excellent. Really, really good. Good answers. Some really good ones. Some things we're going to cover in a bit more detail in a bit. Brilliant. Really good. OK.

So looking at it more broadly, the ways that people might be impacted in their access to digital media. Digital content is visual. so people may not be able to see the screen. Hearing. Somebody might not be able to hear the video content that you've got, or a podcast or something. Speech. With this one, people may not be comfortable talking during a video call. People might not be comfortable talking during an audio call. So sometimes it's good to offer the option of maybe a chat in a meeting as well, so people can engage with the meeting and with digital content that way. Motor. So people may have difficulty navigating around the screen, using a mouse, using a trackpad. Something like that might be difficult for them. And then cognitive. People may have difficulty processing complex subject-specific language, specifically for the 5XÉçÇøÊÓƵ, but even in any sort of area online. In trying to think of your audience, try and make the language appropriate for the audience.

[Powerpoint slide: Cartoon depiction of a deaf person, someone with an ear infection and a bartender]

Impairments aren't always fixed, so we might have people who have an impairment in one situation that isn't in another. So I'm looking back to thinking about hearing. A lot of people would think of a hearing impairment as somebody who is permanently deaf. However, there are also other situations where considerations we make for a permanently deaf person would benefit other people. So here we've got somebody who has an ear infection. They may have temporarily lost their hearing due to having an ear infection or something like that, so they can't hear very well due to something that is affecting them for a temporary period of time. Also situational. So the example here is a bartender in a very loud environment. We have students who take part time jobs, go to work in pubs and things, and they might want to sit down on their lunch break and access the lectures or access digital content from the 5XÉçÇøÊÓƵ online. The same sort of accessible things that we put in place for a deaf person is something that would benefit that student in the noisy environments when they're accessing their lectures and things.

[Powerpoint slide: Image of a cycle showing how content needs to be perceivable, understandable, operable, and robust]

So what needs to happen?

So this is kind of what we're trying to do as a whole, what we're trying to do in the Digital Development and the Digital Content teams. What we're trying to make everybody realise and understand and build into their processes is that the content online needs to be perceivable. People need to be able to see the screen, read it, hear it, access it in some way. They then need to be able to understand the information that they see on the screen. It's great having all the information there,
but if it's displayed in such a way that makes it really difficult to understand, then it's still not going to be that great. It needs to be operable. So if you have a form, if you have a video, the controls for playing that video, the controls for filling out and submitting that form all need to be operable by every user. We need to make sure that everybody can operate our websites, can operate the digital content that we have. And then it needs to be robust. We need to make sure that it doesn't break easily. We need to make sure that it works now and that it's going to work in five years time. So we need to be working to set standards that are future-proofed. So some things that we ask people to do may seem a bit finicky at times. And sort of, why you ask asking for it to be done specifically in this way? And it's because we know that this is the way that web technology and digital technology is being developed. So we need to make sure that we're developing along those paths as well.

So I do have to put in the legal bit here. So access to information and communication technologies is a basic human right. It's covered in the United Nations and it's also now covered under UK law. So making sure that our content and our websites and everything digital that we have is accessible is something that we should be doing anyway. It's just something that we should be doing because it's the right thing to do. We need to make sure that everybody can access this information. However, since 2018 it has become a legal requirement as well. So there are a set of guidelines called the WCAG 2.1 guidelines. I've linked to those at the end of the presentation, so when those get shared round, you'll be able to have the links to those. And we have to meet them. Failing to meet them means that we're in breach of the Equality Act of 2010 and the Disability Discrimination Act of 1995.
The actual law that covers it is this wonderfully-titled Public Sector Bodies (Websites and Mobile Applications) (No.2) Accessibility Regulations 2018. So that's the actual law and we do have to meet it.

So at the moment or you know,in general, does anybody on the call use any assistive technology to browse the Internet? I'm not going to ask anybody to put this in the chat. I just want you to have a little think for yourselves for a minute. If there's anything that you do use that might be might be assistive technology without you really considering it.

OK. Cool. Next question. Does anybody wear glasses or contact lenses when looking at a screen?

[Powerpoint slide: Image of a Border Collie dog wearing glasses]

So if you do, you are wearing or you are using assistive technology at that time to help you read the screen, as the puppy here is very kindly demonstrating. You definitely need to make sure that you're looking after your eyes when using a screen. So in using assistive technology at that point, glasses obviously aren't the only assistive technology that you might be using.

There is a huge amount of technology that people use to access the Internet and any digital content out there. These include and are not limited to - so this is just a selection of the list - but screen readers, Braille keyboards, which are great little strips on the side of your computer that you just put your finger on and it reads the screen as Braille across the strip. So using your browser to zoom in to the web page. Head pointers to show where you're kind of looking on the screen.
Similarly, eye motion trackers to kind of follow your eye movement around the screen to access content. There are things called single switch entry devices, where one button and combinations pressed on that one button allow you to access different parts of the Internet and to access different parts of the website. Mouthsticks, again, where you can kind of point at bits of the screen and tied to those, sip and puff switches. Oversized trackball mice. Adaptive keyboards. Voice recognition software as well. And then also hearing aids and headphones are also used by people to access digital content.

We focus mainly, somebody mentioned it earlier on, on screen readers and the reason for this is screen readers are ones that we can test easily in-house. We don't have access to all of the other technologies. We have access to some obviously, but screen readers are the main ones that use all of the embedded web technology and digital technology to read digital content, and the technology that works for screen readers works for all of the others. So if a screen reader can read the screen and access the content and work with everything that operates, everything on the screen, then it should work for all of the others. So the Braille keyboard will read the screen in the same way as a screen reader. To clarify in case anybody is unsure, a screen reader is something that will go through the website or the web page and it will read out the content on the screen. So at the moment, if I was reading through this PowerPoint, it would read out heading assistive technology. Then it would read list, however many items there are, item one screen readers, item two Braille keyboard. It will just read sequentially through the content on the screen. And like I said, if it works for that, then it should work for everything else. We in the Digital Development team and the Digital Content team are quite well-versed now in using screen readers to read digital content so we can check things pretty quickly as well.

So what do you think, before we move on to kind of specifics, the biggest challenge towards creating 100% accessible content is?

So again, you can write it in the chat if you want, but don't worry too much if you just want to have a short think about what you think might be the biggest challenge towards getting all of our content on the entire 5XÉçÇøÊÓƵ website - or any institution - what the biggest challenge towards making all of the content accessible would be.

I see some suggestions coming up in the chat. Is that right?

Kaye:

Yeah. So we've got: updating old content, awareness, changing habits, volume of content, a number of editors, and the time involved.

Ben:

Very good. Those are all really, really good suggestions, though I think one of them is kind of pretty close, which is sort of the biggest challenge that I've seen. Not to single out Sussex. I'm in quite a lot of online accessibility discussion groups and generally across the board, the biggest challenge that people seem to face is changing workplace culture. So people are very enthusiastic about it, but it can sometimes be forgotten during key development phases of project planning, brief writing, commissioning of work. It can drop off, not intentionally, but it can be left out and that can become a problem. So it's changing that culture around including it and considering it early on in the process of creating digital content, creating websites, creating video, anything like that. So considering it early on, as it's something that is more difficult to fix retrospectively. A really good example of this is PDFs. So it's much harder to go back and turn a non accessible PDF into an accessible PDF, rather than starting out with an accessible template at the beginning. So you start out with the template, build it in through the process of making the PDF, and you end up with a wonderful accessible PDF at the end. If you were to create the PDF and then try to remediate that, which is the process of changing it into an accessible PDF afterwards, that takes a lot more time and resource to go backwards, as it were.

So I'll come back to those in a little bit, but I'm gonna go on to the web pages and I'm not going to spend too long on this. As I said before, I'm aware that not everybody is a Web editor, so I just want to kind of go through this briefly and then I'll say how it applies to two different things as well, as these concepts and these ideas do apply to any digital content. So it's not just web pages.

So in brief, we need to make sure that the content is readable. You need to avoid large chunks of text, avoid using very, very specific language unless you're describing it. If you're giving definitions of very specific terms, that's great. It's good to define them, maybe in sort of a separate section with definitions or something like that. Being aware of who the audience is. So a lot of the time, students are our audience, a lot of the time. So it can be difficult to balance academic language between the language that a prospective student might understand. It's finding that appropriate balance. That's the readability of content. Also across structure of content, using things like appropriate heading levels. We can come back to that shortly. Your link text. When you have a hyperlink, the website is just built up with hyperlinks. That's how it's all held together.
We need to make sure that the link text is descriptive. A page layout must follow a logical order.
Colour contrast. We have a set value of colour contrast. The colour contrast is the difference between - so the background here is this cobalt blue and the foreground, the text is white. So we need to make sure that there's an appropriate colour contrast and at the end, in the links I'll share some tools that will enable you to find out the colour contrast of colours on your web page or in your PDF or your PowerPoints. But if you're making, so you can make sure that you're meeting that particular kind of standard. Images, briefly, must have context and they need to be relevant. I've got a few slides on those in a minute and videos. Again, the key take home message is they must have captions and a transcript of the audio description. So I'll kind of go through what that means in a bit more detail shortly.

So for the Web pages, we've got a lot of it covered for you. We have something called the Components Library. And if you're a Web editor and you're using the WCM, hopefully you know where these are. If not, the link is at the end. These components have all been designed to be accessible. They should meet all of those, all of the standards of WCAG and pass, providing the content that's put in is readable. The images that are put in must have alt-text, for example. It's a finite list. Access to these is through the WCM. We have some pre-defined templates where you can access them really quickly and it just puts them into the page for you. We're updating this list at the moment. We're going to be coming up with some more components. They are limited at the moment, but we need to make sure that everything meets the standards. So we need to make sure that they definitely are right before we put them out for everybody to use. Yes, that's kind of all I'll say on that subject. I'll come back to the things related to that at the end.

So I mentioned page layout earlier on. You need to make sure that your page follows a logical reading order. And that the headings are headings. They're not just a text that is styled to look like headings. So both in Word and PowerPoint, and on the internet if you're writing code for your web page, there is a way to style things as headings. So just taking your heading on your Word document and bolding it and underlining it does not necessarily make it a heading for a screen reader. You'll have separate ability to style sheets to turn things into headings if you're unsure of this. Again, we've got guidance on the Brand part of the website, which is linked to at the end. So for any of these things that I mentioned, there is guidance and instructions at the end if you follow the links.
So following on then from that. You need to make sure that you have headings that are actually headings. Your text is a paragraph and marked up. So similarly to I mentioned before, images have to have things like alt-text, so I'll come to that in a second, particularly for web. Using accordions.
So in this context, it's one that happens quite a lot, is using them just for small sections of non-essential text. If something's essential, don't hide it in accordion. So I just put that one in as that's one that comes up quite a lot, people hiding quite essential text inside an accordion. Then somebody looking at the page might miss it. It's also worth mentioning as well that getting this page, layout and structure is good for a search engine optimisation, commonly referred to as SEO. So this is how Google makes a map of your website. And if you want your website or your page to perform well in Google Search, you need to make sure that you have these hierarchies laid out properly for the Web. It's how Google builds a map of the websites. Also, how a screen reader builds a map of the website as well. So if it's set up properly, a screen reader will be able to read it correctly and navigate it properly. Google will as well. So this is, you know, two bonuses. We want screen reader users to be able to navigate our page well. We also want Google to be able to read it well as well, so it can rank it appropriately when people search.

OK. So readability I mentioned earlier on. Avoid ambiguous language, avoid technical language, unless you've explained it clearly. And again, for Web editors, we have an in-built readability checker in the WCM. So at the bottom of the screen, it's nicely colour-coded and gives you a score. You want a high score that'll turn the box green and it'll let you know kind of the level that you've written your text. You don't want it to be too difficult to read. And again, breaking down your text into smaller paragraphs, so you don't have really, really big chunks of text on the screen.

Link text I mentioned earlier on. This is for links anywhere that they appear. So if you've got links in an email, you've got links on a website, links on a PDF, links to PowerPoint, wherever they are. You want to have descriptive link text to let the user know where the link will take them and what to expect. Do not use the link URL if possible because this doesn't describe to the user where they're going. And also don't use things like click here, here and this. The reason for this is, if a screen reader user is navigating the page, or somebody using any other assistive technologythere is a method of navigating just by links on the page. So if somebody is looking for a link on the page, it will just read out that link text. So if you imagine you're going down a page and somebody has just used click here, click here repeatedly throughout, all that screen reader user will hear when they're navigating the page is just click here, click here and click here. It won't let them know the destination of the link so they won't know any context of where that link is going to take them. You want to put as much information and it is absolutely fine to hyperlink a whole sentence. I know some people are a bit unsure about this. A whole sentence is fine. I wouldn't hyperlink a paragraph or more than a sentence, but if it takes the sentence to let somebody know where they're going, then yeah, please, please do.

So colour contrast is our next thing. So this is a great one and luckily I think a lot of people are kind of on this these days, just because poor colour contrast just really stands out as not very good on the Web these days, but it doesn't just apply to the Web. It'll apply to your Word documents or PDFs, your PowerPoints, whatever you're using. So all the text elements must have a colour contrast ratio of at least 4.5:1 with the background.

[Powerpoint slide: White background. Box with yellow text saying poor colour contrast and a black background box with white text saying good colour contrast]

And I've got some examples over here. So this yellow text on the white background is really poor colour contrast. You wouldn't ever use this. It's a really extreme example, I know, but I just wanted to highlight how it makes it a lot more difficult to read. A good colour contrast is where you can very, very clearly read the text and as I said, there will be some tools in the links at the end that will allow you to compare the two.

Similarly, if you have text on an image, the same rules apply. So if you've got an image and you've got some text over it, you need a coloured background for the text, or for it to be in negative space. And I've got some examples of that coming up. I'm aware that I'm going quite fast. Hope I'm not talking too fast for anyone.

OK. So when it comes to images, the thing that I will ask is that you ensure that the image is relevant, ensure that the image is good quality and is high resolution. So you need to check how it looks on both mobile and on large screen. Also, the flipside of that is, you also need to try and make sure that the image is not, the image file size is not too large. If you have really, really large, high resolution, high file size images on your page, then it's going to cause the page to take a very long time to load, which may not seem like too big a problem, but if you've got limited Internet, if you're using a limited bandwidth Internet connection, you might not be able to load the whole image. It might use a lot of your data to load the image and may load very, very slowly. So we need to make sure that it's good quality, that it looks good on a big screen and also on mobile.
We also need to try and make sure that it isn't super, super enormous, super high resolution images, as they will cause the screens to load, the page to load very, very slowly. If this was a Word file or PDF or PowerPoint, then that's not so much of a consideration. You can use really nice high resolution images for those.

So all images must have alt-text. So alt-text is a descriptive text that's read out by a screen reader for visually impaired users. It is used to describe what's in the background or what the context is of the image. If the image is non-essential and it was just kind of there as a decorative image, you can leave the alt-text blank, that's fine. And it will just be ignored by a screen reader. You don't need to put anything there then, but if it is referred to in the text or something like that, then you will need a descriptive alt-text to say what the image is. Similarly, if you've created an infographic. So these can be fairly tricky for alt-text and descriptions. You need to ensure that either the details and all the information covered in the infographic are also somewhere on the page. Then you can use the alt-text to say something like infographic showing and then whatever it is and say 'all information covered in the infographic is available in the text on the page', so that anybody who is using a screen reader to access that will know that it's somewhere on the page. If it isn't, then we ideally would like that to happen. A solution that we do have at the moment is to create an accordion, which kind of works a little bit like a video transcript, and has a dropdown and a description of all the information that's in the graphic. It's not the best route to go for, but if you absolutely do need to have an infographic and the information isn't on the rest of the page, then that is a solution that we can work with. If anybody has one of these and would like some help working with that, then they can let us know DCM. We're happy to help out with that. OK.

So I mentioned that they need to meet contrast standards already. I've got some examples of this on the next slide. So here's the examples. And these are screenshots from a tool that I've linked to at the end of this PowerPoint, where you can write some text over an image. So you can upload an image to this website. You can write some text over it and it'll tell you whether it passes or not.

[Powerpoint slide: Three images of flowers with text written over them. The first has text over the flower and reads this fails. The second image has text in clear blue space and says this passes. The final image has text with a black background over the flower and says this passes]

So in this first example, I've written the text over the top of the image, and this doesn't give you sufficient colour contrast. So you can't have just text over a background image here. And the first image fails. So the two solutions to this are, one, to put the text in what's called negative space. So if you look at the bottom left image, I've put the text up in the top right corner of the image, but there's a dark blue background and white text on top of it. This will pass the colour contrast standards, so the colour contrast checker will allow this. This is fine. It's very easy to read. The other possibility that we can have is to put a coloured background behind the text over the image. So we see this quite a lot, particularly with subtitles and captions. So put a black background box behind the text and this then makes the image text accessible. Also, if you're doing a Web image, you need to then write this in the alt-text, so these would have the alt-text of this fails, this passes, this passes.

So video. I'm only going to go into this a little bit because there's some really, really good guidance on our video accessibility page. And I put the link to contact our Video Manager there as well, because any video that's being commissioned for the website, you really need to run it by him first because he's really, really well-versed in the accessibility requirements for video and will really help you make sure that you're producing the best quality video. So videos must have captions and they also must have a transcript. And the reason for this is, captions aren't read out by a screen reader. So you could have captions, which are accessible for people who can't hear, which is great, but the transcript is required for somebody using a screen reader. This also needs to include things like audio descriptions. So what these are is any unsaid text or descriptions of items like graphs and tables that the presenter would refer to. So if I'd had at any point during this presentation a graph and I referred to it saying, if you can see from column two for whatever reason, the transcript would then need to have a description of that graph so that anybody reading the transcript would know what the speaker was referring to. So I think an example from this presentation, if you think back to the slide where I was asking about does anybody use any sort of accessibility, aids, anything like that, and I had the picture of the dog with the glasses. I would include the dog with the glasses in the audio description in the transcript, because I referred to it, and say that it's a picture of a dog with glasses. So you would include that. However, if you think about the slide where I was talking about the legal bit, and there was a keyboard with a gavel resting next to it, you wouldn't include that in the audio description because I didn't refer to it at the time, so it's not required to be in the audio description. So you need to make sure that anything that is referred to by the speaker or any key information or any text that wouldn't be read out by a screen reader, you need to then make sure that that is going into the audio descriptions. I also would add things like links as well so that they're easy to access. So at the moment, I would put the link to the video accessibility page or contact our video team, the email address for our video manager. I would add both of those into the transcript and into the audio descriptions. There's some really good guidance with an example video for you to look at on the video accessibility page.

[Powerpoint slide links: /brand/staff/web/accessibility/accessible-video for video guidance and email dcm@sussex.ac.uk to contact the video manager]

OK. So audio, exactly like a video, has to have transcripts as well. So if you're creating podcasts and you want to upload them onto the website, you need to have a transcript for these. And they follow exactly the same guidance as video transcripts. So in-house, we don't recommend specifically a service, but there are a lot of people online offering services to transcribe podcasts and videos for you. Some people do it by uploading the audio in this case into something like Vimeo or YouTube, and then that will auto generate a rough transcript for you. It may not be completely correct, but you can then download this and edit it to to make it correct. And that's a quick and cheap way if you want to do it in-house. But if you've got a very long, several hour long podcast and it's going to take a while for someone to do and you have budget, it might be worth looking into using a third party service for doing that.

OK. So files. Everything that I've mentioned, as I've been saying as I've been going through, applies to all files posted on our website. Absolutely anything from PDF to Word to PowerPoint to Excel. They all need to have the same things. Logical reading order. Making sure that you can read the information or text on images or figures, things like that. Everything that I've covered so far. Colour contrast. It all applies to PDFs, word, PowerPoint and Excel. For Word and PowerPoint, we have templates on the brand part of the website.

So this PowerPoint I'm presenting from was made using the 5XÉçÇøÊÓƵ PowerPoint template that has been set up. There's a whole load of template slides on there that have all been set up to meet accessibility standards. So if you're using that PowerPoint template, you should be fine. There should be no problems. All of the colours in it meet colour contrast. The only thing you need to do is add alt-text to your images that you add in.

So similarly, we have a template Word file as well, which you can download and it has a style sheet set up for you to use, to just put in things like, mark things up, headings, paragraphs and things like that as you go through. So it's really, really quick and easy to use and there's some guidance on there.

Also, Microsoft recently released some videos on how to do this. However, I think ours is a pretty good because if you Google how to make an accessible Word form, the Sussex web pages come up as a number one Google hit. So a lot of people seem to think our guidance is pretty good. OK. So yeah, the links at the end as well.

So when creating a file for publication online, this is kind of before you create the file, we're asking people now at the moment to kind of think about whether the file would work better as a web page first. So web pages are much easier to make accessible. If your file is a Word file with maybe some terms and conditions or just some general information on it, it might be easier for everyone involved to just make an extra web page and put all of that information on there. If you think about how most people access files, they look on mobile anyway. Things like PDFs, when they open, they open in the browser. So they're going to be read using that same browser technology.And it's easier, the sort of screen reader technology, any of the accessibility aids will find it easier to read that from a web page than from a PDF opened in the browser. So if possible, make it as a web page rather than a file. If it does have to be a file, then that's fine. Just make sure that you're sticking to the kind of guidelines that we've set out on our brand pages.

OK. So procurement. This is one that kind of needs to be raised generally more 5XÉçÇøÊÓƵ-wide at the moment, as I think a lot of people are unaware that if you're procuring something third party, any digital content, software, anything like that, that will be accessed online by students or staff, they also fall under this remit. So you need to make sure that absolutely everything that is linked to our site in any way - it might be on a micro site, something like that - it's still linked to Sussex 5XÉçÇøÊÓƵ, so it still comes under the same kind of guidelines that we need to meet. So when you're procuring something along those lines, any form of digital asset, you need to let the provider know in advance that compliance with these WCAG guidelines standards is a legal requirement for UK universities. If you're unsure of what to say or if you want to include us, it's usually best to include us if you can in the procurement process, then please feel free to email us. I put our email address at the end of this presentation, so it's DCM@sussex.ac.uk. If possible, ask for a test sample, example, something like that. So somewhere where this software, app, web microsite or something, has been used previously by another university, by a company, so that we can have a look at it and we can test it there first to make sure that it does meet the standards. So any non-compliant services that we have must legally be listed in our accessibility statement. So this is kind of a key focus of ours at the moment.

We've been audited twice in the last year, once by the government, by the Cabinet Office. And then we also had a private company audit our website for accessibility as well. And both times not a huge amount was flagged, which is great, shows that we are doing the right thing. Some third party providers were flagged during both of those audits. We're currently working with a couple of departments to help them navigate conversations with the suppliers of those digital services. So if you are procuring something and you're unsure whether it's going to meet the standards that we need to meet, please email us to get in touch.

If you work in a department where you have a web service or something, or digital content, whatever, and you're not sure whether it does meet these accessibility standards, please get in touch with us. Happy to receive emails at any time about it so we can check because we do legally have to list anything that doesn't meet the standards in our accessibility statement and give a kind of timeline for when they'll be fixed, when they will meet these standards. So yeah, it's great for us to know so we can update that so we don't have any surprises in any future audits.

Similarly, working with agencies. So this is a fairly similar set of guidelines. Make sure that you include digital accessibility in the brief from the offset. If you are asking an agency to make a PDF for you, a report of some kind, or if you're commissioning video of any kind, podcasts, anything like that, even just images or photography, could you ask them whether they can meet the standards outlined in the WCAG standards first? And if they say no, then maybe have a discussion with them about how they could. Have a discussion with us about how we can assist them in doing this. Again, it is worthwhile to let them know that it's a legal requirement for UK universities now. And yeah, if you're unsure what to say, if you're writing the brief, do contact us and we will help out.

So I'm quite close to the end of what I have to say.

So contact, there's two teams. The Digital Content team and Digital Development team are both happy to help with any accessibility questions. As I mentioned already, we prefer to be contacted before rather than after a project and there's our email address. DCM@sussex.ac.uk. If you email that, the email will get a response pretty quickly. We check that sort of twice a day. So pretty, pretty quick to kind of go through it. And then also I know this has been a very generalised session. I want to say that we are willing to offer specific training sessions for teams and departments. If your team, your department, want some sort of training in something like creating accessible PDFs, creating accessible Word documents, even some WCM training specifically in accessibility, then we're happy to do that. We thought it was too broad a topic to try and cover in one training session today, but to offer it out to other teams and departments to say that we can come in, maybe book a computer room somewhere on campus and do a small training session tailored specifically to what people might need. So again, if you feel that's something that you might need or someone in your team might be interested in, then contact us at our email address.

And finally, we've got those links, however you will notice that some of them are not, I have not followed my own guidance, quite smart here, so some of the link text is good and lets you know where you're going. Some of them, WCAG 2.1, sorry, is not great so I apologise, but when I circulate this around at the end, you'll have access to these links.
So it's got the brand home page stuff, guides to the websites, some how-to guide starts for you. Find out how to make accessible PDFs, accessible word forms, things like that. Accessibility statement, which is where you find out what we have made accessible, what we haven't, and what we're working on.
There's that text-over-image checker, which allows you to check images. There's a Webaim contrast checker which will check on a contrast for you. The Microsoft how-to videos, which are fairly recent from them, and then also the government pages on web accessibility as well.