Hiddlins (“Hiddlins”, “we”, “us” or “our”) wants everyone to be able to use hiddlins.com, whatever their abilities and however they access the web: with a screen reader, a keyboard, voice control, magnification, a switch device or simply a small phone screen in bright sunlight. Accessibility is part of how we build websites for our clients, and we hold our own website to the same standard. This statement explains what we have done, where we know we fall short, and how you can tell us about a barrier. Last updated: October 14, 2026.
Our commitment#
We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA. WCAG is published by the World Wide Web Consortium (W3C) and is the internationally recognised standard for web accessibility. It is referenced by many accessibility laws and standards around the world. You can read an overview of WCAG on the W3C Web Accessibility Initiative website.
WCAG is organised around four principles. Content should be:
- Perceivable: information can be presented in ways people can perceive, for example with text alternatives for images and sufficient colour contrast;
- Operable: every function works with a keyboard and other input methods, and people have enough time and control;
- Understandable: text is readable, behaviour is predictable, and forms help people avoid and correct mistakes; and
- Robust: content works reliably with current and future browsers and assistive technologies.
Accessibility is not a one-off project. We treat it as an ongoing practice: new pages, articles and features are checked before they go live, and we revisit existing content as the website evolves. For a practical introduction to these principles, see our article WCAG 2.2 for Small Businesses.
Conformance status#
WCAG defines three conformance statuses: fully conformant, partially conformant and non-conformant. We consider this website partially conformant with WCAG 2.2 Level AA. This means that the content we design and build ourselves is intended to meet the standard, but some parts of the website, mainly components supplied by third parties, may not yet fully conform. These are described in Known limitations below.
This assessment is based on our own testing, described in Assessment approach. It has not been certified by an independent third party.
Measures we have taken#
We build accessibility into the foundations of the website rather than adding it at the end. Key measures include the following.
Semantic HTML and structure#
- Pages use semantic HTML elements, such as
header,nav,main,article,asideandfooter, so that assistive technologies can identify page regions and users can jump between them. - Each page has a single main heading and a logical heading hierarchy, so that screen reader users can navigate by headings and understand how content is organised.
- Lists, tables and quotations use the correct elements. Data tables have header cells so that relationships between rows and columns are announced.
- Each page has a descriptive, unique title, and the page language is declared so that screen readers use the correct pronunciation.
- We use ARIA attributes sparingly and only where native HTML cannot express the required meaning, following the principle that no ARIA is better than incorrect ARIA.
We explain why this matters in our article on semantic HTML for SEO and accessibility.
Keyboard navigation and focus#
- Skip link. A “Skip to content” link is the first focusable element on every page, letting keyboard and screen reader users bypass the header and navigation.
- All interactive elements, including menus, buttons, links, form fields, the cart and the pricing calculator, can be reached and operated with a keyboard alone, in a logical order.
- Focus indicators are clearly visible, with sufficient contrast against the background, and are never removed without an equally visible replacement.
- We aim to ensure that focused elements are not hidden behind sticky headers or other overlays (WCAG 2.2 success criterion 2.4.11, Focus Not Obscured).
- Menus and dialogs can be closed with the Escape key, and focus returns to a sensible place when they close.
- There are no keyboard traps.
Colour and contrast#
- Body text and interface text are designed to meet a contrast ratio of at least 4.5:1 against their background, and large text at least 3:1 (WCAG 1.4.3).
- Icons, form field borders and focus indicators are designed to meet at least 3:1 against adjacent colours (WCAG 1.4.11).
- Colour is never the only means of conveying information. Links in body text are underlined, and form errors are described in text, not only shown in red.
- Where the website offers light and dark appearances, both are designed to meet the same contrast requirements.
Motion and animation#
- We respect the
prefers-reduced-motionsetting in your operating system or browser. When it is enabled, decorative animations, including animated background effects and transitions, are removed or reduced to simple fades. - No content flashes more than three times per second.
- Decorative animation does not convey essential information, and it does not interfere with reading or navigating the page.
Images and media#
- Informative images have text alternatives (
alttext) that describe their content or purpose. - Decorative images use empty
altattributes so that screen readers skip them. - Charts and diagrams that convey data are accompanied by a text explanation or the underlying data.
- If we publish video content, we will provide captions and, where needed, a transcript.
Forms#
- Every field in our contact form and checkout has a visible, programmatically associated label.
- Required fields are indicated in text, not by colour or an asterisk alone.
- Error messages explain what went wrong and how to fix it, and are announced to screen reader users.
- Fields that collect personal information use appropriate
autocompleteattributes, so that browsers and assistive technologies can fill them in (WCAG 1.3.5). - We avoid asking you to re-enter information you have already provided in the same process (WCAG 3.3.7, Redundant Entry).
- Logging in to a customer account does not require solving a cognitive puzzle, and password managers and copy-and-paste are supported (WCAG 3.3.8, Accessible Authentication).
Layout, text and touch targets#
- The layout is responsive and works at widths down to 320 CSS pixels without horizontal scrolling (WCAG 1.4.10, Reflow).
- Text can be resized up to 200% without loss of content or function, and the layout tolerates custom text spacing settings.
- Interactive targets, such as buttons and links in menus, are designed to be at least 24 by 24 CSS pixels or adequately spaced (WCAG 2.5.8, Target Size Minimum).
- No function requires dragging; where a control could be dragged, a single-pointer alternative is available (WCAG 2.5.7, Dragging Movements).
- Our contact details and help options appear in the same place on every page (WCAG 3.2.6, Consistent Help).
- Body text uses a readable size and line length, and we write in plain language wherever we can.
Performance as accessibility#
A fast, lightweight website is more usable for everyone, especially people on older devices, slow connections or assistive technologies that struggle with heavy pages. We keep scripts to a minimum, avoid unnecessary third-party code, and monitor Core Web Vitals, as described in our Core Web Vitals guide.
Known limitations#
Despite our efforts, some parts of the website may not yet be fully accessible. We are open about these so that you can plan around them and so that we can track our progress.
| Area | Possible issue | What we are doing |
|---|---|---|
| Cookie consent banner (CookieYes) | The banner is a third-party component. Focus management, the order in which its controls are announced, or the labelling of its toggles may not always be optimal with every screen reader. | We configure the banner for accessibility where options allow, test it with a keyboard and screen reader, and report issues to the vendor. The “Cookie settings” footer link reopens it at any time. |
| WooCommerce cart and checkout | Some dynamic updates, such as cart totals refreshing or certain validation messages, may not always be announced to screen reader users. | We test the checkout with each WooCommerce update and add live-region announcements where we can do so safely. |
| Payment provider fields | Card payment fields are embedded from our payment provider in a secure frame that we cannot modify. | We choose providers with documented accessibility support. If you cannot complete payment, contact us and we will arrange an alternative, such as an emailed invoice. |
| Contact form (Contact Form 7) | Some plugin-generated validation and spam-protection behaviour may be less clear than the rest of the site. | We have customised labels and messages and keep testing after plugin updates. You can always email us at hello@hiddlins.com instead. |
| Security checks (Wordfence) | In rare cases, our security software may show a block or verification page that is less accessible than the main website. | If you are blocked or challenged unexpectedly, please email us and we will investigate. |
| Embedded third-party content | Occasional embeds, such as videos or code demonstrations, depend on the provider’s accessibility. | We provide a text summary or link alongside embedded content wherever possible. |
| Older blog articles and code samples | Older content may contain images with less descriptive alternative text, or code blocks that are harder to navigate with assistive technology. | We review older articles as we update them, prioritising the most visited pages. |
If any of these limitations prevents you from using a part of the website, please contact us. We will provide the information or service you need in another way, such as by email or a call.
Compatibility with browsers and assistive technology#
The website is designed to work with recent versions of major browsers, including Chrome, Firefox, Safari and Edge, on desktop and mobile. It is designed to be compatible with commonly used assistive technologies, including:
- screen readers such as NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android;
- screen magnification and browser zoom;
- speech recognition software; and
- keyboard-only and switch navigation.
The website relies on HTML, CSS and JavaScript, together with WAI-ARIA where needed. Core content remains readable if JavaScript fails to load, although interactive features such as the pricing calculator and cart updates require JavaScript.
Assessment approach#
We assess the accessibility of this website through self-evaluation, combining automated and manual methods. Automated tools catch a share of issues quickly, but many accessibility problems can only be found by a person, so manual testing is central to our approach.
| Method | What it covers | When |
|---|---|---|
| Automated scanning | Common issues such as missing alt text, low contrast, missing labels and invalid ARIA | During development and before each release of templates or features |
| Keyboard testing | Focus order, visible focus, skip link, menus, dialogs, forms and checkout without a mouse | For every new template or interactive feature |
| Screen reader testing | Headings, landmarks, link text, form labels, error messages and dynamic updates | For key templates and user journeys, such as contact and checkout |
| Zoom, reflow and text spacing | Layout at 200% and 400% zoom, narrow viewports and custom text spacing | For every new template |
| Reduced motion and contrast review | Behaviour with reduced motion enabled; contrast of text, icons and focus states | When design or colours change |
| Content review | Alt text, heading structure, link text and plain language in new articles | Before each article is published |
We re-test after significant updates to WordPress, WooCommerce, our theme or our plugins, and we aim to review the website as a whole at least once a year.
Feedback and reporting a barrier#
We welcome your feedback on the accessibility of this website. If you encounter a barrier, find content you cannot access, or have a suggestion, please tell us. You do not need to know which WCAG criterion is involved; describing what happened is enough.
To help us respond quickly, it is useful (but not required) to include:
- the web address (URL) of the page;
- a description of the problem and what you were trying to do;
- the browser and device you were using; and
- any assistive technology you were using, such as a screen reader and its version.
How to contact us#
- Email: hello@hiddlins.com
- Our contact form
What happens next#
- We aim to acknowledge your message within 2 business days.
- We will investigate and, where possible, give you the information you need in an accessible format straight away.
- We aim to tell you within 10 business days how and when we plan to fix the issue. Simple fixes are often made within days; issues in third-party components may take longer because they depend on the vendor.
If you need information from this website in a different format, such as plain text or large print, please ask and we will do our best to provide it.
If you are not satisfied with our response#
If you are not happy with how we have responded to your feedback, please let us know and we will review your concern again in full and explain our reasoning. Depending on where you live, you may also be able to contact a national equality, human rights or accessibility enforcement body. We would welcome the opportunity to put things right first.
Accessibility in our client work#
We apply the same practices when building websites for clients, from landing pages to WooCommerce stores and custom web applications. Accessible websites reach more people, tend to perform better in search, and reduce legal risk. If you would like your website reviewed or built to WCAG 2.2 AA, see our services or get in touch. Please note that this statement relates only to our own website; each client website has its own owner and accessibility statement.
Changes to this statement#
We review this statement whenever we make significant changes to the website and at least once a year. The “last updated” date at the top of this page shows when it was last revised.
Contact us#
Accessibility is a shared effort, and your feedback helps us improve. If you have any questions about this statement or the accessibility of our website, please contact us at hello@hiddlins.com or through our contact page.
Hiddlins