Embedded Files
Video Help:
How to check your site for Accessibility Compliance
How to apply the Accessibility Statement Template to your site
Other useful links
Really good third party training on WAVE (full tutorial for submitting, reading and checking)
Standard Government Accessibility Template (excellent source for guidance if you're confused)
Check accessibility in Microsoft Word Documents
Check accessibility in Adobe PDF Documents
I have been asked to add or update my accessibility statement. Do I have to do this?
Yes, so long as your site is published (unpublished sites are exempt).
Why do I need to do this? I already have an accessibility statement applied to my websites?
As our understanding of accessibility and how to adhere to it improves, there will be occasions where we ask people to make changes to their sites. When we do this, the request will come from the service desk and is usually mandatory. We will try to ensure that we only make such requests when necessary.
Is this accessibility statement just for Google Sites? What if my site is hosted with a different provider?
The NIHR Service Desk is most concerned about Google Sites because of the accessibility limitations that were highlighted by the GDS. If your site is not hosted by Google, you will need a different accessibility statement because the statement we have prepared is for Google Sites only. You’re welcome to create your own template, however you must use the required fields on the Government template. You can find this by visiting the gov.uk website.
I am creating a New Google Site. What do I need to do to make sure it satisfies accessibility requirements?
If your proposed New Google Site will be published, whether internally or externally, you must ensure you have checked your website for accessibility and completed an accessibility statement to support your checks. Full guidance on this process is provided on the Accessibility Statement Template page, where instructions can be noted within the statement template itself. In the end, your accessibility statement should be very similar to that of the accessibility statement for this website.
My site is unpublished, do I still have to include an updated accessibility statement?
So long as your site is not shared with anyone, you do not require an accessibility statement. If, however, you wish to publish this site in the future, you must include an updated accessibility statement prior to publishing.
My site is published for internal use only. Do I still need an updated accessibility statement?
Yes. If your site is published, whether that be for internal and/or external use, you must have an updated accessibility statement. Only sites which are not published are exempt from adding updated accessibility statements.
A colleague was not asked to update their accessibility statement. Why do I have to do this?
Because of a current limitation in the technology we have to track Google Sites, we do not have a method to export a list of all New Google Sites. As an imperfect workaround, the IS Function team have managed to create a point in time spreadsheet containing as many Google Sites as we could. This was off the back of a form that we asked site owners to complete in late 2020. Naturally, some sites are missed, so this would explain why for example, you may have been contacted but your colleague hasn’t.
Despite this, all Google Site owners are required to update their accessibility statements and failure to do so may risk their Google Site being unpublished. It is therefore critical to inform colleagues who may not be aware of this task and to make sure they complete the accessibility form.
There are items on my site that are not accessible which I cannot control. What do I do?
If there are items of your website such as embedded documentation or reports that are not accessible and which you have no control over, you must ask yourself whether these documents are critical to the website. If you need these inaccessible documents on your website but there is nothing you can do, such as these documents being owned by a third party, it is crucial that you mention this in the accessibility statement. You must offer the reader of your site with a solution should they really need to understand the content in question. For example, you could offer the reader a phone number to provide a verbal summary of the document in question.
Do I have to do an accessibility statement for every page of my website?
No, you only need one accessibility statement per subdomain. However, this accessibility statement should be a summary of every page on your website. It should list the compliance of all pages found across your website.
Does the WAVE extension automatically check embedded Word and PDF documents for accessibility?
No, WAVE only scans the content of websites and not the embedded elements of them. Unfortunately, this means that if your website uses embedded elements such as AwesomeTables, you'll need to reference this in the 'content that’s not within the scope of the accessibility regulations' section of your accessibility statement.
To check accessibility of Word, see here. For checking accessibility of PDFs, see here.
WAVE is indicating contrast errors on areas of my site where I can tell there is no contrast issue. What do I do?
This is an issue with WAVE which is seeing a text box behind the text itself which is the same colour when in fact, in reality, this is not true. Running WAVE on the published instance rather than the 'edit' instance of the website appears to alleviate this issue for the most part, however some users have highlighted this issue still persists. While WAVE is a good tool to highlight potential accessibility issues, at the end of the day accessibility can only really be determined by us as humans so be sure to exercise a degree of freedom with this. More detailed information is provided by WAVE on their website. Additionally, there are some good resources online by third parties showcasing WAVE's features and what they mean.
What WAVE errors or advisories do I have to action?
In essence, the errors needing to be fixed are highlighted in RED. Sometimes, contrast errors are erroneously presented (please see prior question). The yellows are 'advisories' so need to be assessed in context by the site owner. Ultimately, site owners need to adhere to the RED errors, and review the other information and assess it in context. This is further expanded in the video series provided at the top of this page and useful guidance is provided via the WAVE help links above.
Are there any limitations with wave?
Absolutely. WAVE is suite of tools to help web you make your web content more accessible. WAVE cannot tell you if your web content is truly accessible. Only a human can determine true accessibility. But, WAVE can help you, as a human, evaluate the accessibility of your web content.
Accessibility testing tools such the WAVE can provide efficiencies that cannot be equaled. They can help detect if a web page is inaccessible and identify issues that might otherwise be time consuming or difficult to identify manually. They will catch things such as missing alt text, form controls without labels, and contrast errors. They can catch those types of errors much better than a person can and those kind of errors are very important to accessibility. Automated testing tools excel when the decision logic can be boiled down to a simple yes or no answer, and that answer can be determined using machine accessible data. Automated tools can quickly locate a lot of obvious problems, reducing the initial time one needs to spend looking over a page for problems.
Passing automated accessibility testing does not mean that a Web site or application is accessible. The greatest danger with automated accessibility tools is the assumption that they can somehow replace human involvement in improving accessibility. Use accessibility tools, but remember they are only one part of the toolkit. Sole reliance on them as sole indicators of accessibility compliance gives a false sense of security. In addition they may inaccurately portray a site or app as being fully accessible to people with disabilities when in fact problems exist. Evaluating Web site accessibility is an art not a science - it can't be reduce to running a site through an automated tool.
A level of human interaction will always be required to assure that content is fully accessible. An automated tool is not a complete solution. For example:
Logical flow or logical meaning of content can only be assured through a manual review.
Ensuring that the tab order is logical and follows an expected path and that the current input focus is visible to the end user all require human interaction.
Keyboard access can only be confirmed by a live tester taking the steps to evaluate those functions.
Verifying that text alternatives are meaningful can only be accomplished by manual review.
Therefore you can't stop at automated testing. To be effective, accessibility checkers should form part of a wider process. A comprehensive approach, including testing by people with different abilities and skills as well as evaluation by individuals knowledgeable in the field of accessible Web design is best. While automated tools are not a complete solution they are a necessary part of any serious accessibility evaluation effort.
In addition, a limitation of the WAVE is that it will test one single page at a time and not a whole site.
What does compliance within the accessibility regulations mean?
Compliance is defined as the action or act of complying with a command. In the case of accessibility, our command, or regulation, is to be as compliant as possible within the Web Content Accessibility Guidelines (WCAG). In the case of Google Sites, even if you have ensured your website satisfies all the WCAG conditions, it will at most be partially compliant. This is because of the existing list of Google Sites outlined in the disproportionate burden section of the NIHR accessibility statement template.
When we talk about compliance outside of the accessibility regulations, we are talking about accessibility considerations that fall outside of WCAG. For instance, as WCAG is primarily concerned about the accessibility of web content and websites, objects such as Word documents or PDFs fall outside of these regulations. It is still recommended you try to ensure these documents are as accessible as possible and reference the steps taken to ensure this.
Page updated
Report abuse