Entrazure
Our target
entrazure.com is built to meet the Web Content Accessibility Guidelines version 2.1 at level AA. That is the target we design and code against, and it is the bar we will fix against when someone tells us we have missed it.
We are not claiming conformance. A conformance claim means an audit against every success criterion on every page type, and we have not commissioned one. Saying “WCAG 2.1 AA compliant” without that audit would be exactly the kind of unverified claim we refuse to publish anywhere else on this site.
What we do on purpose
Real HTML. Every page is generated from Markdown into semantic markup. Headings describe the
outline of the page rather than its typography, navigation is a nav element containing real
links, and every link goes somewhere without JavaScript. A screen reader gets the same structure
a sighted reader sees.
Keyboard first. Everything reachable with a mouse is reachable with a keyboard, in an order that follows the page. Focus is visible against both the light and the navy sections. The navigation menu opens on click as well as hover, closes on Escape, and returns focus to the control that opened it. Nothing traps you.
Contrast checked where it is hard. The navy sections are the risky ones, so they are the ones we measure. Body text and interface text meet the 4.5 to 1 ratio; large headings meet 3 to 1. We do not use the light cyan as text on white, because it fails, and no amount of it looking good changes that.
Motion respected. The animated backgrounds and tab transitions stop when your system asks for reduced motion. Nothing on the site flashes, auto-plays, or moves without you starting it.
Text that resizes. Type is set in relative units. Zoom to 200 percent and the layout reflows rather than clipping. There is no horizontal scroll on a small screen.
Labeled inputs and honest errors. Every form field has a visible label attached to it. Error messages say what is wrong in words, not by turning a border red.
Language declared. Each page declares its language, English or French, so a screen reader pronounces it correctly, and the two versions point at each other.
What we know is not resolved
We are honest about the gaps we already know about, and we would rather list them than wait to be told.
- No independent audit has been performed. Our testing is internal: automated checks in the build, keyboard walkthroughs, and screen reader spot checks. That catches a lot, and it does not catch everything.
- Long technical pages rely on a sticky table of contents. It works with a keyboard, but on a narrow screen the reading order is longer than we would like.
- Diagrams are built as markup rather than images so their text is selectable and readable, and the most complex of them may still be hard to follow linearly. If one of them blocks you, tell us and we will write the description out.
- Some documents we link to are produced by Microsoft and other third parties. We do not control their accessibility.
Report a barrier
If any part of this site stops you doing something, write to contact@entrazure.com with “accessibility” in the subject line, or use the contact page.
It helps if you tell us the page address, what you were trying to do, and what got in the way. The browser, operating system and assistive technology you use are useful, and not required. We do not need you to diagnose the problem.
We acknowledge within one business day. We will tell you what we found, when we can fix it, and what we can do in the meantime. If the fix is going to take a while, we will get you the information another way rather than leaving you to wait for a deployment.
Formats on request
Anything published here can be supplied in another format. Ask and we will send it as plain text, as a structured document, or read out on a call.
The work we deliver
This statement covers our website. Accessibility inside a client environment is decided by what that engagement asks for, and it is worth putting in the scope rather than in a retrofit. Ask us about it before the build, not after.