Accessibility Statement

1.1 Our target

WebNuvexa aims for conformance with the Web Content Accessibility Guidelines (WCAG) 2.1 at Level AA for the public website at webnuvexa.com, including the service pages, the contact and quote forms, the blog, and the legal pages.

1.2 Three honest qualifications

• Aim is not certify. This is a self-assessment, not an audit by an independent accessibility conformance auditor. WebNuvexa holds no accessibility certification and is not a registered accessibility auditor. Nobody has independently verified this page.
• Conformance is per page, not per site. WCAG conformance attaches to a specific page or component at a specific moment. A site-wide claim covers every page including future ones, which is not something any organisation can honestly make. Judge any individual page you are reading.
• Target conformance is achievable; full conformance is not yet claimed. Because of the limitations in section 4, we do not claim full conformance with WCAG 2.1 AA across the site today.

1.3 Why we bother

Accessibility is not a marketing benefit, and it is not a favour we do for particular people. Excluding people is the normal outcome of not designing for them. Rough figures from published research consistently put the proportion of people with a disability somewhere near one in six, and that figure rises sharply with age — so an ageing audience is, arithmetically, a more accessible one.

Practically: a site that works with a keyboard, a screen reader and reduced motion also works in bright sunlight, on a cheap phone, on a slow connection, in a noisy room, for someone with a broken hand, and for anyone whose browser has a preference they have forgotten to turn off. Building for the edge cases builds for everybody.

2.1 In scope

• All pages served from webnuvexa.com.
• The shared layout: navigation, footer and page furniture.
• The contact form, the request-a-quote form and the call-to-action form.
• The blog and blog posts.
• The seven legal pages, including this one.
• The CSS and JavaScript used to render them.

2.2 Out of scope

• Systems we build for clients. A software product built for a client has its own requirements, its own users and its own assistive technology matrix. Accessibility is specified per project in the relevant statement of work — typically against a stated WCAG level, plus testing with the client’s actual users. This statement says nothing about the accessibility of any client deliverable.
• Third-party content. If you follow a link to another website, that site’s accessibility is its owner’s responsibility. See the Legal Disclaimer.
• Embedded third-party content. There currently is none on this site, which is itself a deliberate accessibility decision — see section 3.7.
• The administrative area. /admin/ is an internal tool behind authentication, not part of the public site, and is not covered by this statement.

3.1 Structure and semantics

• One <h1> per page. Each page has a single top-level heading, and content is organised beneath <h2> and <h3> without skipping levels.
• Landmarks. A single <main id="main-content"> wraps the page content, inside a <nav> element at the top and a <footer> at the bottom. Screen reader users can navigate by landmark rather than by guessing.
• Real elements, not styled divs. Headings are headings, lists are lists, links are links. The legal pages use <table> with caption and scope="col" / scope="row" for tabular data, and <time datetime> for dates, so the information survives without CSS.
• Language declared. The document is marked <html lang="en">, so a screen reader uses an English voice rather than guessing at pronunciation.
• Meaning never carried by colour alone. Status text such as “All systems operational” is accompanied by the text itself, not conveyed by the colour of a dot.

3.2 Keyboard access

• A skip link. The first focusable element on every page is “Skip to content”, positioned off-screen until focused and then moved into view. It jumps past the navigation directly to #main-content.
• Everything that is a link or a button is reachable and operable by keyboard. Focus is never trapped. There is no keyboard shortcut that duplicates a mouse-only interaction.
• The mobile menu toggle is a real <button> with an accessible name and an aria-expanded state that updates as the menu opens and closes.
• No keyboard trap and no custom focus hijacking. We do not intercept focus in any way, which keeps behaviour predictable for switch users, voice control users and anyone whose browser has its own focus shortcuts.

3.3 Focus visibility

Form inputs and textareas have an explicit focus style: the accent border colour changes and a glow appears. Links, buttons and internal navigation anchors are never suppressed — no rule sets outline: none on them — so the browser’s own focus indicator is shown. On these legal pages, in-page links additionally have a high-contrast 2px focus ring defined for the legal-card and table-of-contents styles.

See limitation 4.3 in section 4.3: we rely on the default indicator for most elements, and on some browser and platform combinations that indicator is low contrast against a dark theme.

3.4 Respecting prefers-reduced-motion

The site’s stylesheet contains a prefers-reduced-motion: reduce block that:

• Makes scroll-reveal content fully visible and static — so content is never left invisible because an animation never ran. This matters more than it sounds: an element animating in but never becoming visible would make the page unreadable, not merely unpolished.
• Switches smooth scrolling off in favour of instant jumps.
• Reduces all animation and transition durations to a fraction of a millisecond, which disables the terminal cursor blink, the loading dots, the pulsing status dot and every hover transition site-wide.

The site’s JavaScript separately checks that same media query before running the animated glitch effect on the hero title, so that effect is skipped for people who have asked for reduced motion rather than merely being shortened.

3.5 Colour contrast

The palette is dark, which makes contrast easy to get right if it is actually measured rather than eyeballed. Measured against the page background #0A0A0F:

Text is not resized by this site; the layout uses relative and fluid units and does not disable browser zoom. Users can increase text size, zoom the page or override colours in their own browser, and the layout continues to reflow.

3.6 Forms

• Every input has a visible, programmatically bound label. Each field uses <label for="..."> pointing at the control’s id, so the field has a real accessible name. Placeholder text is a hint, never the label.
• Required fields are marked with the HTML required attribute, not by visual styling alone.
• Error and success messages are announced. Validation errors are output in a container with role="alert" so assistive technology announces them when they appear; success is output with role="status" in a polite live region.
• The honeypot field is hidden from assistive technology. The bot-trap input is wrapped in an aria-hidden container, moved off-screen, and given tabindex="-1" so it cannot receive focus from the keyboard.
• Validation is server-side. Inputs are validated again on the server with parameterised queries; the form deliberately does not rely on client-side validation as a security or correctness control.
• Autofill-friendly input types are used, so browser and assistive-technology autofill can fill name and email fields.

3.7 Images, icons and media

• There are no raster images to describe. This site uses no <img> elements. All iconography is inline SVG, which means no layout shift, no separate image request, and no dependency on a third party image host.
• No content is carried by an image alone. Every icon sits alongside a text heading or label, so nothing is lost when an image is not rendered.
• No text inside images. Nothing needs translation or reading aloud, because there are none.
• No embedded third-party media. No video players, audio players, live chat widgets, maps, social embeds or CAPTCHA challenges are embedded from another company’s domain. Each of those is a common source of unlabelled controls, keyboard traps and tracking, and none is needed here.
• No flashing content. Nothing on this site flashes more than three times per second.

3.8 Progressive enhancement

All content on this site is rendered on the server. JavaScript adds scroll animations, a mobile menu toggle and a decorative typing effect; it is not required to read any page, follow any link, or understand any content. If JavaScript is disabled or fails to load, the site still works.

That is a deliberate design decision and it is worth its own sentence, because it is also a performance, privacy and resilience win: the site is usable on a slow connection, on an old device, with scripts blocked, and for users whose browsers or network filters break third-party and first-party script alike.

4.1 The services dropdown cannot be opened with a keyboard

Severity: significant. Status: open.

The desktop “Services” menu reveals its panel on :hover and :focus-within. Because the trigger is a plain link to the services section rather than a control, and because the panel is set to visibility: hidden until hovered, the roughly fifty service pages listed in that panel are not reachable by keyboard. A screen reader will not announce them, and a keyboard user cannot tab into them. The menu is also hidden below 900px viewport width, so small-screen keyboard users have the same problem.

Why it is not fixed yet: the navigation markup and its stylesheet are shared, framework-level files that this page does not own and that must not be edited casually. A correct fix — a real <button> trigger with aria-expanded, aria-controls, Escape-to-close and a focus-managed panel — changes the navigation component for the entire site and needs proper keyboard testing rather than a quick patch.

Workaround for you: every service page is also listed in the site footer, and all pages are reachable through the sitemap. Neither route depends on this menu.

4.2 Inline SVG icons have no accessible name

Severity: moderate. Status: open.

Icons are rendered as inline <svg> elements with neither an aria-hidden="true" attribute nor an embedded <title>. A screen reader may therefore announce them as an unlabelled graphic or skip over them unpredictably, producing occasional noise in the reading order.

Impact is limited but not zero. Every icon is accompanied by a visible text heading or label, so no information is lost — the problem is verbosity in the reading order, not missing content. Icons used decoratively alongside text should be marked aria-hidden="true"; icons that convey meaning on their own would need a title.

4.3 Focus indicators rely on the browser default, which is low contrast on a dark theme

Severity: moderate. Status: open.

Form inputs have a deliberate, high-contrast focus style. Almost nothing else does: links, buttons and navigation rely on the user agent’s default focus ring, because no rule removes it. That is better than suppressing it, but the common default is a thin ring in a colour chosen against a light background, and several of those defaults fall below the 3:1 contrast that WCAG 2.1 Success Criterion 1.4.11 requires for non-text indicators — particularly in older browser and operating system combinations.

Why it is not fixed yet: the relevant stylesheets are the shared design-system files. A global focus style is a small change with a site- wide effect on visual design, and it should be made once, properly, rather than patched into individual pages.

4.4 Borders and control outlines do not meet non-text contrast

Severity: minor to moderate. Status: open.

The standard border colour #1E1E2E against the page background #0A0A0F measures roughly 1.2:1, well below the 3:1 that Success Criterion 1.4.11 requires for the visual boundary of a user interface component. In practice this affects:

• The boundary of input fields, which is currently the main cue distinguishing an input from the surrounding panel.
• Cards, panels and the callout boxes on these pages, where the border is decorative rather than load-bearing.

Mitigation, not a fix: every form field also has a visible text label immediately above it, so the field is identified without relying on its border. The decorative use of low-contrast borders — the intended appearance of the design — is not a functional problem. A functional border on an interactive control should be raised to 3:1, and that change belongs in the shared stylesheet.

4.5 Small nav index numbers and placeholder text sit below AA contrast

Severity: minor. Status: open.

The two-digit numbers beside navigation items are rendered at 60% opacity, which brings their contrast to roughly 4.4:1 against the page background — just under the 4.5:1 required for text this small. Form placeholder text is rendered at 50% opacity of the muted colour, roughly 2.2:1.

Placeholder text is the less serious of the two. Placeholders are supplementary hints; the accessible name of every field is the visible label bound to it, and WCAG does not require a placeholder to meet contrast requirements. The nav index numbers are genuine text and should be brought up to full opacity. Both changes belong in the shared stylesheet.

4.6 Form fields have no autocomplete hints, and errors are not tied to specific fields

Severity: minor. Status: open.

• Autocomplete. Form fields do not carry autocomplete attributes, so assistive technology cannot recognise fields whose purpose is known in advance and offer them separately in its own autofill interface. This is Success Criterion 1.3.5 (Identify Input Purpose) and it is a real, if secondary, usability cost for people whose typing is slow, painful or imprecise.
• Error association. Validation errors appear in a correctly announced role="alert" region, but individual error messages are not bound to their field with aria-describedby, and fields are not marked aria-invalid. A screen reader user hears that something is wrong but is not told which field, and must hunt for it.
• Grouping. Related fields are not wrapped in <fieldset> with a <legend>, so a group of controls has no accessible group name.

These are in the shared contact form component, not in individual pages, so they need to be fixed once there and will then apply everywhere the form is used.

4.7 Things that are not limitations but might look like them

• The dark terminal aesthetic. A monospace, dark, developer- tool visual style is unusual for a marketing site. Some people find it striking; some find dense monospace body text harder to read at length, and people with some forms of dyslexia or low vision can find high-contrast monospace harder than a proportional face. Text on this site is deliberately readable in terms of contrast and size — the earlier measurements above apply — but the aesthetic is a choice, and we are not going to pretend every preference is satisfied by it.
• Long legal pages. These documents are long because they are substantive. Every one has a linked table of contents and anchor headings so you can navigate directly rather than scrolling. The long-form prose on them is set in the proportional sans-serif stack, not in monospace, for exactly this reason.
• No user-style control. There is no control on the site to change font size, contrast or spacing, as some public-sector accessibility regulations require. The practical equivalents are built into every browser and operating system — zoom, minimum font size, forced colours, reader modes, and the reduced-motion and contrast preferences described in sections 3.4 and 3.5. If you need a site-provided adjustment control, ask for one; we would rather build it than argue about it.

5.1 Method

This statement was produced by a self-assessment: not yet confirmed: how the accessibility self-assessment was carried out. It was not performed by an independent accessibility conformance auditor, and it has not been verified by one. It has not been validated with disabled users, which is the step that most reliably finds real barriers and which almost no self-assessment performs.

Assistive technology actually exercised during the assessment: not yet confirmed: assistive technology and browser combinations tested. If no combinations were tested with real assistive technology, that is what this page should say, and it does not claim otherwise.

5.2 Basis for the findings

The findings in sections 3 and 4 were obtained by reading the site’s source code and stylesheet — the markup contract in the header, the navigation and footer components, the design-system stylesheet, the supplementary navigation stylesheet, and the site’s JavaScript — together with contrast ratios computed from the actual palette values rather than estimated by eye.

That is a legitimate way to identify problems that are structural, and it is how the limitations above were found. It is not a substitute for testing with real assistive technology, which is how problems that depend on screen reader behaviour, browser quirks, AT bugs and individual user configuration are found. We would expect an independent audit to find things we have not listed here.

5.3 Cadence and ownership

This statement is reviewed at least once every 12 months, and on any change to the shared layout, the navigation, the design-system stylesheet or the form components, since those changes affect every page at once. The reviewer is the responsible developer for the front end, with the product owner accountable for the published statement.

The date at the top of this page is the date the assessment was carried out, not a date on which someone checked that the statement still exists.

5.4 Client work

Accessibility requirements for the software we build for clients are agreed per project in the relevant statement of work, normally against a named WCAG version and level, with testing against the client’s own users and devices before launch. We do not claim that client deliverables meet any particular level unless it is contractually specified and has been tested for that project.

6.1 The standard we target

WebNuvexa targets WCAG 2.1 Level AA. WCAG 2.1 was the current W3C Recommendation when this assessment was carried out. WCAG 2.2 extends it, and we will assess against WCAG 2.2 at the next annual review. Anyone reading this statement after that date should expect the version to have moved on.

WCAG has three levels — A, AA and AAA. AA is the level most public-sector accessibility regulations and most procurement processes reference. AAA includes requirements that cannot be satisfied for every page of every kind of site, and we do not target it.

6.2 What a claim of conformance would require

A claim of conformance means that every success criterion that applies to the page has been satisfied, and that “conforms” is used accurately. Because section 4 records open limitations, we do not claim full conformance with WCAG 2.1 AA today.

We also do not describe ourselves as “accessible” in the absolute and as though the word ended the conversation. It did not: it started one.

6.3 What we will not claim

• We hold no accessibility certification and no accessibility accreditation.
• We are not a registered accessibility auditor and cannot issue a conformance report for another organisation.
• We have not been audited by an independent conformance auditor.
• We do not hold VPATs, ACRs or Section 508 or EN 301 549 conformance claims for this site.
• Nothing on this site should be treated as evidence of any of the above.

Where a procurement process requires an Accessibility Conformance Report, a VPAT or an independent audit, ask us and we will tell you honestly whether we can supply it. If we cannot, we will say so before you rely on us, not afterwards.

7.1 How to report

Email hello@webnuvexa.com with the subject line “Accessibility issue”, or send it to hello@webnuvexa.com if that channel is better monitored. You can also use the form at the foot of this page. You do not need to use any particular assistive technology to report an issue, and you do not need to prove it with evidence.

It helps to include:

• the page URL and, where relevant, the section heading;
• what you were trying to do;
• what happened instead;
• the browser, operating system and assistive technology or settings involved, if you know them;
• whether it stops you using the site entirely, or only makes part of it harder.

If you cannot send an email — that is often the situation on an inaccessible site — ask someone you trust to relay the report, or use the contact form, which is on this page.

7.2 What happens next

We acknowledge accessibility reports within 3 working days and give a substantive response, with an assessment and a decision on what will happen, within 15 working days. These are targets rather than guarantees, but they are the standard we are aiming at and we will tell you plainly if we are missing one.

Where we fix something, we will say so and, with your permission, say what it was so that others can check. Where we are not going to fix it, we will say that too, explain why, and tell you what alternative route exists. A clear “no, here is why” is more useful to you than silence.

7.3 We do not retaliate

Reporting a barrier, or complaining about it publicly, will never affect how we deal with you, and never affects whether we work with you. Good-faith accessibility reports are welcome whether or not you are a client, and we will not treat a report as a commercial opportunity. See also the Acceptable Use Policy, section 6.2.

8.1 Talk to us first

Tell us first. We would rather fix a barrier than be directed to fix one, and a conversation resolves the large majority of reports directly. Use the route in section 7, and escalate internally if it is not resolved.

8.2 Your right to complain

Nothing in this statement or in these terms takes away your right to complain to a regulator. Where the law gives you that right, you may use it, and doing so will not affect your relationship with us.

The bodies that handle accessibility complaints depend on where you are and whether you are making a complaint as a consumer or under an equality law. For not yet confirmed: the country of establishment the relevant body is not yet confirmed: regulatory or enforcement body. Elsewhere, the body for your country is the one with jurisdiction over you, and it will know that itself — you do not need to work it out before you complain.

• Consumers in the UK can escalate to the relevant industry or sector ombudsman, and equality issues to the Equality and Human Rights Commission.
• Consumers in the EU can contact a national equality or consumer body, and complaints about a public body can go to that body’s own national authority.
• In the United States, complaints about a private business are generally made to the relevant state attorney general or to the US Department of Justice; complaints about a federal government service go to that agency’s own enforcement office.

Get the name and route right for your jurisdiction before you use them; we have deliberately not guessed at a specific regulator name.

8.3 If we fail repeatedly

If we miss a commitment, fail to fix a barrier we have acknowledged, or fall materially below this statement’s target, that is a real failure on our part and you are entitled to say so. Escalate it in writing, refer it to a named decision-maker, and use the complaints route in the Terms of Service, section 11, where the dispute process and the governing law are set out.

Turn your browser’s own accessibility features on

• Reduced motion. System settings, or your browser’s own setting, tells the site to remove animation. Honoured today; see section 3.4.
• Increased or forced contrast. Windows High Contrast and macOS Increase Contrast substitute their own palette. The site’s low-contrast decorative borders become invisible under forced colours, which is a fair trade for everything else becoming readable.
• Minimum font size and page zoom to 200% or more. Layout reflows rather than clipping.
• Reader mode, which strips the styling and presents the underlying text. Because every page is server-rendered, there is always a readable text version underneath the design.
• Disable JavaScript. Nothing on this site requires it to read content.

If a particular page is giving you trouble

Every legal page carries a linked table of contents, so you can go directly to the section you need instead of scrolling through everything before it. The //-prefixed section labels in the design are visible text, not decoration you have to see past.

Alternatives to a browser

A browser is not the only way to read this site. Everything published here is also available in structured data — each page carries schema.org metadata describing its content, which tools, aggregators and some assistive technologies can read directly.

• Publisher: not yet confirmed: the registered legal entity name, established in not yet confirmed: the country of establishment
• Accessibility reports: hello@webnuvexa.com — subject line “Accessibility issue”
• Alternative channel: hello@webnuvexa.com
• Security reports: see the Acceptable Use Policy, section 7
• Personal data requests: see the Privacy Policy, section 8

If a correction is needed on this page itself — a limitation that has since been fixed, or a new one we should be recording — tell us. An out-of-date accessibility statement is its own accessibility problem.