Accessibility Statement

NS360 (Netsphere360) builds this website to the Web Content Accessibility Guidelines (WCAG) 2.2, Level AA, published by the W3C in October 2023. Level AA is the middle of WCAG’s three levels and the one most widely used as a benchmark. It asks a site to work for people who use screen readers, keyboards, magnification or voice control, and it meets some of the needs of people who are deaf or hard of hearing, have cognitive disabilities, or are sensitive to motion.

We treat accessibility as part of what “done” means, not as a check at the end. A page is not ready to publish until it has passed the checks described under How we test.

This statement covers every page on this website, including the contact form. It also sets out the standard we apply to the products we build for clients.

WCAG in four words

WCAG is built on four principles:

Perceivable

People can take in the content, whether they read it, hear it or enlarge it.

Operable

People can use every control with a keyboard, mouse, touch or voice.

Understandable

Pages behave predictably and help people avoid and correct mistakes.

Robust

The code follows web standards, so browsers and assistive technology can read it reliably.

Most of WCAG 2.2 carries over from earlier versions, so a site that meets 2.2 at Level AA also meets the widely used WCAG 2.1 AA. These are the requirements 2.2 added at Levels A and AA.

Structure

• Pages use semantic HTML: real headings in order, lists, tables, buttons and links, and landmarks for the header, navigation, main content and footer.
• Each page has one main heading and its own title. The page language is set to English, so screen readers pronounce it correctly.
• All text is part of the page’s HTML, delivered from our server. Nothing you need to read is drawn inside the 3D scene or available only through animation.
• Our trust pages, like this one, open with a short summary and give every section a one-sentence version in plain language.

Keyboard and focus

• You can reach and use every link, button and form control with a keyboard, in an order that follows the page.
• A skip link is the first thing you reach when you press Tab. It jumps past the navigation to the main content.
• Keyboard focus is always visible: a clear outline in red-orange on light backgrounds and brand orange on dark ones.
• On small screens, the full-screen menu has its own Close button. While the menu is open, focus stays inside it. Escape also closes it, and focus returns to the menu button.

Color and contrast

• We check every text color against its background: at least 4.5:1 for normal text and 3:1 for large text, as Level AA requires. Focus outlines, and the borders that show where each form field is, are held to at least 3:1.
• On our light backgrounds, our brand orange is decorative only. It measures under 2.5:1 there, too low for text, so we never use it as a text color or to mark the edge or state of a control. It goes into the logo, the planet and illustration.
• On light backgrounds, links, focus outlines and active states use a darker red-orange that passes AA. In our dark sections the two swap: brand orange passes there (about 7.7:1) and the red-orange is too dark to read, so links and focus outlines use brand orange.
• Color is never the only signal. Errors are written out in words, and links within paragraphs are underlined.

Forms

• Every field on the contact form has a visible label that stays in place while you type. Placeholder text is only ever a hint.
• Only five things are required: your name, your work email, at least one option describing what you need, a message of at least 20 characters, and your agreement to the privacy notice. There is no phone field.
• Required fields are marked in words, not by color alone.
• If something needs fixing, the error is written next to the field and linked to it, so screen readers read the two together. When you submit, a message at the top of the form is announced to screen readers.
• The options describing what you need are ordinary checkboxes in a labeled group, so they work with a keyboard and with screen readers.
• The name and email fields tell your browser what they are for, so autofill can complete them.

Text, zoom and images

• You can resize text to 200% with your browser’s zoom without losing content or functions. Layouts reflow to a single column on narrow screens and at high zoom, so you do not have to scroll sideways to read.
• Informative images have text alternatives that say what they show. Purely decorative images are hidden from screen readers.
• If we publish video or audio, it will come with captions and a transcript.

The site uses some motion: smooth scrolling, a few sections that pin in place and animate as you scroll, and a live 3D scene of the planet from our logo. Motion can cause dizziness, nausea or distraction, so all of it responds to the reduce motion setting on your device, which browsers pass to websites as prefers-reduced-motion.

Level AA does not require us to switch off animation that is triggered by scrolling. That is Success Criterion 2.3.3, at Level AAA. We do it anyway.

To turn the setting on, look in your device’s accessibility settings: Reduce motion on macOS and iOS, Animation effects (switched off) on Windows 11, and Remove animations on Android.

About the 3D scene

• It is decorative. It contains no text, links or information, and it is hidden from screen readers and other assistive technology.
• It is designed to move slowly and never to flash.
• A Pause button next to the scene stops it at any time.
• It loads only after the page’s content. It stays off on devices that ask to save data or report limited memory or processing power, and in browsers that cannot draw it smoothly. A still image takes its place.
• It pauses when it scrolls out of view or when you switch to another tab.
• If you turn on reduced motion while the scene is running, reload the page and the still image takes its place.

No single tool can tell you a site is accessible. Automated tools find some kinds of problem quickly and reliably, and miss many others. So we pair them with checks done by people.

While we build

• We run automated checks with axe, an open-source accessibility testing engine, on each page template while we build it.
• We fix what it reports, or record why a result is a false positive, before the change goes live. Results it flags for human review, we check by hand.
• Whenever we add or change a color, we check it against the contrast ratios above.

Before release

• A keyboard-only pass through each page template: every control reachable, focus visible, nothing that traps you.
• Screen reader checks with VoiceOver on macOS and iOS, covering headings, landmarks, link names, image descriptions and form errors.
• Zoom to 200% and 400%, and screen widths down to 320 CSS pixels, checking that nothing is cut off or overlaps.
• A pass with reduced motion turned on, to confirm that animation stops and all content is still there.

This is a self-assessment. No independent third party has audited this site. If we commission an audit, we will say so here and give its date.

We would rather tell you about a gap than have you find it. These are the ones we know about.

Text inside product screenshots

Some screenshots in our Work section show product interfaces with menus, labels and sample text. Each has a short text alternative that says what it shows, and the surrounding copy explains the points that matter, but we do not transcribe every word in the image. The colors inside a screenshot are that product’s own, not our palette. If you need the full detail of a screenshot, ask and we will describe it to you.

Other websites

Links to other websites take you to services we do not run. Their accessibility is outside our control and outside this statement.

We review this list every time we test the site, and remove items once they are fixed.

The same standard applies to what we build for clients. WCAG 2.2 Level AA is our default floor for the web products we build. For native mobile and desktop apps, we apply the same principles through each platform’s own accessibility features.

• Accessibility is in scope from discovery and design, not added at the end. Colors, type sizes and components in a design system are checked against AA before screens are built from them.
• Components are built with semantic markup, keyboard support and visible focus, and tested with automated checks and screen readers as part of normal delivery.
• If a requested design, feature or third-party component would fall below AA, we say so early and propose an alternative.
• If a client decides to ship with a known gap, we record the decision and the gap in writing, so it stays visible and can be planned for.
• Where a product must meet a particular standard or law in its market, or a higher level for specific criteria, we agree that in the contract and plan for it.

We never present our own testing as an independent audit. If you need one, or a formal conformance report, we will help you scope it with a specialist and plan the fixes it recommends as agreed work. Our Approach page explains where this fits into delivery.

If you cannot use part of this site, or it is harder than it should be, please tell us through the form on our Contact page. You do not need to use technical terms. In the form, choose Not sure yet and start your message with “Accessibility”.

It helps if you include:

• the page address, or what you were looking at;
• what you were trying to do, and what happened;
• if you are comfortable sharing it, the device, browser and any assistive technology you use.

You do not need to tell us about any disability or health condition. If you mention one, we use it only to deal with your report and do not keep it longer than we need to.

We aim to reply within 5 business days (Monday to Friday, excluding public holidays in India). We will tell you what we plan to do and when. If a fix will take time, we will get you the information you need another way in the meantime, for example as plain text by email.

We use what you send only to look into and answer your report. Our Privacy Policy explains how we handle personal data and how long we keep messages.

Standard

WCAG 2.2, Level AA

Status

Partially conformant, by our own assessment. We aim for every page we write to meet Level AA. The known limitations above, including third-party content, are why we do not claim full conformance.

How we assess it

Self-assessment by our own team, using the automated and manual checks described above. No third-party audit.

Technologies relied on

HTML, CSS and WAI-ARIA for every page; the text of each page is in its HTML. The contact form also needs JavaScript. The smooth scrolling, animation and 3D scene use JavaScript too, but they are optional.

Designed for

Recent versions of Chrome, Edge, Firefox and Safari, on desktop and mobile.

Last assessed

Not yet. The first full assessment of the finished site is still to be done, and we will add its date here.

Next review

Within 12 months of the first full assessment, and sooner after any major change to the site.

Accessibility is ongoing work. As the site changes, we test again and update this page, and the version history records each change.