Accessibility Statement
We want anyone to be able to read this site and reach us through it, whatever they use to browse. This page says what we have done, what we know is not perfect, and how to tell us when something gets in your way.
1. The standard we build to
We aim to meet WCAG 2.2 Level AA — the Web Content Accessibility Guidelines published by the W3C, and the level most public sector and procurement requirements reference.
We say aim deliberately. We have not commissioned an independent audit of this site, so we are not claiming certified conformance. What follows is an honest account of the work done and the gaps we are aware of.
2. What we have done
The site works without JavaScript
Every page renders completely with scripts blocked or failed. Content is in the HTML, not assembled in the browser. The contact form still submits and returns a confirmation page. Scripts add convenience — a mobile menu, one-open-at-a-time questions, live figures on the status page — and never gate the content.
Keyboard
Everything interactive can be reached and operated by keyboard. A Skip to content link is the first thing you reach on every page, so you are not forced through the navigation each time. Focus is always visible: a two-pixel outline in our accent green, offset from the element. Opening the mobile menu moves focus into it, traps focus while it is open, closes on Escape, and returns focus to the button you came from.
Structure and screen readers
Pages use real landmarks — header, navigation, main, footer — and a single
logical heading order. Navigation regions are labelled, so a screen reader can
tell the primary menu from the footer's service links. The current page is
marked with aria-current. Common questions use the browser's own
disclosure element rather than a scripted imitation, so they behave the way your
assistive technology already expects.
Forms
Every field has a real label, joined to it properly. Error messages are tied to
their field, so a screen reader reads the problem with the field rather than
stranding it elsewhere on the page. Invalid fields are marked
aria-invalid, and the form's status is announced in a live region
as it changes. Errors say what to do — "Enter a valid email address" — rather
than only that something is wrong, and colour is never the only signal.
Colour and contrast
Every text and background pairing in the palette has been measured against the WCAG contrast formula, and all of them meet or exceed AA. The lowest is 4.99:1 for error text, against a 4.5:1 requirement; body text runs to 17:1. Status is never conveyed by colour alone — every state also carries a word, such as OPERATIONAL or MAINTENANCE.
Motion
The site has some ambient movement: a scanning line on the home page panel, figures that tick on the status page, sections that fade in as you scroll. If your system is set to reduce motion, all of it stops — animations, scroll easing, and the status page's live updating. Nothing flashes, and nothing moves faster than three times per second.
Zoom and small screens
Text is set in relative units and reflows to 400% zoom without loss of content or horizontal scrolling. Layouts are fluid rather than fixed, so the site works from a narrow phone up. Nothing depends on hover, and touch targets on small screens are at least 44 by 44 pixels.
Images
Photographs that carry meaning have descriptive alternative text. Decorative images and the chart shapes are hidden from assistive technology so they are not announced as noise; the numbers those charts illustrate are present as text beside them.
3. Known limitations
We would rather list these than pretend they are not there:
- Status page sparklines. The small trend charts are exposed as decorative. The current value of each metric is read out as text, but the shape of the trend over time is not available non-visually. We consider the numbers to be the substance and the shape to be illustration, but it is a real gap for anyone who would rather have the trend described.
- Live updating figures. The status page refreshes its numbers every few seconds. These are not announced, deliberately — announcing them would be constant interruption. If your system requests reduced motion, the updating stops entirely and the figures hold still.
- No independent audit. Our testing is our own. We have not had a third party assess the site, and we have not tested with every combination of browser and assistive technology.
- The Client Portal is separate. support.portnoc.net is a different system on different infrastructure and is not covered by this statement.
4. How this was tested
During development the site was checked with keyboard-only navigation, with JavaScript disabled entirely, at viewport widths from 390 to 1440 pixels, with reduced-motion preferences active, and by calculating the contrast ratio of every colour pairing in the palette rather than eyeballing it.
This is self-assessment, not certification. If you use assistive technology and something here does not work, your report is more valuable than another round of our own testing — please send it.
5. Tell us if something breaks
If any part of this site is difficult or impossible for you to use, we want to know. Email support@portnoc.net or call +1 920 442 5522.
It helps if you can tell us:
- the page you were on;
- what you were trying to do;
- what happened instead;
- your browser and any assistive technology, if you know it.
We aim to acknowledge within two business days and to tell you what we intend to do about it. If we cannot fix something quickly, we will say so and offer another way to get what you needed.
6. Reaching us another way
The contact form is not the only route. If it does not work for you, or you would simply rather not use it, everything on this site can be done by phone or email:
- Phone: +1 920 442 5522 — you will reach a person, not a queue.
- Email: sales@portnoc.net for new enquiries, support@portnoc.net for existing clients.
- Post: the address below.
We will provide information from this site in another format on request, at no charge.