Hi everyone, welcome to this introduction to accessibility statements including how to write an accessibility statement.
What I've got in front of me is the accessibility statement template that we're putting up on makethingsaccessible.com and this is the template that you can download from the how to write an accessibility statement guide.

It's based off the GDS sample template.

It conforms to the UK required standards and has all the required information and what we'd be doing today is we'll be going through and showing you how to fill this out, showing you some of the complexities with some of these sections, and a few things to watch out for.

Hopefully this will be a useful guide to you filling out your own accessibility statements.
So, let's dive into it.

This is the accessibility statement template.

As I've mentioned, we'll start from the top and do a little quick run through of the various sections explaining what they're for, and then I will go through again and show you how to fill out each section.

We start off with a little introduction.

This just gives a flavour of what the statement applies to and who owns the website.

Then we come to a how accessible this website is section.

This is just a not required section, it's optional.

But it's part of the standard template, so we can keep it in and point below.

You can also provide additional extra information here if you've got further things that you want to say about the state of the website.

Then we've got the feedback and contact information.

Very important section that's there to let users know that if they do have a problem and they need to get in contact with somebody or if they need an alternative format, they can get that information here.

Then we come onto the reporting accessibility problems with this website.

This is a legally required section.

It's similar to the feedback bit but will also still need to remain.

The enforcement procedures, again, a legally required piece of information for anyone that's writing a Public Sector Bodies, (websites and mobile applications) Accessibility Regulations 2018 compliance statement.

And then we've got an optional section contacting us by phone or visiting us in person.

If you do have a way for people to come and visit you physically or other phone options, you can always list them here as well.

Then we get into the real meat of the statement.

So, we've got the technical information about this website accessibility section.

This is a legally required statement that you are trying to make things as compliant as possible.

Compliance status identifies how compliant you are, and you pick one of the three options.

Non accessible content is the overarching heading to the following three subheading areas, of which we've got non-compliance with the accessibility regulations.

This is where your list the outcomes of any of your accessibility testing including any WCAG success criteria and failures you may have.

And then we've got the disproportionate burden sections.

So, this is where you will list any disproportionate burden claims that you are making or let people know that you're not making any claims.

Then the third of the three subsections we've got content that's not within scope of the accessibility regulations.

Now this is where you list all your exemptions, and we'll go through each one of these in just a moment.

And then finally, we have the preparation of this accessibility statement section.

This is another required thing where we say when the statement was prepared, when it was last reviewed, when the tests will last carried out, and some information about how those tests were carried out.

So, let's go through the template.

I'll walk you through it and a lot more detail and we can hopefully come out with a very compliantly worded accessibility statement.

So, let's pick a website, we'll say this is the accessibility statement for make things accessible.

This could be any website, so for whatever website you're writing this statement for that goes there again.

As we've mentioned in the guides before, try to make sure that you're writing really one statement per system, or one statement per website.

That's the best way to do it, to keep the issues kind of focused on the platform at hand.

So, first things first, we've got this introduction section.

Now there are two statements here that we have to keep in, two lines that have to stay there.

They're legally required.

And I've got a bit of an explanation just before that to explain that notes are surrounded by square brackets and this will help anyone identify where note requirements are still there, and obviously by the end we should have nothing left that includes this square brackets.

What I'm going to do is I'm going to remove those notes because we want to end up with a finalised statement, so this accessibility statement applies to, and then what we're going to put in here is we're going to put in the scope of the statement, e.g. the website or domain to which the statement applies.

So, we're going to take out that draft text.

Remember this is legally required.

And we're going to say this applies to www.MakeThingsAccessible.com.

So now we know this statement applies to this particular domain.

Next section, another note, use the section below to make a brief general statement about what the website allows disabled users to do.

If you're testing says one of the features below and not true, remove them.
So, this is about how accessible the website is, and we've also made the website text as simple as possible to understand, et cetera, et cetera.

This is from the sample statement, so we don't need that note as before.

This website is run by.

In this case, it's not actually run by a public sector body, it's run by me, George Rhodes.

However, in the event that you are writing your own accessibility statements, what you'll be putting in here is this website is run by the public sector body.

OK.

And this will be your organizational name, for example, the name of your university, the name of your college, your Council, or whichever other organization you are representing with this statement.

So, this website is run by public sector body.

We've also made the website text as simple as possible to understand.

AbilityNet has advice on making your device easier to use if you have a disability.

This goes to my computer my way, a very useful site that's always good to help direct users too if they do need some support.

So, we leave that in.

The next section how accessible this website is now this is a section that comes from the government template.

Normally it would have a little bit more information including bullet points that say you should be able to zoom.

You should be able to do this, that and the other.

Of course you should, it's the legal requirement.

However, we're kind of duplicating that information further down where we go into detail about what the problems are.
So, what I prefer to do is leave this with just a bit of text to say we know that some parts of the website are not fully accessible, in the event that you do have some issues, you can see a full list of any issues we currently know about in the non-accessible content section of this statement.

So that's further down.

What I would also add in here, which you can do is if you've got something going on like you're building a new website, a new version of the current website or anything else that kind of shows what's happening in terms of accessibility of the website at the moment you can add it in here, give people some additional updates or instructions if required to give a bit more of a summary.

Then, coming onto the feedback and contact Information section now once again this is a legally required section, so you cannot remove it.

I would also suggest that you keep these contacts sections both the feedback and the reporting sections where they're supposed to be here.

Don't play around with the orders of sections from the template, just keep it as is. I know we all want to kind of direct people to resolving problems themselves or online contact routes before we give them the option to ring somebody up or also go and make a complaint or ask for enforcement against us, so some people put these further down at the end of the statement.

Don't do that.

It's much more straightforward just to have the contact information there, because if they do really seriously need it, they are going to find it.

We might as well make it front and centre and give people the support that they need as quickly as possible.
So, feedback and contact information is a legally required section, but you don't necessarily have to use this wording, so you can change the wording on this one.

But I would encourage you to try and give as many different options as possible in terms of contacts routes.
So, e-mail, phone number, any other contact details because it's always good to give people the options.
If we just do a phone number then it can be no good for deaf users.

If there's no text-based contact option, so an e-mail alone is OK.

But if you've got other options then definitely try to add in more options.

So, this should also cover your requirement for if people need alternative formats, here's a good route to go and ask for those.

So, we're going to remove some of these comments if you need information on the website in a different format like accessible PDF, large print, easy read, audio recordings or Braille.

This is who you contact now for our one.

It's going to be the e-mail info@makethingsaccessible.com.

OK, so info@makethingsaccessible.com we're going to link that and that's obviously going to be through to the e-mail address.

We don't have a phone number or any other contact details for make things accessible, but if you did for your one, please add in as many contact routes as possible.

If you've got a different person that would deal with website complaints versus someone that would deal with alternative format requests separate them out, give different contact details as much as is useful.

It's also a good idea to add in a time frame for when people can expect a response.

So, whether that's two days, five days, whatever it is, as long as you let people know that can be really useful if someone in a bit of a rush to get some information about your service and the number of days is going to be a longer than what they need, then they might realize, OK I can put a request in here, but it's not going to come back for a few days.

I'll go and find a more direct or urgent route to get this this information together, so we'll consider your request and get back to you in let's say 5 days, we'll say 5.
Cool.

OK, so we've now got the headings right the intro's right.

How accessible the website is just the standard text that we're keeping there.

Feedback and contact information has the e-mail address and the number of days we're expecting a response.

Next is the reporting accessibility problems with this website.

Now this section is legally required.

Don't remove it and try to keep this as close to this as possible.

So, we're always looking to improve the accessibility of this website.

If you find any problems not listed on this page or think we're not meeting accessibility requirements, contact…
And then this should be how you provide details of how to report these issues to your organization and contact details for the unit or personal responsible for dealing with these reports.

Quite often, especially for small websites or small teams, this is going to be the same as the feedback and contact information.

So, in this case it is info@makethingsaccessible.com.

So that is once again going to be the same, the same e-mail address.

However, if you had larger organizations and different groups would deal with different things, this might be your digital accessibility team address.

This might be a product team address.

Although yes, many a time, it might be that the reporting information and the feedback information are the same, both of these sections are independently legally required, so we do suggest to have a compliantly worded statement that you do keep both of those in the statement.

You don't get rid of either of them.

They are both required.

And then underneath the reporting accessibility problems with this website section, we have a little link here, read tips on contacting organizations about inaccessible websites.

This is a useful thing that we put in a long time ago just to help people get a little bit more information on how to complain about accessibility problems.

This takes you off to W3 to get some more advice.

Next is the enforcement procedure section.

So once again, this is a legally required section and the government sample statement will give you some information on this.

And we've got both options for those who are in Great Britain and those who are in Northern Ireland.

Now what you'll do is you will pick whichever one of these is most applicable to you.

So, if you're in Great Britain you will be picking the first one because you'll be under the enforcement of the Equality and Human Rights Commission.

But if you're in Northern Ireland, you will be under the enforcement of the Equalities Commission for Northern Ireland.

If you are a UK spanning authority or organization in any respect, you will want both so you can keep both in, or you can delete one or the other that's absolutely fine.

What we're going to do just for this example because I'm based in England.

I will be picking the Equality and Human Rights Commission section.

However, if anything's going kind of broad, then we will obviously be picking both or if it's in Northern Ireland specifically we'd pick the Northern Ireland one.

Next one is contacting us by phone or visiting us in person.

Now, I said this was an optional one.

You can add further information here if you want to give directions on how to get to offices or what facilities offices have if someone does come to visit you in person.

This can be good for, places like universities that might have IT drop in desks or any other organizations where you may have in person visitation, and someone might ask about accessibility issues with this service or in general.

However, make things accessible does not have any physical premises that anyone can come and say hello to us at.

So, we're going to take that out as it was optional and we're going to move on to the technical compliance sections.

Technical information about this website accessibility.

This section is also legally required, and this is where you make a committal statement to say that you're committed to making the website accessible in accordance with the regulations.

So, name of organization, we chose public sector body.

Is committed to making its website accessible in accordance with the Public Sector Bodies (Websites and Mobile applications) (No.2) Accessibility Regulations 2018.

That's all you have to do.

Just put in your name.

It's a required statement to identify legally, that you are committing to compliance with the law.

That's all you need there.
The next one is the compliance status section.

Now this is another easy one, but can trip some people up.

What we've got is we've got three options here, so we've got this website is fully compliant, partially compliant, and not compliant.

Now, with each one of these, all you have to do is pick the one that most applies to your website, and then pick whether it's non-compliances, exemptions or non-compliances and exemptions.

For the partially compliant or not compliant options, now just a little bit of wording difference here.

You can see the partially compliant says due to the non-compliances et cetera, whereas the non-compliant one separates it out into two sentences, so it's a full stop and then the non-compliances or exemptions, et cetera are listed below.

So, there is a tiny little bit of wording difference there, so make sure you pick the right one.
It's not the biggest deal, but just for completeness you will want to pick due to for the partial or separate sentence for the not compliant.

Now what we've got is we've got fully compliant, partially compliant, and not compliant.
Fully compliant should be relatively self-explanatory.

It's if you've got no issues whatsoever.

Remember, this is saying fully compliant with the web content accessibility guidelines, not the regulations.

Now that's an important point because you might be fully compliant with the regulations in terms of, all of your content that's in scope of the regulations is accessible, but you have some non-accessible content that is out of scope of the regulations.

Now that is different to being completely WCAG compliant.

OK.

So, in here you're saying that the website is fully compliant with WCAG not with the regulations.

So, remember as far as the wording goes, if you have some content that's outside the scope of the regulations, but otherwise everything else is fully accessible, you'll still want to say that this website is partially compliant due to the exemptions listed below.

OK, so we're saying fully compliant with WCAG or if you've got any issues, disproportionate burden claims or exemptions, we're going to say partially compliant or not compliant, but we'll clarify what it's for.

So, in this case, we're going to say for this example that there are some issues.

So, we know we're not going to be fully compliant.

Then it's a debate as to whether we are partially compliant or not compliant.

Now the way we normally judge this is how severe the issues are, and this is this is up for a bit of bit of debate.
But what we try to say is you are partially compliant if you have any medium or low impact issues which will affect the user journeys.

So, things like colour contrast might not be as good as it needs to be or other relatively minor issues that allow a user to continue to navigate the service or can make their own adjustments, so might be able to apply their own colour filters etcetera that will allow them to continue their journeys.

Not compliant is if you have more serious issues so critical or high issues, this could be something like a form does not work with keyboard controls or there's no focus indication on a page, or none of the buttons have correct names or identify themselves correctly.

Many of these things have more significant impacts on user's ability to navigate and interact with the website, so if we've got more serious issues, we'll probably say not compliant over partially compliant.

But again, it's judgment call and there is information on MakeThingsAccessible.com to help you better understand the way in which we bracket our issue category criteria.

So, we break it down into critical high, medium, low and advisory and that can help you make a decision as to whether you feel that you're partially compliant or not compliant.

Either way, you've got some issues and we'll go through, and we'll list some of those out.

So, in this example, we're going to pick partially compliant.

As you can see here, we've got some notes to just explain what you need to do and to delete the options that don't apply.

So, we've done that.

We don't need that long note at the beginning there.

So, what we've got is this website is partially compliant with the web content accessibility guidelines version 2.1 double A standard, due to and then we've got an insert one of the following the non-compliances.

The exemptions or the non-compliances and exemptions.

Now because I want to show you examples of both, we're going to pick the non-compliances and exemptions listed below.
We're going to remove the other options in there and we're going to leave ourselves with the final statement of this website is partially compliant with the web content accessibility guidelines version 2.1 double A standard due to the non-compliances and exemptions listed below.

If you've got both, you do need to list both the non-compliances and exemptions.

So now we come onto those subsections.

What we've got is we've got the overarching heading of non-accessible content and then we've got non compliances, disproportionate burden, and content that's not within scope.

Now it's very important here that if you've got one section, say for example we only had some non-compliances, but we're not claiming any exemptions and we're not claiming any disproportionate burdens, we still have to have all three sections.

We still have to have all three of the subsections, it's just in the ones where we don't have anything to say what we're going to do is we're going to say that we're not claiming disproportionate burden or we're not claiming any exemptions.

But you do if you have one, you have to have all three, OK?

You can't delete the subsections out if you've got some of them.

So, I'll show you what I mean.

Non accessible content, yes, we don't need that note.

And then we've got non-compliance.

Now we're going to say, OK, we've got some issues, fantastic, haven't got disproportionate burden.

What you can't do is you can't delete that whole thing out.

You don't want to do that.

What you want to do is you want to say at this time we've not made any disproportionate burden claims which is exactly what I'm going to do.

We will cover disproportionate burden in other videos to go through a little bit more what evidence you need to make disproportionate burden claims, but you have to have evidence to support disproportionate burden claims.
Now we'll come back on to that in a second.

Let's continue to move through this in a logical order.

So, as I've said, you can't delete any of the subsections.

Let's go through what each of those subsections are.

First one is non-compliances with the accessibility regulations.

Now this section is where you list all of your known accessibility problems that fall within the WCAG success criteria.

So, we've got some example content here. I've put a few issues together just to show you how you might want to go about structuring them and a little bit of a formula here, so we'll go through.

When you're listing your issues, what you want to do is you want to list each issue.

Give an idea of where it is, who it's affecting, what kind of user groups it's affecting, what the impact is, what the WCAG success criteria is, and then what you're doing about it when you think it might be fixed.
So, let's take a look at a couple of these examples.

So, what we've got is we've got skip to content across all pages of the website, does not move the user to the main content of the page.

Basically, it's a broken skip to content link.

This is not a serious issue as there are only three moves between the skip to content button and the main content in the example that we've given.

So, what we're saying there is that's a relatively minor issue because it's three additional tab moves to get to the main content, so the skip to content is only saving that user a couple of seconds.

Now if we had a mega menu or nested large menus, this might be a more serious issue because without options to skip a user forward or bypass some of those navigational blocks, it would be a very long, arduous journey for a user to get through. If that was the case and it was a more serious issue, we would reflect that here and we'd say this is a big problem because it's got a mega menu and therefore, this is causing the users a lot of delay.

So, what we said is we've said it's a not a serious issue because it's only this very small impact.

So now that the user knows what the problem is, what the impact is, which is they've got tab just a couple more tabs.
Then we're identifying what were tags success criteria this fails against.

So, in this case it fails the WCAG success criteria 2.4.1 Bypass Blocks which is an A success criteria.

And what we have said in letting people know about what we're doing is we have a ticket raised for this issue and expect to fix to be deployed in the upcoming October 2020 update.

OK.
So that's about what you need to say for a singular issue, let's take a look at another one.

We know that the continue button on pages within any given form journey shall we say.

So, say this is our complaints journey, we know that the continue button on pages within the complaints journey are not very clear when focused on keyboard.

OK, so we know that this is a keyboard focus issue.

Now, the reason why we've only said this much is because what we would want to flag up with you in this example is to say, perhaps a little bit more is this that there's no focus indication whatsoever?

Is this because there's a small contrast issue?

Is it because there is a line surrounding it, but it's only a single pixel width line and so it's not very clearly visible, even though it does make contrast requirements?

We would encourage people to give it a little bit more information so that users know which groups it might be impacting.

Now, because this is a focused visibility issue and again, we could say more on this. We said that this fails WCAG 1.4.11 Non-text contrast.

So, we know that this is going to be an issue that it doesn't need the three to one contrast requirements, and 2.4.7 Focus Visible.

So, we also know in there that we're going to have other significant focus visibility problems, not just that it doesn't meet contrast, but it is there.

So, we know that that's going to be quite complex issue. We might want to give more of a description there.

This issue or this error has been raised with the developer and is included on our production roadmap.

We do not yet have a date for when this will be fixed.

Now, this is not preferable.

You know, we would like to say if possible, when we think it is going to be fixed.

Remember to put in dates that are actually in the future.

We've included an October 2020 date in here so that nobody just leaves this copied in.

But if you don't know the dates, if it is going to be on a supplier’s road map and you don't have a date for it yet, let people know that you don't have a date for it yet and say what you're going to try and do about alternatives for this in the meantime, if possible.

Then we've got a final one here where we know this is a problem and what we've also given is as an alternative you can e-mail us directly at blah blah blah while we work on fixing this issue.

So, in this we've given the example of exampleservice@example.co.uk.

So, if you do have problems, you can also let people know about the alternative routes that you've set up.

So, if there is an e-mail address, let them know.

If there is some other route, let them know as well.

Just to recap on a very succinct explanation of the bits that you want to put in when listing accessibility issues in this section.

Remember we're in the non-compliance for the Accessibility Regulation section.

What you want to say is this thing is broken.

Here is where it is broken.

So, what pages it's on, what journeys it's on if you know that.

This is the kind of effect it might have on you as a user.

This is what WCAG point it fails against and here is what you can do instead, and what we're doing to fix the problem.

So, all very useful stuff.

One of the other things I will say because large websites tend to have many, many issues with them.

If you find yourself writing 2-3 pages of issues as we go down, it can become harder to navigate, especially with each one of these being a paragraph to themselves. What you can always do to try and make that a little bit more ‘easy to understand’ is we can always say, right, so, for these three issues here we're going to turn them into a list.

So now each one of those will be a list item, and for users to navigate, it will say this is a list of three items, so they get to know how many issues we've got.

The other thing you can always do is while this is a heading three, you can add in further subheadings, so we might say that we've got navigation issues, OK, and we'll say that that's a heading 4.

We might say that the focus indication issue, although not to do with navigation, is to do with visual appearance.
So, we might say that as a as another issue.

So we'll say that as a heading 4.

We might say there are content issues in which we might write further ones.

Remember again, just while I'm here, not lists of single items.

So, try and keep them to multiple item lists as well.

We always want to avoid single item lists, so content issues we're going to make that a heading 4.

Add an, well, start a new list, and then what we're going to say here is some content includes headings which are visually styled to be headings but not programmatically tagged as headings.

For example, some of our news articles do not contain a correct heading structure.

OK, so, what we're doing is we're letting people know that we've got a problem with some of our headings.

So, they look like headings, but they haven't been styled as headings, so they won't be navigable properly.

They won't appear in a headings list.

We know that this is appearing on some of the news articles.

This fails WCAG 1.3.1 Info and Relationships, and we might say we are undertaking a review of our news article content and updating news articles with this issue before the end of December 2022.

OK.

So, we might say something like that which would be a succinct description.

If we wanted to provide a little bit more information you can go into more detail but for longer lists, these become quite long, so try and be as succinct as possible.

So now we've got some non-compliances.

We've listed out our issues.

We've listed out our WCAG success criteria.

We're going to remove that little prompt just to remind you.

I also always like to include this little section at the end to say if you find an issue that we have yet to identify, please contact us using one of the routes described in the reporting accessibility problems with this website section of this statement, because we may have missed something new things are appearing all the time.
It's always good just to let people know if they find something you have not listed to let you know so that you can add it to the list.

Alternatively, if you have claimed disproportionate burden or have some exemptions, but you don't have any issues, you don't have any non-compliances otherwise, you can always use this sample piece of text which says we've not identified any areas of the website that are not compliant with the regulations and are not otherwise covered by exemptions.

If you find an issue that we have yet to identify, please contact us using one of the routes described in the report accessibility problems bit, so once again it's a little bit of a repeat of that section above but also with the we haven't got anything in this section bit right now.

But we have listed some issues so what we're going to do is we're going to take that out.
Now we come onto disproportionate burden. Now the one main thing I would say when filling out a disproportionate burden section of a statement.

If you're using this template, the default text I've left in is at this time we have not made any disproportionate burden claims.

If you're going to use the government template, in that sample statement there is holding text in the disproportionate burden section and it says things about skip to content, some labels, and orientation.
That text is very specific and it is holding text.

It is an example.

It is not to be used as just generic text, you cannot claim it.

So please, if you see that and you're using that as a template, remove that because I read a lot of accessibility statements and many people leave the example text in the disproportionate burden claim because they think if the government have put that in, then that seems like a legitimate claim and we'll make that same claim.

No.

To make a disproportionate burden claim, you have to have really significant evidence to show that you have worked out that this is going to have a significant cost.

It's not going to make a massive difference to disabled user groups and several other things.

You have to have some evidence to support that.

If I see that you have copy and pasted the text directly from the sample statement, it's almost a given that you haven’t actually provided evidence for that claim and you haven't filled this this statement out correctly, and I see quite a lot of them.

So please, one thing I would ask of everyone is if you're going to use the sample statement template from the government, please clear out the disproportionate burden section and just say at this time we've not made any disproportionate burden claims, only replace it once you have genuinely thought about what claim you're going make, you've double checked it's not already an exemption, which is another thing that a lot of people do.
They claim for things that are already exemptions, so you don't have to.

You've checked you've got your evidence together, and then you can put something in the statement to say we've claimed disproportionate burden for this thing, and that is what the example text within the sample statement is showing you.

The sample statement from the government, that's what that's showing you is once you are ready to make a claim, this is about as much information as you should put in to say here's what we're claiming for, here's the specific thing, we've done an assessment, and its disproportionate burden because of these reasons.

That's what the government statement is trying to show you.

Not saying that the things in the statement are actually a sensible or legitimate claim to make.

So, please do not copy paste the content from the government sample statement.

On to the final subsection, content that's not within scope of the accessibility regulations.

Now this is another important section here.

Once again, you have to have this if you've got the other two.

And what we do here is we're going to list any of the exemptions that may be affecting our website.

Now what I've done is I've included some sample text to get you started on each of the main regulations, which you're likely to be claiming, but obviously you will want to fully replace these with specific text about your own content and about your own website or system.

So, let's take a look at each one in turn.

The first one, we're going have a look at is PDFs and other documents.

Now this is more for older documents.

This falls within the office file formats and PDF's, etcetera.

Various documents that are older.

So, we're talking pre regulations and these may not necessarily need to be made accessible.

However, anything that is used for what is called an active administrative journey, so these might be important forms that you are expecting people to download and fill out, or be able to interact with, and then send back to you anything like that because it's part of an active journey.

It's something that people have to fill out and something people have to interact with rather than just for information.

Those do have to be made accessible, even if they're pre-registration.

So, what we've got here is we might have a load of old documents, meeting minutes from a particular executive board or Council meetings or something there for information and nobody really looks at them and they're pre-regulations so we don't have to make them accessible.

However, if somebody asks for one of these specifically, and they ask for an alternative format, they ask for a reasonable adjustment.

You will obviously be required to provide it for that specific thing, so this becomes a “we'll fix it on request” rather than “we'll proactively go back through all the documentation”, back 5-10 years kind of thing.
So, PDF's and other documents.

We've got some stuff here.

Only if it's for essential stuff.

And remember, this is older documents pre regulations now because make things accessible got set up after the regulations came into effect, I can't claim any of this because all of our documents are going to be put up new.
So, everything must be accessible.

So, I'm not going say that.

But for larger websites you might want to use it but eventually that one will become less relevant.

The next one up is third party content.

Now, you may include third party content onto your website.

This might be in the form of user comments as part of a forum.

This might be documentation that you have to publish legally for other reasons.

It might be provided to you by a national regulatory body or a government department and because they've sent it to you and it's locked and it has to be that way for their other legal requirements there's little you can do about it.
You can try and offer alternatives, but there might be content that's completely outside of your control and you cannot change it.

If you want to know a little bit more about third party content responsibility, we have guides up on MakeThingsAccessible.com which can take you through the five key questions of working out whether you may have responsibility for certain types of third-party content, but it's a useful exemption to be aware of.

Now once again we're not going to…

The problem is I'm not going to have any of these on here because we're making the website accessible from the beginning, so I'm not claiming any exemptions, but just for this example, say we're going to be piping in some third-party content from outside sources that we've got no control over, but it's vitally important that we do so.
So, we're going to claim an exemption for that. So, we'll leave the third-party content exemption there.

The next thing is video content.

Now you're probably watching this on MakeThingsAccessible.com so this is a…

This would be a video up there, however, because it's after 23rd of September 2020 it would be required that we do have accessible alternatives available for this video, such as captioning and a transcript.

Audio descriptions as well, but because this is a talking head video and I hope I've done a good job of narrating what's going on, audio descriptions may not be necessary as a separate audio described version.

But we might include some video content that was published pre-September 2020 as useful references or embeds onto the website.

So, what I'm going to say is that we don't plan to add captions to live video streams because live video is exempt.
Now that is a separate one, and we're not going to do live video.

So, we're going to remove that.

But I am going to say we do have some existing pre-recorded video content that was published before 23rd of September 2020.

This content is also exempt from regulations.

Don't need to say also.

So, this content is exempt from the regulations and all new video content we produce will have appropriate captions, audio descriptions and transcripts as necessary.

So, we're going to say that one that's all good.

Then we've got three more just to take a quick look through.

Online maps, so maps, as long as they're not used for navigational purposes, this could be a map like a Google map, an interactive map on your website.

This could be a picture of a map of a physical space, or a geographical area.

Or it could be a document with a map in for example, say a planning document which has information about the layout of a house or building whatever is being requested for planning permission but it's not used for navigational purposes, so whatever the format the online map comes in, whether it's an interactive map, a picture or a document is still counts as an online map.

Now, they're not required to be accessible because it's almost impossible to kind of provide that guidance.

But what we should be doing is we should be providing alternatives.

So, if we've got information about a about a planning application, many planning services already offer the option for users to come in and speak to somebody and ask questions about the planning process or a particular planning application to their hearts content.

So, what we do is we might claim an exemption because of some online maps we've got, but we talk about the accessible alternatives to say you can contact these people, we can give you a description.

We can talk you through it. We can answer any questions and we put that both here in the accessibility statement and next to the maps wherever they appear.

For navigational purposes.

So, say you've got a map showing how to get to your offices.

You're not going be able to make that map accessible most likely, but what you can do is once again provide more clear, accessible alternatives.

So, you might provide a full postal address so that someone can put it into a sat nav.

You might provide a What 3 Words coordinate.

You might provide direction instructions from the nearest train station or bus stop to help people navigate to your offices, to your campus, wherever it happens to be.

So, online maps are a problem.

You can claim an exemption for them, but the important thing is you should be saying about the accessible alternatives you'll be putting in place.

Once again in a very similar vein to what we had about some of the older PDFs, archive content.

Now this is content that's specifically badged as archives, so this might be an archive of old news articles, an archive of you know, financial reports going back ten years for various reasons.

Archives are exempt.

They have to be clearly badged “It's going to have to be an archive”.

If you update them at any point and you do kind of significant upgrades, then you may be required to further adjust them, but for certain pieces of archive content, you do have an exemption.

Now we don't have any archive content on MakeThingsAccessible.com, so I'm going to remove that and then the final one is quite easy.

There are some timeline-based exemptions for internal systems, so anything prior to September 2019, that is an internal facing system, so, this might be your intranet, this might be staff only systems such as self-service for booking annual leave and things like that.

Anything like that there's requirements for it to be substantially revised post September 2019 to be in scope of the regulations and you have to make sure that it does comply.

Now, we don't need to claim this for MakeThingsAccessible.com, but if you're going to write… If you've got internal systems, I would write an accessibility statement anyway and include this additional line “We have chosen to produce this accessibility statement in advance of the substantial revision, to support our users and our requirement under the Equality Act 2010 and the public sector equality duty.”

Many of us still have a requirement to make things proactively accessible under the Equality Act and the public sector equality duty.

So, it's still a good idea to write a statement, point out that there's an internal systems exemption in this section, but say we're doing it anyway because it's good practice.

Now that's the final exemption I'm going to walk you through.

Once again, like with the other sections, I've got a bit of example text here that you can use if you have no exemptions that you're going to be claiming.

To say, “at this time we've not identified any content that is not within scope of the accessibility regulations.”
So, you can say that if you need to instead of, all of the others.

And then we come onto the final section.

So, the final section is preparation of this accessibility statement.

This is a legally required section once again.

So, you have to have this in it has to be in this kind of format and you have to give further information about how this statement was prepared and how we kind of got to these results.

So, this statement was prepared on, what's the date today?

The date today is the 26th October 2022.

It was last reviewed on and what we'd say is when we published this statement, we're going to say that it was published on the 26th October 2022.

What you'll leave when you update the statement periodically as you leave it up on the website, you'll leave “the statement was prepared on the 26th of October 2022”, as the original date for when it first was added.

It was last reviewed on, and then you'll update this state every time you review it so people can see when it came in and when the last change was.

This is the website was last tested on.

What you will do is you will put in here the date that you received any auditing report or when you completed your testing and when you finalised your reports or when you last did your semi-automated test run.

And this website was last tested on once again 26th of October 2022.

The test was carried out by.

Now, what you're going to do here is you're going to add in a little bit of information about who did the testing and what you did for the testing.

So, the test was carried out by…

You could say you did your own testing.

You can say this was carried out by an internal team.

You could say it was done by a third-party auditing company or whoever.

But whatever you do, you've got to put that in here.

So, this test was carried out, let's say, internally by Make Things Accessible digital accessibility staff.

So, you might have a team for this.

You might have an individual.

You don't need to name them specifically, but you can say this team or this role or responsibility, they last completed the testing.

So, the test was carried out by or carried out internally.

Here we are.

Alternatively, you might say the tester was carried out by All Able limited or anybody else who's doing your report for you.

But in this case, we've said it's carried out internally by staff.
Testing included a mix of manual and semi-automated tool testing including testing with common assistive technology and browser pairings.

So, you want to say a little bit about what you did for the tests.

GDS will ask you about this.

So, they will say, how did you test it?

And you might say, well, we used these automated tools, and someone checked in with the screen reader, and went through it with keyboard, and did all the colour contrast checking manually, and various other bits and pieces.

Now, what you want to say is just to summarize, we did a range of manual checks and semi-automated tool testing.

You could list what tools you used if you really wanted to, but this is fine enough and it's always good to point out if you have indeed tested with common assistive technology and browser pairings if you're if you're going kind of that extra step and that is the completion of an accessibility statement.

This with the removal of the bits that I've just used as example, would be ready for publishing.

So, as a quick recap and run through, we've done the introduction and who this applies to.

We've provided feedback addresses how long it's going to take to get feedback.

We've provided addresses for reporting accessibility problems.

We've picked the enforcement procedure paragraph that applies to us.

We've put our name in the technical information about this website’s accessibility section where all we have to do is just add our name.

For compliance status we've picked, whether we're fully partially or not compliant and chosen whether it's because of non-compliances, exemptions, or both.

Then we filled out the non-accessible content section and each of the three subsections which we have to keep.

So, we've got the non-compliance with accessibility regulations where we've listed our issues and the WCAG success criteria they fail against, and we've split those out to kind of give it a bit more when navigational structure if we've got a lot of issues.

For disproportionate burden, we haven't made any claims and I've given you a little bit of advice on why you need to be very careful with that one, so please make sure you have evidence to support a claim before you put anything in that section.

Content that's not within scope.

We've gone through all of the exemptions that might apply to us.

We've had to think about it, and we've picked the ones that apply and what we would do is we'd go through and make sure that all of that text is applicable to our specific situation with the given website that we're writing the statement for.

And then we finished it all off by filling out the preparation of this accessibility statement where you can see when it was prepared, when it was last reviewed, when it was last tested, who carried out the testing, and finally what that testing entailed.

And that's it.

That's all you need to do to write a PSBAR compliant accessibility statement.

Obviously, you can go above and beyond.

You can add more information in, more support for users, more tools and pieces of assistive technology that they may consider to help interact with your website better.

You might provide more information about how to get support, some of your disability support options.

You might go into more detail about the types of issues and when you're getting fixed you could talk a little bit more about the road map that you're taking to improve the accessibility of this website or system.

There's always ways to go above and beyond, and if you want to look at more information on going above and beyond an accessibility statements, I would suggest going to textBox Digital.

The textBox Digital website, which is where the ASPIRE accessibility statement accreditation process is hosted and that can give you more information on how to really hit what a really good accessibility statement looks like that goes above and beyond legal compliance and helps you improve the content that you're providing for your users.

And also through ASPIRE you can pay, get checked and tested, and get a little badge to say how good your accessibility statement is if you really did want to go for those next steps.

But what we have covered in this video is how to make a legally compliantly worded accessibility statement in accordance with the public sector bodies accessibility regulations.

So, I've shown you how to fill out all of the bits that are legally required and what you need to say to meet your obligations.

Any further questions, you can always contact us either through the make things accessible website on info@makethingsaccessible.com or you can get us directly at info@allable.co.uk.
Thanks for listening.