Accessibility Statement

Last updated: 11 October 2026

Who this statement covers

This statement covers the whole of this website, holmesportfolio.co.uk, including the forms on it.

HolmesPortfolio is based in England. We build application solutions.

We want as many people as possible to be able to use this website. In our tests of the pages listed below, you could:

  • zoom in up to 400% without the text spilling off the screen
  • use this website with only a keyboard
  • see where you are on the page when you move round with a keyboard
  • change the spacing of text without it being cut off
  • use the website without anything moving, flashing or playing on its own

We’ve also tried to make the text on this website as plain as we can.

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

How accessible this website is

We tested this website on 10 October 2026. On 11 October 2026 we tested it again with a screen reader called NVDA. We fixed every problem we found on both days. We haven’t tested every part of it yet. For example:

  • we haven’t tried other screen readers yet, such as JAWS, VoiceOver or TalkBack
  • we haven’t tested it in Safari or on real phones and tablets yet

There’s more detail in the “Content that’s not accessible” part below.

If you can’t use part of this website

If you need something on this website in a different format, tell us. For example, you might need a page as plain text, in large print or read out in a recording. Tell us what you need and we’ll see what we can do.

If anything on this website or in our services is hard for you to use because of a disability, tell us too. We’ll look at what we can change.

Use our contact form, or email david@holmesportfolio.co.uk.

We’ll reply as soon as we can.

Tell us about a problem

If you find a problem that isn’t listed on this page, or you think we’ve got something wrong, please tell us. The “Report an accessibility problem” link at the bottom of every page opens our contact form. You can also email us at the address above.

It helps us to know which page you were on and what went wrong. If you can, tell us which browser and any tools you were using, such as a screen reader or zoom. You don’t need to tell us about your health or any disability.

If you’re not happy with our reply

If you’re not happy with how we answer a problem you’ve reported, tell us through our contact form.

If you’re still not happy after that, you can contact the Equality Advisory and Support Service (EASS).

Technical information about this website’s accessibility

We want this website to meet the Web Content Accessibility Guidelines (WCAG) version 2.2, level AA.

What our tests found

We haven’t tested every part of this website yet, so we can’t say whether all of it meets WCAG 2.2 AA. The parts we haven’t tested yet are listed below.

We know of no remaining failures of WCAG 2.2 AA on the pages we tested. We’ve tested 14 of those pages with one screen reader, NVDA. We haven’t tested any page with another screen reader yet. We’ll update this part as we test the parts listed below.

We tested every page of our support and contact forms, including Check your answers and sending a message. We also tested our feedback form, which has one page, but we didn’t send it. We know of no remaining failures of WCAG 2.2 AA in these forms.

Content that’s not accessible

Problems we know about

We know of no remaining problems on the pages we tested.

Parts we haven’t tested yet

We haven’t yet tested:

  • the website with the JAWS screen reader
  • the website with VoiceOver, the screen reader on Mac and iPhone
  • the website with TalkBack, the screen reader on Android
  • the website in Safari
  • the website on real phones and tablets
  • the guide, the project posts and the tag pages with any screen reader
  • the website with speech recognition, such as Dragon or Voice Control
  • the website in Windows high contrast mode
  • the confirmation email that you get after sending a form

These parts may have problems we don’t know about yet. We plan to test them.

What we fixed in October 2026

Problems we found on 10 October 2026

Our tests on 10 October 2026 found these problems. We’ve fixed them all on this website:

  • menu items now show clearly where keyboard focus is
  • “Back to Menu” now keeps your place instead of sending you to the top of the page
  • Escape now closes the menu
  • the guide pages are now easier to use with a keyboard or a screen reader, and their language is set to British English
  • the forms on this website now keep their error messages when one answer shows or hides another question
  • the forms’ “Back” button now keeps what you’ve typed on the page you leave
  • plain-text emails from our forms no longer put headings in capitals
  • the search results page now has a main heading, and each result is one clear link
  • the search box on the “Page not found” page now has its label above it
  • the search boxes on the Projects list and tag pages now have a label you can see
  • a search of the Projects list that finds nothing now keeps the page’s main heading
  • project posts now have a main heading
  • screen readers now read the date and summary on each post in the Projects list and tag pages
  • the breadcrumb links on project posts now have a name, so screen readers can tell them apart from the main menu
  • the “Top” button no longer covers the last link on the page
  • long words on the HolmesPortfolio Forms page no longer make the page scroll sideways
  • links in our posts and pages that open a new tab now tell screen reader users so
  • screenshots in our project posts now have a text description, or are marked as decorative so screen readers skip them
  • we removed a broken preview link called “Home” from one project post
  • the home page now has a main heading
  • the site name now reads “HolmesPortfolio” in browser tabs and when a screen reader reads the logo
  • the Security page’s title is now correct

Problems we found on 11 October 2026

Our screen reader tests on 11 October 2026 found these problems on a test copy of the website. We fixed them there the same day. The fixes are now on this website too.

On every page:

  • the “Skip to content” link now moves the keyboard focus to the main content, so screen readers start reading there
  • screen readers now say “(opens in new tab)” as separate words, instead of running it on from the link text

In the forms on this website:

  • screen readers now read the box listing your errors once, not twice
  • choosing an answer that shows or hides another question no longer makes screen readers read the question again
  • when an answer shows a message, screen readers now read the message together with the question it comes with, not separately
  • a warning message that appears when you choose an answer is now read out once, not twice
  • moving to the next page now reads out the page’s heading, not the whole page
  • screen readers no longer call the thank-you message a “status bar”
  • word and character counts are now read out once you stop typing, not after every word
  • attaching a file now reads out its name clearly, such as “photo.png added”
  • if another answer hides the question you’re on, the keyboard focus now moves to the next question or button. The whole page is no longer read out.

How we tested this website

We tested this website ourselves on 10 and 11 October 2026. No outside company checked it. On 10 October we tested in the afternoon. In the evening, after uploading our fixes, we tested again the pages those fixes changed.

Later that evening we tested every page of our support and contact forms, for every reason you can choose. That included Check your answers, the thank-you message and sending two test messages. We also tested the project posts, the Projects list and the tag pages.

Last, we checked the fixes to our project posts, home page and site name on the live website.

We tested these pages:

We used Google Chrome on Windows 11. We tested at four screen widths: a normal desktop (1280 pixels wide), 800 and 640 pixels wide (the same as zooming to 200%), and 320 pixels wide (the same as zooming to 400%, or a small phone).

We also checked the website in Firefox. We looked at pages at 1280 and 320 pixels wide, used the menu with a keyboard and checked the forms’ error messages. Firefox showed no new problems.

On 11 October 2026 we tested the website with NVDA 2026.2, a free screen reader for Windows. We used it with Chrome for Testing, the version of Google Chrome made for automated testing, on Windows 11. We recorded what NVDA said as text. Then we checked that against GOV.UK guidance and WCAG.

We did this testing ourselves, using automated runs of a real screen reader. It was not done by disabled people who use screen readers.

On the live website, we used NVDA on 14 of the pages listed above: all of them except the guide, the project posts and the tag pages. We only read the pages. We didn’t send anything. On each page we checked:

  • the page title
  • that the “Skip to content” link is there and has a clear name
  • that there’s one main heading, and the headings are in order
  • the main areas of the page: the header, main menu, main content and footer
  • the first links and buttons

We also checked the menu button. NVDA says whether the menu is open or closed. Escape closes the menu and takes you back to the button. On the support form, we checked the box listing your errors and the links in it. All 75 of these checks passed on the live website on 11 October 2026.

Then we tested the forms and the website’s design more closely on a test copy of the website. That’s where we found the problems listed under 11 October above. We checked our fixes on the test copy too.

The forms on this website are built with our HolmesPortfolio Forms plugin. We also tested the plugin with NVDA on a test copy of the website. We checked every type of question, error messages, questions that show or hide, Check your answers, the “Back” button, file uploads and the thank-you message. This is about the forms on this website. Forms that other people build with the plugin depend on how they’re set up, so this statement doesn’t cover them.

Most of our checks didn’t rely on an automated checker. We used a testing tool to control the browser and press the keys, and checked the results against WCAG one by one. We checked:

  • using every page with only a keyboard, including the menu
  • zooming in, and narrow screens
  • wider text spacing
  • colour contrast, measured in the browser
  • headings, page titles and page language
  • the names of links and buttons
  • forms, including labels, error messages, questions that show or hide, Check your answers and the thank-you message
  • the emails we get when you send a form, including the plain-text version
  • images and their text descriptions
  • movement, and the setting that reduces it
  • the size of buttons and links

We also ran an automated checker, axe-core 4.10.2, in our first test, on every page except the guide. We used it only as an extra check. It missed most of the problems our other checks found. A clean result from an automated checker doesn’t show that a page meets WCAG.

We did not test:

  • other screen readers, such as JAWS, VoiceOver on Mac and iPhone, or TalkBack on Android
  • speech recognition, such as Dragon or Voice Control
  • Safari
  • real phones and tablets (we made the browser window narrower instead)
  • Windows high contrast mode
  • the confirmation email that you get after sending a form

Preparation of this statement

We prepared this statement on 10 October 2026. It was last reviewed on 11 October 2026. We will review it again by 10 October 2027, and sooner if we make big changes to the website.

HolmesPortfolio is not a public body. So the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 don’t apply to this website. We’ve based the layout of this statement on the GOV.UK sample accessibility statement for public sector websites.

These problems can make the website harder to use:

  • Some links in our posts and pages open a new tab without telling you. We plan to add a hidden note to each one so screen readers say it opens a new tab.
  • The “Back” button in our forms loses what you’ve typed on the page you leave. Answers you saved with “Continue” are kept. We plan to keep the unsaved answers too.
  • Plain-text emails from our forms put headings in capitals. Text in capitals is harder to read. We plan to write them in sentence case.
  • The “Skip to content” link moves the page but not the keyboard focus. This means screen readers may not start reading at the main content. We plan to fix this.
  • Screen readers run “(opens in new tab)” on from the link text. We plan to add a space so it’s read clearly.
  • In our forms, screen readers read some things twice or read out too much. For example, the box listing your errors is read twice, and moving to the next page reads out the whole page. We plan to fix this.